| 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 :) |