00:04.21 |
*** join/#brlcad Semhirage
(i=semhirag@unaffiliated/semhirage) |
02:15.04 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
02:15.04 |
*** mode/#brlcad [+o ChanServ]
by irc.freenode.net |
02:16.47 |
*** join/#brlcad Semhirage
(i=semhirag@unaffiliated/semhirage) |
02:18.07 |
*** join/#brlcad Semhirage_
(i=semhirag@unaffiliated/semhirage) |
02:20.10 |
*** join/#brlcad Semhirage
(i=semhirag@unaffiliated/semhirage) |
02:20.10 |
*** join/#brlcad Semhirage_
(i=semhirag@unaffiliated/semhirage) |
02:50.09 |
*** join/#brlcad Semhirage
(n=Semhirag@unaffiliated/semhirage) |
05:13.09 |
*** join/#brlcad PKMOBILE
(n=Apathy@pcp0011677997pcs.waldrf01.md.comcast.net) |
05:14.19 |
Twingy |
O.o |
05:15.56 |
PKMOBILE |
quite |
06:18.21 |
CIA-5 |
BRL-CAD: 03twingy * 10brlcad/src/adrt/libtie/
(define.h tie.c): |
06:18.21 |
CIA-5 |
BRL-CAD: Adding finishing touches to
algorithm. Will be adding some controls to |
06:18.21 |
CIA-5 |
BRL-CAD: tie_init to allow developer to
control both agressiveness of kd-tree building |
06:18.21 |
CIA-5 |
BRL-CAD: algorithm and memory consumption as a
function of # of triangles. |
14:25.05 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/ (7 files in 3
dirs): add a configure test for SGI knobs support, and define the
IR_KNOBS and IR_BUTTONS if/when they are available. |
14:26.06 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/TODO: knobs
really should now work |
14:31.13 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/NEWS: enabled SGI
knobs and button box support for IRIX; reword testing changes to
what they mean to end user, fitting to column 70 |
14:32.28 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/TODO: X11 is
technically configurable now, along with OpenGL -- might not work,
but then that can be a different todo if it doesn't, k? |
14:33.54 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/NEWS: improved
build support detection for OpenGL and X11 |
14:35.14 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/TODO: don't have
access to mingw right now, so push it back |
14:35.55 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/NEWS: improved
ADRT build support |
14:37.01 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/TODO: libbu new
has whereis-style support for locating it's resources at
run-time |
14:38.01 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/NEWS: mged
relocation support |
14:40.37 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/TODO: tim has got
aquatk working |
15:25.55 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/TODO: multiple
threading models not that important in the big picture, it works
and works well enough given mips seems to be on it's way out off of
sgi's high end line |
15:31.33 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/NEWS: performance
enhancements to ADRT |
15:33.31 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/TODO: |
15:33.31 |
CIA-5 |
BRL-CAD: add database support for constraints,
expressions, parametric |
15:33.31 |
CIA-5 |
BRL-CAD: values, construction history, and
timestamping |
15:35.39 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/BUGS: mged will
actually run without being installed now with the new relocation
support and BRLCAD_DATA variable overrides |
15:37.06 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/NEWS: mged will
now work without being installed |
15:40.47 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/BUGS: the X11 15
bit thing is an old bug, add a footer mentioning the 70 column
width formatting. |
15:41.33 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/TODO:
ws |
15:42.27 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/NEWS: NEWS items
are formatted to column 70 |
15:44.51 |
*** join/#brlcad PKMOBILE
(n=Apathy@pcp0011677997pcs.waldrf01.md.comcast.net) |
16:16.02 |
*** join/#brlcad DarkMaster
(n=Apathy@pcp0011677997pcs.waldrf01.md.comcast.net) |
16:16.58 |
*** join/#brlcad Twingy_
(n=justin@pcp0011647505pcs.aberdn01.md.comcast.net) |
16:31.02 |
*** join/#brlcad mahesh
(n=mahesh@12-217-225-64.client.mchsi.com) |
16:31.28 |
learner |
howdy mahesh |
16:31.43 |
Twingy_ |
mmm, I'm seeing 1.2 - 2.5 mil rays per second
on t62 now |
16:31.57 |
learner |
nice |
16:32.02 |
Twingy_ |
yup yup |
16:32.17 |
mahesh |
hi |
16:32.30 |
Twingy_ |
I'm gonna toss kd-tree caching in now I
think |
16:33.02 |
Twingy_ |
on the cluster :) |
16:33.24 |
Twingy_ |
I might be able to squeek out a hair more with
my new algorithm |
16:33.32 |
Twingy_ |
but it's pretty aggressive as it is |
16:33.44 |
Twingy_ |
only way to get that from 2.5 - 5 mil is with
sse |
16:34.54 |
Twingy_ |
still debating on whether it's worth the
effort |
16:35.23 |
Twingy_ |
I suspect if there were 2 people working on
this project I'd be more motivated to put it in |
16:36.06 |
learner |
dammit |
16:36.10 |
learner |
i was looking for him |
16:37.19 |
mahesh |
hey Sean, need some suggestion |
16:37.40 |
learner |
sure |
16:37.58 |
learner |
I suggest you don't mix peanut butter with
tofu |
16:38.05 |
mahesh |
ha ha |
16:38.14 |
Twingy_ |
o.O |
16:38.26 |
learner |
mm.. peanut butter |
16:39.01 |
mahesh |
it looks like I have to rewrite lot of do_work
function |
16:39.23 |
mahesh |
do you think, its ok or should I think of
something else |
16:40.28 |
learner |
in short, yes, it should be good |
16:40.52 |
mahesh |
because its doing a lot of book keeping about
servers |
16:40.52 |
learner |
but it's more a bigger question of
architecture that I'm wondering |
16:41.03 |
learner |
what means were you thinking for the
distribution? |
16:41.26 |
mahesh |
i would use a grid middleware which will
distribute the load among the machines |
16:41.28 |
learner |
did you already have a grid toolkit in
mind? |
16:41.32 |
mahesh |
yes i have |
16:42.01 |
mahesh |
i was talking to a guy who owns a small
company. he has written a grid middleware |
16:42.08 |
mahesh |
it is really light weight i feel |
16:42.12 |
mahesh |
can i use that? |
16:42.22 |
learner |
heh, you can use whatever you want |
16:42.28 |
mahesh |
cool |
16:42.31 |
mahesh |
its written in java |
16:42.34 |
learner |
whether it'll technically work is a different
question :) |
16:42.50 |
learner |
ahh, hrm -- well that's doable, but it'll be
more work for you |
16:43.02 |
mahesh |
so, i will have to probably do socket
communication between c stuff and java stuff |
16:43.07 |
learner |
since you'll have to hook into the java
interface through jni |
16:43.11 |
learner |
or that |
16:43.14 |
learner |
even better |
16:43.38 |
mahesh |
so, i will not be using rsh at all |
16:44.12 |
mahesh |
all the nodes will register with the grid
software |
16:44.41 |
Twingy_ |
hrm |
16:44.43 |
mahesh |
and the software has functionality to start
process on remote machines |
16:44.45 |
learner |
how do they register? |
16:44.57 |
learner |
ahh, the middleware will start them
up |
16:45.04 |
mahesh |
all the nodes have that grid software
running |
16:45.09 |
learner |
okay |
16:45.13 |
Twingy_ |
I can do 20 mil rays/sec on the cluster and
muves is still limited to 300 rays/sec on the whole
cluster |
16:45.21 |
learner |
how are they going to know how to
raytrace? |
16:45.54 |
mahesh |
one node will talk to grid middleware which
inturn talks to other nodes |
16:46.02 |
Twingy_ |
heh, my engine would see 0.0015% utilization
by muves |
16:46.11 |
Twingy_ |
wee |
16:46.14 |
learner |
yep |
16:46.20 |
mahesh |
you could imagine it as a one to many
relationship |
16:47.03 |
Twingy_ |
hrm, they only need to speed things up by 4
orders of magnitude |
16:47.17 |
learner |
i follow how the grid middle ware will manage
data, but how do the remote "deamons" actually end up raytracing?
would you feed the middleware your rt binaries? |
16:48.01 |
mahesh |
all the nodes should have rt binaries in
them |
16:49.10 |
learner |
in this case they'd be rtsrv binaries
yes? |
16:49.21 |
mahesh |
exactly |
16:49.39 |
mahesh |
i would start with the assuption that rtsrv
binaries exist on all nodes |
16:50.05 |
mahesh |
later i could modify in such a way that
middleware will push the binaries if they dont already
exists |
16:58.30 |
mahesh |
i have to go now, i'll ttyl |
17:20.52 |
learner |
sorry, had to run off |
17:20.59 |
learner |
sounds good :) |
17:32.39 |
Maloeran |
I think I may do your SSE, Justin, if you
wish |
17:38.18 |
Twingy_ |
prasad and I have the logic more or less
worked out, but it's only going to benefit us for optical
rendering |
17:38.41 |
Twingy_ |
for ballistic vulnerability analysis, is won't
do much for us |
17:39.07 |
Maloeran |
Right. |
17:39.19 |
Twingy_ |
it would be nice to have... |
17:39.29 |
Twingy_ |
but for things like path tracing |
17:39.33 |
Twingy_ |
and ballistics |
17:39.36 |
Maloeran |
It's nice to defeat rasterization in graphics
rendering |
17:39.37 |
Twingy_ |
where there is no ray-coherency |
17:39.42 |
Twingy_ |
it doesn't do much |
17:39.53 |
Twingy_ |
yah... |
17:40.05 |
Twingy_ |
that's why I'm still kinda interested in
having it in there |
17:40.19 |
Maloeran |
I'm at 10m rays per second, not yet up to
Reshetov's. Do you know if how his is going to be "open",
open-source or open specs? |
17:40.26 |
Twingy_ |
I think maybe as a separate intersection
function |
17:40.32 |
Maloeran |
know * how |
17:40.41 |
Twingy_ |
for what size scene? |
17:40.50 |
Twingy_ |
his scene was like 10 million
triangles |
17:40.57 |
Maloeran |
Merely the usual 140k tank |
17:41.08 |
Twingy_ |
well, 1m on 140k is hardly 10m on 10mil
polys |
17:41.11 |
Twingy_ |
er 10m |
17:41.16 |
Maloeran |
I know that much :) |
17:41.29 |
Twingy_ |
and he was using half the cpu power as
you... |
17:41.58 |
Maloeran |
Indeed. As I said, I'm clearly not yet up to
his ray-tracer |
17:42.28 |
Twingy_ |
I think after I get kd-tree caching in place
I'll revisit the sse integration |
17:42.37 |
Maloeran |
It's really puzzling still, I'm curious to
read more about his |
17:42.43 |
Twingy_ |
there's still some details I haven't quite
worked out though |
17:43.04 |
Twingy_ |
why don't you email him? |
17:43.06 |
Maloeran |
In any case, it makes me consider open-source
if an apparently better solution exists |
17:43.34 |
Maloeran |
Does this paper exist in a digital format
within reach? |
17:43.42 |
Twingy_ |
tried google? |
17:43.46 |
Maloeran |
Yes |
17:45.01 |
Twingy_ |
well, when I get my siggraph dvd's maybe I can
post it |
17:45.13 |
Twingy_ |
until now it's in my siggraph book on my
desk |
17:45.48 |
Maloeran |
Hardly a convenient format :), okay |
17:45.54 |
Twingy_ |
convenient for me ;) |
17:46.07 |
Maloeran |
Will you implement his techniques? |
17:46.16 |
Twingy_ |
good question |
17:46.33 |
Twingy_ |
depends on what kinda performance I can eek
out of what I already got |
17:46.54 |
Twingy_ |
it would be nice |
17:47.13 |
Maloeran |
Assuming you read it a few times already, does
it really make sense to reach this level of performance in scenes
of 10m triangles? |
17:47.15 |
Twingy_ |
I'm mainly interested on how his techniques
would speed up vulnerability analysis |
17:47.25 |
Twingy_ |
yep |
17:48.10 |
Twingy_ |
but it's pretty dense |
17:48.22 |
Maloeran |
Are these 10m rays per second incoherent, with
no shortcuts based on the organisation of primary rays? |
17:48.23 |
Twingy_ |
not something you can implement in a
weekend |
17:48.40 |
Twingy_ |
his 10m comes from sse driven first-hit
optical rendering |
17:49.10 |
Maloeran |
Does he exploit the coherency and organisation
of the rays, beyond SSE? |
17:49.46 |
Twingy_ |
I want to say no |
17:49.57 |
Twingy_ |
but I don't remember entirely |
17:50.22 |
Twingy_ |
I won't be in the position to integrate his
stuff until around february of '06 if I find the time |
17:50.45 |
Twingy_ |
I'm falling behind on my duties with stryker
by spending the last 4 days and nights on nothing but my
kd-tree |
17:51.06 |
Maloeran |
I'm considering joining up, since it's
open-source of course |
17:51.18 |
Twingy_ |
joining up what? |
17:51.31 |
Maloeran |
Your ray-tracer, or ours maybe ;) |
17:52.47 |
Twingy_ |
when I spoke with alexander, he basically said
just email my manager and we should be able to get you a copy of
the source |
17:54.35 |
Twingy_ |
well, I'm certainly not going to turn down an
opportunity to improve the optical rendering capabilities of
adrt |
17:54.54 |
Maloeran |
I just read an abstract overview of the
technique |
17:55.24 |
Maloeran |
It entirely rely on the organisation of rays,
it's for primary or otherwise carefully organized rays |
17:55.54 |
Twingy_ |
yep |
17:55.56 |
Maloeran |
So it is of no use for incoherent ray-tracing,
path-tracing, global illumination, ballistics |
17:56.06 |
Twingy_ |
yah :\ |
17:56.30 |
Maloeran |
Nothing new there then :), ah I almost feel
better. |
17:56.57 |
Twingy_ |
I asked him about rays that go all the way
through geometry on the mic |
17:57.07 |
Twingy_ |
and he said he didn't test anything of the
sort and thereforeh as no number |
17:57.39 |
Twingy_ |
some of the ballistic ray-tracing we do is
grids of rays though |
17:57.47 |
Twingy_ |
whre the rays are parallel with different
positions |
17:57.55 |
Twingy_ |
I dunno if you're method would help with that
at all |
17:58.02 |
Maloeran |
His "beams of rays" are my bundles of rays
that I had briefly implemented, which doubled the performance of
primary rays. All right then, let's finish the job |
17:58.21 |
Maloeran |
Parallel? Okay, that would require a few
changes, but it would work out |
17:58.47 |
Twingy_ |
O |
17:58.49 |
Twingy_ |
err |
17:58.56 |
Twingy_ |
I'm curious what performance you get |
17:59.03 |
Twingy_ |
by means of brute force path tracing |
17:59.09 |
Twingy_ |
1 ray at a time propogating through a
scene |
17:59.49 |
Maloeran |
No SSE, no coherency, 2.5m per
second |
17:59.49 |
Twingy_ |
that would give me a number where I can
compare apples to apples |
17:59.57 |
Twingy_ |
ah |
18:00.00 |
Twingy_ |
neat |
18:00.04 |
Twingy_ |
that's about where I am |
18:00.17 |
Twingy_ |
but I have (2) 3.4ghz xeons |
18:00.26 |
Twingy_ |
so call it like 1.5 mil |
18:00.31 |
Maloeran |
Ah, yes |
18:00.40 |
Twingy_ |
you're still a bit faster, mainly due to the
reliance on properly oriented triangled |
18:00.44 |
Twingy_ |
err triangles |
18:00.51 |
Twingy_ |
we don't always have properly oriented
triangles |
18:00.54 |
Maloeran |
That's for the tank in the bubble by the way,
make it 3.2m or so without the bubble |
18:01.01 |
Twingy_ |
some of the 15 million polygon models we get
have orientations in different ways |
18:01.12 |
Twingy_ |
it would be a real headache to get them all
oriented right |
18:01.16 |
Maloeran |
That can be annoying. |
18:01.19 |
Maloeran |
Understandable |
18:01.32 |
Twingy_ |
that's main reason why I support un-oriented
triangles |
18:01.36 |
Maloeran |
I lose some ~10% of performance if the scene
require dual-sided intersection |
18:01.49 |
Twingy_ |
yah, that's pretty neat though |
18:02.03 |
Twingy_ |
it's sounding like your algorithm under the
same constraints mine is under performs about the same, which is
pretty cool |
18:02.21 |
Twingy_ |
or atleast within the same ballpark |
18:02.37 |
Twingy_ |
but yours still beats the pants off mine for
optical rendering |
18:02.53 |
Twingy_ |
well |
18:02.58 |
Twingy_ |
first-hit optical rendering anyway |
18:03.05 |
Maloeran |
I think the method allows much better
"shortcuts" on this point |
18:03.06 |
Maloeran |
Right |
18:03.07 |
Twingy_ |
for 3d viz stuff, that's highly
useful |
18:03.22 |
Twingy_ |
when crawling around inside the vehicle to
look at it |
18:03.45 |
Twingy_ |
after I'm done my new kd-tree code I should go
over it with you |
18:03.53 |
Twingy_ |
it's fairly intelligent |
18:04.08 |
Maloeran |
With some work, it would work as well for
rasterization-style lighting, not just primary rays |
18:04.15 |
Twingy_ |
yah |
18:04.17 |
Maloeran |
but clearly, it's useless for path-tracing or
anything remotely close |
18:04.31 |
Twingy_ |
I think you should turn it into a source forge
project with an examples directory |
18:04.36 |
Twingy_ |
if the money isn't appealing of
course |
18:04.45 |
Twingy_ |
did you get ahold of the OpenRT
spec? |
18:04.54 |
Twingy_ |
it's available now |
18:05.03 |
Maloeran |
The API specs? I read some papers, nothing
recent |
18:05.08 |
Twingy_ |
you might consider being the "first"
alternative to openrt |
18:05.19 |
Twingy_ |
that could get you some serious
attention |
18:05.43 |
Twingy_ |
you can download the library and API from the
website now |
18:05.55 |
Twingy_ |
you could effectively mimick the API and do a
side-by-side comparisson |
18:06.01 |
Twingy_ |
and then announce to the world that yours is
faster |
18:06.22 |
Twingy_ |
and you'd get ALOT of publicity for
it |
18:06.33 |
Maloeran |
I'm mostly doing this for my own enjoyment, so
there's a point I would have to clarify. If I were to open-source,
would you have abundant time to put together the fastest
open-source ray-tracer out there? |
18:07.01 |
Twingy_ |
you mean library? |
18:07.05 |
Twingy_ |
or application? |
18:07.06 |
Twingy_ |
or? |
18:07.18 |
learner |
it is already |
18:07.32 |
learner |
open-source at least |
18:07.42 |
Maloeran |
The open-source part, yes... ;) |
18:07.52 |
learner |
i mean fastest open source :) |
18:08.00 |
Twingy_ |
I mean all I do at work is ray-tracing
stuff |
18:08.06 |
Twingy_ |
so I could effectively work on this at
work |
18:08.11 |
Twingy_ |
so the answer is yes |
18:08.40 |
Twingy_ |
I'm a bit tied up helping emmanuel stone
finish integrating nurbana into blender |
18:08.46 |
Twingy_ |
but I suspect in 2 weeks that will be wrapping
up |
18:08.47 |
learner |
povray's slow, yafray too |
18:09.09 |
Twingy_ |
so I won't have any other software projects
going on |
18:09.10 |
Maloeran |
Right, nice. I really can't give an answer
yet, but... I think I'm going to open-source |
18:09.26 |
Twingy_ |
I think that's a wiser decision |
18:09.34 |
Maloeran |
What can I say, it just seems much more
appealing, much more entertaining |
18:09.34 |
Twingy_ |
in the long run I think it's worth more than
what you're being offered |
18:09.46 |
Twingy_ |
plus alot more people will benefit from
it |
18:10.07 |
Twingy_ |
if anything |
18:10.12 |
Twingy_ |
you could start up a paypal donation
thing |
18:10.15 |
Twingy_ |
and get both |
18:10.39 |
Maloeran |
Ahah, I suppose |
18:10.45 |
Twingy_ |
of course I cannot have any part of
that |
18:11.10 |
Twingy_ |
anywho |
18:11.14 |
Twingy_ |
we'll have to discuss this more
later |
18:11.21 |
Twingy_ |
I want to resume this kd-tree caching for
now |
18:11.34 |
Twingy_ |
imperative I get that in there before next
stryker meeting |
18:11.36 |
Maloeran |
Right, and I'll have to sort this out. Good
luck |
18:11.40 |
Twingy_ |
k |
18:11.42 |
Twingy_ |
thx |
18:14.32 |
Twingy_ |
mal |
18:14.49 |
Twingy_ |
just an idea, but typically it's worth more
money to create a support contract than it is to sell software or
IP |
18:15.17 |
Twingy_ |
tell those guys that instead of buying IP,
maybe they could buy a contract with you to integrate it into their
software |
18:15.45 |
Twingy_ |
that'll get you the best of both
worlds |
18:18.26 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/configure.ac:
knobs work |
18:23.17 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/configure.ac:
call them dials and buttons |
18:28.28 |
Maloeran |
From what I understood, they want to IP to be
able to sell it back, maybe not even to use it themselves |
18:28.31 |
Maloeran |
Ah oops, he left |
18:28.53 |
learner |
that he did |
18:29.08 |
learner |
so you're up in quebec? |
18:29.48 |
Maloeran |
Correct |
18:31.04 |
learner |
yet to make it there myself other than for a
drive through a couple years ago |
18:31.45 |
Maloeran |
:) Could I ask what your first name is? I have
come to vaguely know Justin's co-workers through various
discussions, or through Erik |
18:32.00 |
learner |
Sean |
18:32.30 |
Maloeran |
Ah right, Sean. Pleased to meet you |
18:32.32 |
learner |
technically not my first name, but that's what
they'd be calling me :) |
18:32.40 |
Maloeran |
Indeed :) |
18:33.53 |
learner |
likewise, pleased to meet you |
18:34.06 |
learner |
though we have talked once or twice before,
albeit only briefly |
18:35.26 |
learner |
every time i see you're nick, I'm reminded of
the old Malestrom game |
18:35.50 |
learner |
that was a fun game .. hmm.. raytraced at
30fps.... |
18:36.03 |
Maloeran |
Eheh, I don't think I have played |
18:36.37 |
learner |
it was a big asteroids variant, popular on the
*nix machines |
18:36.39 |
Maloeran |
Internet nicknames seem to be something one
can pick at 15 years old and it sticks for eternity |
18:37.06 |
learner |
yep, choose wisely :) |
18:39.27 |
learner |
http://www.ambrosiasw.com/games/maelstrom/ |
18:40.30 |
Maloeran |
Oh, I did play this :). I really wouldn't
have guessed it could be ray-traced, it doesn't seem appropriate to
the needs of the game |
18:40.45 |
learner |
of course not :) |
18:41.01 |
learner |
but it could still be pretty neat |
18:43.57 |
learner |
hehe |
18:52.47 |
Maloeran |
Ah, how I have grown to love and cherish these
packages that just break with compiled on a 64 bits arch |
18:52.52 |
Maloeran |
when compiled, even |
18:53.11 |
learner |
tis good stuff, eh? |
18:53.26 |
learner |
amd64? |
18:54.43 |
Maloeran |
For incoherent branching and heavy floating
point number crunching, there's really nothing like
Opterons |
18:55.21 |
learner |
that is quite true |
19:11.27 |
Twingy |
hrm |
19:12.22 |
Twingy |
definetly need to wait till the 2 yr mark to
sell my home |
19:22.37 |
*** join/#brlcad cad528
(n=52ecb3f1@bz.bzflag.bz) |
19:22.41 |
learner |
it's not at all like a structure |
19:24.09 |
Twingy |
you guys make it to nist on time? |
19:24.26 |
learner |
we were actually really early, made it in
great time |
19:24.36 |
learner |
had breakfast, then went over |
19:24.42 |
Twingy |
good deal |
19:24.58 |
Twingy |
my neighbor's mom has some friends that might
be interested in buying my home |
19:25.02 |
learner |
much more impressive to see it working in the
cave than it was at the BoF |
19:25.11 |
Twingy |
what was "it" |
19:25.33 |
learner |
a framework to drive the cave |
19:25.36 |
Twingy |
ah |
19:25.49 |
Twingy |
you guys shoulda took joe |
19:25.59 |
Twingy |
from raytheon that operates the cave in
390 |
19:26.22 |
learner |
it deals with positioning the geometry in
three-space figuring out the view parallax of however many walls
you have and their orientation |
19:26.33 |
learner |
reads the head and wand tracker
devices |
19:26.42 |
Twingy |
gotcha |
19:26.47 |
Twingy |
gpu or raytraced? |
19:26.54 |
learner |
a variety of tools for interacting, and
displaying stuff |
19:27.03 |
learner |
like putting up menus, heads up displays,
etc |
19:27.12 |
learner |
opengl |
19:27.15 |
Twingy |
good for a simulation program |
19:27.38 |
Twingy |
I bet max lorenzo woulda liked to see
that |
19:27.51 |
learner |
supported many different display
modes |
19:27.58 |
learner |
like your standard stereo |
19:28.24 |
learner |
the 3d effect we saw on ours with the shutter
glasses |
19:28.49 |
learner |
that was really cool, much better than the
demos we saw at ours |
19:29.09 |
learner |
you could stand inside your dataset and see
things all around you, the immersion was much much better |
19:29.30 |
Twingy |
probly a more expensive setup too |
19:29.49 |
learner |
i could picture bringing up something like
strker and actually getting a feel for the cabin and what it looks
like from one of the chairs |
19:29.58 |
Twingy |
yah, but for how much? |
19:30.00 |
learner |
no, there's was cheaper than ours |
19:30.01 |
learner |
considerably |
19:30.04 |
Twingy |
how much? |
19:30.08 |
learner |
ours is huge in comparison |
19:30.10 |
Twingy |
we speant $250k on ours |
19:30.33 |
Twingy |
did they load any large geometries? |
19:30.36 |
learner |
same company I think, just smaller version,
and only three-wall |
19:30.54 |
learner |
(two wall and floor) |
19:31.24 |
learner |
not really anything immense, but that wasn't
really the purpose |
19:31.32 |
Twingy |
understood |
19:31.51 |
Twingy |
I've got a framework for the kd-tree caching
down without affecting peak memory |
19:32.07 |
Twingy |
I'm going to make a kd-tree free function that
builds the cache while free'ing |
19:32.25 |
Twingy |
so we can still utilize max memory |
19:33.02 |
Twingy |
it looks like 1 of the 2 opteron machines will
be here monday |
19:33.12 |
Twingy |
supposedly the other one (the head node) is on
the way |
19:33.26 |
Twingy |
so it's pretty much useless until we get
it |
19:33.42 |
Twingy |
unless I slap my extra sata drive into
it |
19:33.49 |
Twingy |
but it's not worth the time |
19:34.36 |
learner |
cool |
19:34.58 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/configure.ac: use
AC_MSG_RESULT for the starting message and summary results so that
they are inserted into config.log, and so they will obey the
--verbose and --quiet flags too. |
19:35.18 |
Twingy |
distcc running on those two opteron machines
will probly be pretty snappy |
19:35.26 |
Twingy |
will be able to do make -j8 |
19:35.41 |
Twingy |
using (8) 2ghz opteron cores |
19:35.59 |
learner |
I added a "fast" make target that should make
building brl-cad on shiva actually utilize the whole
machine |
19:36.07 |
Twingy |
ah |
19:36.08 |
learner |
using distcc |
19:36.23 |
learner |
it builds and links in parallel |
19:36.27 |
Twingy |
the bottleneck was network i/o no? |
19:36.47 |
learner |
nah, it was the link synchronizations it has
to keep doing |
19:36.49 |
Twingy |
cause it was using nfs to run thousands of
binaries over and over |
19:36.55 |
learner |
automake serializes them all |
19:36.57 |
Twingy |
ah |
19:37.08 |
Twingy |
have you tried it yet? |
19:37.12 |
Twingy |
I have the cluster running right now |
19:37.17 |
learner |
everytime it linked a binary or a library, all
the nodes had to sync up and stop |
19:37.23 |
Twingy |
ah |
19:37.36 |
Twingy |
compile it and get some numbers ;) |
19:37.48 |
learner |
argued with the gnu make folks about it for a
while, they seemed pretty clueless |
19:37.55 |
Twingy |
hehe |
19:38.55 |
Twingy |
I got a hostname for the 2 machine cluster, if
you want to call it a cluster |
19:39.10 |
learner |
should be interested to see numbers for
it |
19:39.32 |
learner |
s/ed/ing/ |
19:39.39 |
Twingy |
do it :) |
19:39.52 |
learner |
i meant for the new ones coming in
:0 |
19:39.56 |
Twingy |
oh, heh |
19:40.01 |
learner |
i'll try the fast target on the cluster in a
bit |
19:40.04 |
Twingy |
k |
19:40.50 |
Twingy |
I think I might run to home depot to pick up 2
straps to bind the 2 machines together |
19:40.59 |
Twingy |
actually 3 |
19:41.00 |
learner |
elmers |
19:41.03 |
Twingy |
2 for bottom |
19:41.08 |
Twingy |
and one for around middle |
19:41.13 |
Twingy |
eek |
19:41.17 |
learner |
duck |
19:41.19 |
Twingy |
I got plenty of epoxy |
19:41.20 |
learner |
tape |
19:41.22 |
Twingy |
mmm |
19:41.25 |
Twingy |
duct tape could work |
19:41.39 |
Twingy |
ghetto.arl.army.mil |
19:41.49 |
Twingy |
ducttape.arl.army.mil ? |
19:41.53 |
learner |
dahood.arl.army.mil |
19:41.56 |
Twingy |
hehe |
19:42.16 |
Twingy |
homeslice.arl.army.mil |
19:42.27 |
Twingy |
hrm, food does sound good |
19:42.28 |
learner |
twobits |
19:42.40 |
Twingy |
I might run to riverside pizzeria |
19:42.47 |
learner |
mmm |
19:43.04 |
learner |
you'll be hungry by the time you get there if
you're running ;) |
19:43.08 |
Twingy |
heh |
19:43.12 |
Twingy |
I should go running |
19:43.17 |
Twingy |
maybe I'll do that tommorrow |
19:43.20 |
learner |
i should go work out |
19:43.26 |
learner |
but instead I think I'll stuff my
face |
19:43.28 |
Twingy |
I'm working on my man boobs |
19:43.37 |
Twingy |
*poke* |
19:43.44 |
Maloeran |
an* rather |
19:43.47 |
Twingy |
you want to poke my man boobs mal? |
19:43.50 |
Twingy |
:) |
19:44.19 |
Maloeran |
I'll pass :) |
19:44.43 |
Twingy |
that sad thing is it'll take me 30 years to
catch up to chuck if I start now |
19:51.26 |
Maloeran |
I'm telling you, try a hour of bicycle daily
;), plus some 40 push-ups so the arm and back muscles don't feel
too neglected |
19:55.57 |
Twingy |
my usual routine is 20 minutes of running and
15 minutes of bicycle with 60 situps and 25 pushups in the
middle |
19:56.17 |
Maloeran |
Quite good |
20:25.04 |
Twingy |
back |
20:30.09 |
Twingy |
sean, when you get a chance |
20:30.43 |
Twingy |
can you change permission of source files in
libtie to 644 |
20:30.49 |
Twingy |
somehow they got set to executable |
20:34.43 |
*** join/#brlcad x_spager
(n=x_spager@201.5.98.158) |
20:40.10 |
*** part/#brlcad x_spager
(n=x_spager@201.5.98.158) |
21:10.01 |
Twingy |
heh |
21:10.10 |
Twingy |
if my ray intersection engine did 0
work |
21:10.21 |
Twingy |
I could get 5.2 million rays/sec |
21:10.59 |
Twingy |
so intersecting each ray for me is like the
cost of 5 function calls, damn that's cheap |
21:17.09 |
CIA-5 |
BRL-CAD: 03twingy * 10brlcad/src/adrt/libtie/
(kdtree.c kdtree.h Makefile.am tie.c tie.h): |
21:17.09 |
CIA-5 |
BRL-CAD: kdtree code was put into its own
separate file since it's going to consume |
21:17.09 |
CIA-5 |
BRL-CAD: more than half the actual engine
code. |
21:19.12 |
CIA-5 |
BRL-CAD: 03twingy * 10brlcad/src/adrt/libtie/
(kdtree.c tie.c): removed extraneous stuff |
21:22.41 |
CIA-5 |
BRL-CAD: 03twingy *
10brlcad/src/adrt/libtie/kdtree.c: more cleanup |
21:36.23 |
learner |
Twingy, ugh |
21:36.29 |
learner |
no not really, at least not directly |
21:36.44 |
learner |
have to be careful what the permissions are on
check-in |
21:36.53 |
learner |
s/check-in/add/ |
21:37.30 |
learner |
i'll have to submit a sourceforge support
request to do that |
22:25.24 |
Twingy |
ah |
22:25.25 |
Twingy |
k |
22:25.38 |
Twingy |
gotta love how cvs won't let you udpate
permissions |
23:01.23 |
CIA-5 |
BRL-CAD: 03brlcad *
10brlcad/misc/Makefile.defs: fix the recursion traversal order so
that subdirectories are fully processed before attempting to
link/compile in a directory. |
23:01.39 |
learner |
generally, you'd edit the cvs root for that
but we don't have access to that directly |
23:02.20 |
Twingy |
hrm |
23:02.26 |
Twingy |
hey sean |
23:02.54 |
Twingy |
somone you met at siggraph wants you to visit
her in october :) |