Singleton Discussion

[:wumpus:]

A renderer is something that renders. OpenGL or Direct3D are implementation details, they don't matter.

A renderer object, as I impy, abstracts the rendering system; it would be a subclass of a generic renderer that abstracts OpenGL or Direct3D, and interfaces with one of those.

Take my in-game computer example once more. Say the main game is running a deferredRenderer, which takes up lots of resources. You can give the in-game computer a forwardRenderer, instead.

That's a completely different renderer; what you call renderer I would call 'scene'. And indeed, you want to have multiple scenes, so you can switch between them (or show different ones in different viewports).

Besides, why have a global renderer? What, are your physics going to talk to your renderer? Or maybe your AI? Or maybe your input and logic? No. Only the graphics should have access to a renderer.

In many cases, the separation isn't that clear-cut as that. All I was trying to say is that I don't think global objects or singletons are necessarily a wrong design choice, depending on how much work it is to avoid them (isn't it always about that?).

[nullsquared]

That's a completely different renderer; what you call renderer I would call 'scene'. And indeed, you want to have multiple scenes, so you can switch between them (or show different ones in different viewports).

No, the renderer does not take care of the scene. It simply uses the scene (for example, each renderer takes a pointer to the Ogre::Viewport it's rendering to and the Ogre::SceneManager it's going to use). A scene is a scene, regardless of whether it is rendered via forward or deferred shading.

In many cases, the separation isn't that clear-cut as that. All I was trying to say is that I don't think global objects or singletons are necessarily a wrong design choice, depending on how much work it is to avoid them (isn't it always about that?).

It's really not all that much work to avoid singletons/globals given a flexible design - and the end result remains just as flexible.

[JohnJ]

No, the renderer does not take care of the scene. It simply uses the scene (for example, each renderer takes a pointer to the Ogre::Viewport it's rendering to and the Ogre::SceneManager it's going to use). A scene is a scene, regardless of whether it is rendered via forward or deferred shading.

That's an interesting design, but if I understand it correctly, a bad one. It sounds like this will cause a lot of duplicated data and management code between multiple renderers. In a good design you won't need to have multiple "renderers" to have a fully flexible deferred and forward rendering system. Better would be the concept of a "renderer" simplified to a singular component of your game, to which you add render targets / viewports, which can be individually designated to enable or disable deferred rendering, and to render any view from any scene.

It's really not all that much work to avoid singletons/globals given a flexible design - and the end result remains just as flexible.

From the point of view of someone who knows how to use singletons properly, your code can be seen as making design compromises like this to avoid the extra hard work that would be required to implement it as well designed and efficient as can be accomplished easily (and cleanly) with a singleton/global.

[nullsquared]

No, the renderer does not take care of the scene. It simply uses the scene (for example, each renderer takes a pointer to the Ogre::Viewport it's rendering to and the Ogre::SceneManager it's going to use). A scene is a scene, regardless of whether it is rendered via forward or deferred shading.

That's an interesting design, but if I understand it correctly, a bad one. It sounds like this will cause a lot of duplicated data and management code between multiple renderers.

Mind elaborating? Because it doesn't duplicate data or management at all.

Better would be the concept of a "renderer" simplified to a singular component of your game, to which you add render targets / viewports, which can be individually designated to enable or disable deferred rendering, and to render any view from any scene.

Consider that was the case - then what exactly controls this forward/deferred rendering? As you may know, it is not quite a 1-liner switch

[JohnJ]

Consider that was the case - then what exactly controls this forward/deferred rendering? As you may know, it is not quite a 1-liner switch

It's easy, at least if you design it properly. The viewport or render target if you like simply contains a RenderTechnique enum which can be set (and changed during runtime if desired). It's then a very simple matter to implement the renderer cleanly to render the scenes to the viewports using the specified methods.

For example (pseudocode, but would work):

Code: Select all

RenderTarget *target = new RenderTarget();
target->setRenderTechnique(RT_DEFERRED); //1-liner switch
target->setScene(myScene);

Camera *cam = new Camera()

Viewport *vp = new Viewport(target);
vp->setRegion(0, 0, 1, 1);
vp->setCamera(cam);
...

Mind elaborating? Because it doesn't duplicate data or management at all.

Here's just one example: If you have a forwardrenderer and a deferredrenderer, do you sort transparent and/or opaque objects (back-to-front and front-to-back respectively of course) in both implementations? If so, you're duplicating code. Bad. If not, you're lacking an important optimization/feature. Bad. Or, if you sort your objects outside of the renderer and inject lists, you're doing a renderer-specific action externally. Bad.

[nullsquared]

Consider that was the case - then what exactly controls this forward/deferred rendering? As you may know, it is not quite a 1-liner switch

It's easy, at least if you design it properly. The viewport or render target if you like simply contains a RenderTechnique enum which can be set (and changed during runtime if desired). It's then a very simple matter to implement the renderer cleanly to render the scenes to the viewports using the specified methods.

For example (pseudocode, but would work):

Code: Select all

RenderTarget *target = new RenderTarget();
target->setRenderTechnique(RT_DEFERRED); //1-liner switch
target->setScene(myScene);

Camera *cam = new Camera()

Viewport *vp = new Viewport(target);
vp->setRegion(0, 0, 1, 1);
vp->setCamera(cam);
...

By your foolish example, here:

Code: Select all

//_renderer.reset(new forwardRenderer(_viewport, _sceneMgr));
_renderer.reset(new deferredRenderer(_viewport, _sceneMgr)); // 1-liner switch

I have a feeling you haven't quite written a deferred renderer before, because it's not something you can slap together into a switch () {} block.

Mind elaborating? Because it doesn't duplicate data or management at all.

Here's just one example: If you have a forwardrenderer and a deferredrenderer, do you sort transparent and/or opaque objects (back-to-front and front-to-back respectively of course) in both implementations? If so, you're duplicating code. Bad. If not, you're lacking an important optimization/feature. Bad. Or, if you sort your objects outside of the renderer and inject lists, you're doing a renderer-specific action externally. Bad.

Yup, those are all bad. And I do none of them.

forwardRenderer renders the scene normally with basic "on-the-spot" shaders.

deferredRenderer does all the deferred shading stuff, then renders the transparent parts of the scene normally with basic "on-the-spot" shaders (as does any other deferred renderer).

No duplicated code, no missing feature, and no external renderer-specific action.

Keep in mind this is all built on top of Ogre - it's at a very high level, so stuff like this can easily be done flexibly and cleanly.

Oh, and if it wasn't built on top of Ogre: you're missing the 4th option: put common functionality in the base class

[JohnJ]

I have a feeling you haven't quite written a deferred renderer before, because it's not something you can slap together into a switch () {} block.

Not in your engine, that's for sure. You clearly haven't the slightest clue how my engine achieves the example code I posted, so you accuse me of not knowing what I'm talking about. Great.

Maybe it's too far away from the type of design you're used to, but trust me: it works, the code is very elegant, and it can truly switch views from deferred to forward rendering between frames with no performance hit if you choose to do so.

No duplicated code, no missing feature, and no external renderer-specific action.

Well that's good, but again, I suspect you're sacrificing what could be a better design for the sake of eliminating singletons. Of course, you could have a equally elegant design without singletons, but it's likely that it will require much more work than you're current system.

Oh, and if it wasn't built on top of Ogre: you're missing the 4th option: put common functionality in the base class

Aka a badly designed "god-class" externally implementing renderer-specific concepts. Not me.

[nullsquared]

I have a feeling you haven't quite written a deferred renderer before, because it's not something you can slap together into a switch () {} block.

Not in your engine, that's for sure. You clearly haven't the slightest clue how my engine achieves the example code I posted, so you accuse me of not knowing what I'm talking about. Great.

Maybe it's too far away from the type of design you're used to, but trust me: it works, the code is very elegant, and it can truly switch views from deferred to forward rendering between frames with no performance hit if you choose to do so.

Oh, yes? May I, perhaps, have a screenshot or something? No performance hit? Unless you have the gbuffer and other post-processing textures constantly set up (wasting memory when not using deferred shading), there is no way what you're saying is true. Trust me, I sort of know what I'm talking about:

A full deferred renderer with efficient light shading and proper transparency, etc. cannot be elegantly implemented as a single class that "switches" between forward and deferred rendering seamlessly.

No duplicated code, no missing feature, and no external renderer-specific action.

Well that's good, but again, I suspect you're sacrificing what could be a better design for the sake of eliminating singletons. Of course, you could have a equally elegant design without singletons, but it's likely that it will require much more work than you're current system.

Wait, what? If I need a renderer, I make a renderer. I fail to see how this situation warrants a singleton, and you're clearly arguing for the sake of arguing.

Oh, and if it wasn't built on top of Ogre: you're missing the 4th option: put common functionality in the base class

Aka a badly designed "god-class" externally implementing renderer-specific concepts. Not me.

What? Transparency sorting is back-to-front regardless of renderer type - therefore, common functionality that goes in a base class. It's not a "badly designed god-class", it's "basic usage of C++ OOP principles".

[JohnJ]

What? Transparency sorting is back-to-front regardless of renderer type - therefore, common functionality that goes in a base class. It's not a "badly designed god-class", it's "basic usage of C++ OOP principles".

Not really. In most cases, yes, but there may be special cases where it would take too much CPU to sort everything using the same system, depending on the content, and structure. In this case it would be extremely inefficient to limit yourself in this way. There's a lot more that goes on than just sorting though in a full featured game or simulation system.

Oh, yes? May I, perhaps, have a screenshot or something? No performance hit? Unless you have the gbuffer and other post-processing textures constantly set up (wasting memory when not using deferred shading), there is no way what you're saying is true. Trust me, I sort of know what I'm talking about:

Yes, you do sort of know what you're talking about, but apparently not enough to understand how the example code I posted can work cleanly and efficiently (including memory footprint). But like I said earlier it's all to easy for someone your age (trust me, I've been there) to make the mistake you're making now, and thinking that your relatively limited experience enables you to tell me that my engine cannot be doing what it is already capable of now. I'm not about to go doing the same either, because I recognize that my own experience is limited, and there's always something new to learn, if you keep an open mind.

Edit: BTW, you might want to tone down the HDR and add a little more global illumination to that screenshot, unless you're going for the unreal look (which you may very well be for all I know).

A full deferred renderer with efficient light shading and proper transparency, etc. cannot be elegantly implemented as a single class that "switches" between forward and deferred rendering seamlessly.

Judging by your posts, I'd say you're thinking about this in totally the wrong way. Yes, it can be elegantly implemented in a single class, and yes, it can transition flawlessly between forward and deferred rendering without a hiccup. Oh, and also with full-screen motion blur, subsurface scattering, high quality SSAO, etc. All this I've done in about 4 weekends as a prototype for my hobby engine project on my laptop, so it's really not that hard. I might give you a screenshot, but then that wouldn't really prove anything (and besides, the art is still work-in-progress).

Compared to what I'm doing at work, this is all relatively simple programming - if you're still doubting that I "know what I'm talking about". Honestly, I can't reveal any of it or what I'm doing, I can just hint by observing the fact that the company I work for develops technology that ends up being used by the US and Canadian military, and it's pretty interesting stuff

But this is getting off topic. If you want to continue trying to prove that what I've done is impossible, go right ahead . You're not going to get anywhere though, because it's all true.

[nullsquared]

What? Transparency sorting is back-to-front regardless of renderer type - therefore, common functionality that goes in a base class. It's not a "badly designed god-class", it's "basic usage of C++ OOP principles".

Not really. In most cases, yes, but there may be special cases where it would take too much CPU to sort everything using the same system, depending on the content, and structure. In this case it would be extremely inefficient to limit yourself in this way. There's a lot more that goes on than just sorting though in a full featured game or simulation system.

Elaborate. How, exactly would you need to sort the transparent objects differently? Stop arguing for the sake of arguing.

Oh, yes? May I, perhaps, have a screenshot or something? No performance hit? Unless you have the gbuffer and other post-processing textures constantly set up (wasting memory when not using deferred shading), there is no way what you're saying is true. Trust me, I sort of know what I'm talking about:

Yes, you do sort of know what you're talking about, but apparently not enough to understand how the example code I posted can work cleanly and efficiently (including memory footprint). But like I said earlier it's all to easy for someone your age (trust me, I've been there) to make the mistake you're making now, and thinking that your relatively limited experience enables you to tell me that my engine cannot be doing what it is already capable of now. I'm not about to go doing the same either, because I recognize that my own experience is limited, and there's always something new to learn, if you keep an open mind.

I expected that reply. "Oh, I also know what I'm talking about, you should have a more open mind. It must be your age."

Edit: BTW, you might want to tone down the HDR and add a little more global illumination to that screenshot, unless you're going for the unreal look (which you may very well be for all I know).

There is no HDR. And there is no global illumination. I like to see your flexible real-time global illumination.

A full deferred renderer with efficient light shading and proper transparency, etc. cannot be elegantly implemented as a single class that "switches" between forward and deferred rendering seamlessly.

Judging by your posts, I'd say you're thinking about this in totally the wrong way. Yes, it can be elegantly implemented in a single class, and yes, it can transition flawlessly between forward and deferred rendering without a hiccup. Oh, and also with full-screen motion blur, subsurface scattering, high quality SSAO, etc. All this I've done in about 4 weekends as a prototype for my hobby engine project on my laptop, so it's really not that hard. I might give you a screenshot, but then that wouldn't really prove anything (and besides, the art is still work-in-progress).

Like I said, either prove it, or stop flaunting your amazing non-straight-forward, singleton-proud design.

[JohnJ]

I expected that reply. "Oh, I also know what I'm talking about, you should have a more open mind. It must be your age."

Do I have to point out again that I'm really not so much older than you than you might think?

There is no HDR. And there is no global illumination. I like to see your flexible real-time global illumination.

Ah, I see, so it's just simple oversaturation. And by global illumination, I meant simply what the phrase sounds like, not photon simulation (though you can achieve something close with a good SSAO effect). I guess I shouldn't have used the phrase global illumination in this case.

Like I said, either prove it, or stop flaunting your amazing non-straight-forward, singleton-proud design.

I'm not flaunting it, in fact, far from it; you asked for examples several times earlier, and I said I didn't want to because I thought we could discuss it in theory and it would take too much of my time to give you examples. So now that I'm wasting more of my time giving you examples and replying to your questions, you're complaining because now I am giving you code examples, and apparently they seem too good to be true? This is ridiculous.

Explaining my implementation would take even more time for me to explain how it works, and honestly even if I did want to, I don't think I want to spend that time explaining it to you, because I have a feeling it would be a wasted effort. You'll learn eventually I'm sure, but for now you'll just have to trust me.

And if I am to treat you as an adult, then your "prove it or else" statement would be implying that you are accusing me of lying, to put it bluntly. If so, then that's insulting, and all I could say to that is ask anyone here who knows my work what they think about that. If not, then again I would suggest you be a little more careful when choosing your words.

[nullsquared]

There is no HDR. And there is no global illumination. I like to see your flexible real-time global illumination.

Ah, I see, so it's just simple oversaturation.

No, it's actually an extension to SSAO that colour-bleeds.

And by global illumination, I meant simply what the phrase sounds like, not photon simulation (though you can achieve something close with a good SSAO effect). I guess I shouldn't have used the phrase global illumination in this case.

SSAO is too local to achieve global illumination on the scale of my screenshot. Otherwise, yes, you can achieve something close with a good SSAO effect:

/* three paragraphs of flaunting and absolutely nothing technical */

Forget it.

[xavier]

This discussion has long since passed the useful point.