| 00:00.00 | ``Erik | yeah, my -current box at home |
| 00:00.15 | brlcad | that sounds pretty gaydar :) |
| 00:00.23 | ``Erik | O.o |
| 00:00.32 | brlcad | now .. vigor :) |
| 00:00.44 | ``Erik | heh, pheer my norse mythology machines. |
| 00:00.58 | ``Erik | vidar == god of vengence |
| 00:01.22 | stevegt_ | was confused: the line of code in nirt.c which i thought turns on onehit is turning it off instead -- i must be doing something else wrong though |
| 00:02.09 | ``Erik | or onehit doesn't quite do what you think it does :) |
| 00:03.12 | brlcad | assume you've seen: http://brlcad.org/w/images/f/fe/Interactive_Raytracing_-_The_nirt_Command.pdf |
| 00:03.44 | stevegt_ | wonders if he has to actually configure some 'fmt' commands to get nirt to show anything past the first hit |
| 00:03.47 | brlcad | starseeker wrote a pretty extensive guide to using and configuring nirt |
| 00:05.11 | stevegt_ | brlcad: no, i hadn't seen that PDF yet -- very cool |
| 00:05.26 | brlcad | linked from http://brlcad.org/wiki/Documentation |
| 00:05.39 | brlcad | yeah.. not well organized on the doc front still :) |
| 00:05.55 | brlcad | there's still a lot more not even uploaded, but it'd just get even more messy |
| 00:07.56 | brlcad | stevegt_: I intentionally didn't add distribute() to the header since it was basically being used as an implementation detail and not part of the interface |
| 00:08.15 | brlcad | doesn't matter much at this point, but worth noting |
| 00:17.51 | stevegt_ | brlcad: the docs that aren't uploaded -- are they in svn? |
| 00:20.41 | brlcad | some are, many aren't.. docs accumulated over the years |
| 00:21.09 | brlcad | figure a 1M codebase, 25 or so years .. lot of docs, presentations, papers, etc have been written |
| 00:22.04 | stevegt_ | yep -- and i'm assuming some only exist on paper at this point |
| 00:22.06 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-218.sbndin.btas.verizon.net) | |
| 00:23.29 | stevegt_ | i'm noticed that google can't find some of the papers referred to in the bottom of man pages |
| 00:23.35 | stevegt_ | s/i'm/i've/ |
| 00:24.46 | stevegt_ | now *there's* a possible GSoC project -- organize, scan stuff in... |
| 00:25.44 | brlcad | heh, I wish.. gsoc has to be coding |
| 00:25.52 | brlcad | ghop perhaps |
| 00:26.19 | brlcad | I try to get new folks introduced by having them work on docs, but they tend to get quickly absorbed into coding *ahem* |
| 00:27.28 | brlcad | still think our greatest accelleration of activity could be gained by putting (a LOT of) effort into well organized docs and sources, even without new features or improved gui |
| 00:27.38 | stevegt_ | yes |
| 00:28.13 | stevegt_ | i've been spending > 50% of my time reading code 'cause i can't find what i'm looking for in docs |
| 00:28.26 | stevegt_ | that's gotta be a hurdle ;-) |
| 00:28.40 | brlcad | tis a major project, though .. and major organization feat, and not very exciting work for most :) |
| 00:28.50 | brlcad | yeah |
| 00:29.03 | brlcad | getting the new website up certainly helped a lot, but even that was just a start |
| 00:37.47 | yukonbob | hello, cadheadsw |
| 00:37.50 | yukonbob | *cadheads |
| 00:39.39 | stevegt_ | goes to get the kids -- bbl |
| 00:40.40 | brlcad | howdy yukonbob! .. half hoped you might clean up all that wiki spam we got :) |
| 00:40.44 | brlcad | cya stevegt_ |
| 00:56.01 | yukonbob | brlcad: /me hadn't seen spam |
| 00:56.25 | yukonbob | brlcad: how's it going? Long time, no chat |
| 00:58.00 | brlcad | going pretty good |
| 00:59.48 | yukonbob | doesn't see spam... |
| 01:01.01 | dtidrow | brlcad: i see that Lee is doing some OpenSceneGraph work - is he back from his 'sabbatical'? |
| 01:09.08 | brlcad | dtidrow: yep, he's back |
| 01:09.20 | brlcad | been back for nearly a year now? |
| 01:09.41 | dtidrow | heh - that's how far out of the loop I've been ;-) |
| 01:09.49 | brlcad | yeah, maybe more than a year actually .. |
| 01:10.03 | brlcad | yukonbob: I took care of it all already |
| 01:10.08 | dtidrow | so what's he doing with OSG/ |
| 01:10.11 | dtidrow | ? |
| 01:10.48 | dtidrow | (note to self - get new keyboard to fix sticky shift key...) |
| 01:20.09 | yukonbob | is there anybody else who isn't loving compiling opennurbs (i.e. isn't successfull)? |
| 01:24.14 | ``Erik | hasnt had issues with opennurbs, just libpc :/ |
| 01:45.41 | brlcad | dtidrow: interactive visualization, related to his research project back in utah |
| 01:46.09 | brlcad | yukonbob: yeah, no problems here nor have I heard of any |
| 01:51.07 | yukonbob | will pursue... |
| 02:07.15 | brlcad | ``Erik: woo hoo .. feels like it's an order of magnitude slower now, but no problems observed thusfar |
| 02:12.13 | starseeker | indianlarry: does the nurbs_sphere.s test case work for you with latest svn? |
| 02:14.50 | ``Erik | it is much slower, the speed now is mostly dependent on the smallest field strength |
| 02:15.20 | ``Erik | irregardless of the bounding sphere diameter |
| 02:15.37 | ``Erik | so a small control point in a big bounding sphere does a LOT more point checks |
| 02:20.16 | CIA-32 | BRL-CAD: 03ralith * r35043 10/rt^3/trunk/src/g3d/ (CMakeLists.txt OgreScene.cxx OgreScene.h): Split Ogre/Qt work off into a separate target (make ogretest). |
| 02:20.20 | Ralith | can someone build g3d to see if it's survived my hackery? My updated ogre install here breaks RBGui so I can't easily test myself. |
| 02:24.07 | Ralith | it *should* be okay; the only error I'm getting is the one concerning RBGui/Ogre unhappiness, but it would be nice to be sure. |
| 02:39.12 | CIA-32 | BRL-CAD: 03erikgreenwald * r35044 10/rt^3/trunk/include/GE/io/DataStream.h: include sys/types.h for definition of uint |
| 02:39.40 | *** join/#brlcad stevegt_ (n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) | |
| 03:41.02 | Ralith | ooh, I think I've found a way to step Qt without reimplementing QApplication! |
| 03:42.17 | Ralith | this should make the ogre-centric approach much easier. |
| 03:48.08 | Ralith | wait, what |
| 03:51.43 | Ralith | that's funny... |
| 03:56.45 | Ralith | oh wow, I think ogre's been flipping buffers this whole time after all |
| 04:00.34 | Ralith | DAMN. |
| 04:00.36 | Ralith | that didn't solve it. |
| 04:07.04 | CIA-32 | BRL-CAD: 03ralith * r35045 10/rt^3/trunk/src/g3d/ogretest.cxx: Added a file forgotten from my previous commit. |
| 04:08.07 | Ralith | on the up side... |
| 04:08.11 | Ralith | custom event loop works |
| 04:08.16 | Ralith | mainloop* |
| 04:08.24 | CIA-32 | BRL-CAD: 03ralith * r35046 10/rt^3/trunk/src/g3d/OgreScene.cxx: |
| 04:08.31 | CIA-32 | BRL-CAD: Removed a call that was causing Ogre to go through a full render sequence (undesirable, as it involves buffer flipping and possibly |
| 04:08.37 | CIA-32 | BRL-CAD: other actions based on the assumption that Ogre is the only user of the context), and disabled Ogre rendering altogether to test Qt |
| 04:08.44 | CIA-32 | BRL-CAD: operation with a custom event loop (successful). |
| 04:33.53 | CIA-32 | BRL-CAD: 03ralith * r35047 10/rt^3/trunk/src/g3d/QtRenderListener.h: Beginnings of the QtRenderListener, which should eventually allow Qt to render cleanly on Ogre's terms. |
| 04:34.01 | Ralith | grabs food |
| 05:22.35 | Ralith | returns and starts hacking on the impl |
| 06:02.11 | *** join/#brlcad IriX64 (n=WarLock@bas2-sudbury98-1096600735.dsl.bell.ca) | |
| 07:32.48 | *** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch) | |
| 08:47.08 | CIA-32 | BRL-CAD: 03ralith * r35048 10/rt^3/trunk/src/g3d/ (QtRenderListener.cxx QtRenderListener.h): First-try implementation of QtRenderListener, which should allow Qt to be safely rendered without conflicting with Ogre. |
| 08:48.42 | Ralith | hokay, semi-ogre centric (managed to rely on Qt more than I had initially expected) implementation put together; now to rewrite the test code to find out if it works. |
| 08:51.43 | CIA-32 | BRL-CAD: 03ralith * r35049 10/rt^3/trunk/src/g3d/QtRenderListener.cxx: Added a safety check to prevent any attempt to use the listener with a non-OpenGL Ogre backend. |
| 09:23.11 | *** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch) | |
| 09:30.52 | CIA-32 | BRL-CAD: 03d_rossberg * r35050 10/brlcad/trunk/src/librt/opennurbs_ext.cpp: |
| 09:30.53 | CIA-32 | BRL-CAD: fixed crash on MS Windows with brlcad.dll |
| 09:30.57 | CIA-32 | BRL-CAD: trim.m_ei = -1 => this trim lies on a portion of a singular surface side |
| 09:30.59 | CIA-32 | BRL-CAD: (see src\other\openNURBS\example_brep\example_brep.cpp) |
| 09:32.18 | CIA-32 | BRL-CAD: 03d_rossberg * r35051 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: fixed crash on MS Windows with brlcad.dll and nurbs_test.g |
| 09:41.21 | CIA-32 | BRL-CAD: 03d_rossberg * r35052 10/brlcad/trunk/src/nirt/ (Makefile.am nirt.dsp): MSVC 6.0 isn't supported any more |
| 10:14.28 | CIA-32 | BRL-CAD: 03Ralith 07http://brlcad.org * r1557 10/wiki/User:Ralith: Logs for 2009-07-08 and 2009-07-09 |
| 10:41.35 | *** join/#brlcad mafm (n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) | |
| 11:23.54 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) | |
| 11:31.53 | *** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl) | |
| 11:42.56 | *** join/#brlcad alex_joni (n=alex_jon@emc/board-of-directors/alexjoni) | |
| 12:09.35 | *** join/#brlcad mafm_ (n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) | |
| 12:32.01 | *** join/#brlcad BigAToo1 (n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) | |
| 12:35.20 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) | |
| 12:35.56 | *** join/#brlcad docelic_ (n=docelic@78.134.192.197) | |
| 12:46.17 | CIA-32 | BRL-CAD: 03irpguardian * r35053 10/brlcad/trunk/BUGS: Fixed a couple spelling errors |
| 13:02.49 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) | |
| 13:05.26 | CIA-32 | BRL-CAD: 03erikgreenwald * r35054 10/brlcad/trunk/BUGS: metaball scalloping was fixed last night (I hope) |
| 13:07.56 | ``Erik | *mumble* |
| 13:18.10 | *** join/#brlcad elena (n=elena@89.136.118.141) | |
| 13:38.17 | CIA-32 | BRL-CAD: 03erikgreenwald * r35055 10/rtcmp/trunk/tri.c: fix typo in comment |
| 13:39.02 | *** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl) | |
| 13:43.29 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 13:50.50 | *** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl) | |
| 14:10.05 | CIA-32 | BRL-CAD: 03d_rossberg * r35056 10/brlcad/trunk/src/nirt/nirt.c: |
| 14:10.07 | CIA-32 | BRL-CAD: no extra setmode for MS Windows |
| 14:10.09 | CIA-32 | BRL-CAD: we need the O_TEXT mode here: it converts the CR-LF from the input stream to a single LF (and vice versa for the output) |
| 14:16.58 | CIA-32 | BRL-CAD: 03d_rossberg * r35057 10/brlcad/trunk/ (4 files in 3 dirs): include the nirt program in the MS Windows CMake build |
| 14:18.56 | *** join/#brlcad samrose (n=samrose@24.11.214.181) | |
| 14:34.04 | ``Erik | explains what sleep() does to his officemate. *sigh*. |
| 14:34.56 | brlcad | heh |
| 14:35.33 | brlcad | better to teach him what "man 3 sleep" does |
| 14:35.41 | CIA-32 | BRL-CAD: 03irpguardian * r35058 10/brlcad/trunk/src/proc-db/human.c: Cleanup of some of the vector equations, and some reworking of the method the human is generated. |
| 14:35.47 | ``Erik | ah, theboy, that, um, line wasn't in the history file |
| 14:36.00 | ``Erik | if'n ya noticed my sudo spaz earlier |
| 14:40.14 | ``Erik | huh, no joy :/ |
| 14:41.33 | ``Erik | ahhhhhhh |
| 14:41.41 | ``Erik | was using the wrong username heh |
| 15:28.16 | *** join/#brlcad cosurgi (n=cosurgi@atak.bl.pg.gda.pl) | |
| 15:29.43 | *** part/#brlcad Witch_Doc (n=me@69.196.64.50) | |
| 16:37.16 | *** join/#brlcad elena (n=elena@89.136.118.141) | |
| 17:27.32 | brlcad | hello elena |
| 17:28.27 | elena | hi. |
| 17:28.45 | elena | how are you? |
| 17:28.56 | brlcad | great! |
| 17:29.26 | brlcad | playing with the metaballs example tool at the moment |
| 17:30.41 | brlcad | was hoping the recent fix worked ... and it almost does .. but not quite, has lots of anamolies still |
| 17:30.51 | elena | bugs are not funny. |
| 17:30.52 | brlcad | albeit on a massive metaball dataset.. 10k points :) |
| 17:32.50 | elena | i don't know what's that. |
| 17:36.35 | brlcad | they're "blobby" shapes that are defined by points and threshold/weighting factors |
| 17:36.42 | brlcad | example: http://brlcad.org/tmp/metaball.png |
| 17:37.06 | elena | i've notice a lot of talk around them lately. |
| 17:37.35 | brlcad | yeah, I was putting together an example of using them in code |
| 17:37.48 | brlcad | found a handfull of issues that we've been working on fixing |
| 17:40.26 | brlcad | http://brlcad.org/tmp/metaball2.png even better example |
| 17:41.47 | elena | nice. |
| 17:42.05 | elena | the former was the funnier :) |
| 17:42.56 | brlcad | hehe |
| 17:46.23 | ``Erik | since it's a sampling algo instead of a solver, there'll always be 'anomalies', it's a tradeoff between how many and how fast :( |
| 17:46.56 | elena | nice. |
| 17:46.56 | ``Erik | mebbe the initial and final step sizes should be user specifiable |
| 17:49.15 | CIA-32 | BRL-CAD: 03brlcad * r35059 10/brlcad/trunk/BUGS: the lingering ogl framebuffer after an rt is consuming 100% cpu (sometimes?) until the window is closed. needs to sleep/select instead of spin. |
| 17:49.53 | CIA-32 | BRL-CAD: 03brlcad * r35060 10/brlcad/trunk/src/proc-db/metaball.c: |
| 17:49.55 | CIA-32 | BRL-CAD: add the ability to be able to specify how many points you want instead of just |
| 17:50.01 | CIA-32 | BRL-CAD: the previous hard-coded value. uses 1/111, 10/111, and 100/111 for the three |
| 17:50.03 | CIA-32 | BRL-CAD: datasets it creates (with at least 1 per set) so that the final is close to the |
| 17:50.07 | CIA-32 | BRL-CAD: requested value (plus one or two more). |
| 17:55.01 | brlcad | ``Erik: http://brlcad.org/tmp/mbug/mbug3.png .. it's pretty close, just a little chewing |
| 17:55.21 | brlcad | and it didn't take as long as it seemed, maybe 5-10 min |
| 17:55.56 | brlcad | granted, with some partitioning, that'd probably be down to less than a min :) |
| 17:56.18 | ``Erik | making the initstep size smaller will alleviate that... feel free to come up with a better formula, it's not computed per ray anymore, so there's no need to make it simple and fast *shrug* |
| 17:56.35 | ``Erik | it's now in _prep |
| 17:56.36 | ``Erik | :D |
| 17:57.28 | ``Erik | figuring out which formula is being used might be important O.o |
| 17:58.00 | ``Erik | is guessing there is an "unreasonably small" point in your cloud forcing it into t he bounding volume algo |
| 17:59.55 | brlcad | hehe, just printed/sorted all balls |
| 18:00.03 | brlcad | smalles is 0.000574094 |
| 18:00.53 | brlcad | 20 or so are an order "bigger", then everything else is an order larger (0.01+) still |
| 18:01.12 | brlcad | largest is 51.1789 |
| 18:01.31 | ``Erik | and the bounding volume radius? a couple thousand? heh |
| 18:05.32 | CIA-32 | BRL-CAD: 03starseeker * r35061 10/brlcad/trunk/ (3 files in 3 dirs): Continue tweaking opennurbs cleanup files |
| 18:11.17 | *** join/#brlcad b0ef (n=b0ef@084202026157.customer.alfanett.no) | |
| 18:19.53 | *** join/#brlcad b0ef (n=b0ef@084202026157.customer.alfanett.no) | |
| 18:22.10 | CIA-32 | BRL-CAD: 03irpguardian * r35062 10/brlcad/trunk/src/proc-db/human.c: |
| 18:22.14 | CIA-32 | BRL-CAD: Made arms, legs use human_data_t struct for limb positioning |
| 18:22.20 | CIA-32 | BRL-CAD: Made arms get limb positioning externally of arm function. |
| 18:22.22 | CIA-32 | BRL-CAD: Added command line attribute to make premade stances, '-s#' |
| 18:22.24 | CIA-32 | BRL-CAD: -s0 = stand -s1 = sit, -s2 = drive |
| 18:30.50 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 18:38.38 | CIA-32 | BRL-CAD: 03bob1961 * r35063 10/brlcad/trunk/src/tclscripts/mged/text.tcl: Update tab_expansion proc to work with the new expand behavior (i.e. expand returns an empty string if nothing suitable is found in the database). |
| 19:02.33 | CIA-32 | BRL-CAD: 03irpguardian * r35064 10/brlcad/trunk/src/proc-db/human.c: |
| 19:02.34 | CIA-32 | BRL-CAD: Added roundness to shoulder area. |
| 19:02.36 | CIA-32 | BRL-CAD: Also refined some poses, so there are now 4 programed- |
| 19:02.40 | CIA-32 | BRL-CAD: stand, sit, drive, arms out, fancy sit |
| 19:07.10 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) | |
| 19:54.59 | CIA-32 | BRL-CAD: 03Ebautu 07http://brlcad.org * r1558 10/wiki/More_Changelog: /* July 7 - Today */ |
| 20:08.21 | CIA-32 | BRL-CAD: 03starseeker * r35065 10/brlcad/trunk/ (3 files in 3 dirs): More nurbs tweaks - getting visual artifacts in the sphere when I use sane flatness settings that are due to intersection failures on the hierarchy - so far haven't successfully tracked down the problem. |
| 20:09.40 | CIA-32 | BRL-CAD: 03bob1961 * r35066 10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: Added brep_debug to the librt build. |
| 20:12.56 | starseeker | growls in frustration |
| 20:13.51 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 20:20.07 | *** join/#brlcad cosurgi (n=cosurgi@chello089079134153.chello.pl) | |
| 20:24.19 | CIA-32 | BRL-CAD: 03bob1961 * r35067 10/brlcad/trunk/src/libged/3ptarb.c: Free memory. |
| 20:27.16 | CIA-32 | BRL-CAD: 03bob1961 * r35068 10/brlcad/trunk/ (56 files in 5 dirs): |
| 20:27.18 | CIA-32 | BRL-CAD: These changes fix bug 2278126 (i.e. rt doesn't get geometry path right). The |
| 20:27.20 | CIA-32 | BRL-CAD: tact was to replace the solids list with a display list where each item in the |
| 20:27.22 | CIA-32 | BRL-CAD: list refers to what was asked to be drawn. Each of these display list items has |
| 20:27.26 | CIA-32 | BRL-CAD: its own solids list. |
| 20:30.55 | *** join/#brlcad stevegt_ (n=stevegt@cislunar.TerraLuna.Org) | |
| 20:39.42 | jdoliner | what tools does brlcad already have for polynomial manipulation, solving evaluating etc? |
| 20:41.40 | jdoliner | aha libbn/poly.c |
| 20:45.43 | jdoliner | is there support for multivariate polynomial anywhere? |
| 20:46.26 | pacman87 | jdoliner: not that i found, and the solver is limited to 4th order |
| 21:14.34 | jdoliner | well I definitely need those to proceed |
| 21:15.01 | pacman87 | what are you trying to do with multivariable polynomials? |
| 21:15.05 | pacman87 | systems of equations? |
| 21:15.11 | jdoliner | yes |
| 21:15.35 | jdoliner | nurbs surface intersection |
| 21:15.39 | jdoliner | to be precise |
| 21:16.00 | pacman87 | two second-order two-variable equations can be combined to get a fourth order single-variable equation for one variable |
| 21:17.15 | pacman87 | if you need higher-order polynomials, you may have to use an iterative solver |
| 21:18.00 | jdoliner | In the literature they use the dixon resultant |
| 21:18.31 | jdoliner | we don't have any such solvers already implemented do we? |
| 21:18.46 | pacman87 | i don't know enough to answer that |
| 21:19.51 | jdoliner | k |
| 21:20.25 | jdoliner | brlcad impart some wisdom? |
| 21:25.45 | ``Erik | told him to look at irc |
| 21:26.17 | jdoliner | thanks |
| 21:44.43 | CIA-32 | BRL-CAD: 03irpguardian * r35069 10/brlcad/trunk/src/proc-db/human.c: Cleaned up some code |
| 21:51.27 | CIA-32 | BRL-CAD: 03bob1961 * r35070 10/brlcad/trunk/ (5 files in 4 dirs): Changes to get things building on MSVC8. |
| 21:59.48 | CIA-32 | BRL-CAD: 03r_weiss * r35071 10/brlcad/trunk/src/libged/make_pnts.c: improved error messages, logic cleanup |
| 22:02.31 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-211.sbndin.btas.verizon.net) | |
| 22:40.30 | stevegt_ | is pondering two alternatives: (1) write his 2d laser cutter toolpath generation tool as a C executable (2) write it as a python wrapper around nirt and mged |
| 22:42.01 | stevegt_ | given my python currency and C rustiness, I'm favoring the latter, but don't want to make people go "ooooh, yuck" |
| 22:42.20 | stevegt_ | s/the latter/the python route/ |
| 22:45.45 | stevegt_ | seems like brl-cad's history has favored special-purpose C executables in ./bin, rather than special-purpose scripting around fewer, more general-purpose C cores |
| 22:46.50 | Ralith | stevegt_: a wrapper around nirt and mged would be a very strange thing to do, considering that you'll want to interact with rt directly. |
| 22:47.18 | Ralith | what you could do instead would be write a python API for rt and whatever else you need, and then use that in python. |
| 22:47.38 | stevegt_ | Ralith: so far it's looking like nirt's custom outputs can give me everything i need |
| 22:47.42 | stevegt_ | other than speed ;-) |
| 22:48.06 | Ralith | stevegt_: still a very strange thing to do, and probably relatively slow at that. |
| 22:48.06 | Ralith | using the API directly would be immensely cleaner |
| 22:48.14 | Ralith | and probably less prone to breakage |
| 22:49.55 | stevegt_ | i agree that the "right" thing to have would be python bindings for librt and/or libged etc. -- but that give me a much longer lead time to get the machine design project done that i'm actually supposed to be working on |
| 22:50.08 | stevegt_ | i'm already getting pressure to "just use solidworks" ;-) |
| 22:50.14 | Ralith | actually, wrapping a C API in your language of choice is usually trivial |
| 22:50.20 | stevegt_ | s/give/gives/ |
| 22:50.43 | Ralith | I'm not familiar with python's relevant facilities, but it's generally a task so straightforward as to be easily automated :P |
| 22:50.48 | Ralith | in fact... |
| 22:51.04 | stevegt_ | Ralith: brl-cad's use of macros for function names makes SWIG less straightforward to run |
| 22:51.19 | stevegt_ | afaict anyway |
| 22:51.26 | Ralith | that would be odd; it's a perfectly reasonable thing to do |
| 22:51.47 | Ralith | things like POSIX actually explicitly state that macros can be used interchangably with functions in many contexts |
| 22:51.53 | stevegt_ | SWIG doesn't run cpp |
| 22:52.01 | Ralith | good thing the API you'd be wrapping is C :P |
| 22:52.26 | stevegt_ | so it's "easier" to just write a new .h, rather than use e.g. raytrace.h or ged.h |
| 22:52.37 | Ralith | wat |
| 22:53.11 | Ralith | stevegt_: like I said, the API is all C. |
| 22:53.16 | Ralith | there's no C++. |
| 22:53.19 | stevegt_ | when i say "cpp" i mean "the C preprocessor" |
| 22:53.27 | Ralith | oh :P |
| 22:53.31 | Ralith | that's a highly ambiguous term |
| 22:54.11 | Ralith | so run SWIG on the functions and rewrite the macros in python? |
| 22:54.30 | ``Erik | heh, only to retards who fuck up terminology and think cpp means c++, instead of using .c++, .C, .cxx, ... |
| 22:54.32 | ``Erik | :D |
| 22:54.33 | ``Erik | *duck* |
| 22:55.00 | Ralith | :[ |
| 22:55.19 | Ralith | .C is a bad idea |
| 22:55.24 | Ralith | given the existence of case insensitive filesystems |
| 22:55.26 | stevegt_ | deletes a line about "dinosaurs like me who think of C++ as a new language" |
| 22:56.29 | stevegt_ | s/new/new and unproven/ |
| 22:57.01 | Ralith | stevegt_: and of course a pure C implementation would be cool too, simply because of the drastically smaller overhead, but if you're not comfortable in C and don't have the time to become so then it's not worth the effort |
| 22:59.51 | stevegt_ | Ralith: I think it's one of those things where I'd better go ahead and do it the fastest way, lest it not get done at all ;-) |
| 23:00.01 | Ralith | reasonable. |
| 23:00.21 | stevegt_ | or at least try -- the parsing of mged output might slow things down enough that i'd have to go to pure C anyway |
| 23:00.56 | Ralith | what do you need mged for? |
| 23:01.02 | stevegt_ | depends on how many rays I wind up working with for a reasonably-complex assembly |
| 23:01.38 | stevegt_ | I *think* I need mged just to list the basic shapes, so I know I'm hitting all of them while discovering holes and other booleans |
| 23:02.45 | Ralith | er |
| 23:02.51 | Ralith | all you should need to know is the region you're targeting |
| 23:02.58 | Ralith | which the user is supposed to provide |
| 23:06.08 | stevegt_ | i need to be able to make sure that any grid or other pattern is fine-grained enough to hit hairline features -- they are easy to machine with a laser, and do get used |
| 23:06.46 | Ralith | the way you do that is by shooting enough rays that your resultant toolpath is guaranteed to be more precise than the machine can produce |
| 23:09.12 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 23:11.39 | ``Erik | you can ignore mged and write a treewalk routine to collect all the region names. |
| 23:12.15 | stevegt_ | Ralith: i guess i'm (possibly prematurely) trying to optimize, was thinking about adaptively sizing a tight grid around edges, ignoring the rest -- if i just to a uniform grid, then we're looking at about a half-billion rays for a 20" square |
| 23:12.18 | ``Erik | db_walk_tree() or one of that family |
| 23:12.23 | stevegt_ | the laser precision is 50 um |
| 23:12.52 | Ralith | stevegt_: did you expect you wouldn't be using a lot of rays? :P |
| 23:12.52 | stevegt_ | ``Erik: in python |
| 23:12.55 | Ralith | don't optimize prematurely. |
| 23:13.04 | Ralith | make it work, THEN make it fast. |
| 23:13.50 | stevegt_ | Ralith: i'm going to have to do some performance proof of concepts up front -- maybe i don't need the adaptive grid |
| 23:14.42 | Ralith | stevegt_: unless you're trying to shoot rays via calling an external tool one ray at a time it should be fine. |
| 23:17.19 | Ralith | <PROTECTED> |
| 23:18.12 | stevegt_ | i'm thinking to essentially drive nirt as a filter, control both stdin and stdout/err from the python script, so it only needs to fork once, keep it fed with a stream of rays |
| 23:19.52 | stevegt_ | i'll test the speed of all this this weekend, see if it makes sense at all |
| 23:22.39 | stevegt_ | anyway, Ralith, ``Erik, thanks for being a sounding board -- i can see now that i need to do the performance testing next, before i decide anything else |
| 23:33.56 | Ralith | np |
| 23:33.58 | Ralith | best of luck! |
