> 104 million MODELS have been tested, running at several frames per second

Now THAT'S impressive! ;)

Seriously, really cool. What spatial structure do you use?

Ah! Now that's something. Very nice model.

Now for the performance part, as you're a bit light on details, i'll have to wild guess: 1 light, most rays missing the detailled mesh (which has only one texture applied - no bump etc)... Hmm... you said it moves, so that might put some constraints on the space partionning, unless you really meant "move" as opposed to "some parts are animated"... and then you're hoping for a 2x speedup? I'd say you've gone the Wald style, right?


PS: there's no such thing as a 3.4Ghz opteron.

That's very cool. How do you store that many polygons? And how long does it take to build a kd-tree for that many polygons? :)

Interesting that so many people are working on high performance ray tracers nowadays. You are the fourth that I know that is getting this kind of performance.

BTW do you use adaptive supersampling? Just curious. And while I'm at it, I might as well ask another question: If you had to choose, would you first implement bump mapping, or adaptive super sampling? :)

it cant be raytraced!
evidence: theres no sphere/s

What do you think of the hardware accelerated raytracing card at this years GDC? I couldnt find any videos of it but it sounded really cool.

Jacco,
a) you're ugly.
b) bump mapping, any day.
c) you're ugly.
d) if i, like an undisclosed ugly person, was confusing sub-sampling and AA, i'd keep a low profile.

BTW, you said 4: who's the third?

Hi all. Thanks for the coments :)

500,000 polys ray traced @ 0.5 fps with reflections and shadows? Holy crap. Do you have a demo?

Where did you find 104 million 3D models? I didn't even know there were 104 million 3D models worth ray tracing.

-m

I honestly hope that was sarcasm.

I thought poly count is not a huge problem with raytracers when the raw performance is sufficient (log scaling)

That rt card at the GDC is under development for quite some time already. You can find videos @ www.openrt.de .

nope not sarcasm

Wow, really cool stuff Iñigo.
Fear the raytracing!

Dude, thanks to you my sarcasm detector just exploded.

Impressive results!
3 questions:
- you're using a 4-processor system I assume. Are you running exactly 4 threads?

- those 4 processors are constantly accessing memory... Is the performance bottleneck indeed due to memory access, or still CPU-related?

- For the 104M tris scene, was that a single model, or did you use instancing? BTW where can we find that model?

Instancing = interesting problem in ray tracing.

So far the only attempts at real time ray tracing for a game has been done by Wald & friends @ Saarcor. Rendering at interactive speeds is a though task in itself, animating makes it worse: High performance ray tracing currently requires a high-quality kd-tree, and animation means you have to update this tree in real-time. In practise, this means lower quality trees.

I'm bringing this up because right now I don't know of any ray tracer that actually uses instancing in the kd-tree, although it might be possible. I do however see lots of scenes with lots of repetition. Look at the ship above: I can see a row of 8 guns, and I suspect there's another 8 on the other side (you didn't cheat *that* badly did you? ;) ).

The problem with instancing is quite similar to the problem with animation: Somehow you need to insert prefab kd-tree nodes somewhere in the tree.

Did anyone experiment with that? You can speak safely, El Pinto has had too many Pinto's and is asleep. ;)

104M: You could of course simply toss together lots of smaller models. Imagine an army of Buddha's. ;) Now that I am thinking of it, lots of bunnies is probably more suitable.

Indeed, you precompute kd-trees for the to-be-instanced object, and just plug it into another subdivision structure. It's simple and extremely fast. Just look at this example (which you've probably seen already):
http://www.openrt.de/Gallery/OliverDeussen_Sunflowers/Images/sunflowers_1.jpg
They only use one flower, but replicate it a few thousand times. It gives you a billion tris per second of performance. However, it doesn't generalize to non-instanced models because you need to access more memory. The model might not even fit in RAM, so out-of-core rendering is required. I guess a "model_size/sec" might be a better metric than #tris/sec for ray tracing performance of insanely complex models. BTW, Wald has already looked into the problem of out-of-core rendering (see "An Interactive Out-of-Core Rendering Framework for Visualizing Massively Complex Models ").

Oh, if he means that he ran a scene with 104 million models, I'm not (as) shocked. I thought he meant that he tested with 104 million different 1-model scenes and was able to achieve real time on all of them.

-m

As i know Inigo IRL, i can answer a few questions until he's back:
- the 104M models is a typo, it's one model with 104M Tris.
- he doesn't use instancing or any kind of cheating. Some objects like the cannons in the ship might be repeated but they're all "physically" different triangles.
- the 104M Tris models is not available to the public (it's an oil plat-form). It's also given as a poly soup, so no instancing there either. It takes 4 or 5 Gb to load in RAM.
- Inigo's raytracer uses multi-threading for multi-cpu/core systems. I also programmed a cluster version on top of his code, which we are testing with multiple computers in a LAN.
- the performance is in log(n) and dependant on the resolution (amount of pixels to trace) as you'd expect from any raytracer. Which is why actually larger models are not that slower.. but on the other side, more simple models are not that faster!

Brebion, since you coded the cluster version, perhaps I can ask you a question: How did you deal with the comms between the various systems? I added networked rendering to my tracer, but I had quite severe problems with the amount of data going to and from 'slave' machines. At 10fps / 300kb per frame you don't want to use TCP, but UDP is unreliable, and there are problems with packet collisions. Could you give some hints?

(I did get it working decently in the end, but I'm still experiencing problems with more than 2 slaves, and the overhead is quite bad)

Jacco, UDP is the way to go, IMHO. You can implement reliable UDP networking. There are some methods around.

I commonly use numbered packets with acknowledge requests, and receive data in many small, fragmented blocks. If an ack packet is not received by the sender, it resends the lost packet. It works very well, because UDP is really faster than TCP.

Oh, BTW, I have written a networking class that handles non-blocking, reliable UDP networking. Packets may or may not request acks, and it works well for me.

Packet collisions do not occur when using a switch instead of a hub, or am I just plain wrong here?

Again, UDP is far better than TCP, I'm pretty sure you know this.

http://www.deviantart.com/deviation/16098446/

Can any of you guys give hard numbers for UDP + reliability layer vs. TCP? I'm interested to know what kind of bandwidth and latency difference you have measured. There's a lot of discussion about writing one's own UDP wrapper, but I haven't yet seen a case where that was actually demonstrated to be significantly faster.

-m

Another question:
Got any idea about #tri/ray?
What kind of spatial subdivision do you use?