4-day Multi-threaded Interactive Ray Tracer

[nullsquared]

The implementation of global illumination that is currently being made won't need a larrabee to run in real-time. It'll run on performance similar to the demo's already shown. (There are some neat tricks behind it)

Something I forgot to mention. There are many global illumination demos out there that use rasterization and run at 400+ FPS on common 'casual-gamer' machines. My favorite, http://lightsprint.com/

http://www.youtube.com/watch?v=lB5_x2BVRH0

[Kojack]

Just look at the screenshots in this thread, 3 completely different RT engines, based on different algorithms and skills produce nearly the same result, visually speaking.
So, for me RT can be tweaked, but not very much...

Surely you aren't seriously saying that because 3 people implement the very simplest component of a ray tracer as a hobby and the results look similar that must represent the limits of ray tracing as a whole?

All the following pics are from just 2 ray tracers.
Realsoft 3D:







Povray:

[jjp]

I don't think it's because they don't know how to fully utilize RT..

They've actually tried to use GI and didn't like it. But as already said: movies are different in that regard. An artist can manually place light sources to get better looking results than "real" GI algorithms. Which works for movies but doesn't work for interactive 3d graphics.

[_tommo_]

*many images*

Really, i'm serious... and the images you posted simply prove my idea... hey, they all have the same visual feeling!
For example, there's one image representing bolts on wood made with Realsoft and one made with powray: they are nearly identical.
Also all the panoramas are really "cold" and clean, they look like photos made in early morning.

I can't see how you can say that those images are very different between each other... they look all similar to me, regarding light and atmosphere settings...
if you posted them without the tool's name i could easily think that they were made with the same one.

Think at the difference between Doom3 and Halo, for example... i think that it's easier to recognize the engine used from a random screenshot...

[jjp]

..these are done with mentalray and I'd say they have a different visual feeling.

[_tommo_]

Ok i changed my mind then

But why one should need a RT for a toon render?

Anyway mine it's not a critic to the RT rendering, wich is for sure a very interesting challenge... i wanted only to expose my doubts, since you see many many RT crystal spheres, and very few NPR renderings.

[jjp]

Ok i changed my mind then

But why one should need a RT for a toon render?

I have no idea But I guess one shouldn't think in terms of rasterization and ray tracing as the two mutually exclusive methods for rendering 3d graphics. Rather both are "low level" building blocks which can be used for lighting algorithms.

[jacmoe]

I can't see how you can say that those images are very different between each other... they look all similar to me, regarding light and atmosphere settings...
if you posted them without the tool's name i could easily think that they were made with the same one.

They look similar because they look lifelike. They look like the real thing, the real world.
Some may say they look better than the real world, because they would take a very expensive camera to make, have they been photos.

[Azgur]

The reason you see so many spheres in programmer made scene is because they're the easiest primitive to implement and accomplish something a rasterizer can't.

[nullsquared]

The reason you see so many spheres in programmer made scene is because they're the easiest primitive to implement and accomplish something a rasterizer can't.

Only reason I used spheres was because they are so common...

Considering my ray tracer uses Newton, you can freely use boxes/spheres/arbitrary triangle meshes/cones/cylinders/etc/arbitrarily scaled versions of these/etc with a single line swap from phys::mesh::ball() to whatever you need

[nullsquared]

For example, effortless boxes:

(so, anyone tried the 'interactive' version yet?)

Edit:
Effortless eggs:

[nullsquared]

Effortless convex hulls:

[jjp]

Yeah, I just tried it.. gave me my first blue screen since I don't know how many months on Windows. And the first one ever on Vista so far

[nullsquared]

Yeah, I just tried it.. gave me my first blue screen since I don't know how many months on Windows. And the first one ever on Vista so far

woah. I don't know if I should tell others to try it now or just take it down for debugging on my other computers ... sorry about that

[_tommo_]

Yeah, I forgot to mention that the "interactive" demo gave me a sudden Blue Screen of Death

Extract -> double click -> BSOD.

It was not the video driver, it was really bad.
I ran it on Vista 32bit + Core2Duo E6600 + Catalyst 8.11, X1950 pro.

And it was the first BSOD i ever had since a year or more.

[jjp]

woah. I don't know if I should tell others to try it now or just take it down for debugging on my other computers ... sorry about that

Don't worry about it For your information: I tried it on a Core2Duo.

[nullsquared]

Yeah, sounds like something is mega-wrong there. I'll see what I can do, then reupload.

[Caphalor]

The interactive version works for me. I have an amd athlon x2 3800.
By the way: While watching the great screenshots here, I decided to write a simple raytracer, too. But I'm not finished yet...

[Azgur]

