Changes in Render To Texture interface

Discuss about anything related to the Irrlicht Engine, or read announcements about any significant features or usage changes.
Post Reply
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Changes in Render To Texture interface

Post by 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.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
hendu
Posts: 2600
Joined: Sat Dec 18, 2010 12:53 pm

Re: Changes in Render To Texture interface

Post by 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
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: Changes in Render To Texture interface

Post by 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.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: Changes in Render To Texture interface

Post by Nadro »

This feature will be available in trunk in upcoming days.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
christianclavet
Posts: 1638
Joined: Mon Apr 30, 2007 3:24 am
Location: Montreal, CANADA
Contact:

Re: Changes in Render To Texture interface

Post by christianclavet »

Thanks Nadro!
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: Changes in Render To Texture interface

Post by 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.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
devsh
Competition winner
Posts: 2057
Joined: Tue Dec 09, 2008 6:00 pm
Location: UK
Contact:

Re: Changes in Render To Texture interface

Post by devsh »

can you elaborate on causes of this performance drop and how to avoid it?
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: Changes in Render To Texture interface

Post by 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.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
Nadro
Posts: 1648
Joined: Sun Feb 19, 2006 9:08 am
Location: Warsaw, Poland

Re: Changes in Render To Texture interface

Post by 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.
Library helping with network requests, tasks management, logger etc in desktop and mobile apps: https://github.com/GrupaPracuj/hermes
Post Reply