| 01:21.14 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 01:59.54 | *** join/#brlcad keltor (n=keltor@unaffiliated/keltor) | |
| 02:00.23 | keltor | hello - are there any good autocad->mged tutorials? |
| 02:06.59 | brlcad | keltor: there is a pretty extensive mged tutorial series on the website |
| 02:07.35 | brlcad | they start from the ground up and demonstrate basic 3D creation and editing techniques |
| 02:08.16 | keltor | yeah i've been reading it - i think i'm probably just impatient since i'm an autocad user since like 1988 |
| 02:10.05 | brlcad | keltor: as autocad is fairly grounded in a 2D centric approach and drafting operations at heart, you'll find a lot of differences |
| 02:10.56 | brlcad | we're more in line with the likes of catia, unigraphics/nx, solidworks with a fundamentally 3D-based approach |
| 02:11.28 | brlcad | brl-cad does have 2D facilities, but nowhere near on par with autocad, particularly for drafting purposes |
| 02:12.11 | brlcad | 2D sketch objects and drafting-style hidden line drawings/renderings are about as close as we get to that domain |
| 02:12.17 | keltor | i'm very ok with solidworks actually (as well as using inventor rather often) |
| 02:12.31 | keltor | in college that was the 3d cad of choice |
| 02:12.46 | brlcad | http://brlcad.org/w/images/4/44/Industry_Diagram.pdf covers the gist of where we're at |
| 02:13.21 | brlcad | we're actively working on expanding to the left, but that's major long-term effort |
| 02:13.59 | brlcad | autocad is a CADD system, fwiw, to get some bearings |
| 02:15.21 | brlcad | the three I mentioned are more squarely in the larger CAD domain (catia in particular), but that's still a huge domain and the focus is still often CAID purposes |
| 02:15.33 | keltor | yes I'm familar, i generally start with autocad for my base mechanicals designs, then move on to orcad, then proengineer |
| 02:15.40 | keltor | then pspice |
| 02:15.47 | keltor | work is never done ... |
| 02:42.33 | brlcad | heh, quite a fleet of licensing.. |
| 02:44.57 | louipc | hahah |
| 02:45.28 | louipc | yep small shops can't compete, so they pirate :P |
| 02:54.41 | keltor | very true |
| 02:54.59 | keltor | i'm fairly sure we license it all legally |
| 02:55.02 | keltor | lol |
| 02:55.17 | keltor | in some of the cases they are licensing patents from us so ... |
| 08:37.20 | *** join/#brlcad ibot (i=ibot@rikers.org) | |
| 08:37.20 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Release 7.14.8 posted (20090511) || GSoC2009 Next Step: code code, type type, commit frequently while you work! update wiki/blog on daily progress. | |
| 08:38.14 | CIA-79 | BRL-CAD: 03ralith * r35359 10/rt^3/trunk/src/g3d/ (6 files): First attempt at reinstalling the GUI. Not quite what we want yet, but awesome nevertheless. |
| 08:41.44 | Ralith | hehe |
| 08:48.48 | CIA-79 | BRL-CAD: 03ralith * r35360 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx OgreGLWidget.h): Removed the last of the flickering. |
| 08:49.59 | Ralith | If anyone wants to see something neat, how would be a great time to check out g3d |
| 09:02.44 | CIA-79 | BRL-CAD: 03ralith * r35361 10/rt^3/trunk/src/g3d/ (MainWindow.cxx MainWindow.h): Restored widget layout. |
| 09:06.18 | CIA-79 | BRL-CAD: 03ralith * r35362 10/rt^3/trunk/src/g3d/Console.cxx: Made event filtering better behaved. |
| 09:48.19 | CIA-79 | BRL-CAD: 03ralith * r35363 10/rt^3/trunk/src/g3d/Console.cxx: Flipped the event filters the right way around. Not sure how it managed to work originally. |
| 09:52.35 | CIA-79 | BRL-CAD: 03ralith * r35364 10/rt^3/trunk/src/g3d/OgreGLWidget.h: Undefined some dangerous stuff brought in from GLX. |
| 10:48.26 | CIA-79 | BRL-CAD: 03ralith * r35365 10/rt^3/trunk/src/g3d/ (6 files): Partially restored camera controls. |
| 11:18.24 | CIA-79 | BRL-CAD: 03d_rossberg * r35366 10/rt^3/trunk/ (2 files in 2 dirs): typing |
| 12:33.16 | *** join/#brlcad mafm_ (n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) | |
| 12:47.57 | brlcad | Ralith: awesome, can't wait to see it |
| 12:48.30 | Ralith | brlcad: actually, bad news |
| 12:48.37 | Ralith | it turns out this approach massively rapes performance. |
| 12:49.11 | Ralith | relies on glX/wglMakeCurrent which apparently sucks hugely. |
| 12:50.23 | Ralith | frustrating; I just spent all day making it work >:| |
| 12:51.02 | Ralith | I'm presuming that performance is going to matter on typically large models, so I'm going to go back and try some other approaches |
| 12:51.15 | Ralith | I (finally!) got in contact with some knowledgable qt guys and got some suggestions. |
| 12:51.21 | brlcad | rapes performance in what regard? |
| 12:52.03 | Ralith | the 70% CPU on idle regard. |
| 12:52.21 | brlcad | one thing to keep in mind with regards to performance, one thing that will eventually have to be changed is a no-refresh idle loop |
| 12:52.34 | brlcad | so that you only refresh the display when it's invalidated/changed |
| 12:52.42 | brlcad | not XX frames per second all the time |
| 12:52.49 | Ralith | I'm told it might actually copy the entire GPU memory into and out of system memory each flip. |
| 12:52.57 | Ralith | brlcad: okay, that's actually easy. |
| 12:53.00 | Ralith | that's Qt's default >_> |
| 12:53.12 | Ralith | just gotta wire up the camera controls so they let Qt know that it needs redrawing |
| 12:53.49 | Ralith | will try to get the OpenGL thing fixed properly before that, though. |
| 12:53.56 | brlcad | k |
| 12:54.51 | Ralith | I'm correct in considering this kind of performance unacceptable, right? |
| 12:55.24 | brlcad | copying all GPU memory on each frame, .. yeah :) |
| 12:55.32 | Ralith | heh |
| 12:55.35 | Ralith | kk |
| 12:55.46 | Ralith | you might want to play around with the current revision anyway |
| 12:55.48 | Ralith | it's very pretty |
| 12:56.01 | Ralith | although somewhat impractical due to a bug I hadn't gotten around to squashing before discovering the issue |
| 12:56.01 | brlcad | screenshot? |
| 12:56.04 | Ralith | okie |
| 12:56.47 | brlcad | if you can have something stabilized before tuesday, I can give a demo or show screenshots at siggraph |
| 12:57.06 | Ralith | ooo! |
| 12:57.19 | Ralith | I'll see what I can do |
| 12:59.10 | Ralith | brlcad: http://isitloadedyet.com/~ralith/pretty.png |
| 12:59.37 | Ralith | with a medium gray background color that might actually be somewhat practical. |
| 13:00.44 | brlcad | awesome! :) |
| 13:00.49 | brlcad | that is looking good |
| 13:00.58 | Ralith | ^^ |
| 13:01.16 | brlcad | ~Ralith++ |
| 13:01.37 | Ralith | when I eventually get back to this point I'll put some background color on the widgets for the sake of reliable text readability, though |
| 13:02.03 | Ralith | as cool looking as fully transparent backgrounds are, I can see it being a real pain on, say, lit models with both dark and light areas |
| 13:07.57 | *** join/#brlcad samrose (n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) | |
| 13:27.52 | *** join/#brlcad docelic (n=docelic@78.134.206.105) | |
| 13:31.57 | *** join/#brlcad BigAToo (n=BigAToo@208.95.141.188) | |
| 13:34.31 | *** join/#brlcad BigAToo (n=BigAToo@208.95.141.188) | |
| 13:49.20 | *** join/#brlcad elena (n=elena@89.136.118.141) | |
| 13:54.53 | starseeker | Ralith: yeah, semi-transparent is usually the way to go |
| 13:55.36 | louipc | hmm! neat |
| 14:00.04 | starseeker | Ralith: you might jump into that thread and ask if those folks are seeing the same performance hit |
| 14:00.23 | starseeker | Marseyeah seems responsive |
| 14:01.08 | elena | hi starseeker. |
| 14:01.13 | starseeker | hey elena |
| 14:01.17 | starseeker | how goes it? |
| 14:01.18 | elena | how are you? |
| 14:01.23 | elena | very good! |
| 14:01.41 | elena | except i'm upset with g-vrml. |
| 14:01.46 | elena | it's very slow. |
| 14:01.51 | starseeker | can't say he's surprised |
| 14:02.16 | elena | i try to convert the havoc example and it's running for 45mins and hasn't stop |
| 14:02.19 | brlcad | most of the tessellating exporters are very slow, and may not even successfully complete |
| 14:02.40 | elena | :( |
| 14:02.49 | elena | that takes out one of the features. |
| 14:02.53 | elena | of the site. |
| 14:02.58 | brlcad | hm, that's pretty long, even for havoc |
| 14:03.04 | elena | i finished rendering and conversion code. |
| 14:03.24 | elena | you can upload a bunch of formats and they get converted to g |
| 14:03.27 | brlcad | i don't see a g-vrml running on .bz, was this local? |
| 14:03.42 | elena | then they get rendered and they you can convert to other formats too |
| 14:03.46 | brlcad | cool |
| 14:04.00 | brlcad | there does need to be some sort of awareness of the underlying geometry type |
| 14:04.03 | elena | so i enabled vrml conversion. ppl with vrml plugins can see what they will get |
| 14:04.12 | elena | before downloading brlcad + model. |
| 14:04.18 | brlcad | so when you convert, you can determine whether it was faithful or lossy |
| 14:04.56 | elena | i'd say it's almost always lossy. |
| 14:05.06 | elena | but the original file is always available. |
| 14:05.07 | brlcad | e.g., g-vrml of havoc is lossy because it's going from primitives with CSG boolean operations to an evaluated polygonal mesh format |
| 14:05.19 | brlcad | right, most are lossy, but some aren't |
| 14:05.40 | brlcad | if havoc were a polygonal mesh to start with, then g-vrml would have been lossless |
| 14:05.54 | elena | btw, should i put the code on the old server, or the new one? |
| 14:06.13 | elena | how can I tell what type is it? |
| 14:06.42 | brlcad | that's a good question |
| 14:06.48 | elena | oh, btw, I'm thrilled about the raytracing stuff. |
| 14:07.13 | brlcad | some you know what type it is simply by the file format, because some file formats only support one type |
| 14:07.16 | elena | I create a file with matrices and commands for rt for all the raytracings and then with a single rt command i get all the images. |
| 14:07.30 | elena | so i don't have to start it each time for each image. |
| 14:07.54 | brlcad | e.g., stl, vrml, ply are all evaluated polygonal/triangle mesh explicit boundary representation formats |
| 14:08.13 | brlcad | woot, way to use rt scripting :) |
| 14:08.28 | elena | however, I have one question. |
| 14:08.40 | elena | i've noticed that I have to do units mm |
| 14:09.00 | elena | or the values in saveview will not match the values from the view command. |
| 14:09.12 | elena | but there is still a small difference between them. |
| 14:09.19 | elena | if i say saveview |
| 14:09.42 | elena | i'll get in the file something like eye_pt 1000 1000 1000 let's say. |
| 14:09.59 | elena | but if I do view eye in mged i'll get something less |
| 14:10.04 | elena | like 950 950 950 |
| 14:10.10 | brlcad | hum |
| 14:10.17 | elena | i can provide a real example if you want. |
| 14:10.19 | brlcad | sounds like unexpected behavior to say the least |
| 14:10.24 | brlcad | possibly a bug |
| 14:10.36 | elena | ah. ok. |
| 14:11.15 | elena | it's not a big difference, and the images look the same. I was just curios where could the difference came from. |
| 14:11.20 | CIA-79 | BRL-CAD: 03bob1961 * r35367 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Tweak dbExpand in ArcherCore. |
| 14:11.53 | elena | initially, i had cm units and besides the value diference there was also a 10x difference. |
| 14:12.19 | elena | g-vrml still working on havoc. 53mins. |
| 14:12.37 | elena | and 13mb written. :( |
| 14:16.37 | CIA-79 | BRL-CAD: 03bob1961 * r35368 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added a createWrapper and modified "make" and "cp" to call it. Also brought the "in" command into the undo framework. |
| 14:16.59 | brlcad | see if it completes, it may |
| 14:17.05 | elena | at this poin, user will probably want to download the much slower g file :) |
| 14:17.11 | elena | slower => smaller. |
| 14:18.03 | brlcad | another thing to consider given it takes that long is that you could queue up conversions to happen idlely in the background when a geometry is uploaded, so once you have the vrml, you don't have to convert it again |
| 14:18.32 | elena | i did this. |
| 14:18.50 | elena | all convertions and raytracing is done in a queue. |
| 14:18.51 | brlcad | otherwise, you just tell them "thanks for your request .. it's been queued for processing .. eta [random] hours" :) |
| 14:19.12 | elena | the submission process is not blocked. |
| 14:19.53 | brlcad | fwiw, havoc is particularly expensive to convert because it's fully CSG |
| 14:19.59 | brlcad | there's a lot of booleans that have to be evaluated |
| 14:20.26 | elena | so i picked the wrong one to mess with :D |
| 14:20.40 | elena | the truck.g was quite fast. |
| 14:20.44 | elena | about 10s |
| 14:21.26 | brlcad | yeah, truck is tiny in comparison |
| 14:21.38 | brlcad | even havoc is pretty small compared to a full vehicle |
| 14:22.40 | elena | about the web server? should I start uploading on the current server? |
| 14:29.48 | brlcad | wherever you've been uploading, I'd just keep on there |
| 14:29.59 | brlcad | so old is fine, or new if you already started |
| 14:30.26 | elena | ok. old it is then. |
| 14:33.24 | *** join/#brlcad BigAToo1 (n=BigAToo@host-69-95-46-65.spr.choiceone.net) | |
| 14:34.08 | elena | is there a doc about the rt commands? |
| 14:34.24 | elena | i only know the ones from the saveview file. |
| 14:35.37 | brlcad | mm.. |
| 14:35.39 | *** join/#brlcad BigAToo2 (n=BigAToo@208.95.141.188) | |
| 14:36.02 | CIA-79 | BRL-CAD: 03ebautu * r35369 10/web/trunk/htdocs/more/sites/all/modules/brlcad/scripts/ (7.14.txt generic.txt): New tcl script output format (raytracing is done outside the script in a separate run). |
| 14:36.30 | brlcad | i don't think so |
| 14:37.32 | brlcad | but you can see the list of commands in http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/rt/do.c?view=markup around line 1009 |
| 14:37.48 | elena | thank you. |
| 14:39.39 | CIA-79 | BRL-CAD: 03ebautu * r35370 10/web/trunk/htdocs/more/sites/all/modules/brlcad/ (brlcad.inc brlcad.module): Updated code to raytrace all images with a rt script (prevents PHP from crashing due to processes overlap). Updated code for conversion. |
| 14:41.00 | elena | ok. then I know almost half of them. ;) |
| 14:44.49 | starseeker | wonders if anyone has attempted to build BRL-CAD on minix 3 |
| 14:47.54 | CIA-79 | BRL-CAD: 03ebautu * r35371 10/web/trunk/htdocs/more/sites/all/modules/light_download_count/ (5 files): Lightweight download counter custom made module (works with private and public downloads) |
| 15:04.59 | brlcad | heh, I have a minix 3 disk sitting right in front of me |
| 15:05.35 | brlcad | one of the minix devs was at the mentor summit and was pretty interested in getting brl-cad working |
| 15:10.52 | CIA-79 | BRL-CAD: 03ebautu * r35372 10/web/trunk/htdocs/more/.htaccess: .htaccess setup for tracking downloads |
| 15:14.26 | CIA-79 | BRL-CAD: 03ebautu * r35373 10/web/trunk/htdocs/more/sites/all/themes/fireflystreamcom/ (node-model.tpl.php style.css template.php): Custom model themeing |
| 15:28.16 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 15:33.02 | CIA-79 | BRL-CAD: 03brlcad * r35374 10/brlcad/trunk/TODO: |
| 15:33.04 | CIA-79 | BRL-CAD: new tool that reports summary information about a given geometry file such as |
| 15:33.06 | CIA-79 | BRL-CAD: object types used, classes of geometry representations used, and more. most |
| 15:33.08 | CIA-79 | BRL-CAD: usefully for the web interface to be able to introspect on a geometry file to be |
| 15:33.10 | CIA-79 | BRL-CAD: able to classify and compare imported geometry. |
| 15:42.18 | CIA-79 | BRL-CAD: 03starseeker * r35375 10/brlcad/trunk/ (14 files in 8 dirs): Rename bbsize to bb, add -c option to create bounding box, fix NEWS item to refer to bb not bbsize |
| 16:11.09 | CIA-79 | BRL-CAD: 03ebautu * r35376 10/web/trunk/htdocs/more/sites/all/themes/fireflystreamcom/style.css: Fixed slogan theme bug. |
| 16:25.32 | CIA-79 | BRL-CAD: 03irpguardian * r35377 10/brlcad/trunk/src/proc-db/human.c: |
| 16:25.34 | CIA-79 | BRL-CAD: Added support for individual person regions in the makeArmy command. |
| 16:25.36 | CIA-79 | BRL-CAD: Each human model's region is numbered in the same manor the parts are numberd: |
| 16:25.38 | CIA-79 | BRL-CAD: Body.r0.... Body.r12.... etc. |
| 16:32.44 | CIA-79 | BRL-CAD: 03starseeker * r35378 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: Print out some more type identifications to get a better idea of what exactly is contained in the 3dm m_object_table. |
| 16:47.22 | CIA-79 | BRL-CAD: 03jdoliner * r35379 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: Implemented surfacesurfaceintersect which facilitates finding starting points of intersection, walking intersections and removing starting points once they've been crossed. |
| 16:48.04 | elena | g-vrml took about 4h on havoc |
| 16:50.57 | starseeker | how does the result look? |
| 16:51.09 | elena | 40mb files. |
| 16:51.11 | starseeker | is actually a bit surprised it succeeded |
| 16:51.20 | elena | my browser plugin hangs when loading it :) |
| 16:51.21 | starseeker | does it visually resemble havoc? |
| 16:51.25 | starseeker | ah |
| 16:51.32 | elena | i 'll try again. |
| 16:51.40 | elena | to load it. |
| 16:51.45 | louipc | :O |
| 16:51.52 | starseeker | might try a standalone viewer |
| 16:52.01 | starseeker | seeks edibles |
| 16:52.57 | louipc | why isn't a screenshot enough? :P |
| 16:53.05 | louipc | err a small render |
| 16:53.17 | elena | it is. i was just curios how long it will take. |
| 16:53.19 | louipc | or a few small renders |
| 16:53.21 | louipc | ah ok |
| 16:53.43 | louipc | it bugs me how every application is being thrown onto the web these days :P |
| 16:54.23 | starseeker | is old school - don't want my apps in a browser |
| 16:55.18 | louipc | especially when it comes to flash haha |
| 16:56.09 | louipc | hopefully that'll be disappear as html5 support improves though |
| 16:57.46 | elena | i have freewrl. doesn't seem to handle havoc.vrml very well. |
| 16:58.17 | CIA-79 | BRL-CAD: 03irpguardian * r35380 10/brlcad/trunk/src/proc-db/human.c: |
| 16:58.21 | CIA-79 | BRL-CAD: Added individual bounding boxes to makeArmy command. No hollow region support yet. |
| 16:58.27 | CIA-79 | BRL-CAD: Named as such: Box.r# |
| 17:02.16 | *** join/#brlcad mafm (n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) | |
| 17:03.43 | *** join/#brlcad talcite (n=matthew@206-248-128-129.dsl.teksavvy.com) | |
| 17:05.48 | CIA-79 | BRL-CAD: 03starseeker * r35381 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: Few more formatting tweaks in debug output of 3dm-g. Names such as '(#101029) PIPE' are a problem for e * in MGED - maybe such things should be 'cleaned up' a little? |
| 17:10.45 | brlcad | starseeker: surprised there's not a polymorphic way to dump/print the types -- should just need a parent type |
| 17:11.11 | brlcad | i.e., there should be a polymorphic way :) |
| 17:14.40 | starseeker | brlcad: probably - I was just doing a quick extension of what Dave had originally done |
| 17:14.54 | starseeker | in the end, the whole thing will probably go away |
| 17:15.22 | starseeker | needs to figure out what to do with InstanceRef |
| 17:15.38 | brlcad | dave was not adept in c++, so caution |
| 17:15.53 | starseeker | ah, k |
| 17:21.29 | CIA-79 | BRL-CAD: 03ebautu * r35382 10/web/trunk/htdocs/more/sites/all/modules/fivestar/ (89 files in 17 dirs): Fivestar update (1.16) - fixed average votes display bug |
| 17:34.01 | starseeker | blinks in surprise as 3dm-g on the openmoko.3dm largely succeeds this time... |
| 17:34.14 | starseeker | aaaaaaand kills the raytrace by asking for too much memory |
| 17:39.36 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 17:45.42 | talcite | hey starseeker |
| 17:45.56 | elena | hi talcite |
| 17:46.03 | talcite | did you get my message last night about the macros? |
| 17:46.14 | talcite | hi elena |
| 17:49.02 | brlcad | talcite: thanks for the RFE, think I have a working solution that should help |
| 17:49.22 | *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net) | |
| 17:49.22 | talcite | brlcad: not a problem. Thanks for fixing it quickly |
| 17:49.34 | brlcad | not technically a bug, though, fwiw ;) |
| 17:49.52 | talcite | brlcad: I think there might be an issue with fedora's compatibility with the configure script |
| 17:50.15 | brlcad | how so? |
| 17:50.31 | talcite | brlcad: the macro enabling the include for Xutils.h doesn't get enabled by the configure script |
| 17:50.51 | brlcad | I read a bit of the log from many hours back -- there are a few options that should help package configuration/integration |
| 17:51.01 | talcite | it's searching in /usr/X11, but that doesn't exist in fedora |
| 17:51.10 | brlcad | the macro -- which macro? |
| 17:51.23 | brlcad | we don't do much X11 testing directly, we rely on automake's tests |
| 17:51.29 | talcite | HAVE_X11_XLIB_H |
| 17:51.40 | brlcad | that's not a macro :) |
| 17:51.54 | talcite | ahh, precompiler directive? I never know the proper term for them heh |
| 17:52.13 | brlcad | yeah, that's a preprocessor define |
| 17:52.30 | brlcad | set by configure when it finds a header |
| 17:53.01 | talcite | anyways, the define doesn't get set by the configure script, and I do have the header |
| 17:53.36 | talcite | it's in /usr/include/X11, not /usr/X11 |
| 17:53.42 | louipc | I don't have /usr/X11 either |
| 17:53.46 | talcite | hmm |
| 17:53.58 | louipc | seemed to work alright for me |
| 17:54.14 | talcite | I wonder why I'm failing this test then |
| 17:54.41 | talcite | my bash isn't great. This configure script is really complex |
| 17:54.46 | brlcad | talcite: back up some .. |
| 17:54.55 | brlcad | what is your goal? |
| 17:55.11 | talcite | brlcad: to compile it first, then to package it from source |
| 17:55.46 | brlcad | okay, so then what is your configure line |
| 17:56.13 | talcite | ./configure --disable-jove --with-tclconfig=/usr/lib64/ --with-tkconfig=/usr/lib64/ |
| 17:56.38 | brlcad | oof, tcl/tk overrides are a bear .. |
| 17:56.40 | brlcad | okay |
| 17:57.02 | brlcad | so that means it's going to try to autodetect nearly everything else given you're not using --enable-all or --disable-all |
| 17:57.22 | talcite | --enable-all? hmm |
| 17:57.23 | brlcad | so configure completes presumably, yes? then compile fails at some point? |
| 17:57.30 | talcite | brlcad: yes |
| 17:57.42 | talcite | the XVisualInfo struct isn't defined |
| 17:57.49 | talcite | because Xutils.h isn't being included |
| 17:58.05 | brlcad | so then can you pastebin up your configure output? |
| 17:58.15 | talcite | sure |
| 17:59.12 | talcite | brlcad: http://fpaste.org/paste/20290 |
| 18:07.32 | brlcad | hm, looks like your version of AC_PATH_XTRA is not setting the have_x variable |
| 18:07.41 | brlcad | what's your version of autoconf? |
| 18:11.22 | talcite | brlcad: 2.63 |
| 18:12.08 | talcite | brlcad: sorry I'm not very familiar with AC. I'm not running autoconf am I? I just ran the configure script |
| 18:12.55 | brlcad | autoconf is run during autoreconf or autogen.sh in order to generate the configure script |
| 18:13.05 | brlcad | that's probably why - you're using a very recent version |
| 18:13.13 | brlcad | they probably changed the interface slightly |
| 18:13.47 | talcite | brlcad: but I've never run autoreconf or autogen.sh. Should I have? |
| 18:13.49 | brlcad | edit configure.ac and delete the three lines that are wrapped in have_x |
| 18:13.56 | brlcad | oh! |
| 18:14.22 | talcite | I just ran the configure script that was already present in the tar.bz2 |
| 18:14.28 | brlcad | hold on then.. that could be the issue -- AC_PATH_XTRA needs to be regenerated for your newer system |
| 18:14.31 | brlcad | right |
| 18:14.33 | talcite | ahh |
| 18:14.58 | brlcad | basically an autoconf 'bug' for loose definitions of bugs, but a problem nonetheless |
| 18:15.48 | brlcad | the configure script you generate on one system 'should' work on any other system, but that's only true 99% of the time as there are bugs and updates that are required for newer configurations |
| 18:16.00 | brlcad | try running "sh autogen.sh" |
| 18:16.12 | brlcad | should take just a couple minutes |
| 18:16.20 | brlcad | then re-run configure |
| 18:16.40 | brlcad | then look for HAVE_X11 in include/brlcad_config.h |
| 18:16.48 | talcite | sounds good. I'll give that a shot |
| 18:17.02 | talcite | thanks for the help |
| 18:20.32 | brlcad | I have a change that might avoid the problem down the road |
| 18:20.44 | brlcad | but will still be good to know if that fixes it |
| 18:20.59 | talcite | brlcad: k. I'm running configure now |
| 18:22.49 | CIA-79 | BRL-CAD: 03brlcad * r35383 10/brlcad/trunk/configure.ac: don't use/assume have_x will be defined. just do a header test right here. might need more cppflags logic to search in the dirs we just found from ac_path_xtra |
| 18:23.20 | talcite | brlcad: yup, it works now |
| 18:23.36 | brlcad | cool |
| 18:23.37 | louipc | sweet |
| 18:23.41 | talcite | I'll try compiling, but it should work |
| 18:23.53 | talcite | yeah, that was quite the bug =S. I've never run into that before |
| 18:24.05 | brlcad | so there's some magic that 2.63 added in for it to properly detect X11 and set have_x for your system |
| 18:25.03 | brlcad | commit should hopefully avoid the issue, but all we can do on our end is try to be sure to use at least 2.63 when generating configure for our source tarballs |
| 18:25.06 | brlcad | come release time |
| 18:25.32 | louipc | when's the next one planned for? |
| 18:25.36 | talcite | what system do you do the compiling on? |
| 18:26.06 | brlcad | louipc: any day, hopefully before friday |
| 18:26.12 | louipc | cool! |
| 18:26.26 | talcite | haha should I wait to do the packaging then? |
| 18:26.30 | brlcad | we missed two iterations unfortunately |
| 18:26.36 | louipc | talcite: good idea :D |
| 18:27.04 | talcite | alright. Let me get the hang of the ogl and optimize builds in the mean time |
| 18:27.05 | brlcad | talcite: heh, not really -- at best all that should change is the patch number in your script |
| 18:27.27 | brlcad | you don't really need ogl, don't recommend it for a release configuration |
| 18:27.33 | talcite | ahh ok |
| 18:27.54 | brlcad | it's good on a per-system basis but there are some systems that have really bad behavior |
| 18:28.19 | brlcad | doesn't limit functionality or performance on our end, it's just the protocol we talk in our display management system on the backend |
| 18:28.29 | talcite | oh ok |
| 18:28.31 | louipc | I guess the user should decide what to use then |
| 18:28.37 | brlcad | X11 is just fine (and can actually out-perform in many cases) |
| 18:28.51 | talcite | haha well then no reason to use ogl |
| 18:28.59 | brlcad | not yet |
| 18:29.05 | louipc | heheh |
| 18:29.13 | talcite | yeah, I heard Ralith just got Qt embeds working |
| 18:29.15 | brlcad | we've got a dev working on a nice shaded display interface that is really snazzy |
| 18:29.23 | brlcad | and it uses ogl with ray-tracing |
| 18:29.28 | talcite | haha sweet |
| 18:29.30 | louipc | I want to get mged in the framebuffer :D |
| 18:30.32 | brlcad | talcite: yeah, though that's for longer-term development effort -- new gui interface that will likely supplant current in 4 years or so (prototype much earlier than that though) |
| 18:30.59 | brlcad | prototype hopefully before this year's end |
| 18:31.14 | talcite | whoa. no kidding. You're not worried that Qt will deprecate the API call? |
| 18:31.26 | brlcad | not at all |
| 18:31.47 | brlcad | it's under continuous development -- if they change things we'll be changing right along |
| 18:32.08 | talcite | I see |
| 18:32.12 | brlcad | it'll simply take that long to bring the interface up to a capability level on par with mged/archer |
| 18:32.33 | brlcad | plan is mged -> archer -> new gui |
| 18:33.03 | brlcad | archer is about ready to demo now, nearing alpha stage, and will carry the gui for at least a couple years |
| 18:33.08 | brlcad | while the new one gets worked on |
| 18:33.25 | talcite | when do you think Archer will be released? |
| 18:33.27 | brlcad | rolling updates, can't abandon existing userbase |
| 18:33.47 | brlcad | that one should go full alpha before year's end |
| 18:33.47 | talcite | ahh |
| 18:34.06 | brlcad | beta later in the year |
| 18:34.13 | brlcad | maybe final by end of 2010 |
| 18:34.23 | talcite | heh you guys seem to have a pretty strong development timeline |
| 18:34.34 | brlcad | around that time, new gui should be about ready for alpha |
| 18:39.36 | talcite | blam. another build error =D |
| 18:40.12 | brlcad | paste? |
| 18:40.28 | talcite | coming up |
| 18:40.35 | brlcad | there are a few known issues with the 7.14.8 build that have since been fixed |
| 18:40.41 | talcite | http://fpaste.org/paste/20296 |
| 18:40.42 | brlcad | particularly with regards to mixed system installs |
| 18:40.46 | talcite | it's a java error |
| 18:41.10 | brlcad | wow, that's a new one |
| 18:41.15 | talcite | I hope it's not because I'm using openJDK instead of sunJava |
| 18:41.43 | brlcad | yeah, looks like some bug in fop or java |
| 18:41.47 | louipc | java! |
| 18:41.55 | louipc | crazy |
| 18:41.59 | brlcad | the good news is that the build succeeded |
| 18:42.06 | brlcad | that part of the build is generating documentation |
| 18:42.10 | talcite | ahh it's just documentation stuff |
| 18:42.33 | louipc | I have openjdk too |
| 18:42.35 | talcite | well that's minor, but I should probably fix it anyways |
| 18:42.37 | brlcad | can add --disable-documentation to turn it off |
| 18:43.26 | talcite | hmm... is the documentation useful though? |
| 18:43.45 | louipc | I didn't get any pdfs though.. |
| 18:43.49 | brlcad | given xsltproc processed the first xml file just fine, it may be a typo in build_pattern.xml ( starseeker ) |
| 18:44.01 | talcite | haha |
| 18:44.17 | louipc | ah I don't have 'fop' installed |
| 18:44.23 | brlcad | ah, my bad .. it processed the xml fine to html, just not to .fo for fop |
| 18:44.31 | brlcad | so probably not |
| 18:44.50 | brlcad | talcite: does fop work for you? |
| 18:45.15 | brlcad | and of course the documentation is useful |
| 18:45.17 | brlcad | just not necessary :) |
| 18:45.21 | talcite | brlcad: hmm I've never used fop before |
| 18:45.35 | talcite | it seems to work more or less |
| 18:45.38 | brlcad | there are extensive docs on the website, and other docs that get installed too |
| 18:46.10 | brlcad | dunno what to say on that one -- looks like an fop issue |
| 18:46.15 | louipc | html docs are good enough |
| 18:46.47 | brlcad | could try running /usr/bin/fop build_pattern.fo -pdf build_pattern.pdf manually |
| 18:46.58 | talcite | yup, that's my plan so far |
| 18:47.05 | talcite | I need to find it first though |
| 18:47.31 | brlcad | doc/docbook/articles/build_pattern/en |
| 18:47.42 | talcite | thanks |
| 18:49.16 | talcite | nope, same problem |
| 18:49.54 | talcite | wait, there's something weird |
| 18:50.05 | talcite | build_pattern.fo doesn't exist |
| 18:50.26 | talcite | [matthew@desktop en]$ pwd |
| 18:50.26 | talcite | /home/matthew/Download/brlcad-7.14.8/doc/docbook/articles/build_pattern/en |
| 18:50.26 | talcite | [matthew@desktop en]$ ls |
| 18:50.26 | talcite | build_pattern.html build_pattern.xml Makefile Makefile.am Makefile.in |
| 18:51.12 | talcite | brlcad: and I'm getting the same error as the build_pattern.fo command |
| 18:52.01 | CIA-79 | BRL-CAD: 03irpguardian * r35384 10/brlcad/trunk/src/proc-db/human.c: |
| 18:52.03 | CIA-79 | BRL-CAD: Made it where the makeArmy command now places all humans into Crowd.c combination, for easy access to all |
| 18:52.06 | CIA-79 | BRL-CAD: persons. |
| 18:52.34 | brlcad | right, the .fo is what it generates |
| 18:52.55 | brlcad | er, rather -- hmm |
| 18:53.14 | brlcad | does this generate the .fo? XML_CATALOG_FILES=../../../../../doc/docbook/catalog.xml /usr/bin/xsltproc -nonet -xinclude -o build_pattern.fo ../../../../../doc/docbook/resources/standard/xsl/fo/docbook.xsl build_pattern.xml |
| 18:53.43 | brlcad | according to the log, it did |
| 18:55.42 | talcite | hmm that's strange. The file isn't there |
| 18:55.54 | talcite | maybe fop removes the input file? |
| 18:57.40 | talcite | hmm no... well anyways I've created the file, but it still NPEs |
| 18:59.06 | brlcad | yeah, sounds like an fop bug if xsltproc generates it correctly |
| 18:59.16 | brlcad | or maybe a version mismatch between the two |
| 18:59.30 | brlcad | or a problem with java |
| 18:59.40 | brlcad | either way, --disable-documentation :) |
| 19:00.05 | talcite | haha I guess it works temporarily. I'll probably need to get it fixed before the fedora repo maintainers will allow it for inclusion though |
| 19:01.12 | talcite | lets see if it's still an issue in the next release |
| 19:09.46 | brlcad | hm? you mean hold up our inclusion because fop doesn't work? that's kinda silly |
| 19:10.30 | brlcad | only thing we can do on our end is default it to off so you don't need to specify the disable |
| 19:12.32 | talcite | hmm. I guess I could always just build the documentation package seperately when fop works again |
| 19:14.52 | talcite | is there a listing of configuration options? |
| 19:15.18 | brlcad | INSTALL file |
| 19:15.29 | talcite | thanks |
| 19:15.41 | louipc | ./configure --help too |
| 19:18.35 | talcite | is there a reason the debug symbols are enabled by default? |
| 19:20.19 | brlcad | yep, for debuggability, stack traces |
| 19:20.38 | brlcad | we have automatic crash reports that can get generated if something goes horribly wrong |
| 19:20.43 | talcite | brlcad: Is there a big hit on performance if it's enabled? |
| 19:20.52 | brlcad | nope, not at all |
| 19:20.59 | talcite | ahh ok. So I should leave them in for the package |
| 19:21.13 | brlcad | --enable-optimized will give a huge performance difference |
| 19:21.19 | brlcad | nearly 2x on rendering performance |
| 19:21.26 | talcite | yup. I just set that configure flag |
| 19:21.48 | brlcad | it'll also make compilation take 2x ;) |
| 19:21.55 | talcite | brlcad: you mentioned there's a couple flags that make packaging easier? |
| 19:21.57 | talcite | =/ |
| 19:22.05 | talcite | oh well. I'm working from home today |
| 19:23.24 | brlcad | for packaging systems --disable-almost-everything and then specifically enabling anything you won't have |
| 19:23.37 | brlcad | (like tkhtml3 and tnt) |
| 19:23.43 | talcite | oh I see |
| 19:24.20 | talcite | sounds good to me |
| 19:24.44 | CIA-79 | BRL-CAD: 03bob1961 * r35385 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added mirror to the undo framework. Tweaked killWrapper. |
| 19:25.13 | brlcad | wishes bob would push those wrappers down into libged proper |
| 19:27.16 | ``Erik | mebbe if you jerked a couple out from under him, he'd get the idea? |
| 19:27.21 | CIA-79 | BRL-CAD: 03ebautu * r35386 10/web/trunk/htdocs/more/sites/all/modules/brlcad/brlcad.module: Fix metadata editing bug (only editors can edit it now) |
| 19:29.01 | ``Erik | grumbles a bit |
| 19:33.52 | talcite | brlcad: does --disable-almost-everything also disable the --with-x11 etc? |
| 19:34.08 | brlcad | talcite: no |
| 19:34.26 | brlcad | it only disables the various --disable-*-build options, as listed in INSTALL |
| 19:34.39 | talcite | ahh ok |
| 19:34.47 | brlcad | the with flags merely specify how/where to find system services |
| 19:35.17 | louipc | does it automatically check for --disable* flags? |
| 19:37.19 | louipc | ah ok I see :D |
| 19:38.19 | louipc | oh darn I did add tkhtml3 in that switch hah |
| 19:43.04 | talcite | argh I forgot to make -j2 =/ |
| 19:44.42 | starseeker | just Ctrl-c and restart |
| 19:44.47 | starseeker | it will pick up where it left off |
| 19:44.59 | talcite | ahh cool |
| 19:45.25 | talcite | hmm that's right. I forgot make can do that |
| 19:47.37 | talcite | whoa. I'm getting 4x performance after --enable-optimized |
| 19:47.43 | talcite | cool |
| 19:48.19 | louipc | how long did the build take? |
| 19:49.35 | brlcad | talcite: it's interruptible |
| 19:50.06 | talcite | build took about 30 mins, but only because I forgot to use make -j2 =D |
| 19:51.54 | louipc | pretty quick |
| 19:53.23 | talcite | louipc: it's a fairly powerful system by the standards a couple years ago. Core 2 duo, 2 gigs of ram, |
| 19:53.40 | louipc | nice |
| 19:53.49 | louipc | takes me 3hr to build :( |
| 19:53.52 | talcite | =o |
| 19:54.11 | talcite | why not upgrade? you can get a much more powerful system than mine for $500 these days |
| 19:55.36 | louipc | I'm cheap, and I don't do that much compiling I guess |
| 19:55.49 | louipc | or I'm waiting for usb3.0 hahh |
| 19:56.06 | louipc | it'll be out soonish |
| 19:56.57 | talcite | louipc: hmm... well you can probably put usb 3.0 on any system with a PCIE 4x slot |
| 19:57.16 | louipc | that's cheating! |
| 19:57.39 | talcite | they'll release add on cards. It'll be pretty expensive for you to buy a usb 3.0 system right when they come out |
| 19:57.54 | louipc | hmm yeah probably |
| 19:57.59 | talcite | and after they've come out, it'll be at least 2 years till they're coming off lease |
| 19:58.14 | talcite | oh, off lease computers are the secret to getting a good deal |
| 19:58.26 | louipc | what are those? |
| 19:58.42 | talcite | I got a machine capable of a quad core processor, with 2 gigs of ram. for under $300 last year for my work |
| 19:59.02 | louipc | I just bought some parts and threw them in a box |
| 19:59.12 | *** join/#brlcad _sushi_ (n=_sushi_@84-73-206-53.dclient.hispeed.ch) | |
| 19:59.18 | talcite | louipc: businesses and governments usually lease their computers. When the leases expire, they get sold as second hand equipment |
| 19:59.26 | louipc | ohh nice |
| 19:59.31 | talcite | but they're usually in great shape, so it's really cheap |
| 20:00.30 | talcite | louipc: here: http://www.itxchange.com/itxchange/product.asp?part_no=6073-AR4-B3-06&SEORewriteUrlSrc=Website |
| 20:00.50 | talcite | you should check out that site. They're probably the largest supplier of off-lease equipment in the world |
| 20:01.18 | talcite | if you look around more, I'm sure you can find one that has a good chipset and lots of room for upgrades. |
| 20:01.23 | louipc | damn that's pretty cheap |
| 20:02.34 | talcite | yup |
| 20:02.46 | talcite | it's more powerful than my current system if you don't count the graphics card |
| 20:03.06 | talcite | plus they're all fairly linux compatible since they're IBM/lenovo |
| 20:05.06 | talcite | my suggestion is to find a tower model with a motherboard/chipset that takes the quad core processors, like Q35. It gives you a good upgrade path in the future. All of these boards also take up to 16 gb usually |
| 20:05.26 | talcite | they'll also have enough Sata ports to give you raid capability |
| 20:05.41 | talcite | used to do IT purchasing for an NGO |
| 20:05.59 | talcite | had no money, but needed performance =P |
| 20:21.46 | CIA-79 | BRL-CAD: 03starseeker * r35387 10/brlcad/trunk/include/opennurbs_ext.h: |
| 20:21.48 | CIA-79 | BRL-CAD: subdivision size factors can apparently be disabled without impacting the |
| 20:21.50 | CIA-79 | BRL-CAD: raytracing, and VASTLY speeding up prep and lowering memory used. With these |
| 20:21.52 | CIA-79 | BRL-CAD: changes, able to raytrace 900+ breps (some of which have in turn hundreds of |
| 20:21.54 | CIA-79 | BRL-CAD: surfaces) in a surprisingly reasonable time. |
| 20:30.39 | *** join/#brlcad elena (n=elena@89.136.118.141) | |
| 20:32.21 | CIA-79 | BRL-CAD: 03Ebautu 07http://brlcad.org * r1590 10/wiki/More_Changelog: /* July 7 - Today */ |
| 20:32.37 | *** join/#brlcad Patmcc19 (n=chatzill@174-17-160-123.phnx.qwest.net) | |
| 20:41.28 | brlcad | ~elena++ |
| 20:42.32 | brlcad | is curious what an arb8 comparison looks like for the various forms it can exist as now |
| 20:44.11 | brlcad | arb8, nmg, bot, brep (new nurbs), bspline (old nurbs), vol/dsp/ebm (1x1 cell) ... |
| 20:45.09 | brlcad | starseeker: ran across my SPM08 notes .. some good tidbits I'd forgotten -- see if I can post up something |
| 20:49.00 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) | |
| 20:53.03 | talcite | crap... I'm failing the make test now =P |
| 20:54.20 | brlcad | talcite: that's not necessarily anything you're doing wrong |
| 20:54.32 | brlcad | our tests are more meant for devs under controlled environments/settings |
| 20:54.39 | talcite | oh ok |
| 20:54.40 | brlcad | there are plenty that will cause test failures |
| 20:54.56 | brlcad | "make benchmark" is a good validation |
| 20:55.17 | talcite | I see. Well there wasn't any problems with that |
| 20:55.21 | talcite | make install didn't go well either though |
| 20:55.25 | brlcad | running "mged" and having it start up a gui is a good validation |
| 20:55.38 | brlcad | make install didn't work? |
| 20:55.43 | talcite | nope |
| 20:55.50 | brlcad | need a lil more info :) |
| 20:55.52 | talcite | something about overwriting a file that it just created |
| 20:55.59 | talcite | just a sec |
| 20:57.08 | talcite | /usr/bin/install: will not overwrite just-created `/home/matthew/Download/temp/share/man/man3/librle.3' with `librle.3' |
| 20:57.33 | talcite | http://fpaste.org/paste/20314 |
| 20:59.13 | brlcad | looks |
| 21:00.53 | talcite | ok, I'll brb. I need a quick shower before I head out |
| 21:02.56 | brlcad | ahh, damn -- yeah that issue is fixed on head |
| 21:03.06 | brlcad | there's a duplicate entry for librle.3 in 7.14.8 |
| 21:04.28 | brlcad | talcite: can see starseeker's edit on 34667 at http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/other/libutahrle/Makefile.am?view=log to see the 'fix' |
| 21:13.20 | CIA-79 | BRL-CAD: 03bob1961 * r35388 10/brlcad/trunk/src/libged/clone.c: Modified ged_clone (v5 only) to return the name of the clone, as before, as well as a list of all cloned objects. |
| 21:14.29 | talcite | argh. I really need to learn how to use sourceforge better |
| 21:14.33 | talcite | I can't get a diff from it |
| 21:15.07 | talcite | their link to 'patch' gives me some text, but then you can't download from that URL |
| 21:16.11 | CIA-79 | BRL-CAD: 03bob1961 * r35389 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Added clone to Archer's undo framework. |
| 21:16.53 | louipc | seems to work for me |
| 21:19.34 | talcite | =S |
| 21:19.46 | talcite | blah ok, I need to try this later tonight. I've got to head out for a dinner |
| 21:37.44 | CIA-79 | BRL-CAD: 03starseeker * r35390 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: All red for all regions is getting boring - make it random until we figure out if there is color info in there and how to extract it. |
| 21:44.55 | Ralith | starseeker: I'm told the performance issue is a direct result of makeCurrent, and thus rather unavoidable |
| 21:45.12 | Ralith | I have an idea for another approach that's just as good, though |
| 21:45.17 | Ralith | based on the overlay context |
| 21:45.21 | starseeker | cool |
| 21:45.36 | Ralith | it requires OpenGL impl. support but hopefully that's widespread |
| 21:50.14 | starseeker | ah, there we go - much better when it isn't all red: http://bzflag.bz/~starseeker/openmoko_subset.png |
| 21:52.29 | Ralith | oooh :D |
| 21:52.40 | Ralith | since when was NURBS so far along? |
| 21:53.25 | starseeker | a while back now - last major user visible enhancement was when I got the bounding box building to respect trims |
| 21:53.51 | Ralith | pretty nice |
| 21:54.02 | Ralith | what's with that USB port on the bottom of the shot though? |
| 21:54.18 | starseeker | the model as imported has a lot of overlaps |
| 21:54.32 | starseeker | not to mention geometry that doesn't seem to make sense as part of the phone |
| 21:54.48 | Ralith | so it's just oddly positioned in the source files? |
| 21:54.50 | starseeker | all we're doing right now in 3dm-g is sucking in each brep as a region |
| 21:54.55 | starseeker | I think so |
| 21:55.05 | Ralith | kk |
| 21:55.12 | starseeker | not totally sure |
| 21:55.23 | Ralith | could always break out whatever it is that uses 3dm natively |
| 21:55.38 | starseeker | Rhino |
| 21:55.54 | brlcad | starseeker: holy fuck, awesome |
| 21:56.03 | brlcad | pardon my language, that's freaking cool |
| 21:56.15 | starseeker | :-) |
| 21:56.23 | starseeker | here's the wireframe underlay: http://bzflag.bz/~starseeker/openmoko_underlay.png |
| 21:56.49 | starseeker | looks a heck of a lot better when it isn't all red |
| 21:57.06 | brlcad | great gallery shot |
| 21:57.09 | Ralith | ooh |
| 21:57.09 | Ralith | pretty |
| 21:57.12 | brlcad | should add an openmoko section |
| 21:57.22 | Ralith | yeah |
| 21:57.34 | starseeker | heh - start with the historical iges wireframe, and up to the present :-) |
| 21:57.38 | Ralith | so is the NURBS stuff considered to be largely stable? |
| 21:57.49 | brlcad | getting there |
| 21:58.07 | Ralith | looks very solid |
| 21:58.17 | brlcad | still working on improved import paths (3dm and step) |
| 21:58.24 | brlcad | but ray-tracing is looking pretty good |
| 22:00.37 | *** join/#brlcad samrose (n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) | |
| 22:14.54 | CIA-79 | BRL-CAD: 03ebautu * r35391 10/web/trunk/htdocs/more/sites/all/modules/brlcad/ (brlcad.inc scripts/7.14.txt scripts/generic.txt): Implement individual raytracing of models. |
| 23:12.57 | Ralith | brlcad: hm, none of my ideas are working out :/ |
| 23:13.14 | Ralith | I could just get lazy redraw working, minimizing heavy CPU usage to when smooth animation is taking place. |
| 23:13.15 | *** join/#brlcad archivist_ (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 23:14.43 | Ralith | maybe I should just bite the bullet and wrap input |
| 23:17.46 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 23:57.14 | Ralith | what's the easiest way to dig through past revisions' code? |
