Organizing rendering code

そら · 2015-07-28T22:21:06

I'm writing a small engine, mainly for educational purposes. Where I want it to be able to use differente APIs (OpenGL, DirectX, etc). So In my intend to separate API specific code from the engine's logic I thought on using pImpl Idiom, something like this: template<class T> class RenderManager { public: // pImpl-> Create & Release resources // pImpl-> Draw scene objects private: T pImpl; // DirectX/OpenGL specific class }; Everything was ok with that approach, until I needed to add rendering code to the RenderManager which is not API specific (like adding passes for Shadows, AlphaBlend, etc). Adding that code to my pImpl class doesn't seem right template<class T> class RenderManager { public: // pImpl-> Create & Release resources void Update( ) { myObjects = // retrive objects for shadow pass pImpl->Pass( myObjects ); myObjects = // retrive objects for diffuse pass pImpl->Pass( myObjects ); myObjects = // retrive objects for alpha blend pass pImpl->Pass( myObjects ); } private: T pImpl; // DirectX/OpenGL specific class }; So I could use an abstract class from which API specific code inherits: class RenderManagerBase { virtual void Pass( objectList ) = 0; virtual void // Create & Release resources = 0; void Update( ) { myObjects = // retrive objects for shadow pass Pass( myObjects ); myObjects = // retrive objects for diffuse pass Pass( myObjects ); myObjects = // retrive objects for alpha blend pass Pass( myObjects ); } }; class RenderManager_dx11 : public RenderManagerBase { }; class RenderManager_ogl : public RenderManagerBase { }; But using virtual functions in rendering code could bring performance issues to something very time-critical such as the rendering. So I thought about using some kind of reverse inheritance (the general class inheriting from the API specific class): class RenderManager_dx11 { }; class RenderManager_ogl { }; template<class T> class RenderManagerBase : public T { void Update( ) { myObjects = // retrive objects for shadow pass Pass( myObjects ); myObjects = // retrive objects for diffuse pass Pass( myObjects ); myObjects = // retrive objects for alpha blend pass Pass( myObjects ); } }; Not very "standard" way of doing it, but since I know there will only be two classes (one inherited from the other), this way the calls to the API specific methods wouldn't have the performance problems of using virtual functions. So.... I'd like to know your oppinion... how do you happen to handle your rendering code to make it API agnostic and writing rendering code not API-specific? Thanks PD.- Also... If I have a pure virtual function, which gets implemented in its only derived class, I'm guessing it probably wouldn't have such a performance impact since there won't be more than one function to look up to... (but still would have better performance calling the function directly)

Graphics and GPU Programming Programming OpenGL

Started by そら July 25, 2015 11:52 PM

10 comments, last by slicer4ever 8 years, 8 months ago

TheChubu

9,484

July 28, 2015 10:11 PM

Still, worrying about the overhead of calling "renderer.update()" is kinda silly. I mean, how many calls of those are you even going to issue per frame? One? A dozen at most? I don't think you could even measure that kind of overhead properly.

In any case, making "pass(objects)" a method of the render manager sounds like a bad idea to me. You'll end up with a bunch of specialized methods like OGLManager->ShadowPass(objects), D3DManager->ShadowPass(objects), OGLManager->GeometryPass(objects) and so on.

IMO the pass itself should be an object, not a method. You got your render manager, it has a list of passes to run. So it iterates over each pass, executing the "render" method of each of them Pass knows what state to setup, what shaders to run, and the way you can handle the "object" list to draw can vary (make it part of the pass object, make it external managed by the render manager, etc).

Maybe that way the render manager doesn't even needs to be API specific, just the pass objects themselves.

Thats the bucketing way of drawing things. You essentially got buckets of objects that go into particular passes for drawing. Another popular way of drawing is using keys to sort and draw, each key has the state it needs to be executed packed in it. And there are probably combinations of both principles (bucketing and render-key based sorting).

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

slicer4ever

6,773

July 28, 2015 10:21 PM

So I could use an abstract class from which API specific code inherits:
But using virtual functions in rendering code could bring performance issues to something very time-critical such as the rendering.

Honestly, i think your severely overestimating the performance impact a virtual call has. yes it's a bit of indirect with looking at vtables, but I'm extremely doubtful this is going to ever be your bottleneck.
yet again it comes back to a case of pre-mature optimzations, demonstrate it is an actual issue before looking for complex patterns that results in overcomplicating your design because you think that it might be an issue.

Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

Organizing rendering code

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Organizing rendering code

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines