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 |