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 |