Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 


Submitted by Iņigo Quilez, posted on March 18, 2005




Image Description, by Iņigo Quilez



Hi all! Well, another raytracer. Something special on this one?? Not really, may be the ability to display big models. Up to 104 million models have been tested, running at several frames per second (with shadows) using 4 CPUs, in small windows :( . The raytracers works on Win32, Win64, Linux64 and MsDos 6.2/Vesa2.0 (32bit).

The image above is a render of a medium-small model (half million polys, from www.deespona.com). The ship moves at 0.6 fps on 1280x960 resolution, using a 3.4 Ghz Opteron. I hope I can reach two times that performance soon (still lot of work to do - ...do I need to say this?).

There is support for textures (only bilinear right know) and some rudimentary shaders, as the ocean shader shown on the screenshot. That one uses 2 rays (additional to the primary one) for shadow and reflection. The shader of the ship is wrong right now, but you can maybe see some shadows on it.


[prev]
Image of the Day Gallery
www.flipcode.com

[next]

 
Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Sebastian Wagner

March 18, 2005, 11:57 AM

> 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?

 
El Pinto Grande

March 18, 2005, 12:09 PM

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.

 
Jacco Bikker

March 18, 2005, 01:16 PM

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.

 
Jacco Bikker

March 18, 2005, 01:18 PM

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

 
zed zeek

March 18, 2005, 01:29 PM

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

 
ZEN

March 18, 2005, 01:50 PM

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.

 
El Pinto Grande

March 18, 2005, 01:55 PM

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?

 
iql

March 18, 2005, 02:47 PM

Hi all. Thanks for the coments :)

Sebastian Wagner wrote: >104 million MODELS have been tested, running at several frames per second Now THAT'S impressive! ;)


104 million tris ;)


Jacco Bikker wrote: 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? :)


Well, the bump mapping is not something the raytracer engine should implement, but the "shader" itself. In fact it is allready done (and tested on other models) becasue is quite easy, both texture-based (normalmaps) and procedural. I also have other effects like reflection/fresnel/refractions, procedural textures (like the sea in this picture), and others. But as I said, I think thatīs something more on the shading part, no the raycaster itself.

The AAA is bit more complex. So, I would start with the bump mapping if you have to choose :)

El Pinto Grande wrote: 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...


Well, I can tell you that when you are completelly inside the ship walking thru the 40 canions inside, performance does not suffer. In the other hand, quite a lof of CPU work in this picture is actually spend on the ocean. Several Perlin noise evaluations are performed for the ocean surface and bump map, plus the reflection/refraction rays on the ocean.

El Pinto Grande wrote: I'd say you've gone the Wald style, right?


Well, there are good ideas in Wald's methods, but his is not "The True". There are some similar points in his and my method, thougth.

Well, I will post some new images when I have a faster inet conection next week. Thank you all.

 
Morgan

March 18, 2005, 04:09 PM

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

 
El Pinto Grande

March 18, 2005, 04:10 PM

iql wrote: So, I would start with the bump mapping if you have to choose :)

EPG WINS!

Well, I can tell you that when you are completelly inside the ship walking thru the 40 canions inside, performance does not suffer.

But that would put a different load on your space partionning, ie traversing way more nodes to get a hit.

In the other hand, quite a lof of CPU work in this picture is actually spend on the ocean. Several Perlin noise evaluations are performed for the ocean surface and bump map, plus the reflection/refraction rays on the ocean.

Ok, so in that shot you're kinda shading limited (like i tried to point).
Could you post an "interior view"?
And could you detail your animation system a bit?

Well, there are good ideas in Wald's methods, but his is not "The True". There are some similar points in his and my method, thougth. Well, I will post some new images when I have a faster inet conection next week. Thank you all.


Please do :)

 
[MENTAL]

March 18, 2005, 04:19 PM

I honestly hope that was sarcasm.

 
Axel

March 18, 2005, 04:30 PM

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

 
Jacco Bikker

March 18, 2005, 05:21 PM

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

 
zed zeek

March 18, 2005, 07:39 PM

nope not sarcasm

 
Ono-Sendai

March 18, 2005, 11:23 PM

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

 
Sebastian Wagner

March 19, 2005, 02:03 AM

Dude, thanks to you my sarcasm detector just exploded.

 
T_M

March 19, 2005, 07:01 AM

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?

 
Jacco Bikker

March 19, 2005, 07:22 AM

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. ;)

 
Jacco Bikker

March 19, 2005, 07:24 AM

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.

 
T_M

March 19, 2005, 08:20 AM

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 ").

 
Morgan

March 19, 2005, 10:27 AM

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

 
Brebion flavien

March 19, 2005, 10:54 AM

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!

 
Jacco Bikker

March 19, 2005, 12:23 PM

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)

 
Scali

March 19, 2005, 06:50 PM

Jacco Bikker wrote: So far the only attempts at real time ray tracing for a game has been done by Wald & friends @ Saarcor.


Hey, don't forget the bowling games from www.realstorm.com :)

 
Vander Nunes

March 19, 2005, 11:51 PM

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.

 
Vander Nunes

March 19, 2005, 11:55 PM

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.

 
El Pinto Grande

March 20, 2005, 03:02 AM

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

Utterly wrong.
With a hub you share the collision domain, so they are more probable but that's it.

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

I hope you really meant UDP is better than TCP in this particular case.

 
 
Morgan

March 20, 2005, 10:55 AM

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

 
Lotuspec

March 21, 2005, 05:14 AM

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

 
This thread contains 30 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.