   designing a rendering system
  I'd like your opinions on a rendering system I'm thinking about implementing(C++).I'm thinking I'll have each rendered object inherit from an IRenderable interface, providing a few methods such as render(), and getRenderingInformation(), the latter would return some standard RenderingProperties struct that would contain information such as a pointer to the vertex and index lists, type of primitives, transparency and other material information.each object in a scene would be tested for culling, etc..., then be submitted to a renderer class that would control shaders, render states, vertex and index buffers, etc..., and do the actual rendering.The renderer would have an add(const IRenderable &object) method that adds the object to a priority queue (based on transparency and whatnot).This way I can decouple my game's objects from Direct3D/openGL, and be able to swap renderers if I so chose.Are there any disadvantages to this situation?  Feel free to criticize/suggest alternate approaches.Thanks.
  That approach does not scale so well to multi-core systems, and involves a lot of virtual function calls. Do some research on a command buffer approach. Essentially you submit rendering jobs (e.g. "render mesh" including shader params, materials, etc) to a command queue. This queue can then be sorted and grouped by material etc to optimize the draw calls. One advantage of this approach is that multiple processes can submit to the queue at the same time.I guess culling could be done at the submit job stage - each subsystem decides whether to draw or not based on frustum information passed in. Thus avoiding the virtual function call.If you're exclusively PC based then (unless you use DX11 I think) you won't have hardware support for a GPU command buffer, but it's still a good way of organizing the code.*Disclaimer - I've not implemented this approach myself - feel free to ignore!*;  Command buffer system as in this?;  Just wanted to post a link to another thread I've started as I was having the same problems as above.. I posted a possible solution with some questions as to possible pitfalls to that solution here.edit: Sorry for linking to another thread by the way.. I did link to your thread as well in the other that I started.   ;Quote:Original post by godsenddeathThis way I can decouple my game's objects from Direct3D/openGL, and be able to swap renderers if I so chose.Are there any disadvantages to this situation?  Feel free to criticize/suggest alternate approaches.There's no need to use dynamic dispatch (virtual functions) to achieve this goal, especially when it's not likely to change while the game is running.Instead, I'd select the renderer at compile time (and supply two EXEs/DLLs if you want to support 2 renderers on the one OS for some reason)://Renderer/Model.h#if defined(USE_GL_RENDERER)#include "Renderer/GL/Model.h"#elif defined(USE_DX_RENDERER)#include "Renderer/DX/Model.h"#else#error "No renderer selected"#endifQuote:I'm thinking I'll have each rendered object inherit from an IRenderable interface, providing a few methods such as render(), and getRenderingInformation(), the latter would return some standard RenderingProperties struct that would contain information such as a pointer to the vertex and index lists, type of primitives, transparency and other material information.There isn't much of a need to make this an abstract-base-class in my experience.I'd just use concrete classes:- Mesh Resource - contians your verts/indices.- Texture Resource.- Shader Resource.- Material Resource - links shaders, textures, blend modes, uniform data, etc- Renderable - links a mesh resource with a material resource and some extra uniform data (such as the model-to-world matrix).You add function can then just take concrete Renderables instead of polymorphic IRenderables.   ;  I would put the Render() method on the renderer, not the renderable. It doesn't really make sense to render one object all by itself; you draw them all at once, right? And that way, Render() can take care of all the occlusion testing and stuff.   ;Quote:Original post by godsenddeathCommand buffer system as in this?Yes pretty much - although there's probably not so much need to go down the DX recorder for your commands - at least at first. If you want to keep it largely platform independent then just create your own command structure. The biggest win will come from avoiding the need to branch or do any complex processing on the thread that is issuing the render commands.As Hodgman said though if you can avoid using virtuals then you'll get a win anyway. Instead of running through a list of arbitrary objects, deciding instantaneously which bit of code to jump to (a virtual function call) and blowing the instruction cache probably along with the data cache, you are iterating over a bunch of the same object (hint: instructions to operate on that object are probably in the cache) and if the objects are contiguous then you also stand a chance of the data being in the cache as well.   