Thoughts about rendering 3d scenes

Started by
1 comment, last by Opwiz 18 years, 1 month ago
Hello I just wanted to share some new ideas on how to go about rendering 3d scenes. My approach has always been to, in each frame, determine the renderable objects that are visible and then let them draw themselves using a specified renderer. So in pseudo-code: foreach visible renderable object object.draw(renderer) end We also want to sort the render-operations in the draw() method so that they are performed in optimal order. The problem is that this sorting is done each frame and for objects that pretty much does the same render-operations each frame this is not very efficient. So I was thinking about some kind of event-based approach. Renderables are informed whenever they are visible or not visible and can register/unregister render-operations in a sorted queue. The objects may also update the render-operations when it changes state. This render-operations in the queue are executed each frame. So what do you think? Is this practical and possible to implement? Regards Opwiz

www.marklightforunity.com | MarkLight: Markup Extension Framework for Unity

Advertisement
If you prefere that method then yes it is both practical and possible, although Im going to suggest a slightly different approach.
Each frame determine visible renderable objects (like you do at the moment) then rather than call .draw on each object you call .get_render_op() and insert the returned render-operation into a render-queue. The queue will then sort the operations for efficiency (state-changes, etc), then the renderer will iterator over the queue and render each operation.

Pseudo-code:
//Request each render-op and add to the queuefor_each visible renderable object    render_queue.add( object.get_render_op() );next//Sort the render-queuerender_queue.sort();//Render the queue with the desired rendererrenderer.apply( render_queue );


This solution, I believe, lies part way between your current and suggested systems.

Edit:
Sorry to explain how this would be better:
The implementation of the render_queue can be abstracted away via polymorphism or templates.
A simple implementation would clear the queue each frame and be ready to accept a whole new set of render ops.
A more complex implementation might retain the previous list of render ops (all still sorted of course), when the new bundle of render ops are added the implementation can make a best-guess at where to place it within the queue based on where they were placed on the previous frame, only new render-ops that were not added on the previous frame need to be sorted.

The point is that this is more flexible, you could design even more complex or even simpler implementations that are hidden away without affecting the rest of your rendering code.

Hope that made sense. Any questions just ask.

[Edited by - dmatter on March 16, 2006 11:30:03 AM]
Quote:Original post by dmatter
Hope that made sense. Any questions just ask.

It makes sense. Thank you.

www.marklightforunity.com | MarkLight: Markup Extension Framework for Unity

This topic is closed to new replies.

Advertisement