The reason you see so many spheres in programmer made scene is because they're the easiest primitive to implement and accomplish something a rasterizer can't.

Only reason I used spheres was because they are so common...

Considering my ray tracer uses Newton, you can freely use boxes/spheres/arbitrary triangle meshes/cones/cylinders/etc/arbitrarily scaled versions of these/etc with a single line swap from phys::mesh::ball() to whatever you need

Doesn't change my point really
Spheres and planes are the easiest primitives to implement. Deriving them mathematically is easier than deriving other primitives. At least in my opinion.
I wasn't talking about you specifically, but rather the impression I got after seeing a complete class write ray tracers.

But back to the main topic. Quite addictive isn't it?

[twilight17]

Since it's giving a BSOD on Intel-based CPUs (C2Ds), it sounds to me like you compiled it for AMD CPUs. There's probably architecture specific code or a compiler setting that's causing this. (Caphalor's AMD Athlon X2 3800 works.)

[nullsquared]

Since it's giving a BSOD on Intel-based CPUs (C2Ds), it sounds to me like you compiled it for AMD CPUs. There's probably architecture specific code or a compiler setting that's causing this. (Caphalor's AMD Athlon X2 3800 works.)

Yeah, except there is no CPU-specific code in there at all.

@ others: does the non-interactive demo I posted blue screen as well?

[xadhoom]

Hi!

In my opinion spheres are special among boxes and "convex hulls" because they
give you a non linear distortion in reflection which is very uncommon effect in the
rasterized world and ofcourse you don´t have the triangle corners like in case
of a common triangle sphere.
Perfect parametric surface visualisation, like Nurbs are very unlikely with rasterisation (maybe the
tesselation techniques of the latest cards will change this)

[Kojack]

Since there's a bit of confusion on here about what raytracing really is, I'll provide a little detail. Of course there's various ways for these to work (different features, lighting equations, etc), this is just a basic way. I'll use a triangle as the primitive for both to simplify.

A rasteriser takes a each triangle one at a time and projects it onto the screen. The triangle is rendered a row at a time, with the colours, normals and uv coords of each pixel calculated by interpolating the 3 corners of the triangle. The z buffer is used to compare the distance from the camera of each pixel against the last distance for that pixel, so you can skip rendering a pixel which is behind something you've already rendered.

