| 00:29.34 | starseeker | is afraid to ask |
| 00:30.15 | *** join/#brlcad BigATo1 (n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 00:32.32 | *** join/#brlcad dreeves (n=dreeves@64.178.177.71) |
| 01:31.47 | CIA-28 | BRL-CAD: 03starseeker * r34382 10/brlcad/trunk/configure.ac: (log message trimmed) |
| 01:31.47 | CIA-28 | BRL-CAD: Need src/conv/step in the list for Makefile generation. Attempts to build as of |
| 01:31.47 | CIA-28 | BRL-CAD: r34379 seems to suggest that there are missing files that need to be checked in |
| 01:31.47 | CIA-28 | BRL-CAD: to get a working src/conv/step build - ssince src/conv/step is currently keying |
| 01:31.47 | CIA-28 | BRL-CAD: off the BUILD_STEP variable (which bty it shouldn't do that forever - in theory |
| 01:31.50 | CIA-28 | BRL-CAD: it should check for a system install if BUILD_STEP is off) turn off STEP |
| 01:31.52 | CIA-28 | BRL-CAD: altogether until it the rest of the necessary files get checked in. This is a |
| 01:35.10 | CIA-28 | BRL-CAD: 03starseeker * r34383 10/brlcad/trunk/src/libtclcad/ged_obj.c: Another instance of fb_pgflush - change to fb_flush |
| 01:36.44 | starseeker | makes a note to mention the svn status command to indianlarry... |
| 01:45.05 | starseeker | brlcad: Sean, FB_WPIXEL in include.h seems to be using _fb_pgin and _fb_pgout - I'm getting a linking error when I try to build libfb |
| 01:47.27 | starseeker | fb/fbgrid.c, fbed/fbed.c and lgt/reflect.c are using FB_WPIXEL |
| 01:54.36 | *** join/#brlcad madant_ (n=d@117.196.132.131) |
| 01:54.42 | starseeker | can we define FB_WPIXEL in the fb_paged_io.c and export that? |
| 01:55.17 | starseeker | isn't sure how that works for inline versions of things... |
| 02:00.16 | brlcad | hm, looking |
| 02:03.48 | starseeker | er, include/fb.h rather |
| 02:03.58 | brlcad | nods |
| 02:05.53 | brlcad | that's three very obscure tools .. they can probably just use fb_wpixel instead.. I really doubt the "inline" performance boost is signficant any longer |
| 02:06.06 | starseeker | alrightie |
| 02:06.09 | starseeker | want me to get it? |
| 02:06.17 | starseeker | q |
| 02:06.19 | starseeker | whoops |
| 02:07.05 | brlcad | you can if you beat me to it, but it's my mess to clean up |
| 02:07.21 | starseeker | is stubbornly working towards a build ;-) |
| 02:16.47 | CIA-28 | BRL-CAD: 03starseeker * r34384 10/brlcad/trunk/ (4 files in 4 dirs): Remove inline version of fb_wpixel, change calls to non-inline version - speed change is likely not significant any longer and the inline version requres exposure of fb_pgin and fb_pgout |
| 02:17.27 | brlcad | oof, heh |
| 02:17.55 | brlcad | beat me to it by mere seconds |
| 02:18.18 | starseeker | heh, sorry :-) |
| 02:18.32 | brlcad | no matter, trivial change |
| 02:18.36 | brlcad | but thanks |
| 02:18.46 | starseeker | np :-) |
| 02:19.21 | *** join/#brlcad madant (n=d@117.196.130.67) |
| 02:20.51 | starseeker | sighs in relief |
| 02:20.56 | starseeker | on the docs now |
| 02:21.09 | starseeker | brlcad: is that an ok hack for the step build until monday? |
| 02:21.20 | starseeker | either I'm nuts or there's a bunch of files not committed yet |
| 02:21.38 | starseeker | (or both) |
| 02:24.10 | CIA-28 | BRL-CAD: 03brlcad * r34385 10/brlcad/trunk/ (doc/deprecation.txt include/fb.h): deprecate FB_WPIXEL since it's been around for such a long time 'just in case'. |
| 02:25.54 | brlcad | starseeker: good enough for now, sure |
| 02:26.01 | CIA-28 | BRL-CAD: 03starseeker * r34386 10/brlcad/trunk/src/other/step/src/ (exppp/Makefile.am express/Makefile.am): Whoops. Commit fixes for src/other/step Makefile.am files so they will work with multiple processor building. |
| 02:26.57 | starseeker | brlcad: OK, we'll be nice about it ;-) |
| 02:27.44 | starseeker | waves broadsword wildly over his head with manical look in his eyes - "Cut 'em out!" |
| 02:28.45 | starseeker | now, let's see what happens with tire... |
| 02:30.31 | starseeker | ERROR: bad pointer x9b474b0: s/b rt_sketch_internal(x736b6574), was Unknown_Magic(x65787472), file ../../../brlcad/src/librt/primitives/sketch/sketch.c, line 1868 |
| 02:32.29 | brlcad | starseeker: that's very interesting |
| 02:33.02 | brlcad | this is why magic numbers are so useful :) |
| 02:34.14 | brlcad | if you look up the unknown magic, it's very insightful |
| 02:34.53 | brlcad | and that line number is telling, has to be related to the changes |
| 02:35.48 | starseeker | libbu/magic.c? |
| 02:38.17 | starseeker | ah, got a bomb trace that means something |
| 02:38.27 | starseeker | rt_sketch_ifree |
| 02:38.42 | starseeker | called from rt_extrude_ifree |
| 02:39.13 | brlcad | did you look at the unknown magic? |
| 02:39.50 | starseeker | I looked at the c file - doesn't that mean it can't tell what it is? |
| 02:40.05 | brlcad | not the c file |
| 02:41.04 | brlcad | whenever you see a magic code, you should look it up |
| 02:41.06 | starseeker | oh - that number matches RT_EXTRUDE_INTERNAL_MAGIC? |
| 02:41.12 | brlcad | there ya go |
| 02:41.24 | starseeker | erm |
| 02:41.24 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) |
| 02:41.29 | brlcad | so sketch's ifree was called, but seemingly passed an extrude object |
| 02:41.59 | starseeker | checks rt_extrude_ifree |
| 02:42.32 | hippieindamakin8 | waves at everybody and wishes |
| 02:42.35 | brlcad | obviously related to my recent change, but tbd whether it's an init problem now that it's going through the functab or some other issue |
| 02:45.10 | starseeker | extrude.c:2321 is where the call is coming from |
| 02:45.17 | brlcad | do you see the bug :) |
| 02:45.38 | starseeker | giving it ip of extrude? |
| 02:45.39 | brlcad | has it fixed, fwiw |
| 02:45.43 | brlcad | yep |
| 02:45.52 | starseeker | cool |
| 02:46.02 | CIA-28 | BRL-CAD: 03brlcad * r34387 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: free the sketch that the extrude was using, not the extrude itself. and good gravy, don't pass the extrude to sketch's ifree. |
| 02:46.13 | brlcad | copy-paste bug of a var that just happened to work in that scope |
| 02:46.15 | starseeker | thanks! |
| 02:46.39 | starseeker | thanks for the magic number tutorial - that helps :-) |
| 02:47.12 | starseeker | won that one :-P |
| 02:47.20 | starseeker | er you won that one |
| 02:47.51 | starseeker | tests |
| 02:49.38 | brlcad | reviews the other ifree() mods in case similar mistakes were injected |
| 02:49.41 | starseeker | ../../../brlcad/src/librt/primitives/extrude/extrude.c: In function 'rt_extrude_ifree': |
| 02:49.44 | starseeker | ../../../brlcad/src/librt/primitives/extrude/extrude.c:2321: error: incompatible type for argument 1 of 'tmp_ip.idb_meth->ft_ifree' |
| 02:49.50 | brlcad | bah |
| 02:49.53 | brlcad | still compiling :) |
| 02:51.10 | CIA-28 | BRL-CAD: 03brlcad * r34388 10/brlcad/trunk/src/librt/primitives/extrude/extrude.c: poinnnterrrrrr |
| 02:51.33 | starseeker | &tmp_ip rather than tmp_ip? |
| 02:51.38 | brlcad | there's another thing noteworthy about your bad pointer message |
| 02:51.39 | brlcad | yes |
| 02:51.50 | brlcad | Unknown_Magic |
| 02:51.57 | brlcad | it's clearly not "unknown" |
| 02:52.03 | starseeker | yes |
| 02:52.06 | brlcad | which means the table is out of sync (and should be syncd) |
| 02:52.21 | brlcad | doesn't like that table |
| 02:52.31 | brlcad | needs to be a better way to register magic numbers |
| 02:52.36 | starseeker | aaah. I was wondering a little why it didn't go ahead and say something useful... |
| 02:52.39 | brlcad | but C does make that a pain |
| 02:53.15 | starseeker | that's the magic.c table? |
| 02:54.00 | starseeker | looks at the Primitives section and his jaw drops |
| 02:54.13 | starseeker | no eto, no hyp, no sketch, no extrude... |
| 02:54.37 | starseeker | ouch |
| 02:55.43 | starseeker | checks first this time - you working on it already? |
| 02:57.30 | brlcad | nope |
| 02:57.39 | starseeker | hops to it |
| 02:57.46 | starseeker | here magic.h magic.h magic.h... |
| 02:58.32 | brlcad | I spent a good bit of time cleaning up magic.h many moons ago, left magic.c as an exercise to the reader |
| 02:59.49 | brlcad | magic.c isn't maintainable as-is .. and it was way too much of a diversion to make it something better at the time |
| 03:00.03 | starseeker | nods |
| 03:00.07 | brlcad | looks like extrude was isolated.. |
| 03:00.08 | brlcad | -rt_sketch_ifree(&tmp_ip); |
| 03:00.09 | brlcad | +tmp_ip.idb_meth->ft_ifree(ip, resp); |
| 03:00.26 | starseeker | yep, sneaky |
| 03:08.34 | CIA-28 | BRL-CAD: 03starseeker * r34389 10/brlcad/trunk/src/libbu/magic.c: Gah - update the magic.c list of primitives so the error messages know about more primitives |
| 03:08.58 | starseeker | still unmaintainiable, but hopefully slightly more useful |
| 03:13.33 | CIA-28 | BRL-CAD: 03starseeker * r34390 10/brlcad/trunk/src/libbu/magic.c: update libbu magic.c entries while we're at it. |
| 03:17.10 | *** join/#brlcad madant_ (n=d@117.196.132.175) |
| 03:17.26 | CIA-28 | BRL-CAD: 03starseeker * r34391 10/brlcad/trunk/src/libbu/magic.c: update nmg magic.c entries. |
| 03:34.35 | CIA-28 | BRL-CAD: 03starseeker * r34392 10/brlcad/trunk/src/libbu/magic.c: and update the rest of magic.c's entries. RT_CNURB and RT_SNURB are apparently duplicates of other magic value definitions - leave the originals |
| 03:34.41 | starseeker | there we go |
| 03:35.12 | starseeker | yep, tire is working again too |
| 03:35.15 | starseeker | awesome |
| 03:44.39 | starseeker | calls it a night |
| 04:14.47 | *** join/#brlcad dreeves (n=dreeves@64.178.177.71) |
| 05:58.39 | *** join/#brlcad dreeves (n=dreeves@64.178.177.71) |
| 06:27.24 | dreeves | hey so I notice that breplicator and brep_cube is generating errors and not generating the test case and did anyone get a chance to work on any more test cases? |
| 06:35.13 | starseeker | dreeves: beyond what I've got up on bz? |
| 06:35.28 | starseeker | I can make some more - the current ones are showing errors last time I looked |
| 06:35.53 | starseeker | haven't tried the test cubes lately - what's the failure? |
| 06:36.20 | starseeker | gah. |
| 06:36.34 | starseeker | must sleep now - will answer once consciousness is regained |
| 06:38.42 | dreeves | starseeker I have been busy on something else lately so if you have created more then I don't know about them. The only one I'm finding is brep_pinch |
| 06:39.55 | dreeves | I will go check out bz |
| 07:40.27 | *** join/#brlcad Mouette (n=chatzill@fw1.phys.sinica.edu.tw) |
| 08:23.51 | *** join/#brlcad _sushi_ (n=_sushi_@77-58-239-152.dclient.hispeed.ch) |
| 08:24.05 | *** join/#brlcad Elrohir (n=kvirc@p5B14E546.dip.t-dialin.net) |
| 08:37.20 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 10:19.29 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 11:13.41 | *** join/#brlcad madant (n=d@117.196.130.130) |
| 11:50.23 | starseeker | dreeves: everything other than nurbs_tests.g in http://bzflag.bz/~starseeker/nurbs_tests/ is "new" |
| 11:50.41 | starseeker | I don't have the sh script set up to raytrace the new ones, unfortunately |
| 12:30.42 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) |
| 12:31.31 | CIA-28 | BRL-CAD: 03brlcad * r34393 10/brlcad/trunk/src/proc-db/breplicator.cpp: turn off the new face as the new face doesn't have the right UV trimming parameters (domain is wrong iirc), but is still a good example for understanding how the trims work. |
| 12:31.48 | brlcad | dreeves: that last commit makes breplicator.cpp work again -- the new face that was added was a trimming example |
| 12:40.59 | CIA-28 | BRL-CAD: 03brlcad * r34394 10/brlcad/trunk/src/proc-db/brep_cube.cpp: this wasn't broken, just quirky. you had to provide an(y) argument or it wouldn't write out the geometry file. the subsequent db_lookup would then get passed a null dbip, causing a bomb to go off. |
| 12:41.08 | brlcad | and that 'fixes' the brep_cube example (it wasn't broken, just dumb) |
| 13:03.53 | dreeves | ok thanks |
| 13:11.42 | *** join/#brlcad samrose (n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) |
| 14:45.09 | *** join/#brlcad madant (n=d@117.196.128.102) |
| 18:18.03 | CIA-28 | BRL-CAD: 03brlcad * r34395 10/brlcad/trunk/TODO: libfb needs to have fb_open_existing/fb_close_existing pushed up into the fb functab and the #ifdef sections eliminated. |
| 18:44.30 | CIA-28 | BRL-CAD: 03brlcad * r34396 10/brlcad/trunk/src/conv/step/Makefile.am: this still needs a lot of work. the built sources aren't declared portably. add a BUILT_SOURCES section, sort, and make the vars specify one-per-line. the fedex sources should be a noinst lib. |
| 18:46.19 | CIA-28 | BRL-CAD: 03brlcad * r34397 10/brlcad/trunk/src/libfb/getput.c: remove the vax section. DEPRECATE all of these routines as they are exactly what libbu provides. |
| 18:51.21 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-61.sbndin.btas.verizon.net) [NETSPLIT VICTIM] |
| 18:51.23 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT VICTIM] |
| 18:51.23 | *** join/#brlcad CIA-28 (n=CIA@208.69.182.149.simpli.biz) [NETSPLIT VICTIM] |
| 18:52.12 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) [NETSPLIT VICTIM] |
| 18:52.12 | *** join/#brlcad brlcad (n=sean@bz.bzflag.bz) |
| 18:52.16 | *** join/#brlcad madant (n=d@117.196.128.102) [NETSPLIT VICTIM] |
| 19:02.23 | CIA-28 | BRL-CAD: 03brlcad * r34398 10/brlcad/trunk/include/bu.h: meh |
| 19:02.41 | starseeker | heh - that's a bob commit message ;-) |
| 19:02.47 | brlcad | :) |
| 19:02.53 | ``Erik | nah, too many syllables |
| 19:02.58 | madant | hah |
| 19:14.01 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 19:14.01 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net |
| 19:15.07 | CIA-28 | BRL-CAD: 03brlcad * r34399 10/brlcad/trunk/ (include/pkg.h src/libpkg/pkg.c): pkg_2send's buffers aren't modified. declare them const. |
| 19:27.48 | brlcad | yeah, looks like the few references I can find indicate a 20-30% acceptance rate roughly |
| 19:27.58 | starseeker | ndos |
| 19:28.01 | starseeker | er nods even |
| 19:28.04 | brlcad | the paper rate is 15-20% |
| 19:28.13 | brlcad | varies year/year |
| 19:28.20 | starseeker | not too surprising really |
| 19:32.14 | brlcad | looks like rate was 18% in 2008 if this random guy's count is correct |
| 19:36.50 | CIA-28 | BRL-CAD: 03brlcad * r34400 10/brlcad/trunk/src/libfb/if_remote.c: convert all fbputshort/fbputlong/fbgetshort/fbgetlong calls to the corresponding libbu xdr routine (bu_pshort and friends), using unsigned char pointers were appropriate and casting as needed when going through libpkg. |
| 19:41.43 | CIA-28 | BRL-CAD: 03brlcad * r34401 10/brlcad/trunk/src/libfb/if_remote.c: ws style indent comment cleanup |
| 19:50.00 | *** join/#brlcad JucaBlues (n=felipe@189.79.78.26) |
| 19:50.08 | brlcad | hello JucaBlues |
| 19:50.14 | JucaBlues | hi! |
| 19:50.30 | brlcad | inkscape always welcome ;) |
| 19:50.37 | JucaBlues | :-) |
| 19:51.05 | JucaBlues | I've been looking at libdwg |
| 19:51.11 | JucaBlues | it is written in esperanto!!! |
| 19:51.15 | brlcad | sorry to hear that ;) |
| 19:51.31 | JucaBlues | we gotta fork that! |
| 19:51.32 | brlcad | ahh, yeah.. it's got a lot wrong with it :) |
| 19:51.33 | JucaBlues | :-P |
| 19:51.46 | brlcad | aside from dwg being a horrible format |
| 19:52.13 | JucaBlues | yeah, I know, but we need to build the "bridge", dont we? |
| 19:52.29 | brlcad | there's lots of bridges possible ;) |
| 19:52.56 | brlcad | dxf is generally better and nearly as pervasive as dwg |
| 19:53.11 | brlcad | btw, there is 'opendwg' from the creative alliance |
| 19:53.28 | brlcad | mired in legal woes with autodesk, but they're further along iirc |
| 19:53.37 | JucaBlues | does brlcad deal with both file formats? |
| 19:53.48 | brlcad | s/creative alliance/open design alliance/ |
| 19:53.53 | brlcad | we deal with dxf |
| 19:53.58 | JucaBlues | but opendwg libs are proprietary... |
| 19:54.21 | JucaBlues | the only good thing I see in opendwg is their documentation of reverse engineering efforts |
| 19:54.46 | brlcad | dwg would be 'nice' ... but not necessary or a priority frankly given it's a proprietary format that autodesk is intent on defending |
| 19:55.39 | brlcad | our more current efforts have been towards beefing up dxf support (all 3d entities, and now nearly all 2d entities) |
| 19:55.50 | brlcad | and in implementing a full STEP conversion capacity |
| 19:55.56 | brlcad | that's our hot one atm |
| 19:56.01 | brlcad | big project |
| 19:56.30 | JucaBlues | not having dwg support would lead to less poeple adopting freesoftware CAD tools such as brlcad ? (in your opinion) |
| 19:56.33 | brlcad | curious, what do you need dwg for? |
| 19:57.00 | JucaBlues | I am not a CAD user |
| 19:57.07 | JucaBlues | I am a developer wishing to help |
| 19:57.25 | JucaBlues | so, I am not totally aware of users needs |
| 19:57.26 | brlcad | there are so many proprietary CAD formats, no I don't think not supporting dwg would be a major deciding factor for anyone -- it's more about usability and features of the CAD system |
| 19:57.58 | JucaBlues | but it seems to me that support for proprietary file formats would be good in order to lower the barrier to adoption of free software tools |
| 19:58.25 | brlcad | just about every major CAD vendor has a massively popular proprietary format that they default to .. dwg is only as visible as it is because of autocad's big (30% or so) market share |
| 19:59.29 | brlcad | JucaBlues: I'd certainly agree with you there .. it's more a matter of time and priorities, and the payoff (in terms of adoption/users/visibility/etc) |
| 20:00.47 | brlcad | we could spend a lot of time trying to reverse engineer any of the top five proprietary formats, or implement one of several major open interchange formats (that most of the major CAD vendors support) like STEP, IGES, and DXF |
| 20:01.25 | brlcad | the payoff is much greater .. so long as they can export their data from their system and import |
| 20:01.53 | JucaBlues | I have been in touch with free software since my first years at university (2003). Then, since mid-2007 I've been helping Inkscape. In the university I've been advocating alot about freesoftware |
| 20:02.07 | brlcad | starseeker: were you doing a build on mac or linux yesterday when you were fixing src/conv/step? |
| 20:02.11 | JucaBlues | only now, in 2009, we have successfully founded a study group here |
| 20:02.16 | starseeker | brlcad: mac |
| 20:02.20 | brlcad | huh, odd |
| 20:02.24 | starseeker | why, is it busted still? |
| 20:02.27 | brlcad | i'm getting failures on the built sources |
| 20:02.29 | brlcad | yeah, it is |
| 20:02.30 | JucaBlues | and we are now focusing on cad tools |
| 20:02.31 | starseeker | arrrgh |
| 20:02.32 | brlcad | I can fix it, though |
| 20:02.38 | brlcad | JucaBlues: what sort of focus? |
| 20:02.59 | JucaBlues | we are trying to figure out a way of helping free software CAD tools |
| 20:03.04 | brlcad | JucaBlues: and glad to hear about the advocacy, good stuff ;) |
| 20:03.41 | JucaBlues | we are a group of half dozen people and we meet once a week to discuss it |
| 20:03.52 | JucaBlues | some of us are coders |
| 20:04.05 | brlcad | that's where I would emphasize interoperability through the few open standards (if you preserve everything exported, users really don't care) |
| 20:04.10 | JucaBlues | others are more interested in political aspects of the free software movement |
| 20:04.21 | CIA-28 | BRL-CAD: 03starseeker * r34402 10/brlcad/trunk/src/libged/tire.c: Sigh. Try another tread pattern tweak for tire. |
| 20:04.28 | brlcad | STEP is the big one that just about every single major CAD vendor adopted in early 2000's |
| 20:04.50 | brlcad | that was a massive ISO collaboration to 'solve' the interoperability problems and proprietaryness |
| 20:05.16 | brlcad | the only problem for open source is that ISO spec is freaking expensive and enormous (as it's sort of the combination of all CAD formats into one) |
| 20:05.31 | brlcad | fortunately for us, though, we have it ;) |
| 20:05.35 | JucaBlues | expensive?! |
| 20:05.40 | brlcad | ISO |
| 20:05.45 | JucaBlues | isnt it freely distributed just like SVG? |
| 20:05.46 | brlcad | iso sells their specs |
| 20:05.54 | brlcad | like ISO C |
| 20:06.13 | brlcad | you won't just find the C standard floating around the web, you have to buy it |
| 20:07.11 | JucaBlues | sad... |
| 20:07.35 | brlcad | but like I said, not so much an issue with anyone that works with us on step since we have copies of the specification, provided via ARL for BRL-CAD use |
| 20:07.59 | brlcad | yeah, CAD is one of the biggest industries that have the least open source penetration |
| 20:08.08 | brlcad | and massive vendor lock-in through proprietary formats |
| 20:08.22 | brlcad | even ISO STEP is a massive step forward, *ahem* |
| 20:08.42 | brlcad | much better than the alternatives |
| 20:09.20 | brlcad | but it's not all about the file formats.. that's only a small piece to the puzzle, and one I'd argue that's not nearly as important as, say, usability and features |
| 20:09.33 | brlcad | usability in particular |
| 20:09.37 | JucaBlues | can brlcad be easily used for 2d architecture work? or is it really a CAD tool focused in engineering ? |
| 20:10.37 | brlcad | it can be (and has been) used for 2d and architecture work, it's just not an area of emphasis (read: an area the current core devs focus on) |
| 20:10.53 | JucaBlues | ok, cool |
| 20:11.08 | brlcad | here's a broad brush-strokes overview of the main areas being worked: http://brlcad.org/BRL-CAD_Priorities.png |
| 20:11.46 | brlcad | turning brl-cad into a fully hybrid modeler, bolstering the open source community, improved infrastructure, and a better gui |
| 20:12.12 | brlcad | we have a ton of functionality (more than blender believe it or not), but you wouldn't know it given our gui/usability |
| 20:12.41 | JucaBlues | but it has fundamental differences if compared to blender, right? |
| 20:12.57 | brlcad | so a lot of work is going into strapping up a new interface, making the existing binaries be plugin functionality to that new interface |
| 20:13.05 | brlcad | absolutely |
| 20:13.10 | brlcad | blender is a content modeler |
| 20:13.23 | brlcad | content modelers are horribly suited for CAD work, at a fundamental level |
| 20:14.37 | brlcad | akin to the fundamental difference between other commercial content modelers like 3D Studio MAX or even Maya .. compared to the likes of AutoCAD, Solidworks, NX, CATIA, Pro/E |
| 20:14.43 | brlcad | night and day |
| 20:14.57 | brlcad | the similarities sort of end at "they both deal with modeling" |
| 20:16.00 | JucaBlues | I got impressed by brlcad statistics (such as 20 years old development history). Does it still have funding from US government? Is the core dev team employed to develop it? |
| 20:16.06 | brlcad | JucaBlues: so do you have a goal or just surveying what's out there or looking for a niche to work on or ..? |
| 20:16.45 | brlcad | yeah, the project was started circa 1979, first release in 1984, so more than 25 years now |
| 20:17.01 | brlcad | it is still majorly funded by ARL |
| 20:17.53 | brlcad | many of the devs have full-time jobs with ARL, but not all, and even many of those that are employed invest even more time outside of work of their own volition |
| 20:18.44 | JucaBlues | we are committed to using free software on one of our university labs (we are the guys who removed MSWindows from those PCs) and now we have to figure out how to provide free software solutions to the needs of the projects that are developed in this lab |
| 20:19.07 | brlcad | I estimated a while back that the open source contributors will probably exceed the funded contributors in two or three years if our rate of development continues to increase and the open source community continues to grow (which would be awesome) |
| 20:20.34 | brlcad | well we are the *only* open source CAD system that's actually in production use, of production quality, but we are certainly very far off from most of the commercial codes (particularly wrt usability) too |
| 20:20.39 | brlcad | ;) |
| 20:20.47 | brlcad | nice to hear that commitment, though |
| 20:21.19 | JucaBlues | we figured out that most of the projects there will need CAD. So we started this research initially focusing on CAD tools. We nedd to (1) tell them which free software they should use. (2) set up the machines (install/compile it) and (3) provide guidance (tutorials/courses) |
| 20:22.58 | JucaBlues | and we think that we should code stuff in case we figure out that the available solutions are still not enough |
| 20:23.11 | brlcad | our biggest issue in terms of replacing something like autocad is drafting facilities (2d sketch support needs more work), constraints and parametric support (a GSoC project now for the second year), and gui usability (huge overhaul effort under way) |
| 20:24.04 | JucaBlues | are there tutorials available regarding the 2d stuff? where can I read more about it? |
| 20:24.06 | brlcad | well if you all decide that you're interested in working with brl-cad, you're more than welcome any time |
| 20:24.36 | brlcad | I don't think our goals are separate, more just only so many clock ticks per day and existing core devs are pulled in dozens of directions with goals :) |
| 20:24.49 | brlcad | mmm.. 2d tutorials |
| 20:25.07 | brlcad | yeah .. there are, but it really is sucky |
| 20:25.18 | brlcad | easier to script their use than it is to use the gui |
| 20:25.24 | brlcad | unfortunately |
| 20:25.57 | brlcad | not sure where they're at though.. hm. |
| 20:30.30 | brlcad | for what it's worth, another reason the 2D support is minimal is that most of the industry has moved away from utilizing a 2D drafting approach as the foundation, instead modeling directly in 3D with 3D techniques and deriving 2D as needed |
| 20:31.12 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 20:31.14 | brlcad | plus we're a solid modeler, so 2D entities are totally second-class citizens .. you can't do anything with them without an extrusion/sweep/revolve operation to define a volume :) |
| 20:31.35 | brlcad | similar to how the big-boys treat them, just with a worse 2D sketcher :) |
| 20:33.38 | JucaBlues | (sorry ... I was on telephone here) |
| 20:34.14 | JucaBlues | so... it is cool to hear that there is 2d support even though it seems to be minimal and not very user friendly |
| 20:34.15 | brlcad | np |
| 20:34.21 | brlcad | I rant from time to time ;) |
| 20:34.32 | brlcad | yeah, the support is totally there engine-wise |
| 20:34.37 | brlcad | gui-wise, it's teh suck |
| 20:35.02 | JucaBlues | I am participating on GSoC again this year (in inkscape), so I cant get committed to another project right now |
| 20:35.26 | brlcad | that's why we can import a DXF nearly faithfully, most of their entities (2d and 3d) transcribes to one of our entities |
| 20:35.28 | JucaBlues | but I will inform my colegues about it |
| 20:35.36 | brlcad | cool |
| 20:35.51 | brlcad | well if you want to dabble, or if they want to dabble, welcome to |
| 20:36.05 | brlcad | commit access is an easy deal for competent folks :) |
| 20:36.20 | brlcad | what's your gsoc project? |
| 20:36.26 | JucaBlues | ok. is there a subset of the coders who are most familiar with the 2d stuff (gui and core) ? |
| 20:36.37 | JucaBlues | who sould I contact? |
| 20:37.00 | brlcad | best to just ask in here or on the brlcad-devel mailing list, someone will chime in |
| 20:37.09 | brlcad | highly likely I will answer if someone else doesn't :) |
| 20:37.34 | JucaBlues | ok. are you sort of a project leader? |
| 20:37.35 | brlcad | notes that tendancy even with hundreds of folks on the list :P |
| 20:38.04 | brlcad | yeah |
| 20:38.33 | JucaBlues | May I know your name? Or do you preffer the anonimity? |
| 20:38.41 | brlcad | i'm Sean |
| 20:38.58 | JucaBlues | pleased to meet you, Sean. I am Felipe Sanches. |
| 20:39.20 | madant | :) anonymity .. synonymity rather :D |
| 20:39.24 | brlcad | likewise, pleasure :) |
| 20:39.46 | brlcad | Christopher Sean Morrison in full absurdity longness ;) |
| 20:39.53 | JucaBlues | I think that it is rare to have such a great/fast feedback on other projects irc channels |
| 20:40.26 | brlcad | oh chatter here comes and goes too .. just depends what's going on, I was between commits and almost always available on irc |
| 20:40.27 | JucaBlues | Felipe Corrêa da Silva Sanches in full (mine is longer :-P) |
| 20:40.32 | brlcad | haha |
| 20:41.36 | JucaBlues | ah! My SoC project this year is user interface improvements for CMYK colorspace and ICC color profiles handling in Inkscape |
| 20:42.22 | JucaBlues | Last year I worked on initial implementation of SVG Fonts support in Inkscape (which is one of the features defined in the SVG 1.1 spec) |
| 20:42.26 | brlcad | cool, like preference selection and applying to the current project? |
| 20:43.32 | JucaBlues | color transforming palettes and color pickers using the currently selected target device color profile |
| 20:43.36 | brlcad | thinks it would be awesome to have a brl-cad composite renderer that output svg ... mmm |
| 20:52.45 | CIA-28 | BRL-CAD: 03brlcad * r34403 10/brlcad/trunk/TODO: vector renderer ala rtedge but with vectors instead of raster and with support for filled regions. |
| 20:53.03 | starseeker | brlcad: that needs nurbs, doesn't it? |
| 20:55.39 | brlcad | to be done "well", yeah probably, but depends |
| 20:56.10 | brlcad | i mean rtedge could probably do a fantastic job as it is |
| 20:56.36 | brlcad | with just region tracking and interpolating a spline between contiguous regions |
| 20:57.49 | CIA-28 | BRL-CAD: 03brlcad * r34404 10/brlcad/trunk/ (5 files in 3 dirs): get gone getput() |
| 21:44.51 | CIA-28 | BRL-CAD: 03brlcad * r34405 10/brlcad/trunk/configure.ac: use single tick quotes to avoid escaping |
| 21:49.02 | CIA-28 | BRL-CAD: 03brlcad * r34406 10/brlcad/trunk/src/conv/step/ (Makefile.am needFunc.cc needFunc.h): |
| 21:49.03 | CIA-28 | BRL-CAD: this should at least restore the build to a working state for now. make it an |
| 21:49.03 | CIA-28 | BRL-CAD: EXTRA_PROGRAMS so we can traverse into here even though the fedex stuff isn't |
| 21:49.03 | CIA-28 | BRL-CAD: being generated. (STEP_FEDEX_PLUS, STEP, and STEP_AP203 are not subst'd) few |
| 21:49.03 | CIA-28 | BRL-CAD: other minor changes are keeping 'sources' and headers declared separately for |
| 21:49.05 | CIA-28 | BRL-CAD: consistency. |
| 21:50.05 | CIA-28 | BRL-CAD: 03brlcad * r34407 10/brlcad/trunk/configure.ac: can traverse into src/conv/step again (though it won't do anything due to the EXTRA_PROGRAMS declaration) |
| 22:08.33 | Ralith | brlcad: that *would* be really cool |
| 22:23.34 | CIA-28 | BRL-CAD: 03brlcad * r34408 10/brlcad/trunk/src/conv/step/Makefile.am: don't even make them a clean rule so dist doesn't try to clean them |
| 22:53.18 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 23:26.46 | brlcad | Ralith: so you're ready to take it on? :) |
| 23:26.52 | brlcad | would be a fun little project for someone |
| 23:26.54 | Ralith | hehe |
| 23:27.00 | brlcad | not even that hard really |
| 23:27.14 | Ralith | perhaps once I know my way around librt. |
| 23:27.29 | Ralith | or, even better, once nurbs is working. |
| 23:27.46 | brlcad | even as a sampled approximation, it would look pretty superb |
| 23:27.51 | Ralith | indeed. |
| 23:28.12 | brlcad | with nurbs, you'd still have to figure out the projected contours and those aren't so easy |
| 23:28.15 | Ralith | but then, rtedge's output would give pretty good results just tracing using standard tools, no? |
| 23:30.00 | brlcad | what do you mean? |
| 23:30.45 | Ralith | vector auto-tracers |
| 23:30.52 | Ralith | dunno what they're called |
| 23:31.02 | Ralith | but like in inskcape, you can just tell it to trace a bitmap |
| 23:31.07 | Ralith | inkscape* |
| 23:31.36 | brlcad | right now rtedge fires rays at the model in a grid and looks at each neighbor to a ray to determine if it's on an "edge" |
| 23:31.45 | brlcad | if it is, it renders a pixel for that grid cell |
| 23:31.59 | Ralith | yes. |
| 23:32.03 | Ralith | and then you take that render as an image |
| 23:32.10 | Ralith | and feed it to a vector tracing tool. |
| 23:32.20 | Ralith | tracing as in following the lines, not raytracing |
| 23:32.27 | brlcad | instead of rendering a pixel, it'd probably need to instead store a spline control point on that edge |
| 23:34.16 | brlcad | walking over the grid of results, you could build up the 2d connected spline paths, output as svg |
| 23:34.32 | Ralith | yeah |
| 23:34.35 | brlcad | little more detail than that, but it's the jist |
| 23:34.56 | Ralith | I'm just commenting that output as a plain bitmap could probably be converted into a svg for pretty good results too |
| 23:35.07 | Ralith | albeit not *as* good |
| 23:35.10 | brlcad | and if you threw in some adaptive refinement sampling, the result would probably be pretty indistinguishable from a projected brep |
| 23:35.16 | brlcad | ahh |
| 23:35.17 | brlcad | yeah |
| 23:35.22 | brlcad | I tried that a few years ago |
| 23:35.31 | brlcad | it was pretty bad |
| 23:35.59 | brlcad | reconstructing connectivity based on raster image alone is starting with too much information lost |
