| 00:01.41 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca) |
| 02:18.51 | starseeker | indianlarry: Idea on handling of the raytracing of NURBS. Expanding the boxes is killing our performance by forcing more interative solutions of intersected bounding boxes (which are not needed in most cases but are in a few). What if, for each bounding box leaf we propose to search for intersections in, we see if the xy coordinates of any of the previously found intersection points are within the bounding uv square of the leaf BB about to be consider |
| 02:21.43 | starseeker | taking that one step further, when we build the surface tree we could actually store two trees in parallel, one with the minimal bounding boxes that give good raytrace performance, and one with the BB growth factor turned on. Then we can raytrace using the default bounding boxes, and for shots that return either an odd hit count or zero intersection boxes we repeat the hierarchy test with that same ray, only this time instructing it to use the grown bb |
| 02:23.29 | starseeker | compare the list of leaves obtained from the grown hierarcy test to the original list - any new boxes, test them for hits. If hits are found that aren't already in the hit list, add them and resort the list |
| 02:24.12 | starseeker | so in essence, each BBnode in the surface tree would store two sets of bounding box dimensions rather than one - otherwise, it's the same tree build |
| 02:26.31 | starseeker | we don't even have to walk the surface list twice |
| 02:27.32 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca) |
| 04:39.57 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-203.sbndin.btas.verizon.net) |
| 05:49.46 | Ralith | hm, I sent in my tax forms a couple days ago, still hasn't been confirmed as received |
| 05:49.53 | Ralith | :/ |
| 05:50.56 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca) |
| 05:57.39 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1128564968.dsl.bell.ca) |
| 09:01.51 | *** join/#brlcad _clock_ (n=_sushi_@84-72-91-14.dclient.hispeed.ch) |
| 12:02.39 | *** join/#brlcad docelic_ (n=docelic@78.134.203.126) |
| 12:56.51 | *** join/#brlcad madant_ (n=d@117.196.131.212) |
| 14:54.30 | *** join/#brlcad samrose (n=samrose@h134-215-226-37.lnngmi.dedicated.static.tds.net) |
| 15:38.10 | starseeker | indianlarry: Question: If we allow uv hit points outside uv boxes, but when performing the trimming test actually find (via a "2d" IntersectHierarchy test, I suppose) the uv box that contains the "out of box" hit point and use that to do the trimming test, would we actually get rid of the jagged edges on the trims while still allowing out of box hits? |
| 17:16.23 | *** join/#brlcad ``Erik_ (n=erik@ftp.brlcad.org) |
| 17:18.50 | *** join/#brlcad ``Erik (i=erik@c-69-140-109-104.hsd1.md.comcast.net) |
| 18:54.57 | CIA-28 | BRL-CAD: 03bob1961 * r34722 10/brlcad/trunk/misc/win32-msvc8/opennurbs/opennurbs.vcproj: mods to get things building again on windows |
| 18:55.38 | *** join/#brlcad madant (n=d@117.196.129.38) |
| 19:57.15 | *** join/#brlcad ``Erik_ (n=erik@ftp.brlcad.org) |
| 20:32.14 | *** join/#brlcad samrose (n=samrose@h134-215-226-37.lnngmi.dedicated.static.tds.net) |
| 20:47.13 | indianlarry | starseeker: You still workin |
| 20:47.53 | indianlarry | starseeker: think i found an easy solution to our box growth issue |
| 20:49.33 | indianlarry | starseeker: erik also mentioned his ideas about keeping neighbor links for his work that may play into the out of box hits we get |
| 20:51.44 | starseeker | still here |
| 20:52.00 | starseeker | sorry, chatting with Bob about Archer stuff |
| 20:52.05 | starseeker | what's the easy solution? |
| 20:52.13 | ``Erik | foiled their productivity mwahahhaa |
| 20:53.02 | indianlarry | starseeker: think i can grow only those boxes that need it just need to check if the corner normal pass the x,y,z normals |
| 20:53.41 | indianlarry | starseeker: since we bound be x,y,z min/max those are the only ones that would stick out |
| 20:53.54 | indianlarry | starseeker: that's why we were seeing patterns |
| 20:54.08 | indianlarry | starseeker: should actually be easy |
| 20:54.26 | ``Erik | famous last words? :D |
| 20:54.28 | starseeker | so you're saying check the normals at the corners in 3 space and see if they indicate "bad" behavior somehow? |
| 20:54.51 | indianlarry | starseeker: see id they change quadrants |
| 20:55.02 | indianlarry | starseeker: octants |
| 20:55.12 | starseeker | oh, hmm |
| 20:55.31 | starseeker | that might work, actually |
| 20:55.46 | indianlarry | starseeker: i think we can use the knots to ensure no more then two hits as well |
| 20:55.54 | starseeker | cool |
| 20:56.19 | starseeker | that might make my ideas overkill then... |
| 20:57.11 | indianlarry | starseeker: if we use knots during initial subdivision may make flatness resolve quicker |
| 20:57.46 | starseeker | ponders... yes, that might be true |
| 20:57.51 | indianlarry | starseeker: then again i've had a few too many already |
| 20:57.59 | starseeker | are you suggesting breaking into quadrants ON the knots? |
| 20:58.43 | indianlarry | starseeker: check flatness if not flat find median knot closest to center u,v and split there |
| 20:59.09 | indianlarry | starseeker: looks like openNURBS has a closest knot index function |
| 20:59.21 | starseeker | hmm. sounds promising |
| 21:00.18 | indianlarry | starseeker: guit there today? |
| 21:00.31 | starseeker | quiet |
| 21:00.37 | indianlarry | starseeker: yes aorry |
| 21:00.40 | starseeker | 'cept Bob says "get a life!" |
| 21:00.45 | starseeker | indianlarry: for what? |
| 21:01.07 | starseeker | indianlarry: you've been doing and continue to do awesome work! |
| 21:01.17 | indianlarry | starseeker: for the typing |
| 21:01.26 | starseeker | pfft. I was trained on slashdot |
| 21:04.06 | indianlarry | starseeker: i'll try and hit it later but busy weekend (graduation parties to attend) |
| 21:04.33 | starseeker | don't worry about it - that's way more important! |
| 21:05.01 | starseeker | scowls at the single odd hit report still coming from shape1.s at high res... |
| 21:06.02 | indianlarry | starseeker: I'll try and put that fuzz check in there, also need to see how they handle intersect closeness between surfaces problem could be there |
| 21:06.25 | starseeker | nods - yeah, kinda looks like that |
| 21:06.29 | starseeker | who's graduating? |
| 21:06.56 | indianlarry | starseeker: mothers cousins kin way down the line |
| 21:07.14 | starseeker | heh - well, it's a good drink excuse :-) |
| 21:07.31 | indianlarry | starseeker: that's what i thought |
| 21:07.44 | indianlarry | have a good weekend all |
| 21:08.05 | indianlarry | is brlcad in the channel |
| 21:08.16 | starseeker | you too |
| 21:08.20 | starseeker | haven't seen him today |
| 21:08.39 | indianlarry | catch up with him later |
| 21:10.20 | indianlarry | need to make sue GSoC joeDee has commit access to SVN |
| 21:11.24 | starseeker | nods :-) |
| 21:11.28 | starseeker | yeah, that helps |
| 21:11.53 | *** join/#brlcad _sushi_ (n=_sushi_@80-218-234-36.dclient.hispeed.ch) |
| 21:12.14 | starseeker | just in case this helps, xyz 4.315565 -2.942501 15.995774 dir -0.742404 -0.519837 -0.422618 with backout on is the shape1 test case |
| 21:30.54 | brlcad | indianlarry: I can set it but his commits will have to be watched carefully -- his patch indicated he needs more instruction on patches, commits, svn, our HACKING guidelines, style/ws, etc |
| 21:31.47 | brlcad | might want to have him simply start submitting patches (to the tracker for his work) and iterate with him on the patches until they commit unmodified |
| 21:32.21 | brlcad | shouldn't take more than a day or two to get anyone up to speed |
| 21:33.09 | indianlarry | brlcad: i'll touch base with him |
| 21:34.02 | brlcad | otherwise he does need to get kicking really soon now or there's no way he'll pass midterms |
| 21:35.32 | indianlarry | brlcad: looks like he's beeen writing some test code for some simple brep primitive so i think he's starting to get into it |
| 21:36.31 | indianlarry | brlcad: he emailed me some code to look at and he was re-writing dot,cross product macros and i pointed him at vmath.h |
| 21:37.15 | indianlarry | brlcad: i know it can be a little hard finding things |
| 21:38.27 | indianlarry | brlcad: i think he's also finding out that some of the opennurbs functions he needs are limited and sometimes replaced with stubs |
| 21:38.34 | brlcad | indianlarry: yeah, it's completely understandable -- just part of the process for "commit access" |
| 21:38.46 | indianlarry | brlcad: thanks |
| 21:41.54 | brlcad | he should work on showing he understands the dev guidelines before getting deep into the code regardless, which covers making patches, frequent commits, not breaking things, what his responsibilities are when he does break something, etc |
| 21:42.08 | brlcad | particularly for the gsoc kids, it's part of their http://brlcad.org/wiki/Google_Summer_of_Code/Checklist |
| 21:43.20 | brlcad | indianlarry: did he send you patch files or whole files or snippets? |
| 21:45.11 | indianlarry | brlcad: just a single file snippet just to look at overall style |
| 21:45.13 | brlcad | either way, that's the "tendancy to default to private conversations" I mentioned months back -- you shouldn't allow that or at least should respond to their message to the dev list (with a note to keep dev chatter public) |
| 21:45.43 | brlcad | many students do that, it's natural but really should be nipped in the bud early |
| 21:45.55 | indianlarry | brlcad: i mentioned that to him i think he need just a little push |
| 21:46.16 | indianlarry | brlcad: i think he tried to commit some stuff and couldn't |
| 21:46.50 | indianlarry | brlcad: i'll try and work it out with him |
| 21:47.08 | brlcad | it's multiple issues -- not being able to commit isn't an excuse |
| 21:47.10 | brlcad | he has to communicate |
| 21:47.40 | brlcad | he's certainly not said anything here yet has been joining, so it's even worse |
| 21:48.36 | indianlarry | brlcad: he was the one that had late finals so hopefully he'll start to get involved |
| 21:48.42 | brlcad | nods |
| 21:49.02 | brlcad | ~gsoctimeline |
| 21:49.03 | ibot | gsoctimeline is, like, http://socghop.appspot.com/document/show/program/google/gsoc2009/timeline |
| 21:50.31 | brlcad | yeah, three weeks to his midterm evaluation, two or three of the students are going to have to seriously kick it in or they'll have to be dropped |
| 21:50.58 | brlcad | will have to send a note this weekend, didn't realize that much time had passed already |
| 21:50.58 | indianlarry | brlcad: i'll mention it to him |
| 21:51.12 | indianlarry | tell me about it |
| 21:51.39 | *** join/#brlcad mafm (n=mafm@199.Red-88-26-141.staticIP.rima-tde.net) |
| 21:51.49 | brlcad | they're on a tight schedule and it's supposed to be a full-time job -- that's three weeks of no-show |
| 21:52.21 | indianlarry | brlcad: acts like he has a gov't job ;^) |
| 21:52.29 | brlcad | heh |
| 21:53.23 | indianlarry | i'm out for a while i'll try to push things along have a good weekend |
| 21:53.29 | brlcad | cya! |
| 21:54.07 | mafm | hi |
| 21:54.10 | brlcad | Ralith: nice to see you getting started, lemme know if you have any problems |
| 21:54.13 | brlcad | mafm: howdy! |
| 21:54.19 | brlcad | pacman87: how's it going?.... :) |
| 21:54.57 | Ralith | brlcad: I shall. |
| 21:55.29 | CIA-28 | BRL-CAD: 03starseeker * r34723 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: When an odd nurbs hit point shows up, print out the nirt commands that will fire just that ray (make debugging 'em simpler) |
| 21:56.36 | brlcad | Ralith: remember to keep a daily note for any days you work, a single brief sentance suffices -- like a commit message -- to say what you got done |
| 21:57.01 | Ralith | oh, wups |
| 21:57.08 | Ralith | on my wiki page? |
| 21:57.13 | brlcad | roberthl: wow, no longer living in obscurity? :) |
| 21:57.19 | brlcad | er, anonymity |
| 21:57.29 | brlcad | yeah, wiki page work |
| 21:57.32 | brlcad | *works |
| 21:57.51 | brlcad | or blog or tweets, just someplace convenient (and ideally rss-able) |
| 21:58.22 | brlcad | pacman did a pretty good job last year: http://brlcad.org/wiki/User:Pacman87 |
| 21:59.00 | roberthl | brlcad: Yeah, I kind of gave up that when I started being payed to do stuff. :) |
| 21:59.20 | roberthl | (development) |
| 21:59.28 | brlcad | nods |
| 21:59.50 | mafm | tweets are the root of evil, just say no! :P |
| 22:04.05 | *** join/#brlcad bz8z7 (n=543ebaea@bz.bzflag.bz) |
| 22:07.18 | CIA-28 | BRL-CAD: 03Ralith 07http://brlcad.org * r1478 10/wiki/User:Ralith: Added first log entries |
| 22:15.12 | ``Erik | hey, c'mon now, indianlarry, some of us gov't foke are only no-show for 2 weeks :D |
| 22:22.43 | pacman87 | it's been rather hectic at my house with relatives visiting for little bro |
| 22:22.46 | pacman87 | 's graduation |
| 22:23.31 | pacman87 | and i got recruited to move my brother in this week |
| 22:23.46 | pacman87 | so now there's no more distractions |
| 22:24.28 | pacman87 | which place? |
| 22:24.31 | pacman87 | the speech? |
| 22:24.54 | pacman87 | ww |
| 22:25.24 | pacman87 | now everything's back to normal |
| 22:25.29 | pacman87 | and i can get back to coding full-time |
| 22:25.50 | pacman87 | speaking of which, is there a good sample sketch i can use to test my revolve? |
| 22:26.25 | pacman87 | just examples of syntax for the two spline types, carcs, and lsegs |
| 22:36.23 | brlcad | could try the sketch in http://brlcad.org/tmp/sketch.g |
| 22:36.43 | brlcad | includes each entity type except the unimplemented nurbs type |
| 22:48.43 | ``Erik | pacman87: if you were to draw a half circle, then revolve around a line that touch both ends of that arc like 30 degrees or so, would the resultant geometry be something like an orange slice? am I gettin' the purpose right? |
| 22:50.27 | pacman87 | yes |
| 22:50.42 | pacman87 | ``Erik: ^^ |
| 22:51.41 | *** join/#brlcad jdoliner (n=jdoliner@c-98-227-157-38.hsd1.il.comcast.net) |
| 22:52.42 | jdoliner | sean, can you explain to me how I should submit code? |
| 22:53.06 | jdoliner | brlcad? |
| 22:54.42 | pacman87 | jdoliner: are you starting new files, or modifying existing ones? |
| 22:55.18 | jdoliner | I started a new file in proc-db |
| 22:55.38 | jdoliner | and I've also modified a file |
| 22:55.38 | pacman87 | do you have commit access yet? |
| 22:55.44 | jdoliner | no I don't believe so |
| 22:56.20 | pacman87 | go to the brlcad sourceforge site |
| 22:56.27 | pacman87 | under 'tracker' click 'patches' |
| 22:56.48 | pacman87 | then click 'add new' |
| 22:56.59 | pacman87 | and there's some instructions there |
| 22:57.50 | jdoliner | k thanks |
| 22:58.09 | ``Erik | yes, your first few patches will be via the sourceforge patch submission page so we can know that you understand the HACKING file and can produce correct and consistent code :) |
| 23:01.38 | ``Erik | hah, trying to install cmake and accidently typed cake, got a rush of bad memories off of that |
| 23:01.59 | ``Erik | (cake was the archaic fugly build system BRL-CAD used before I hacked it up for automake :D ) |
| 23:14.50 | jdoliner | fair enough I could use some criticism |
| 23:16.08 | jdoliner | would you guys call brep on brep intersection geometry editing, or modeling? |
| 23:19.35 | brlcad | probably geometry editing, but that field isn't really important |
| 23:20.46 | brlcad | jdoliner: yeah, the main issue with commit access is spelled out in the HACKING file (which you've read right?) :) as well as http://brlcad.org/wiki/Google_Summer_of_Code/Checklist (which you've read right?) :) just to make sure you understand your responsibilities |
| 23:21.53 | ``Erik | is rt^3 wanting dev or stable ogre3d? |
| 23:22.29 | jdoliner | yes of course |
| 23:22.32 | brlcad | it shouldn't take you more than a day really to get commit access sorted out, so you can commit in good faith, but you aren't just given it before showing some basic understanding (and your gsoc patch didn't show that.. can talk about that if you like) |
| 23:22.55 | jdoliner | no that's fine I just submitted my work up to this point |
| 23:23.12 | brlcad | keep in mind that you absolutely should not be coding away quietly |
| 23:23.20 | jdoliner | it's now using vmath macros instead |
| 23:23.32 | ``Erik | you manually reviewed your patch file, yes? :) I always do an svn diff before commiting just to make sure |
| 23:23.32 | jdoliner | I swear I haven't been |
| 23:23.33 | brlcad | getting commit sorted out is priority #1, should have happened before gsoc started really |
| 23:24.01 | jdoliner | k let's do that immediately then |
| 23:24.13 | brlcad | also shouldn't be communicating in private -- here or on mailing list if it has anything to do with code/project/progress |
| 23:24.17 | ``Erik | finds a pointy stick to jab brlcad with until he gets his ogre question answered O:-) |
| 23:24.30 | brlcad | ``Erik: ask the Ralith guy, beats me! |
| 23:24.36 | ``Erik | ok |
| 23:24.40 | ``Erik | asks ralith and beats brlcad |
| 23:24.40 | brlcad | or mafm |
| 23:24.45 | brlcad | heh |
| 23:24.57 | mafm | what about Ogre? |
| 23:25.04 | ``Erik | dev or stable |
| 23:25.06 | Ralith | ``Erik: g3d you mean? |
| 23:25.08 | mafm | ralith removed it yesterday with consent from starseeker |
| 23:25.10 | Ralith | Ogre stable should work |
| 23:25.14 | Ralith | it's >=1.6 right? |
| 23:25.21 | CIA-28 | BRL-CAD: 03Jdoliner 07http://brlcad.org * r1479 10/wiki/User:Jdoliner: |
| 23:25.25 | mafm | I noted that I had put it there last year to have all dependencies inside |
| 23:25.26 | ``Erik | um, 1.6 is stable |
| 23:25.32 | Ralith | then that'll work |
| 23:25.43 | Ralith | mafm: iirc, the reason it was there last year was because 1.6 wasn't stable yet and we needed some 1.6 features |
| 23:25.45 | ``Erik | I'll grab dev anyways, there may be some future-proofing opportunities |
| 23:25.55 | ``Erik | (and damnit, brlcad, you're supposed to know EVERYTHING) |
| 23:25.57 | mafm | but I don't know which version Qt (or Ralith) needs |
| 23:26.15 | mafm | it only needed a simple patch for RBGui |
| 23:26.20 | Ralith | well, the Qt-in-Ogre-in-Qt thing I think I'm going with depends on a 1.6 feature |
| 23:26.29 | mafm | but now that RBGui is gone, no problem for me |
| 23:26.31 | brlcad | reiterates http://brlcad.org/wiki/Google_Summer_of_Code/Expectations for all students |
| 23:26.34 | Ralith | mafm: works fine unpatched with RBGui, too. |
| 23:27.18 | mafm | probably because they include the patch in newer versions -- it was only a new function |
| 23:27.37 | Ralith | yeah, I think I remember debugging that when I first tried a system ogre actually |
| 23:27.51 | mafm | Frequent communication with mentor -- ouch, I failed in that :P |
| 23:28.28 | brlcad | we'll probably rebundle it later -- there's no problem either way until we go to press a source release and have to consider dependency management from non-developer compiling users |
| 23:34.43 | mafm | current stable version is 1.6.2 (and recent, 2 months old), so if it's enough, I'd go with it |
| 23:37.10 | ``Erik | <-- did an svn checkout of ogre3d's trunk |
| 23:42.17 | ``Erik | yay, dependancy hell :D |
| 23:46.15 | mafm | such a big library (needing in turn other libraries) is indeed not fun |
| 23:46.49 | mafm | isn't there some concept in SVN about virtual repositories? |
| 23:47.26 | mafm | you have a separate module (with ogre and the like) and then attach it to some point in other directories (g3d and maybe others) |
| 23:47.43 | mafm | it could help in maintenance if several parts depend on it |
| 23:48.16 | mafm | because OGRE needs about a dozen other libraries... |
| 23:49.14 | ``Erik | and zziplib doesn't wanna build clean, neato |