A ray tracer loops through every pixel on the screen and casts a ray from the eye through the pixel. The ray is tested for intersects with every triangle in the scene (in real life you'd use various spatial subdivisions to increase performance). If there are several intersects, only the closest one to the camera is kept. The result of the ray cast will be the position on the nearest triangle which intersected the ray. The values for the intersect point on the triangle (colours, normal and uvs) can be calculated by interpolating the 3 corners of the triangle. Since we always return the closest intersect, no z buffer is needed.

So far, both techniques are interpolating colours, normals and uvs across the face of a triangle.

Lighting (without shadows):
In a rasteriser the normal of the pixel being rendered (interpolated surface normal, or a normal map, etc) is dot producted with the normalised vector from the pixel to the light source. The result is multiplied by the colour of the light, the attenuation factor and the diffuse colour of that point on the triangle (texture lookup, interpolated corner colours, etc). That gives the diffuse colour of each pixel.

In a ray tracer the normal of the pixel being rendered (interpolated surface normal, or a normal map, etc) is dot producted with the normalised vector from the pixel to the light source. The result is multiplied by the colour of the light, the attenuation factor and the diffuse colour of that point on the triangle (texture lookup, interpolated corner colours, etc). That gives the diffuse colour of each pixel.

In other words, both calculate diffuse lighting in the exact same way.
When doing shadows though, ray tracers have an advantage. Just before doing the dot product of the normal and the light direction, you cast out another ray from the pixel to the light. If it hits anything closer than the light, that pixel is in shadow and you can skip the rest of the diffuse calculation.

The exact same thing happens for specular lights, both rasterisers and ray tracers use the same basic formula.

Transparent objects:
A rasteriser renders transparent objects sorted by distance (far to near) so each one can blend with anything underneath. Refraction can be done by having a cubic environment map of the entire scene already rendered from the location of the pixel, then do a lookup of it based on the angle of incidence and the difference in media density (air to glass, etc). But rendering a full cubic environment map (which requires 6 renders of the scene) for every pixel is SLOW, so people usually render one from the center of the whole object, which is ok for faking it, but inaccurate and has no self refractions.

A ray tracer will cast a new ray from the intersect point on a transparent object, to see the next thing that it hits, and blend with the result. If that intersect is also a transparent object, the process continues. Refraction can be performed by changing the direction of the extra rays based on the angle of incidence and the difference in media density.

Reflections:
Similar to refractions for both. You need something like a cubic environment map for a rasteriser to reflect surrounding objects (same problem, you either need one per pixel (SLOW) or one per object (inaccurate). The ray tracer just bounces another ray off the surface.

So overall the actual appearance of a pixel in both ray tracing and rasterising is calculated in virtually the same way. Any standard lambert lighting based scene (a game, whatever) done by a rasteriser can be recreated by a ray tracer. But the ray tracer can also use non triangles, like true mathematical solid objects (a rasteriser could too, but current gpus can't. Software rasterisers like Max could though).


With unlimited time, both techniques can produce virtually identical results. But they both have certain speed and ease of use advantages over the other.


There's a good 130 page pdf on Pixar's website which goes into ray tracing in far more detail, and talks about how it's been used in all Pixar movies since A Bug's Life, and in particular was used pretty heavily in Cars (all ambient occlusion and shadows were ray traced, and all reflections and refractions were ray traced).

[Shadow007]

I'm late to the discussion !!! Sorry for reviving old arguments...

And about the real-time ray tracing ... The thing is, of course it's possible. But it cannot surpass rasterization. I don't care if some ray tracer can do normal mapping, specular, diffuse, per-pixel shadows, etc, at 20 FPS on a quad-core. You can do all of that and way more just by using rasterization with a modern GPU and some shaders - at above 100 FPS.

Yes, you're right. But what about comparing apples to apples : What are the performance of software only rasterization ? In one case, you have a "fully CPU" run software, in the other case you use HIGHLY specialized hardware...

Once you start adding in complex reflections and refractions, correct soft shadows, ambient occlusion, global illumination, and the rest of the stuff that ray tracing is really meant for, it's not going to be real-time anymore.

Once again you're right. But with some help from hardware, all of these problems could also be "accelerated" 10-100 time. While ambient occlusion and global illumination would still remain too costly to be used really interactively, the other effects would become quite "cheap" ... and thus mostly "for free".

It's true that rasterizing is the primary, most efficient/performence... at the moment, thanks to the specialized GPUs.
That trend can shift since GPUs tend to be more and more programmable, meaning that in some case their power is/will be used for other areas than rasterizing. One such area is Ray-Tracing.

Why? Larrabee screams "better configurable rasterization pipeline" I think

Yes, but also "sufficiently general purpose GPU" to be used as a ray-tracing accelerator...

As Azgur may tell you, A MAJOR bottleneck for Arauna is the CPU-side equivalent to the texturing unit. It takes 40% of the CPU just to compute a bilinear filtering for 1 texture. In the Larrabee architecture, which is otherwise fully programmable , the texturing unit is the only one that was kept as fully hardware...

The sphere code in Arauna is efficient, and does not reduce the performance of scenes that have no spheres.

The way that is written, I understand it as 'add in a few reflective spheres and you've got a big performance problem.' One of the primitive problems solved by ray tracing, reflections, is pretty much dismissed.

I'm quite sure (though not completely of course) that it should be interpreted as :
"I needed to render some spheres, so added code in Arauna to do it. Since it's a feature that may not be needed in some situations, I made sure that the new feature imposes no penalty in situations where it's not usefull."
Regarding the performance of reflective spheres, I've no Idea, but I guess it's not that bad, since reflections/refractions were already handled "quite efficiently" in Arauna.
Perhaps Azgur may ask his teacher about it ???


Regarding Artists and RT for games (later in the thread), Azgur is a student in a school where Jacco Bikker (aka Phantom) is a teacher. The goal of some of Phantom's courses is to educate artists/programmers to "the ways of ray-tracing", to showcase Ray-tracing as an other option to Rasterizing, and to present the limits of the technology to his students.

With the advent of "Ray-tracing friendlier" GPUs, I think he's right to at least familiarize his students to this topic.

An artist can manually place light sources to get better looking results than "real" GI algorithms. Which works for movies but doesn't work for interactive 3d graphics

On the contrary, beeing able to place/displace the light completely during the game design, or simply to put fully dynamic lights which will behave "correctly" will help the artists, making it easier/faster for them to express their artistic view, without having to preoccupy themselves with things as mundain as LISPSSM/**SSM shadow maps parameters/algorithms.

[jjp]

On the contrary, beeing able to place/displace the light completely during the game design, or simply to put fully dynamic lights which will behave "correctly" will help the artists, making it easier/faster for them to express their artistic view, without having to preoccupy themselves with things as mundain as LISPSSM/**SSM shadow maps parameters/algorithms.

I don't get what you are saying. My point was: for a movie you can hand-tweak every shot, because the camera moves on a pre-defined path. With interactive 3d graphics this is different; the camera can move around relatively freely. So among other things you can't fake lighting as easy as you could in a movie.