Pandora Raytracer For The Pandora

[rahulgarg]

I am starting a new raytracer (right now for the PC but later for the Pandora).

So why I am writing a raytracer? Because I know nothing about raytracing so want to learn
The goal is to optimize it for multicores and SSE on the PC first then once Pandora comes out will see what can be done with the Cortex A8.

The idea is to have a system similar to Povray : you write your scene in a file and the raytracer converts it into an image. Right now learning Povray and got a book on raytracing as well.

People who have experience with ray tracers : any tips ?

(Btw license will probably be apache2 for people who care about this stuff. but well I need to write code first )

 

[atomicthumbs]

Cool. I'd like to see this when it's finished; maybe you (or somebody else) could write a modeler, like KPOVmodeler.

 

[MilanC]

Optimizing for multicores and SSE first seems strange, as you'll have none of that on Pandora.
Well, you could get some sort of multithreading, but the DSP isn't the same arch as the A8.

Maybe a more modular approach: a generic C program, and specific libs:
-Generic version first (compile on any arch)
-x86 SSE optimized version
-ARM optimized version

I almost don't know anything about programming, so that might just as well be stupid.

 

[hessiess]

don't expect it to be very fast on pandora, partly because of ram limitations and partly because of limited processing power. softwere rendering is very resource demeaning, especially more advanced techniques like global illumination, transparancy, colour bleeding and SSS (sub surface scattering).

If you program it on Linux, that would make porting easier.

 

[rahulgarg]

Optimizing for multicores and SSE seems strange, as you'll have none of that on Pandora.
Well, you could get some sort of multithreading, but the DSP isn't the same arch as the A8.

Maybe a more modular approach: a generic C program, and specific libs:
-Generic version first (compile on any arch)
-x86 SSE optimized version
-ARM optimized version

Well thats pretty much how I plan to go.

1. Working towards a generic simple C version with no platform specific assembler.

2. Then the next step will be to optimize for SSE. Will probably include it within a conditional define or something. The reason I want to do SSE first is .. well I already have a PC but have no idea when the Pandora (or any other OMAP3xxx based device for that matter) will actually be released.

3. Optimizing for Cortex A8. The cortex a8 seems to have some SIMD instructions (NEON) but havent looked in detail at them yet. The documentation is sparse. As for DSP, right now have no idea how ray tracing may potentially use a DSP and dont know the exact status of DSP compiler anyway.

4. Last step is to parallelize on PC. Ray tracing parallelizes well. POVray has a beta that can use all cores.

don't expect it to be very fast on pandora, partly because of ram limitations and partly because of limited processing power. softwere rendering is very resource demeaning, especially more advanced techniques like global illumination, transparancy, colour bleeding and SSS (sub surface scattering).

If you program it on Linux, that would make porting easier.

Thanks for the tips. Yes I can see that raytracers are slow. Tracing complex scenes takes a fair bit of time even with Povray which is a very mature system. Povray claims that the code is optimized for SSE2 and the beta does take advantage of multicores too. So I guess realtime raytracing isnt coming anytime soon

Part of the reason of doing this project is to learn about raytracing and partly to have a somewhat well defined problem so that I can learn more about the OMAP3xxx. I do have some experience with x86 assembler and SSE.

I do expect that it will take time .. a lot of time.

I am programming in Linux.

Cool. I'd like to see this when it's finished;

Lets meet again in 10 years
Well basic raytracers seem simple but raytracers seem to be never ending pits.

 

[MilanC]

[ removed ]

 

[Tozarian]

Wow! I hope this turns out great!

 

[Jaxartes]

Good luck. I wrote a ray-tracer when I was in college (back in the mid-1990s; started out as a hobby project but ended up doing it for a class). Didn't bother optimizing or using architecture specific features.

Here're a few thoughts. They're probably already covered in your book, but I'll put them out there anyway:

1. One big problem my ray tracer had, had to do with arithmetic inaccuracy. Consider what happens after you've intersected a ray with an object. You've computed the point of intersection, and the direction the reflected ray takes from there. Now you go through and search for intersections... and find the same one you were starting from! Due to arithmetic inaccuracies, sometimes it'll appear to be "behind", and some times "in front", of you. The end result is a lot of weird speckles in your image, as the rays go somewhere other than expected. It's not a trivial problem (consider that it's possible for an object to intersect itself). I worked around the problem and got my ray tracer running, I think by just adding a "fudge factor" or something. But I'd have preferred something more elegant. Like, maybe having the ray tracer "identify" the intersection point, while doing the reflection, in some way that it can reliably recognize when processing the reflected ray.

2. Ray tracers favor different kinds of shapes, and different ways of specifying them, than are familiar in some other kinds of 3D graphics. AFAIK, live rendering favors shapes that take the form of a "mesh" of polygons. But in a ray tracer, while such a mesh is certainly possible, it's not necessarily optimal. Computing a sphere, as a sphere (infinitely smooth) may actually be better than approximating it with a large number of polygons. Another thing you can do is define a shape by combining other shapes. (In fact, that's the main area I was interested in when I wrote my ray tracer.) You can define a shape as the "intersection" of two other shapes (that is, the composite shape contains all points that are in *both* of the component shapes) or the "union" or "difference" of two shapes. It's fairly straightforward to compute, and you can do it to any shapes you want. Basically, when you're computing the possible intersections between a ray and your object, you compute the set of intersections between it and the two component objects, and then combine the two sets together in the appropriate manner (your book will probably have a lot more detail on this).

3. As pointed out above, Pandora's not that spectacular a system for ray tracing. I'm not convinced the memory usage is such a big issue. But it's an area where the more CPU speed you can get, the better. (Although I'll point out, when I was working on my ray tracer the available CPUs were considerably slower than Pandora is going to have, even on high end workstations. A single 100MHz 64-bit CPU (MIPS R4000) in a $20,000 machine) I'll also point out that the 3D graphics hardware is probably useless to a ray tracer. It just works differently. (I could be mistaken on that. Maybe someone's found a way to do it.)

 

[rahulgarg]

Good luck. I wrote a ray-tracer when I was in college (back in the mid-1990s; started out as a hobby project but ended up doing it for a class). Didn't bother optimizing or using architecture specific features.

Here're a few thoughts. They're probably already covered in your book, but I'll put them out there anyway:

1. One big problem my ray tracer had, had to do with arithmetic inaccuracy. Consider what happens after you've intersected a ray with an object. You've computed the point of intersection, and the direction the reflected ray takes from there. Now you go through and search for intersections... and find the same one you were starting from! Due to arithmetic inaccuracies, sometimes it'll appear to be "behind", and some times "in front", of you. The end result is a lot of weird speckles in your image, as the rays go somewhere other than expected. It's not a trivial problem (consider that it's possible for an object to intersect itself). I worked around the problem and got my ray tracer running, I think by just adding a "fudge factor" or something. But I'd have preferred something more elegant. Like, maybe having the ray tracer "identify" the intersection point, while doing the reflection, in some way that it can reliably recognize when processing the reflected ray.

2. Ray tracers favor different kinds of shapes, and different ways of specifying them, than are familiar in some other kinds of 3D graphics. AFAIK, live rendering favors shapes that take the form of a "mesh" of polygons. But in a ray tracer, while such a mesh is certainly possible, it's not necessarily optimal. Computing a sphere, as a sphere (infinitely smooth) may actually be better than approximating it with a large number of polygons. Another thing you can do is define a shape by combining other shapes. (In fact, that's the main area I was interested in when I wrote my ray tracer.) You can define a shape as the "intersection" of two other shapes (that is, the composite shape contains all points that are in *both* of the component shapes) or the "union" or "difference" of two shapes. It's fairly straightforward to compute, and you can do it to any shapes you want. Basically, when you're computing the possible intersections between a ray and your object, you compute the set of intersections between it and the two component objects, and then combine the two sets together in the appropriate manner (your book will probably have a lot more detail on this).

3. As pointed out above, Pandora's not that spectacular a system for ray tracing. I'm not convinced the memory usage is such a big issue. But it's an area where the more CPU speed you can get, the better. (Although I'll point out, when I was working on my ray tracer the available CPUs were considerably slower than Pandora is going to have, even on high end workstations. A single 100MHz 64-bit CPU (MIPS R4000) in a $20,000 machine) I'll also point out that the 3D graphics hardware is probably useless to a ray tracer. It just works differently. (I could be mistaken on that. Maybe someone's found a way to do it.)

Thanks for the pointers. Will keep them in mind
The GPU is pretty much useless for raytracing. Will basically focus on driving the cortex to the maximum.

 

[ldesnogu]

3. Optimizing for Cortex A8. The cortex a8 seems to have some SIMD instructions (NEON) but havent looked in detail at them yet. The documentation is sparse.

Indeed. All freely available information is linked here: http://pandorawiki.org/Hardware_documentation

QUOTE
As for DSP, right now have no idea how ray tracing may potentially use a DSP and dont know the exact status of DSP compiler anyway.

Again look at the wiki: http://pandorawiki.org/Development_tutorials

 

[rahulgarg]

3. Optimizing for Cortex A8. The cortex a8 seems to have some SIMD instructions (NEON) but havent looked in detail at them yet. The documentation is sparse.

Indeed. All freely available information is linked here: http://pandorawiki.org/Hardware_documentation

QUOTE
As for DSP, right now have no idea how ray tracing may potentially use a DSP and dont know the exact status of DSP compiler anyway.

Again look at the wiki: http://pandorawiki.org/Development_tutorials


Thanks.

 

[yosh64]

hey

I actually started a raytracer recently also, but stopped working on it for now. I only got up to rendering spheres with diffuse and specular lighting and also shadows (with multiple light sources ), and I did try rendering polygons but I think my triangle intersection is screwed.

Anyhows I advise ya start by just renderering spheres, they very fast and quite easy to detect intersections and such.

Later ya might wanna look into photon mapping and such also, but nevermind this for now.

Umm, here are a few extra resources ya might find handy. Although I hope I don't overwhelm you with these or anything.

Ray Tracing News Guide (has lots of cool stuff)
DevMaster.net <- Raytracing: Theory & Implementation
Interactive Ray Tracing (another interesting article by The Phantom)
cfxweb.net <- Real Time Ray Tracing (mentions alot of optimisations)
The Big Honkin' Ray Tracing Tutorial
Ray Tracing tutorial
mandelbrot-dazibao.com <- Raytracing
The Recursive Ray Tracing Algorithm

Finally, I think the GPU can be quite handy to optimise a software raytracer for realtime raytracing. Hmm, well I remember reading a nice tip but can't remember now. Although I'm not sure how handy the pandora gpu would be, hehe.

edit
BTW, I think you might be particularly interested in The Phantom's Interactive Ray Tracing article, as to quote "See how advances such as Hyper-Threading Technology and dual-core processors affect ray tracing—allowing for three- to four-fold speed increases." .

cya

 

[rahulgarg]

hey

I actually started a raytracer recently also, but stopped working on it for now. I only got up to rendering spheres with diffuse and specular lighting and also shadows (with multiple light sources ), and I did try rendering polygons but I think my triangle intersection is screwed.

Anyhows I advise ya start by just renderering spheres, they very fast and quite easy to detect intersections and such.

Later ya might wanna look into photon mapping and such also, but nevermind this for now.

Umm, here are a few extra resources ya might find handy. Although I hope I don't overwhelm you with these or anything.

Ray Tracing News Guide (has lots of cool stuff)
DevMaster.net <- Raytracing: Theory & Implementation
Interactive Ray Tracing (another interesting article by The Phantom)
cfxweb.net <- Real Time Ray Tracing (mentions alot of optimisations)
The Big Honkin' Ray Tracing Tutorial
Ray Tracing tutorial
mandelbrot-dazibao.com <- Raytracing
The Recursive Ray Tracing Algorithm

Finally, I think the GPU can be quite handy to optimise a software raytracer for realtime raytracing. Hmm, well I remember reading a nice tip but can't remember now. Although I'm not sure how handy the pandora gpu would be, hehe.

edit
BTW, I think you might be particularly interested in The Phantom's Interactive Ray Tracing article, as to quote "See how advances such as Hyper-Threading Technology and dual-core processors affect ray tracing—allowing for three- to four-fold speed increases." .

cya



Big thanks
Will check out all the linked articles. Right now reading a book called "ray tracing from the ground up" and thinking of ordering a book called "physically based rendering" which is supposed to deal with lots of advanced stuff not necessarily related to ray tracing.

edit : Btw ray tracing is certainly a parallel task. Intel likes to showcase raytracing on multicores. Someone even converted Quake4 to raytracing based engine which runs in realtime at 720p using 16 cores.

 

[ldesnogu]

thinking of ordering a book called "physically based rendering" which is supposed to deal with lots of advanced stuff not necessarily related to ray tracing.

If you mean this book amazon, then do not hesitate a second, buy it, it's great!
However, it lacks the latest refinements: packet coherent RT which is used to SIMDize ray tracing; to get that info, you will need to dig into research articles, google is your friend

 

[rahulgarg]

If you mean this book amazon, then do not hesitate a second, buy it, it's great!
However, it lacks the latest refinements: packet coherent RT which is used to SIMDize ray tracing; to get that info, you will need to dig into research articles, google is your friend



Thats the book. I will order it now

 

[yosh64]

hey

I just remembered the gpu optimisation and thought I'd let ya know .

Basically you assign a color to each object and render them all with flat shading (no lighting and what not), then when it comes to looping through and checking for collisions with each ray of the screen you check the color of the pixel and lookup the object to check for collisions against if there are any.

Obviously this is only useful for direct/primary rays, and so doesn't help much with any indirect/secondary rays. Hmm, unless you rendered the scene again from the point and direction of the secondary arrays or something, which kind of reminds me of radiosity, which I'd like to try and do some day .

I forget where I read about this optimisation, I think it was breifly mentioned in some article I've read.

Anyhows if you are interested I could give ya some links about raytracing on the GPU and Photon Mapping, but I thought I would leave those for now as not to overwhelm you, hehe.

edit
Realistic Image Synthesis Using Photon Mapping <- I think this book is pretty well regarded also, although I don't have it.

Umm, I thought I might also refer you to this interesting thread about Ray Tracing Shadows and Refraction that you might find handy at some time when trying to implement refraction. I ran into this thread a little while back on gamedev.net.

another edit
I just realised that book I just mentioned is also on the amazon page of the other book linked to, where it says "Buy Together", and also in that thread I just linked to .

cya

 

[rahulgarg]

hey

I just remembered the gpu optimisation and thought I'd let ya know .

Basically you assign a color to each object and render them all with flat shading (no lighting and what not), then when it comes to looping through and checking for collisions with each ray of the screen you check the color of the pixel and lookup the object to check for collisions against if there are any.

Obviously this is only useful for direct/primary rays, and so doesn't help much with any indirect/secondary rays. Hmm, unless you rendered the scene again from the point and direction of the secondary arrays or something, which kind of reminds me of radiosity, which I'd like to try and do some day .

I forget where I read about this optimisation, I think it was breifly mentioned in some article I've read.

Anyhows if you are interested I could give ya some links about raytracing on the GPU and Photon Mapping, but I thought I would leave those for now as not to overwhelm you, hehe.

edit
Realistic Image Synthesis Using Photon Mapping <- I think this book is pretty well regarded also, although I don't have it.

Umm, I thought I might also refer you to this interesting thread about Ray Tracing Shadows and Refraction that you might find handy at some time when trying to implement refraction. I ran into this thread a little while back on gamedev.net.

another edit
I just realised that book I just mentioned is also on the amazon page of the other book linked to, where it says "Buy Together", and also in that thread I just linked to .

cya



Thanks for the pointers. Will keep them in mind though I guess I need to go through the more basic material first. Will bug you again in a few months

 

[Hotcooler]

Theoretically you can use GPU. Since it supports universal scalable shader architecture. Plus it uses the same ram as CPU, so theoretically you can compute something using shader engine and then pick the result from ram. So it should be easyer than it's done on PC's with Nvidia's CUDA and something same from ATI (There at lease you need to export result from GPU's Ram to main Ram).

 

[rahulgarg]

Theoretically you can use GPU. Since it supports universal scalable shader architecture. Plus it uses the same ram as CPU, so theoretically you can compute something using shader engine and then pick the result from ram. So it should be easyer than it's done on PC's with Nvidia's CUDA and something same from ATI (There at lease you need to export result from GPU's Ram to main Ram).

I am not familiar with the SGX architecture but I am familiar with CUDA and ATI's SDK both.
I dont know whether SGX has a global write capability. i.e. whether you can write to arbitrary positions in memory or do you need to write to specific locations? You cannot do arbitrary writes using OpenGL alone AFAIK and thats the extra capability exposed through CUDA and ATI SDK.

Not very sure how it affects raytracing .. just curious to know what stuff the SGX supports.