| 00:07.03 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 00:09.34 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 00:42.06 | CIA-32 | BRL-CAD: 03brlcad * r35021 10/brlcad/trunk/src/libwdb/wdb.c: missed a commit.. have to initialize the ctrl head else bad things happen |
| 00:46.30 | CIA-32 | BRL-CAD: 03brlcad * r35022 10/brlcad/trunk/ (4 files in 4 dirs): |
| 00:46.32 | CIA-32 | BRL-CAD: deprecate the rather useless bu_fopen_uniq() .. would remove it given it's only |
| 00:46.34 | CIA-32 | BRL-CAD: in use in one place (dsp plot debug code), but don't know if anyone has relied |
| 00:46.36 | CIA-32 | BRL-CAD: on it. go ahead and schedule it for removal. update dsp to just use fopen |
| 00:46.38 | CIA-32 | BRL-CAD: instead. |
| 01:07.58 | CIA-32 | BRL-CAD: 03brlcad * r35023 10/brlcad/trunk/src/libbu/ (fopen_uniq.c image.c rb_extreme.c rb_internals.h): remove all calls to bu_exit(). shouldn't be used by library code even for fatal situations. use bu_bomb() instead or (better) cascade the failure up to the application level. |
| 01:23.27 | CIA-32 | BRL-CAD: 03brlcad * r35024 10/brlcad/trunk/src/librt/prep.c: wow, not only shouldn't librt be calling bu_exit, but prep should definitely not be calling it. failing to prep can be quite normal under some circumstances and the application needs to be able to know. |
| 01:27.48 | CIA-32 | BRL-CAD: 03brlcad * r35025 10/brlcad/trunk/src/librt/primitives/ebm/ebm.c: remove the outdated test driver application. better to stash test app in a separate file or proc-db or util or regress. |
| 01:28.27 | ``Erik | all ur bu_exit are belong to brlcad |
| 01:40.37 | CIA-32 | BRL-CAD: 03brlcad * r35026 10/brlcad/trunk/src/librt/primitives/ebm/ebm.c: mass consistency/ws/style/indent/comment cleanup |
| 01:53.55 | ``Erik | prep.c:1322: error: too many arguments to function 'bu_bomb' |
| 01:54.07 | ``Erik | assumes brlcad forgot to commit include/bu.h |
| 01:54.52 | ``Erik | prep.c:1771: error: incompatible types in assignment |
| 01:55.14 | ``Erik | point_t x; x = INFINITY; <-- ummm, no :) |
| 02:06.47 | CIA-32 | BRL-CAD: 03brlcad * r35027 10/brlcad/trunk/src/librt/prep.c: oops, unbreak the build and do major consistency cleanup on prep while we're at it. |
| 02:07.08 | brlcad | yeah, I noticed right away .. just took a while with the rest of the cleanup |
| 03:50.14 | yukonbob | hello, cadheads |
| 03:50.35 | ``Erik | ssshhhh |
| 03:55.56 | CIA-32 | BRL-CAD: 03brlcad * r35028 10/brlcad/trunk/src/proc-db/metaball.c: restructure in preparation for re-reading from the .g we just created so the metaballs can be combined together. |
| 03:57.18 | ``Erik | O.o |
| 03:57.28 | CIA-32 | BRL-CAD: 03brlcad * r35029 10/brlcad/trunk/TODO: make db_open modes be identical to fopen modes |
| 04:03.11 | yukonbob | minds ``Erik's scolding... |
| 04:03.41 | yukonbob | >.> |
| 04:03.46 | yukonbob | <.< |
| 04:04.56 | ``Erik | what scolding? heh |
| 04:15.59 | yukonbob | how's it going :) |
| 04:22.17 | yukonbob | thrashes his disk doing full table scan on /quereyy |
| 04:24.09 | CIA-32 | BRL-CAD: 03brlcad * r35030 10/brlcad/trunk/src/librt/db_lookup.c: save the callers of db_lookup from *having* to call db_dirbuild. since db_lookup is useless without building a directory, build it automatically if there are no records. |
| 04:26.04 | CIA-32 | BRL-CAD: 03brlcad * r35031 10/brlcad/trunk/src/librt/db_lookup.c: shoot, breaks the contract. db_lookup is const, db_dirbuild is not, so we're back to manual |
| 04:35.25 | yukonbob | has no love for opennurbs atm. |
| 04:35.25 | yukonbob | fails to build :P |
| 04:38.33 | *** join/#brlcad pacman87 (n=pacman87@bz.bzflag.bz) |
| 04:38.39 | *** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) |
| 05:50.59 | *** join/#brlcad alex_joni (n=alex_jon@emc/board-of-directors/alexjoni) |
| 05:55.25 | CIA-32 | BRL-CAD: 03brlcad * r35032 10/brlcad/trunk/src/proc-db/metaball.c: add the logic to load up the metaballs we added, and combine them manually into one megametaball via librt/libwdb routines. |
| 05:56.16 | brlcad | aaand that does it |
| 06:50.44 | Ralith | yay! |
| 07:28.23 | *** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch) |
| 09:05.43 | *** join/#brlcad madant (i=cb7baf0f@gateway/web/freenode/x-f3cb7d0826618484) |
| 09:40.53 | CIA-32 | BRL-CAD: 03Drlex 07http://brlcad.org * r1546 10/wiki/User:127_buy_nymphomax: |
| 09:42.22 | CIA-32 | BRL-CAD: 03Drlex 07http://brlcad.org * r1547 10/wiki/User:323_buy_depo_medrol: |
| 09:42.57 | _clock_ | *LOL* |
| 09:43.10 | CIA-32 | BRL-CAD: 03Drlex 07http://brlcad.org * r1548 10/wiki/User:765_buy_zyprexa: |
| 09:43.33 | madant | hates wiki spammers |
| 09:43.56 | CIA-32 | BRL-CAD: 03Drlex 07http://brlcad.org * r1549 10/wiki/User:900_buy_levitra: |
| 09:46.02 | CIA-32 | BRL-CAD: 03Drlex 07http://brlcad.org * r1550 10/wiki/User:552_buy_viagra: |
| 09:46.29 | CIA-32 | BRL-CAD: 03Drlex 07http://brlcad.org * r1551 10/wiki/User:976_buy_cleocin: |
| 09:49.20 | CIA-32 | BRL-CAD: 03Drlex 07http://brlcad.org * r1552 10/wiki/User:901_buy_5_htp: |
| 09:51.03 | CIA-32 | BRL-CAD: 03Drlex 07http://brlcad.org * r1553 10/wiki/User:180_buy_flonase: |
| 09:51.47 | CIA-32 | BRL-CAD: 03Drlex 07http://brlcad.org * r1554 10/wiki/User:391_buy_cialis: |
| 09:52.54 | louipc | woohoo |
| 09:53.26 | CIA-32 | BRL-CAD: 03Drlex 07http://brlcad.org * r1556 10/wiki/User_talk:526_buy_viagra: |
| 10:14.39 | *** join/#brlcad ``Erik (i=erik@c-69-140-109-104.hsd1.md.comcast.net) [NETSPLIT VICTIM] |
| 10:15.14 | *** join/#brlcad d-lo (n=claymore@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 10:15.14 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT VICTIM] |
| 10:15.14 | *** join/#brlcad indianlarry (n=indianla@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 10:15.14 | *** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl) [NETSPLIT VICTIM] |
| 10:15.14 | *** join/#brlcad CIA-32 (n=CIA@208.69.182.149) [NETSPLIT VICTIM] |
| 10:15.14 | *** join/#brlcad SWPadnos (n=Me@emc/developer/SWPadnos) [NETSPLIT VICTIM] |
| 10:15.14 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) [NETSPLIT VICTIM] |
| 10:15.14 | *** join/#brlcad roberthl (n=robert@silentflame/member/roberthl) [NETSPLIT VICTIM] |
| 10:15.14 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT VICTIM] |
| 10:15.14 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT VICTIM] |
| 10:15.43 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 10:15.43 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) [NETSPLIT VICTIM] |
| 10:15.43 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 10:29.45 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 10:29.45 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) [NETSPLIT VICTIM] |
| 10:29.45 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 10:50.18 | d-lo | Mernin all! |
| 10:50.33 | d-lo | *readreadread* |
| 11:02.30 | d-lo | 'Megametaball' That's got a nice ring to it. |
| 11:17.10 | *** join/#brlcad madant (i=cb7baf0f@gateway/web/freenode/session) |
| 11:27.33 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 11:33.56 | CIA-32 | BRL-CAD: 03davidloman * r35033 10/rt^3/trunk/src/ (13 files in 13 dirs): Adding more CMakeLists.txt files. Continuing cmake build system integration. |
| 13:18.38 | ``Erik | wow, g-stl on sphflake is a monster |
| 13:24.44 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) |
| 13:57.46 | *** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl) |
| 15:12.14 | CIA-32 | BRL-CAD: 03brlcad * r35034 10/brlcad/trunk/src/proc-db/metaball.c: add a slew of additional comments for the intended audience, make three metaballs of differing sizes so the field strength differences can be emphasized. clean up output formatting. |
| 16:02.01 | *** join/#brlcad mafm (n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) |
| 16:37.36 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 16:39.08 | CIA-32 | BRL-CAD: 03bob1961 * r35035 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added a wrapper for attr. Also added a checkpoint_olist method for creating multiple ledger entries for an action. |
| 16:54.10 | CIA-32 | BRL-CAD: 03brlcad * r35036 10/brlcad/trunk/BUGS: metaballs aren't fully rendering correctly. see the proc-db example to see the chewing pattern on grazing edges. |
| 16:55.25 | CIA-32 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Drlex]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 16:56.20 | CIA-32 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/delete: deleted "[[User talk:526 buy viagra]]": content was: '' (and the only contributor was '[[Special:Contributions/Drlex|Drlex]]') |
| 16:58.02 | *** join/#brlcad BigAToo1 (n=BigAToo@pool-96-230-124-218.sbndin.btas.verizon.net) |
| 17:50.48 | *** join/#brlcad docelic (n=docelic@78.134.195.197) |
| 17:52.19 | brlcad | Ralith: any progress today? |
| 17:52.29 | brlcad | still waiting to see that commit ;) |
| 17:52.44 | brlcad | jdoliner: how's it going on your end? |
| 17:53.16 | jdoliner | it's going, although things are getting more complicated than I was hoping |
| 17:53.22 | jdoliner | did you read my wiki post? |
| 17:55.57 | brlcad | yep |
| 17:57.12 | jdoliner | it's kind of a brute force solution |
| 17:57.46 | jdoliner | but it'll get the job done |
| 17:59.02 | ``Erik | does tk have a zomfg fast canvas? |
| 17:59.11 | brlcad | from the big picture perspective, what I'm most worried about is end result being a set of routines that work on a subset of polygonal mesh intersections .. as that is pretty much our nmg library (and there's no way you'll finish all possible situations in a summer) |
| 17:59.48 | brlcad | ``Erik: not really, but it's decent enough for most purposes -- depends on how many canvas objects you have and what rendering goes into it |
| 18:00.30 | jdoliner | what subset do you think they won't work on? |
| 18:01.23 | ``Erik | rgb blits |
| 18:01.25 | brlcad | much of that assumes clean numerics |
| 18:01.30 | ``Erik | think tk isst |
| 18:02.06 | brlcad | real world meshes are absolutely riddled with "errors" that you have to account for where there are floating point tolerance problems on micro and macro scale |
| 18:02.38 | brlcad | our nmg library does a phenomenal job and it only handles 99% or so |
| 18:02.53 | brlcad | more to the point of the project, though, is that polygonal meshes aren't the focus :) |
| 18:02.59 | brlcad | spline surface intersections are |
| 18:03.27 | jdoliner | so should I be working on spline surface intersections instead? |
| 18:04.01 | brlcad | well I presumed from what you've been saying that you've been approaching the mesh side to get a better handle on just how the data structures and logic works out |
| 18:04.05 | brlcad | yes? |
| 18:04.21 | brlcad | since polygonal meshes are certainly "easier" in many regards |
| 18:04.32 | jdoliner | well yes that's been part of it |
| 18:04.50 | brlcad | so that part is good/great/useful |
| 18:05.00 | jdoliner | I was also under the impression for a while though that we needed mesh mesh intersection |
| 18:05.13 | jdoliner | (brlcad src is a big place) |
| 18:05.15 | brlcad | just shouldn't be the whole project given we already have a library that does mesh/mesh intersections .. unless we're going to shift your project to making it even more robust ;) |
| 18:05.58 | brlcad | that was the nmg code I pointed you at in src/librt/primitives/nmg/nmg_*.c (nmg_bool.c and nmg_eval.c come to mind) |
| 18:06.28 | brlcad | the main difference there is that they use different data structures, a radial edge data structure |
| 18:06.38 | jdoliner | yes |
| 18:06.53 | jdoliner | our code diverges actually very quickly |
| 18:07.06 | jdoliner | can you tell me more about why nmg fails? |
| 18:07.09 | brlcad | high-level, though, they represent arbitrary polygons and will evaluate intersections of those |
| 18:07.18 | jdoliner | well when really |
| 18:07.59 | brlcad | nmg fails on a small subset of geometry mostly due to numerics and tolerance tracking problems |
| 18:08.29 | brlcad | consider three points on a line, perhaps vertices to three polygons o---o---o |
| 18:08.42 | jdoliner | k |
| 18:09.05 | brlcad | it's numerically actually completely ambiguous other than there being only one solution that results in topologically solid geometry |
| 18:09.34 | brlcad | so in the code, it attempts to determine if those vertices are the same or not, for example |
| 18:09.55 | brlcad | so it knows whether to collapse them (so we have solid geometry, critically important) or not |
| 18:10.27 | brlcad | say all three points are within some 'collapse' tolerance of each other, but not the two farthest |
| 18:11.00 | brlcad | if it collapses middle to left, it ends up with a dangling face; if it collpases middle to right, it ends up with a dangling face |
| 18:12.03 | jdoliner | i see |
| 18:12.06 | brlcad | it could collapse left to middle, but then if it collapses middle to right then that original point has drifted drastically from the original value (which can cascade problems) |
| 18:12.29 | brlcad | lifewise right to middle, middle to left, same problem |
| 18:12.50 | brlcad | that "point drift" problem happens all over the place in tiny tiny increments (at a minimum it occurs at the floating point tolerance level) |
| 18:13.52 | jdoliner | okay that would be a problem |
| 18:14.11 | jdoliner | but I have trouble imagining how their could be a real solution |
| 18:14.29 | jdoliner | like how could a system ever avoid this? |
| 18:14.45 | brlcad | there are lots of possible solutions, it just entails a fair bit of book keeping |
| 18:15.43 | brlcad | you either have to track your decisions and be able to back up (akin to a decision tree graph, have to be able to find other solutions) or you keep track of and accumulate error, not allowing error to grow beyond a certain amount |
| 18:17.36 | jdoliner | okay, so basically when we collapse we remember and then if we detect a dangling face or a similar error, we go back and say whoops that wasn't such a good idea afterall and undo it? |
| 18:27.40 | ``Erik | hrmph |
| 18:29.36 | jdoliner | Probably the most important questions is which does brlcad need more, a more robust mesh intersection system, or spline intersection, my inkling is that spline intersection is more needed. |
| 18:31.47 | ``Erik | I'd be apt to agree at this point |
| 18:32.41 | ``Erik | so hop to, boy, onward to spline evaluations :D |
| 18:33.36 | jdoliner | alright then, spline evaluations it is |
| 18:33.54 | indianlarry | the loop/trim logic should carry over to the spline work |
| 18:34.04 | jdoliner | yeah it certainly will |
| 18:34.27 | jdoliner | my work over the past 2 weeks has been with polylines |
| 18:34.30 | indianlarry | wait till you see the tolerance errors in the u.v space trim approximations |
| 18:34.41 | indianlarry | ;^) |
| 18:34.58 | jdoliner | k what code should I start reading? |
| 18:35.21 | jdoliner | ON_Nurbs objects seems like an obvious place to start |
| 18:35.55 | indianlarry | ON_Brep->ON_Surface->ON_Face |
| 18:36.52 | indianlarry | you'll find the trimming loops on the face's |
| 18:37.19 | jdoliner | alrighty |
| 18:43.18 | brlcad | both are needed, people would be just as happy if you made the nmg code tessellations more robust |
| 18:43.28 | brlcad | heck, some would be absolutely ecstatic :) |
| 18:43.48 | brlcad | but that wouldn't be best done by "starting over" .. you'd need to dig into the nmg code and make it more robust |
| 18:44.28 | brlcad | otherwise, original goal definitely is a hot need too, being able to evaluate two NURBS objects and give a resulting object sans booleans |
| 18:45.23 | brlcad | e.g. simple test case is two overlapping boxes unioned together, provide a resulting nurbs box (with or without trims) that is just one object with no boolean |
| 18:45.43 | brlcad | then try to get two spheres, similar situation, then sphere on box, etc |
| 18:46.33 | CIA-32 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:509 buy biaxin]] with an expiry time of infinite (account creation disabled): Spamming links to external sites |
| 18:46.49 | jdoliner | k I'll reshift my focus to that |
| 18:47.07 | CIA-32 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:900 buy glucotrol xl]] with an expiry time of infinite (account creation disabled): Spamming links to external sites |
| 18:47.07 | jdoliner | but I'll also take a look at the nmg tesselation at some point |
| 18:47.30 | CIA-32 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:494 buy lopressor]] with an expiry time of infinite (account creation disabled): Spamming links to external sites |
| 18:47.44 | jdoliner | ban hammer!!! |
| 18:48.30 | brlcad | jdoliner: I'd pick one or the other and run with it :) |
| 18:48.39 | brlcad | too much work to dabble in both :) |
| 18:49.03 | brlcad | given all your investment in mesh logic to date, you're probably just as well poised for either |
| 18:49.07 | brlcad | both have a major impact |
| 18:49.36 | jdoliner | k sounds sage |
| 18:49.54 | ``Erik | if topic contains '%buy%' do exec ipfw ... |
| 18:50.15 | jdoliner | then we'll just get spam to rent things ;P |
| 18:51.08 | brlcad | buy brl-cad! |
| 18:51.20 | ``Erik | if topic contains '%your mom%' ... |
| 18:51.22 | ``Erik | O:-) |
| 19:06.51 | CIA-32 | BRL-CAD: 03starseeker * r35037 10/brlcad/trunk/include/opennurbs_cleanup.h: Add distribute to the cleanup opennurbs code too. |
| 19:25.55 | brlcad | jdoliner: so you have an inclination as to which? |
| 19:27.16 | *** join/#brlcad elena (n=elena@89.136.118.141) |
| 19:31.37 | ``Erik | ja, /20.0 -> /200.0 gives better display results :/ |
| 19:35.43 | brlcad | cool, that's good actually |
| 19:35.51 | jdoliner | my inclination right now is toward spline intersection |
| 19:36.11 | brlcad | just a matter of making that tweak dynamic .. as opposed to an outright but that takes a while to hunt/fix ;) |
| 19:36.30 | brlcad | jdoliner: okay, then I'd say run down that way and don't look back :) |
| 19:36.53 | ``Erik | *hackhackhack* |
| 19:36.59 | brlcad | I would suggest starting with a high-level goal like i mentioned instead of low-level, just to have a simple test-driven goal |
| 19:37.07 | ``Erik | have a dynamic thing coded up, compiling now ot test |
| 19:37.32 | brlcad | like box/box intersection, find the result .. write a test harness and work towards getting that test harness working with all the behind-the-scene detail |
| 19:37.32 | ``Erik | all keepin' me from .g loading in isst, bastage |
| 19:37.53 | brlcad | :) |
| 19:38.11 | brlcad | well I know the sec dave or that dude try the sample code, they're going to see the bug :) |
| 19:38.28 | jdoliner | k sounds good boxes in brepcube are a good starting point |
| 19:38.32 | brlcad | already anticipate having to explain why mk_metaball() is going to crash for them :) |
| 19:38.36 | jdoliner | for wriiting the test |
| 19:39.11 | brlcad | yeah, or even starting with a .g that has two cubes already placed with an operation |
| 19:39.19 | brlcad | then dealing with them at the code level |
| 19:39.34 | brlcad | just so you don't get caught up in all the nasty that is involved in manually stitching together brep objects |
| 19:40.45 | jdoliner | k, what can I read about the .g format, I'm a bit unfamiliar with how to put operators in it |
| 20:09.47 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) |
| 20:16.13 | CIA-32 | BRL-CAD: 03erikgreenwald * r35038 10/brlcad/trunk/ (include/rtgeom.h src/librt/primitives/metaball/metaball.c): fix "scalloping" bug by making step size depend on the smallest control point as well as the bounding sphere radius. Cache initial and final step sizes in the internal representation. |
| 20:28.42 | *** join/#brlcad Patmcc19 (n=chatzill@71-223-27-160.phnx.qwest.net) |
| 20:36.51 | CIA-32 | BRL-CAD: 03starseeker * r35039 10/brlcad/trunk/ (6 files in 3 dirs): Plugging along with opennurbs_ext cleanup - compiles now but trimming isn't working. |
| 21:45.46 | brlcad | hello Patmcc19 |
| 21:58.22 | CIA-32 | BRL-CAD: 03r_weiss * r35040 10/brlcad/trunk/src/libged/make_pnts.c: added deallocation of internal structure when exit on error for make_pnts command |
| 22:18.19 | CIA-32 | BRL-CAD: 03brlcad * r35041 10/brlcad/trunk/TODO: add support to rt to have a viewsize/scale/zoom option so you don't have to provide a -M view script just to get a bigger zoom size |
| 22:19.33 | brlcad | hehe, ``Erik .. you made it a lot worse :) |
| 22:21.38 | ``Erik | ermmmm, it looked fine on the 2 things you provided? |
| 22:22.14 | brlcad | try running the metaballs tool and render meatballs.s |
| 22:22.37 | ``Erik | might have to tweak the formula or numbers for finding the 2 step sizes |
| 22:22.51 | ``Erik | ups and installs on his lappie |
| 22:23.07 | brlcad | yeah, there are like no anamolies on the middle, but now misses a solid 30% of the model |
| 22:23.25 | ``Erik | hm |
| 22:23.25 | brlcad | oh, ya know what.. I think I had a mod in there too |
| 22:23.30 | brlcad | hold on, lemme make sure it's not me |
| 22:23.39 | ``Erik | if anything, it'd be missing stuff in the middle, not towards th eedges |
| 22:24.38 | brlcad | hm, yeah, not just my mod |
| 22:24.52 | brlcad | pretty interesting pattern |
| 22:26.25 | ``Erik | it rendered the 'make' primitive as well as the two in the .g file you provided just fine when I committed :/ |
| 22:26.37 | ``Erik | *shrug* compiling away, touched rtgeom.h heh |
| 22:26.44 | brlcad | http://brlcad.org/tmp/mbug/mbug2.png |
| 22:26.49 | ``Erik | looks like something common to mged got touched, too |
| 22:27.31 | ``Erik | 404 |
| 22:28.03 | brlcad | refresh |
| 22:28.25 | ``Erik | neat |
| 22:46.23 | *** join/#brlcad Witch_Doc (n=me@69.196.64.50) |
| 22:46.28 | Witch_Doc | anyone here use navisworks? |
| 22:54.26 | ``Erik | ok, I see the issue, I have to contemplate the interplay of the different values to get the formula right |
| 22:54.40 | ``Erik | forages |
| 23:14.21 | *** join/#brlcad stevegt_ (n=stevegt@cislunar.TerraLuna.Org) |
| 23:17.05 | stevegt_ | hey all -- does anyone know of any python bindings for librt, SWIG or otherwise? |
| 23:18.37 | stevegt_ | ~seen brlcad |
| 23:18.42 | ibot | brlcad is currently on #bzflag (13h 2m 54s) #brlcad (13h 2m 54s). Has said a total of 64 messages. Is idling for 50m 39s, last said: 'refresh'. |
| 23:20.08 | ``Erik | there was discussion about making a swig interface, but it never went anywhere, and I haven't heard of any python bindings :/ |
| 23:24.32 | stevegt_ | thanks ``Erik -- just wanted to check before I spend any time on it |
| 23:25.37 | stevegt_ | another alternative would include patching nirt -- afaict, onehit is hardcoded... |
| 23:25.54 | stevegt_ | or else i'm crazy |
| 23:26.03 | ``Erik | swig interface to bu, bn, rt, ged, etc would probably be greatly appreciated and get snarfed into the repo pretty quickly |
| 23:26.12 | stevegt_ | i bet it would ;-) |
| 23:26.25 | ``Erik | nirt is a fairly specialized rt shell |
| 23:27.38 | stevegt_ | i'm wanting to be able to do batch python scripting of raytrace-based toolpath generation jobs, nirt looks like it might almost work, except for onehit... |
| 23:28.12 | CIA-32 | BRL-CAD: 03erikgreenwald * r35042 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: more futzing with step sizes. This seems to render all the current test cases reasonably. |
| 23:28.31 | ``Erik | would like to do lisp coding around librt :) |
| 23:28.40 | ``Erik | mebbe ruby, too |
| 23:29.14 | stevegt_ | welll... i suppose if someone were to make a working .i for librt, then you could use SWIG for lisp, python, perl, whatever... |
| 23:29.33 | ``Erik | if you have experience with swig, include/bu.h include/bn.h include/ged.h include/raytrace.h to see how easy it would be to integrate? *shrug* |
| 23:31.09 | stevegt_ | i did try the simple thing, including raytrace.h in the SWIG .i file -- blows chunks though; my first guess is that it's going to actually need some wrapper functions |
| 23:32.22 | ``Erik | hm, bu.h might be the best first target, raytrace depends on libbn and libbu, libbn depends on libbu, ... |
| 23:32.37 | ``Erik | bu just requires a sane system and tcl |
| 23:32.49 | stevegt_ | SWIG docs say it doesn't run cpp, so I think that means all of brl-cad's macro function names are going to be in the way... |
| 23:33.31 | ``Erik | hrm, perhaps convince make to run the headers through the preprocessor and sick swig on the output of that? |
| 23:34.48 | stevegt_ | i ran cpp on raytrace.h myself, of course that pulls in the whole world, starting with stdio.h... at some point someone's either going to have to massage cpp output, or just write a SWIGable library on top of librt |
| 23:35.06 | stevegt_ | hmm. maybe nirt might be a place to start with the latter |
| 23:35.43 | stevegt_ | start with the nirt code, kill main()... |
| 23:35.45 | ``Erik | I'm sure once some code hits the disk, bikeshed discussions will start about how it SHOULD have been done :) |
| 23:36.01 | stevegt_ | yep |
| 23:36.16 | ``Erik | so *shrug* release early, release often :) |
| 23:36.43 | stevegt_ | do you have SVN commit access? |
| 23:36.46 | ``Erik | yes |
| 23:37.31 | stevegt_ | about how big is the local sandbox? (I'm still running checkout) |
| 23:37.47 | ``Erik | if you have something you'd like to contribute, upload it to the sourceforge patches tracker and hollar, someone will respond pretty darn quick :) |
| 23:37.54 | ``Erik | um, "local sandbox"? |
| 23:38.14 | ``Erik | on my mac, after everything is compiled, it all adds up to 730 megs |
| 23:38.40 | stevegt_ | okay -- then i'm getting close |
| 23:39.11 | ``Erik | I think it's more like 80-100 megs before compiling? *shrug* |
| 23:40.13 | stevegt_ | uh oh -- i'm at 430 and counting so far -- you must be talking about trunk only or something |
| 23:40.20 | ``Erik | yes, trunk only |
| 23:40.33 | ``Erik | um, if you are getting every branch, that's many gigs :( |
| 23:41.04 | ``Erik | svn co https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad |
| 23:41.22 | stevegt_ | kills his 'svn co' and starts over ;-) |
| 23:44.22 | ``Erik | ok, here we go, if you add up the tags and branches, there are 95. You were checking out 95 copies of BRL-CAD :D |
| 23:44.44 | stevegt_ | nope |
| 23:45.04 | stevegt_ | i was checking out 95 copies of brlcad, as well as jbrlcad, rt^3, etc... ;-) |
| 23:45.19 | ``Erik | ah, those arne't tagging or branching |
| 23:45.28 | ``Erik | so 95 BRL-CAD's, plus the other five or 6 |
| 23:45.32 | stevegt_ | gee |
| 23:46.11 | brlcad | stevegt_: hehe |
| 23:46.19 | brlcad | ~cadsvn |
| 23:46.20 | ibot | To obtain BRL-CAD from Subversion: svn checkout https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad |
| 23:46.29 | brlcad | that there be the main line |
| 23:47.14 | brlcad | hmm.. python bindings. not directly, but you can certainly script mged from python just fine and do nearly everything |
| 23:47.53 | ``Erik | doublecheck my metaball fix, brlcad, I think I have it 'ok' now. performance is kinda wonky, but it seems to do ok on all the geometry I threw at it |
| 23:48.03 | brlcad | it would be very trivial to bind libged to python, just nobody has done so (or needed to thusfar) |
| 23:48.14 | brlcad | yeah, saw the commit, was just about to try |
| 23:48.39 | brlcad | will find some way to press the limits even further :) |
| 23:48.50 | ``Erik | asymptotic performance of it is now noncontinuous :( |
| 23:48.52 | brlcad | that script does make it trivial to make arbitrarily complex blobs |
| 23:49.24 | ``Erik | mebbe some day I'll build an acceleration structure into the guts of it *sigh* |
| 23:49.35 | brlcad | riight :) |
| 23:50.12 | ``Erik | yeah, about 6 months after I retire and find an ancient todo file. |
| 23:50.32 | brlcad | stevegt_: I wouldn't start with raytrace.h .. ged.h is a lot simpler interface, a little higher level |
| 23:50.39 | stevegt_ | brlcad: looking |
| 23:51.06 | brlcad | what did you mean about nirt's onehit? |
| 23:51.16 | brlcad | nirt is pretty configurable (and scriptable) too |
| 23:51.34 | brlcad | it has a command-mode similar to mged |
| 23:53.05 | brlcad | stevegt_: fyi, also very keen on handing out commit access to folks that are actively interested in getting involved that are easy to work with, regardless of their project/goals/interests |
| 23:55.55 | brlcad | HACKING has some basic guidelines on top of that, but it mostly amounts to "do no harm" and aims to keep the project cohesive (we're complex enough as it is to be arguing over petty issues) |
| 23:58.55 | stevegt_ | brlcad: <grin> re complex ;-) |
| 23:59.00 | brlcad | ``Erik: fyi, they're about to tag a final 3.4 itcl just so you know -- guys have been bugging them so they can update the ports entry, there is a b1 posted now |
| 23:59.29 | ``Erik | hm, I finally got vidar back up and running, I still have to update cad/brlcad :/ |
| 23:59.32 | ``Erik | and a few others heh |
| 23:59.39 | ``Erik | bugle, gauche, ... |
| 23:59.51 | brlcad | vidar? |
| 23:59.54 | ``Erik | poor machine went a year without updates |
