Changes in Render To Texture interface

[Nadro]

I want to extend our Render To Texture interfaces and I would ask what you think about this idea. Short description of this proposal:
1. We'll add new E_COLOR_FORMAT for depth and stencil, so it'll be possible to create depth, stencil and packed depth-stencil textures manually and next reuse them eg. in shaders.
2. IVideoDriver::setRenderTarget method will be modified:
a) two new params will be available: ITexture* depth, ITexture* stencil, so if you use packed depth-stencil you need to apply the same ITexture object for both params.
b) one new param will be available: ITexture* depthStencil, so if you want to use stencil you need to use packed depth-stencil (as I know in D3D11 it's the only possible solution, OGL is more flexible).
Built-in system for auto create shared depth textures will be removed, so user must manually create and apply depth texture for RT (example no. 13 will be modified of course).

These changes will break API, but it will finally solve problems with depth and stencil textures. What do you think about this idea? Maybe do you have a better idea in this case? These changes will be part of v1.9.

[hendu]

As you know I've been using a simpler approach (a bool "useStencil"), but the extended way you propose is ok. I don't really see why anyone would want to create a non-packed DS texture, given almost everything supports it.

You could avoid breaking the API by creating auto-shared textures as before, but only using them when the 2b) param is NULL. Making it default to NULL will preserve the API. The wasted memory is rather small.

[Nadro]

I prefer solution with ITexture* param, because it'll allow users to use depth/stencil texture inside shaders.

I agree that one param for depthStencil and auto create depth for cases when param is NULL is the best solution. If nobody has better solution I'll implement it in that way. In this way we'll not break API.

[Nadro]

This feature will be available in trunk in upcoming days.

[christianclavet]

Thanks Nadro!

[Nadro]

In near future we should add interfaces for handle FBO manually and clean-up current RTT stuff, because automatic system where one texture = one fbo is really bad. It cause a performance drop.

[devsh]

can you elaborate on causes of this performance drop and how to avoid it?

[Nadro]

It's related mostly to MRTs, where we attach textures (glFramebufferTexture2D) during rendering phase instead of setup phase, so at rendering phase we both bind FBO and attach textures. It's really bad solution. Interface should be more flexible, so user will be allow to:
- choose 1 FBO per (multiple) render target(s).
- use 1 global FBO and attach different textures to them (iirc D3D9 works in similar way).
- use different attachment slots for different textures like in MRTs, but render just to one textures thanks to different params in glDrawBuffer function (the fastest solution).

To achieve this effect we should prepare new RenderTarget class. These changes will break API, anyway current RTT API is really bad, because RenderTarget isn't a Texture like it looks in Irrlicht at now.

[Nadro]

In the latest commit I added support for the new color formats related to depth/stencil. At now only OpenGL driver supports new features.