IRC log for #brlcad on 20090611

00:13.52 Ralith <3 flyspell-prog-mode
00:15.14 starseeker indianlarry: here's an odd thing - the odd hits in that vertical line on the right of the image seem to be due to a bounding box problem of some sort
00:15.45 starseeker setting ae to 270 0 0
00:15.48 Ralith tries svn again
00:15.51 Ralith yay!
00:15.57 starseeker you see a vertical line all the way up and down the object
00:16.13 CIA-28 BRL-CAD: 03ralith * r34711 10/rt^3/trunk/src/g3d/CMakeLists.txt: Added Qt4 + OpenGL to dependencies cmake is aware of
00:16.44 starseeker if I've got this right, gdb reports five child leaf nodes. All five return hits
00:18.34 starseeker of course, it might be that we need to return two hits somewhere and aren't...
00:22.50 CIA-28 BRL-CAD: 03homovulgaris * r34712 10/brlcad/trunk/src/libpc/ (pcMathGrammar.h pcMathLF.h): Math expression grammer defined (4/4) . lazy function wrapper implementation of address_of
00:27.52 ``Erik svn traps sigterm to try to 'clean up' gracefully
00:28.12 ``Erik if you -9 it, you might need to use "svn clean"
00:30.27 Ralith thanks for the notice
00:30.32 Ralith seemed to ci cleanly, but I'll be sure
00:31.09 ``Erik it'll bitch if it needs it :)
00:31.15 Ralith okay then
00:31.48 Ralith oh cleanup?
00:31.50 Ralith yeah I had to do that
00:32.45 starseeker hmm - weird
00:33.04 ``Erik yes, you are quite weird, cliff :D
00:33.07 ``Erik *duck*
00:33.08 starseeker the problem area is definitely grazing on a trimming curve...
00:33.21 starseeker and proud of it, too!
00:33.33 Ralith hm, cmake screwed up the linking :/
00:36.01 Ralith asks #cmake
00:40.55 Ralith idea!
00:43.22 Ralith ...weird
00:43.41 *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net)
00:43.42 Ralith there's a /lib/rt-2.9.so on my system
00:43.44 Ralith wonder what that is.
00:43.48 Ralith librt-2.9.so*
00:46.37 CIA-28 BRL-CAD: 03ralith * r34713 10/rt^3/trunk/src/g3d/CMakeLists.txt: Fixed Qt linking
00:48.55 starseeker ah, so that's it - utah_newton_4corner returns one hit rather than two, which it should be returning two or zero
00:49.30 starseeker or rather, utah_brep_intersect_test is
00:52.04 starseeker yeah, it's utah_newton_4corner
00:54.28 starseeker wonders if we should multiply the u or v parameter of ray and uv space/curves by a factor so the numbers are less small...
00:54.31 starseeker hmm...
01:13.33 Ralith oh wow
01:13.40 Ralith when did sf.net completely redo their layout
01:24.22 madant Ralith: didn't you get the mail :)
01:27.24 *** join/#brlcad Axman6_ (n=Axman6@pdpc/supporter/student/Axman6)
01:29.47 *** part/#brlcad Axman6_ (n=Axman6@pdpc/supporter/student/Axman6)
01:30.56 starseeker indianlarry: if it helps any, here are two specific cases that are provoking errors - the first one is that long vertical miss due to getting one hit point when two are needed:
01:31.06 starseeker Origin (x y z) = (-3.21022700 -49.92187372 6.84440400)
01:31.09 ``Erik some leenewxes have a librt as an interface to real-time facilities
01:31.18 starseeker Direction (x y z) = (0.00000000 1.00000000 0.00000000)
01:31.33 starseeker second one is a trimming curve related snaffu:
01:31.43 starseeker xyz -1.296691 -0.623331 -0.940507
01:31.50 starseeker dir -0.7424 -0.5198 -0.4226
01:32.07 starseeker (should turn on backout for both of these: backout 1)
01:32.59 starseeker if I'm not mistaken, on the second one it's reporting four hit points but the very first one is getting trimmed away - when I look at the uv values this makes sense so I'm not quite sure what's going on there
01:33.35 starseeker it's only very close to the trimming curves that this happens
01:34.21 starseeker when I plotted the trimming curves over the edges I didn't see any obvious issue where trimming curves were mapping into different lines than the edges were
01:49.22 starseeker if I had to guess, it's something to do with not getting a hit point in the box on the surface above where this trimmed hit was reported
01:56.04 starseeker indianlarry: is there a possibility that when iterating to a solution very close to the edge of a bounding box, the haulting process is too aggressive? I.e., perhaps it should be "if it goes outside and doesn't attempt to come back in on the next iteration?"
01:56.52 starseeker I have a feeling that could be what's going on here, since the trimmed point passed both the linear AND the curved "closest point" on trimming curve based tests
01:56.58 starseeker i.e. it wasn't even "close"
02:04.38 starseeker or, alternatly, it could be not getting all the boxes needed...
02:09.56 *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca)
02:15.43 werneck I'm new to brlcad, I just finished a design, is there any tool to get a 2D print of the blocks, or some CNC output?
02:19.13 starseeker no cnc - if you want a line rendering there's rtedge
02:19.47 starseeker if you need cnc, you can look for export options into formats that can be used to generate cnc paths
02:20.12 starseeker indianlarry: nevermind, allowing iteration outside didn't do anything
02:20.18 indianlarry starseeker: hey just looking over your comments
02:20.43 indianlarry starseeker: i generated some nice images of the black widow
02:21.11 starseeker coool :-)
02:22.18 indianlarry starseeker: need to undefine (//#define) the KTANGENTBREAK in opennurbs_ext.cpp
02:23.08 indianlarry starseeker: otherwise locks in prep(looks to not be converging in the bin iter will look at tomorow'
02:24.28 werneck starseeker: ok, thanks
02:24.45 indianlarry starseeker: still thinking about trying to iterate uphile in oppisite direction
02:25.05 indianlarry starseeker: definitely need something better than the four corner approach
02:26.24 indianlarry starseeker: what dotg are you refering to the nurbs_shape1.g ?
02:26.29 starseeker I can't help thinking that iterating to a "max" point and using that somehow would help
02:26.33 starseeker yes shape1.s
02:26.59 indianlarry starseeker: i'll walk it through the debugger and let you know
02:29.42 starseeker should try to dope out a routine to draw the 3d bounding boxes of every leaf that intersects a ray, just so we can be sure we're getting the right leaves to start with...
02:29.53 starseeker should also get home before he gets in worse trouble...
02:32.00 indianlarry starseeker: why buy a house when you can buy a cheap cot and stay there
02:32.41 starseeker hehe
02:33.21 starseeker can think of few ways of achieving SDDSO (Sudden Death Due to Significant Other)
02:33.47 starseeker few better ways rather
02:34.22 indianlarry gotta keep the significant other happy
02:34.36 indianlarry catch up with you tomorow
02:34.50 starseeker sounds good
02:34.55 starseeker runs for it
02:43.06 brlcad indianlarry: why do you think there's a bed in my office? :)
02:45.09 brlcad good for an emergency early morning crash
02:59.42 werneck is there any way to not hide lines in rtedge?
03:26.20 CIA-28 BRL-CAD: 03ralith * r34714 10/rt^3/trunk/src/g3d/ (CMakeLists.txt OgreGLWidget.cxx OgreGLWidget.h): Untested Ogre Qt widget
03:26.38 Ralith got cmake and qt's metastuff playing together nicely
03:31.12 *** join/#brlcad schwinn434 (n=schwinn4@cpe-75-81-202-25.we.res.rr.com)
03:34.09 CIA-28 BRL-CAD: 03ralith * r34715 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx OgreGLWidget.h): Narrowed include scope, included resource loading, fixed copyright/doc headers
03:39.35 Ralith brlcad: any conventions on exceptions yet?
03:52.22 CIA-28 BRL-CAD: 03ralith * r34716 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx OgreGLWidget.h): Added useful destructor, scene setup; moved resource loading into its own function
03:53.13 Ralith ahh, it's good to be making commits.
04:25.21 starseeker posts this link to himself in case it comes in handy... http://tom.cs.byu.edu/~tom/papers/bezclip.pdf
04:32.05 starseeker indianlarry: much as I hate to suggest this, what about the following approach: In the case where we detect that two intersections are a possibility, and current methods fail to identify two different intersection points, temporarily subdivide the leaf bounding square in uv space into 4 subsquares, take the center of each and iterate - if they all leave the boxes, then the other root (if it exists) must be in the remaining subbox with the existing root
04:33.07 starseeker a bit expensive, but wouldn't it work?
04:44.11 *** join/#brlcad madant_ (n=d@117.196.134.174)
07:11.28 *** join/#brlcad _clock_ (n=_sushi_@84-72-91-14.dclient.hispeed.ch)
07:37.13 *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca)
08:12.56 *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca)
08:57.36 *** join/#brlcad mafm (n=mafm@126.Red-83-45-252.dynamicIP.rima-tde.net)
09:04.14 *** join/#brlcad ChanServ (ChanServ@services.)
09:04.14 *** mode/#brlcad [+o ChanServ] by irc.freenode.net
09:10.12 *** join/#brlcad ChanServ (ChanServ@services.)
09:10.12 *** mode/#brlcad [+o ChanServ] by irc.freenode.net
09:54.54 *** join/#brlcad geocalc (n=geocalc@lns-bzn-38-82-253-99-25.adsl.proxad.net)
12:07.40 *** join/#brlcad docelic (n=docelic@78.134.196.16)
12:30.44 starseeker boots his brain back into gear
13:02.17 *** join/#brlcad madant (n=d@117.196.137.241)
14:05.20 brlcad ``Erik: can metaballs have per point weights?
14:05.40 brlcad or are they uniform across a metaballs set
14:12.06 *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-135.sbndin.btas.verizon.net)
14:15.30 brlcad goes with the per-point theory
14:24.43 CIA-28 BRL-CAD: 03brlcad * r34717 10/brlcad/trunk/src/proc-db/metaball.c: ws while peeking. huh, looks like this was never finished/implemented.
14:44.27 ``Erik heh, they combine a per point weight with a per primitive value and let 'em duke it out
14:46.43 CIA-28 BRL-CAD: 03davidloman * r34718 10/rt^3/trunk/ (cmake/ cmakemodules/): Refactor in prep for converting rt^3 module's build system to cmake.
15:05.43 d-lo Ralith: Since you are making Qt an external dependancy (which is good imho), what about making orge an external one also?
15:08.35 starseeker d-lo: Problem there is we might need to patch Ogre to get it to work, based on last year (IIRC, anyway)
15:09.16 d-lo starseeker: as in a homegrown patch, or a patch from the Ogre devs?
15:15.46 starseeker I THINK it was a homegrown patch, but it's been a while
15:16.07 starseeker 'course, a year might have fixed things on the Ogre side too
15:18.12 d-lo do you recall what issue the patch was concerning?
15:18.50 starseeker nope - I wasn't paying as much attention at that point :-/
15:19.00 d-lo kk thanks anyways
15:19.06 starseeker first thing to do is try the latest Ogre though
15:19.20 starseeker doubts we've synced in a while
15:20.19 starseeker oh, wait - it's coming back a bit - I think RBgui needed some feature that was either being removed or wasn't working in the "release" version of Ogre at that time
15:20.38 starseeker so might be moot for Qt
15:21.44 d-lo ..which would be good :)
15:21.58 d-lo ogre isnt exactly small :)
15:22.17 starseeker agreed
15:22.18 d-lo one might say... its a bit of a beast.
15:22.29 d-lo slaps his knee.
15:25.26 *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-135.sbndin.btas.verizon.net)
15:33.47 *** join/#brlcad fgfdg (n=fdgdfg@71.161.80.190)
15:46.53 *** part/#brlcad fgfdg (n=fdgdfg@71.161.80.190)
17:17.20 *** join/#brlcad BigATo1 (n=BigAToo@pool-96-230-124-25.sbndin.btas.verizon.net)
17:25.29 *** join/#brlcad mafm (n=mafm@199.Red-88-26-141.staticIP.rima-tde.net)
17:45.17 *** join/#brlcad samrose (n=samrose@adsl-68-73-194-95.dsl.sfldmi.ameritech.net)
18:44.39 *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38)
19:24.03 CIA-28 BRL-CAD: 03indianlarry * r34719 10/brlcad/trunk/ (3 files in 3 dirs):
19:24.03 CIA-28 BRL-CAD: fixed trim H/V tangent checks, now using curve estimate of trim versus
19:24.03 CIA-28 BRL-CAD: linear, grew 3D bounding boxes to cover surface curvature extruding box
19:24.03 CIA-28 BRL-CAD: need to fix correctly
19:42.25 Ralith starseeker, d-lo: Ogre works fine as an external dep; shall I kill it from the repo?
19:43.52 starseeker Ralith: sure, go for it
19:46.46 CIA-28 BRL-CAD: 03ralith * r34720 10/rt^3/trunk/src/other/ogre/: Dropped Ogre from internal repository, as the official releases should work fine for us.
19:52.04 louipc tcl/tk next :P
19:52.17 starseeker yeah, that's... harder
19:53.02 CIA-28 BRL-CAD: 03ralith * r34721 10/rt^3/trunk/ (13 files in 3 dirs): Moved cmake modules into root cmake module directory
19:54.34 Ralith afks for another few hours
19:58.02 mafm Ralith: starseeker: last year brlcad/Sear suggested me (under torture, even if he doesn't admit) to have all dependencies inside
19:58.21 mafm similar to the rest of libraries in main brl-cad module
19:59.00 mafm that is, I didn't put Ogre there because we needed to have a heavily patched version or anything
20:00.56 starseeker mafm: really? huh. Well, we can always add them in later at need
20:01.35 mafm yes well, just noting it
20:37.04 *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca)
22:19.03 *** join/#brlcad madant (n=d@117.196.131.16)
22:29.01 Ralith weird, ohloh doesn't seem to be updating commit stats
22:47.00 brlcad they lag by a few days
22:55.26 *** join/#brlcad pacman87 (n=pacman87@pool-173-57-41-37.dllstx.fios.verizon.net)
22:56.24 *** join/#brlcad jdoliner (n=jdoliner@c-98-227-157-38.hsd1.il.comcast.net)
23:44.14 ``Erik w00t, a/c is fixed O.o

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.