| 00:05.45 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 01:08.54 | jarray52 | louipc: What would be the primary limitations of using brl-cad for designing something like a car, motorcycle, diesel generator, or satellite? |
| 01:10.56 | jarray52 | And the primary advantages over AutoCad or solidworks? |
| 01:59.46 | starseeker | makes a note to read this in more detail: http://www.linuxjournal.com/article/3687 |
| 02:02.42 | louipc | jarray52: brl-cad has no dimensioning feature, or 2d drafting ability, no step export, and step import is still in development |
| 02:05.41 | louipc | jarray52: one of brl-cad's main purposes was for ballistics analysis for the military, so it doesn't have the regular CAD stuff you usually expect |
| 02:08.42 | louipc | jarray52: not even a shaded view for solids in editing.. you have to explicitly render the view |
| 02:09.32 | jarray52 | What are its primary advantages? |
| 02:10.34 | louipc | seems more geared for making 'true' solids |
| 02:10.36 | jarray52 | over something like solidworks |
| 02:10.40 | jarray52 | or autocad |
| 02:10.43 | jarray52 | other than cost |
| 02:11.04 | louipc | it's not really in the same realm at the moment |
| 02:11.17 | louipc | or ever? dunno |
| 02:12.29 | louipc | depends on what you want to do I guess |
| 02:12.37 | jarray52 | in quality or purpose? |
| 02:12.45 | louipc | purpose |
| 02:13.01 | jarray52 | it can export .dxf |
| 02:13.25 | louipc | think so |
| 02:54.54 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.13) | |
| 03:23.19 | *** join/#brlcad abhi2011 (~chatzilla@117.200.86.180) | |
| 03:38.20 | brlcad | jarray52: the primary limitation is usability -- like any cad system, there's a significant learning curve |
| 03:38.30 | brlcad | and ours is particularly steep |
| 03:40.39 | brlcad | jarray52: BRL-CAD's strength is for assisting with a variety of engineering analysis work, generally niche fields that have varied/unpredicatble requirements |
| 03:42.41 | jarray52 | brlcad: After getting past the learning curve, is the system nicely useable? |
| 03:42.53 | brlcad | for basic design/modeling, BRL-CAD is good once you get up the learning curve but it is a different command-line driven approach that usually favors people with scripting skills |
| 03:43.21 | brlcad | it's usable, been used for production analysis work in the DoD for several decades |
| 03:43.29 | jarray52 | I'm a python/c++ programmer with little CAD experience. So, I really like the idea of scripting oriented CAD. |
| 03:43.54 | brlcad | but make no mistake, that learning curve is steep -- brl-cad is huge with lots of features and lots of ways to get tasks done ;) |
| 03:44.02 | jarray52 | Is the engineering analysis work limited to ballistics/electromagnetics. |
| 03:44.06 | jarray52 | ? |
| 03:44.36 | jarray52 | brlcad: Is the learning curve steeper than learning a programming language like C++ for the first time? |
| 03:44.45 | brlcad | not really, and we don't even include that analysis logic directly within BRL-CAD -- hooks are provided to the analysis codes |
| 03:44.58 | brlcad | oh heavens no |
| 03:45.15 | jarray52 | what about learning python for the first time? |
| 03:46.03 | brlcad | the biggest issue is probably that it's not a discoverable system, you'll only learn by going through tutorials (for which there are EXTENSIVE tutorials across a range of topics), reading man pages, and modeling, modeling, modeling |
| 03:46.41 | brlcad | I don't think so, but that's a bit of a skewed question to ask... |
| 03:46.59 | jarray52 | Once mastered, does it have lots of features not found in programs like autocad, catia, and pro engineer? |
| 03:47.11 | brlcad | is it harder to learn being a professional woodworker or a professional mechanic? |
| 03:47.24 | jarray52 | sorry... |
| 03:47.27 | brlcad | they both can take decades to master ;) |
| 03:47.40 | jarray52 | the questions were misguided... |
| 03:47.57 | brlcad | it's fine, just don't want you to have unrealistic expectations |
| 03:48.27 | brlcad | there are some features BRL-CAD provides that are arguably better or more powerful than features in commercial CAD systems |
| 03:48.38 | jarray52 | such as? |
| 03:49.15 | brlcad | we are one of the very best at loading superbly complex models with minimal memory and processing, and still being able to render/analyse those models more quickly than anyone else |
| 03:49.51 | brlcad | notorious for being able to open models that bring Pro/E, NX, and others to their knees on a powerful workstation |
| 03:50.24 | brlcad | our other flexibility is in the breadth of flexibility, lots and lots of tools that you can chain together to get a job done |
| 03:51.47 | jarray52 | Just so I understand... this type of thing could for example be used to model an aircraft carrier with planes taking off and landing or a space station with multiple space vehicles docking, leaving, and so on. |
| 03:52.27 | jarray52 | Is that the type of specialized thing that brlcad would do well? |
| 03:52.28 | brlcad | if we were an operating system code, we'd be more like bsd userland tools and a bsd microkernel -- not the pretty shiny layer on top ala osx or the facades of gnome/gtk, windows, etc |
| 03:52.53 | starseeker | Our graphical interactions are very primitive by modern standards |
| 03:52.54 | jarray52 | microkernel? |
| 03:53.47 | starseeker | jarray52: more like using a (relatively) small amount of information to represent complex geometry - that's a specialty |
| 03:53.48 | jarray52 | Would this be a good tool to design and model a diesel or car engine? |
| 03:54.12 | jarray52 | with internal moving parts and all... |
| 03:54.22 | brlcad | jarray52: nevermind the microkernel analogy if it's unfamiliar, the linux kernel works as an analogy too -- we're (presently) more of a kernel, not an easy-to-use distribution like ubuntu or fedora |
| 03:54.22 | starseeker | we don't currently simlulate part interactions |
| 03:54.43 | brlcad | jarray52: you can model just about anything -- it's what you do with the model once you're done |
| 03:54.45 | starseeker | (some nifty work going on to integrate bullet, but that's in the experimental stages) |
| 03:55.12 | brlcad | so yeah, you could model up an entire aircraft carrier down to every nut bolt and wire, no problem |
| 03:55.15 | starseeker | jarray52: if you're going to create a model in BRL-CAD, you'll need to use constructive solid geometry |
| 03:55.20 | brlcad | generate renderings and visualizations, no problem |
| 03:56.02 | brlcad | but then if you want blueprints -- we can provide the hidden line blueprint-style image, but not with dimensions or labels annotated |
| 03:56.33 | brlcad | or if you want an animation, no problem .. but we don't (yet) provide physics simulations with contact constraints |
| 03:57.16 | jarray52 | starseeker: I don't understand what you mean by "we don't currently simulate part interactions". |
| 03:57.25 | brlcad | jarray52: take a look at the introduction to mged tutorial and scripting tutorial on the website, they'll give you a good idea of some things possible (along with the image gallery) |
| 03:57.29 | jarray52 | in light of the other comments made by yourself and brlcad. |
| 03:57.46 | starseeker | jarray52: if you model two gears and try to have one turn the other, for example |
| 03:58.00 | starseeker | we don't do that right now |
| 03:58.18 | brlcad | jarray52: http://brlcad.org/wiki/Documentation <-- #2 |
| 03:58.34 | brlcad | and http://brlcad.org/wiki/SGI_Cube for a very brief scripting example |
| 03:59.12 | jarray52 | starseeker: Does any cad program allow one gear to turn another? |
| 03:59.30 | brlcad | yeah, the big five all have that ability |
| 04:00.02 | jarray52 | brlcad: big five=CATIA, Pro/Engineer, NX, AutoCAD, xxx? |
| 04:00.09 | brlcad | you have to specify a lot of crap to make it happen automagically, but it's "possible" |
| 04:00.13 | brlcad | solidworks |
| 04:00.18 | jarray52 | right |
| 04:00.56 | brlcad | technically, it's sorta possible in brl-cad, but that's functionality that was last used more than 10 years ago |
| 04:01.17 | brlcad | we have someone working on a new system now, way way cooler and easier to use .. but just getting started :) |
| 04:01.53 | jarray52 | brlcad: So, the user has to specify the motion for animations along with contact constraints, but it is possible, right? |
| 04:03.06 | brlcad | jarray52: this may be more familiar with your python background .. it's a perl modeling example, but could do almost exactly the same with python: http://brlcad.org/wiki/Spiral |
| 04:03.49 | brlcad | jarray52: well like I said -- it's a new system and I wouldn't recommend trying to use the old system unless you're willing to help debug |
| 04:04.31 | brlcad | until then, you basically have to manually put geometry where you want it, motion is just basic model transformations |
| 04:05.06 | brlcad | ala claymation, just not quite as tedious |
| 04:05.21 | brlcad | (because you can script it all) |
| 04:05.58 | jarray52 | brlcad: That's actually very cool because an external program could be doing calculations and transformations and moving the parts. |
| 04:06.05 | brlcad | louipc: ah, interesting, I'd tried .1 and it found some new issues .. .2 finds more .. someone must be actively boosting up those detection abilities |
| 04:06.41 | brlcad | jarray52: that's actually the intent (and you can see how we start to "fit in" with external analysis codes) |
| 04:07.59 | jarray52 | brlcad: And, once the model and external analysis code work the way they are intended to work(in theory at least), the parts can be exported to .dxf and manufactured. |
| 04:08.55 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 04:09.28 | jarray52 | brlcad: I think you have me sold on BRL-CAD now. |
| 04:10.09 | starseeker | jarray52: the thing that will probably feel strangest about BRL-CAD in its current form is the lack of 3D shaded displays - we visualize only with wireframes or raytracing now, unless you happen to have a triangle based model |
| 04:10.53 | jarray52 | Raytracing with wireframes only? |
| 04:11.05 | starseeker | no, interactive display with wireframe only |
| 04:11.13 | starseeker | raytrace is when it gets pretty :-) |
| 04:11.23 | brlcad | interactive as in grab the mouse and spin the model around -- wireframe only |
| 04:11.34 | brlcad | hit the render button, though, and you get your pretty shaded picture |
| 04:12.04 | jarray52 | brlcad: That's acceptable. |
| 04:12.33 | jarray52 | brlcad: At the end of the day, one can sell the pretty picture to a boss or investors. |
| 04:12.39 | jarray52 | :) |
| 04:12.41 | brlcad | nods :) |
| 04:12.52 | brlcad | you've seen the gallery yes? |
| 04:12.58 | jarray52 | brlcad: Yes. |
| 04:13.06 | jarray52 | brlcad: And read through some of the manuals. |
| 04:13.19 | brlcad | so that's a pretty wide range of different types of projects and different ability levels |
| 04:13.21 | jarray52 | brlcad: I'm a CAD/CAE/CAM newbie. |
| 04:13.27 | jarray52 | brlcad: Yes. |
| 04:13.33 | brlcad | all the better, less to unlearn :) |
| 04:14.20 | starseeker | folks expecting a Blender-like GUI are in for a shock, but there's a lot of power under the hood |
| 04:14.56 | jarray52 | starseeker: I prefer scripted model development. |
| 04:15.07 | starseeker | longer term we're planning to get there, but there's a *lot* of foundational work that has to come before the pretty interactive 3d |
| 04:15.10 | starseeker | :-) |
| 04:15.18 | starseeker | jarray52: then you're in the right place :-) |
| 04:15.38 | jarray52 | In theory, scripted development should be faster, right? |
| 04:15.55 | starseeker | for some classes of problems, absolutely |
| 04:15.59 | jarray52 | probably depends on the designer. |
| 04:16.10 | jarray52 | starseeker: Yes. Most definitely. |
| 04:16.13 | brlcad | very much so |
| 04:16.18 | starseeker | if you have data you can feed the script, that's where scripting shines |
| 04:16.31 | brlcad | if the designer doesn't know how to write a script, that's a pretty huge hurdle ;) |
| 04:16.37 | starseeker | jarray52: if you really want to go to town, there are C apis for model generation |
| 04:17.05 | brlcad | jarray52: a case study example that may be of interest: http://brlcad.org/wiki/Ronja |
| 04:17.06 | starseeker | that's what the tire tools does, for example - tire dimensions in, tire geometry out. |
| 04:17.10 | starseeker | procedural modeling |
| 04:18.04 | brlcad | jarray52: that's an individual that learned to model in less than a day, spent maybe a week modeling his design, then another week writing scripts to generate various images and animations: http://ronja.twibright.com/3d/ |
| 04:19.15 | brlcad | not the best example of good modeling practices in his models, but a decent showcase of what is possible within just a few days time |
| 04:19.40 | starseeker | oh, this one is kinda fun for "what's possible" http://more.brlcad.org/model/basic-impeller |
| 04:20.13 | brlcad | that'd be a fun one to feed to an arylic printer |
| 04:20.27 | starseeker | reflects we really should get that default GPL license label off the more.brlcad.org listings... |
| 04:21.45 | jarray52 | brlcad: BRL-CAD would probably be a good tool for modelling a network of telephone or power transmission lines including the powerplant, right? |
| 04:21.59 | brlcad | sure |
| 04:22.17 | brlcad | starseeker: you going to close out and document sf bug #3435642 ? |
| 04:22.22 | brlcad | the obj export bug |
| 04:22.23 | starseeker | fun with the pipe primitive :-) |
| 04:22.33 | starseeker | brlcad: oh, right - he confirmed the fix, didn't he |
| 04:22.36 | jarray52 | brlcad: This would be the type of design for which BRL-CAD shines, right? |
| 04:23.50 | brlcad | yeah, there are only a few types of models that BRL-CAD is ill-suited for direct modeling (import is fine though) |
| 04:25.28 | brlcad | namely: soft bodies (e.g., human skin) and highly curved surfaces (e.g., some modern car bodies) |
| 04:26.47 | brlcad | objects that can be broken down into constituent primitives shapes can be directly modeled much easier |
| 04:27.17 | louipc | brlcad: http://louipc.mine.nu/brlcad/brlcad-7.20.4-1-x86_64-build.log |
| 04:27.39 | louipc | that's a full build log with my version of gcc if that interests you |
| 04:27.52 | louipc | strict=off |
| 04:31.45 | CIA-109 | BRL-CAD: 03brlcad * r47479 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: |
| 04:31.46 | CIA-109 | BRL-CAD: attempt a fix for a variety of gcc 4.6.2 strict compilation failures reported by |
| 04:31.46 | CIA-109 | BRL-CAD: louipc (irc). compiler was clever enough to figure out that 2d-arrays were |
| 04:31.46 | CIA-109 | BRL-CAD: getting passed around as pointers and getting later treated as 3d-arrays. |
| 04:32.03 | brlcad | louipc: thanks... but do you have an svn checkout? :) |
| 04:32.09 | louipc | yeah |
| 04:32.10 | CIA-109 | BRL-CAD: 03starseeker * r47480 10/brlcad/trunk/NEWS: |
| 04:32.10 | CIA-109 | BRL-CAD: obj export was producing facets that all shared the same number instead of |
| 04:32.10 | CIA-109 | BRL-CAD: pointing to the correct points - problem was very precisely identified by |
| 04:32.10 | CIA-109 | BRL-CAD: Christopher Pitts (down to the incorrect variable in the source file), so he |
| 04:32.10 | CIA-109 | BRL-CAD: gets credit for the fix - thanks\! |
| 04:32.26 | brlcad | line numbers will be askew and easier to verify if you can svn up while I fix |
| 04:32.40 | louipc | ok |
| 04:34.11 | brlcad | starseeker: cool, thx |
| 04:35.02 | brlcad | unrelared, r47471 seems wrong .. removed bu.h and pulled in a bunch of header foo it was using in the test client? |
| 04:35.19 | brlcad | presume you encountered some problem? |
| 04:35.44 | starseeker | the point of that client was to be totally self contained |
| 04:36.29 | brlcad | is ntohll required for something in the test client?? |
| 04:36.35 | brlcad | that seems .. wrong :) |
| 04:36.50 | starseeker | IIRC, Eric was using it to ensure network order when packing some stuff |
| 04:37.35 | starseeker | shrugs - I'm still doing remedial education at this point, I did that to ensure the build worked |
| 04:37.40 | brlcad | no problem |
| 04:37.45 | brlcad | it was more a curiosity |
| 04:37.55 | brlcad | it could frankly be a shell script making telnet calls |
| 04:38.33 | starseeker | in principle, sure - in practice I'm trying to at least *pretend* the goal is to be portable to Windows :-P |
| 04:38.42 | brlcad | but by "self contained" the main requirement is actually just not calling any gs/ge code |
| 04:38.47 | starseeker | right |
| 04:39.01 | brlcad | bu.h isn't in that category, so it's an impl detail |
| 04:39.31 | brlcad | it's the stuff in the geomcore checkout that should be avoided (for the indep test only of course) |
| 04:39.54 | starseeker | nods - I could have fixed the build logic too, but the logic ran "why's this failing - oh, that's supposed to be self-contained - huh it's just using that one feature - commit" |
| 04:39.54 | brlcad | either way, like I said -- more just a curiosity, carry on ;) |
| 04:40.18 | starseeker | resumes wallowing in ignorance :-P |
| 04:40.30 | starseeker | btw, welcome back |
| 04:41.25 | brlcad | it raised my "what?" radar simply because it fails DRY and that usually trumps |
| 04:41.39 | starseeker | ponders whether SCL should do as BRL-CAD does with version numbers... |
| 04:42.36 | brlcad | for a project that small, the version number could live in the top-level CMakeLists.txt file, maybe wrap in a macro if it's needed in multiple places but the built-in versioning hooks are probably sufficient |
| 04:43.08 | brlcad | we're more of a platform where that number is used all over the place in various ways |
| 04:43.11 | brlcad | scl not so much |
| 04:43.38 | starseeker | nods - that was my thought |
| 04:43.56 | starseeker | just do some .in files if they want it in headers |
| 04:44.51 | starseeker | s/Eric/Erik |
| 04:44.57 | starseeker | alright, bedtime |
| 04:47.09 | brlcad | hasta la pasta |
| 04:48.42 | louipc | oops? http://louipc.mine.nu/brlcad/brlcad-svn47480-build.log |
| 04:48.48 | jarray52 | brlcad: Thanks for answering my questions. |
| 04:49.11 | jarray52 | I want to thank starseeker and others as well. |
| 04:50.23 | louipc | thanks for being patient and sticking around ;) |
| 05:39.25 | jordisayol | brlcad: hasta la pasta!? |
| 05:41.11 | jarray52 | 8-) |
| 08:10.20 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 08:52.57 | *** join/#brlcad abhi2011 (~chatzilla@117.200.85.67) | |
| 09:07.51 | *** join/#brlcad hackrat (~packrator@c-98-209-146-133.hsd1.mi.comcast.net) | |
| 11:39.05 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.176) | |
| 12:45.29 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.88.176) | |
| 12:50.03 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.88.176) | |
| 13:27.18 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.176) | |
| 13:42.04 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 14:10.20 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.152) | |
| 14:22.24 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 14:34.32 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) | |
| 15:03.38 | CIA-109 | BRL-CAD: 03d_rossberg * r47481 10/rt^3/trunk/ (2 files in 2 dirs): |
| 15:03.39 | CIA-109 | BRL-CAD: method to get a simple facetized boundary-representation of a subtree |
| 15:03.39 | CIA-109 | BRL-CAD: it's a method of the database because not only one element is involved but the tree below the requested element |
| 15:09.48 | ``Erik | the GS "ping/pong" uses a network order uint64, so ntohll() was needed... personally, I think the protocol should evolve as a human readable ascii thing over the line (yes, so telnet can be used, and it can be easily debugged), then add a 'binary' command and mode down the road |
| 15:14.28 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:41.40 | brlcad | d_rossberg: not that it matters much, but "nmg" stands for n-manifold geometry |
| 15:42.07 | brlcad | the original paper was entitled non-manifold, but by the time it was implemented and announced, it became n-manifold |
| 15:48.35 | brlcad | of course, the generalized structure happens to support n-manifold surfaces as well as non-manifold vertices and edges (not sure about non-manifold faces) |
| 16:00.29 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.84.128) | |
| 16:02.07 | d_rossberg | these n-manifold vs. non-manifold sounds unfortunate, espaecially because it is still the original Weiler non-manifild |
| 16:02.51 | d_rossberg | including all its ballast |
| 16:03.23 | brlcad | it's mainly due to the audience perspective, though |
| 16:03.46 | brlcad | weiler was trying to solve the academic problem of how to model non-manifold entities |
| 16:04.17 | brlcad | the structure does that, even if the dominant use is for n-manifold surface boundaries |
| 16:05.18 | d_rossberg | i wouldn't mind to get rid of the burden |
| 16:05.23 | brlcad | from our users perspective, it should really just be called a "mesh" or "solid polygonal mesh" or similar :) |
| 16:05.50 | brlcad | burden? |
| 16:06.14 | d_rossberg | the model, region and lower dimensional things |
| 16:07.02 | brlcad | you mean implement a non-weiler polygonal mesh api or something else? :) |
| 16:07.17 | d_rossberg | all we really need is a single shell |
| 16:08.36 | d_rossberg | it looks like most of the algorothms using nmg can't handle models with multiple regions |
| 16:09.30 | brlcad | that's because they're all just copies of each other and the first guy was lazy |
| 16:09.34 | d_rossberg | these are relics of the original nmg CAD project |
| 16:09.48 | ``Erik | most assume an NMG is a single NMG region with a single NMG shell, iirc |
| 16:11.21 | brlcad | I don't believe the boolean evaluator used for E/ev is that limited |
| 16:11.58 | d_rossberg | and support of Euler operations would be nice |
| 16:13.27 | brlcad | if I have an rcc and subtract an arb8 from the middle, makes two shells -- you really don't want to create two single-shell nmg objects, you want just one named object with the two shells in it |
| 16:15.25 | d_rossberg | nmg_booltree_leaf_tess creates a new model for every primitive |
| 16:16.13 | brlcad | nmg supports most euler operations iirc |
| 16:16.37 | brlcad | perhaps not all |
| 16:22.28 | brlcad | creates a new model for each prim, but then pairwise extracts their (single) shell and performs the boolean |
| 16:22.53 | brlcad | the limitation is only on a single primitive that might have multiple shells (BoT, pnts, dsp, ..) |
| 16:24.14 | brlcad | otherwise, the boolean of two shells will result in n-shells |
| 16:28.14 | d_rossberg | a shell is a simple collection of faces, loops, edges and a vertex, there is no real restriction to a single connected volume |
| 16:28.24 | d_rossberg | however, i plan to write down my impress |
| 16:28.44 | d_rossberg | -ions and send them to the devel-list |
| 16:28.55 | d_rossberg | ... later |
| 16:29.54 | brlcad | well, no restriction other than that is the (current) definition of a shell :) |
| 16:32.31 | brlcad | that said, I do agree that there's no practical benefit that comes to mind for having models and regions (to a slightly lesser degree) |
| 16:33.49 | brlcad | there would be a purpose for regions and models if you could associate user-data (void*) to caller API |
| 16:34.58 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 16:35.42 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.93) | |
| 17:21.04 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.93) | |
| 18:22.46 | starseeker | hah, cool: http://code.google.com/p/libmv/ |
| 18:51.57 | ``Erik | was looking at that a while ago, have they actually been working on it? O.o seemed like a dead end at the time |
| 18:52.48 | CIA-109 | BRL-CAD: 03erikgreenwald * r47482 10/geomcore/trunk/tests/func/GE/GeometryEngineTest.cxx: fix usage typo |
| 19:00.53 | *** join/#brlcad merzo (~merzo@128-101-133-95.pool.ukrtel.net) | |
| 19:02.24 | *** join/#brlcad abhi2011_ (~chatzilla@117.200.80.170) | |
| 19:06.11 | brlcad | "BRLCAD" is a typo too |
| 19:06.32 | brlcad | dash merely in the wrong place |
| 19:59.25 | CIA-109 | BRL-CAD: 03brlcad * r47483 10/brlcad/trunk/ (5 files in 5 dirs): |
| 19:59.25 | CIA-109 | BRL-CAD: make the invoking wrapper batch scripts all set the PATH before running |
| 19:59.25 | CIA-109 | BRL-CAD: mged/archer/bwish/rtwizard so that tools invoked by commands can be found. |
| 19:59.25 | CIA-109 | BRL-CAD: untested, but should do the trick without requiring the user to have |
| 19:59.25 | CIA-109 | BRL-CAD: admin/profile rights to modify the PATH permanently. this is in response to a |
| 19:59.25 | CIA-109 | BRL-CAD: feature request from the dwayne kregel. |
| 20:13.25 | CIA-109 | BRL-CAD: 03brlcad * r47484 10/brlcad/trunk/ (4 files in 2 dirs): apply another tclscript update from carl g moore jr that reports what the input object names are that weren't combs and makes reid report the highest value set. |
| 20:20.56 | CIA-109 | BRL-CAD: 03brlcad * r47485 10/brlcad/trunk/TODO: document dwayne's detailed feature request for a geometry prep lintian command |
| 20:55.02 | CIA-109 | BRL-CAD: 03brlcad * r47486 10/brlcad/trunk/NEWS: |
| 20:55.02 | CIA-109 | BRL-CAD: daniel applied a fix in r47473 for a bug that was preventing the detection of V4 |
| 20:55.02 | CIA-109 | BRL-CAD: regions during raytrace. it looks like this is the same bug reported by chris |
| 20:55.02 | CIA-109 | BRL-CAD: pitts a couple weeks ago, which he'd traced down to db5_sync_attr_to_comb() |
| 20:55.02 | CIA-109 | BRL-CAD: wiping out the comb structure. |
| 21:02.47 | CIA-109 | BRL-CAD: 03brlcad * r47487 10/brlcad/trunk/NEWS: bob added the 'l'ist command to archer, which improves/fixes the 'g' grouping command |
| 21:08.45 | CIA-109 | BRL-CAD: 03brlcad * r47488 10/brlcad/trunk/AUTHORS: special thanks to chris pitts for his efforts to report, diagnose, and even help pinpoint where in the source code a problem was occurring. helped with v4 raytracing and obj export issue. |
| 21:11.02 | CIA-109 | BRL-CAD: 03brlcad * r47489 10/brlcad/trunk/AUTHORS: browder now belongs up in the code contributions section given all of the recent documentation efforts. |
| 22:53.22 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) | |
| 23:10.59 | CIA-109 | BRL-CAD: 03n_reed * r47490 10/brlcad/trunk/src/other/ (9 files in 2 dirs): adding sources for an experimental scanner-generator |
| 23:11.24 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 23:20.54 | *** join/#brlcad velociostrich (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |