Ray Tracer implementation

[edapx]

Hello, I'm following the graphic codex tutorials http://graphicscodex.com/projects/rays/index.html and I'm now at the point where I've to build a ray tracer in OF, precisely:
“Backward” ray tracing algorithms iterate over the light rays that entered a camera and trace them back along the negative direction of propagation to discover the surfaces, and eventually light sources, that gave rise to them.

I need a gui, with a button that trigs a "render", and this render will take some minute or seconds, depending on the resolution, to render the Cornell Box.

My question is, once that I've set up (in the setup method) the scene with the model (a loaded .obj file with the Cornell Box), I've defined the camera position and the light position, and I've initialized the GUI, where should i draw the rendered image? I assume not in the draw method, as what I need to draw is an image that progressively gets updated.
The same thing for the ray tracing loop, it should not go into the update method, right?

So, I think everything should go in the setup method, that restart from the beginning when i click on the "render" button in the GUI.

Is this correct? do someone have some suggestion about the skeleton of my application?

[Jordi]

The way I would do it is: get your GUI trigger to start an of Thread, then do the render calls (your raytracing loop) inside the ofThread which will render your image to an FBO. This way your renderer is decoupled from the ofLoop so it does not matter how long it takes to render, you will see the progress when drawing the fbo from your draw() method.
Maybe other people has better ideas?

[edapx]

Actually, the final implementation should be multithread. can an ofThread have child threads? in this case I could do as you say.

But, to be honest, I would try to keep it as simple as possible at the beginning, and I would like to introduce threads later, when the minimal implementation works.

[roymacdonald]

Hi, did you solve this?
unfortunately you cannot use an FBO within a thread different to the main thread. it is an openGL limitation, I think.
take a look at this example https://github.com/openframeworks/openFrameworks/tree/master/examples/threads/threadExample
It is quite much what you need.
in order to distribute the work load along all possible running threads, which depends on the number of cores your computer has, run several threadedObjects, but modify it so you can specify which area of the total pixels it is that the thread should handle.
this might be useful also

bakercp/ofxTaskQueue

cheers

[edapx]

Hello @roymacdonald , no, unfortunately I did not solve it. Also, I would like to focus on the ray tracer first, without using ofThread.
What I've now is:
a CornellBox scene loaded through ofAssimp,
a camera position
a light position.
a point in the virtual image plane (a point between the camera and the object, in which the rays pass through )

I want to trace the ray that from the camera goes to the object, passing through the point on the virtual plane.

Image from http://graphicscodex.com/, by Morgan McGuire.

What I think I will do is:
1)In the setup method, I set a GUI, a scene and an empty png image
2)In the setup method, I start the ray casting. I still have to dig into the algorithm but I thing it belongs here and should not go in the update method
3)Whenever I found a point on the surface of the object that intersect with one of the ray, I calculate the light and the final color of the pixels, and then I save it into the png image
4)The draw method (that is called 60 times per second) just display the actual status of png, that is still being updated by the ray tracing loop launched in the setup method.

Do you think it make sense?
When I get this working I will start to see how can I improve the speed adding ofThread, but for now I leave it out.

[roymacdonald]

I see. I thought that you had the raytracer solved. There is ofxRay which kinda makes what you intend to do. At least it will let you setup the camera that "shoots" rays. The approach you mention should work but it will not have lights just the color of the objects. To add lights, you'll need to bounce the rays from the object, depending on the surface properties the light will get scattered in a certain amount, generating more rays. Then you check if any of these rays arrive on a light. Then from this you compute the final color of the pixel in the png.
I'm not sure if this is the standard approach, I'm just guessing.
Also, it might me more efective to run a kind of low res render first and then based on that one make a higher res one, taking into account what is in the low res in order to discard unused rays.

hope this helps.

best