RenderTarget | render to texture

[solan-solan]

• adxe version:
• devices test on:
• developing environments
  • NDK version: r19c
  • Xcode version: 12.4
  • VS/msvctools version: Visual Studio 2019(16.11)/14.29.30133
  • cmake version: Steps to Reproduce:

One question about RenderTexture. The cocos itself supports case when there is one FBO and multiple textures (color, depth, stencil) which can be attached to it. Engine controlled the process to change these textures before rendering. Now I see last commit [824e06d] which append 'sharedRenderTarget' variable, but what does it mean?

_director->getRenderer()->getOffscreenRenderTarget(); returns one object always. Who is responsible to set properly attachments?

[rh101]

The changes in that commit do not affect the compilation or behaviour of the code, so it should work as it does in Cocos2d-x. The default value of sharedRenderTarget is true.

I'm not sure what you mean by attaching multiple textures to it, so I can't comment about that.

[solan-solan]

I will try to explain my thought. Suppose, we have two RenderTexture objects, which share one _renderTarget variable, by the reason of this code _renderTarget = _director->getRenderer()->getOffscreenRenderTarget(); in RenderTexture::initWithWidthAndHeight function. In this case, it is needed to call

 _renderTarget->setColorAttachment(_texture2D);
 _renderTarget->setDepthAttachment(depthStencilTexture);
 _renderTarget->setStencilAttachment(depthStencilTexture);

somewhere in the engine, before rendering to RenderTexture. It is called right after _renderTarget creation now, but it cause to _renderTarget keeps final added textures only.

[rh101]

OK, now I understand what you mean by the attachments. Are you actually having a problem with the shared render target? If so, then you have two options:

Option 1 - Set the sharedRenderTarget parameter to false when creating the RenderTexture. This is what I had to do to fix my problem that appeared after the new render changes in https://github.com/adxeproject/adxe/commit/1889180a75322a3b7e611f93d56f6e622c6cb92c.

Option 2 - You can leave sharedRenderTarget as true, but just call Director::getInstance()->getRenderer()->render(); after the call to RenderTexture::end().

[solan-solan]

Thanks for suggestion, but to my understand

1. In my case, I need to have more then two RenderTexture. It could be up to 10 as example. It is related with post processing inpementation when you draw the scene to first texture and then render four quad sprite with this texture to other texture and so on. Besides there are some old phone devices (with gles 2.0) which support only one FBO.
2. Is your proposel is good to performance? Since it breaks 'two circle' render cycle, when you collects render commands at one pass and render these commands at the second pass, if I properly understand.

PS. As one of possible solutions which helps me now is to add above setAttachments to RenderTexture::onBegin() right after renderer->setRenderTarget(_renderTarget); Please consider this desision as well, since cocos can process render to texture with one render target itself

This is what I had to do to fix my problem that appeared after the new render changes in https://github.com/adxeproject/adxe/commit/1889180a75322a3b7e611f93d56f6e622c6cb92c

I have some more issues after final changes related to rendering and camera but it is not simple to explain them. It would be best to be a little careful with such changes =))

[rh101]

2. Is your proposel is good to performance? Since it breaks 'two circle' render cycle, when you collects render commands at one pass and render these commands at the second pass, if I properly understand.

My implementation doesn't stress the system enough to test performance. The way you use it would be a good test case if you have time to write one and test it.

Regarding issues with the renderer and camera, @halx99 would be the one to ask about that.

[solan-solan]

Regarding issues with the renderer and camera, @halx99 would be the one to ask about that.

There is rather one another aproach then a bug, if to say about camera, but I will ask @halx99 if something critical appear.

The way you use it would be a good test case if you have time to write one and test it.

Now I can submit that it helps to exchange textures for render target in my case, at least. If to say about my way to use, it applicable directly for 3d rendering and allows to add some affects like blur or dof. Effects like bloom are not so good since there is no support of hdr textures in the engine. I can think about example project if it is interesting.

One of similar implementations is shadow, like in https://github.com/solan-solan/HeightMap

[rh101]

@solan-solan Can this issue be marked resolved and closed, or is there still something that needs to be addressed for this specific issue?

[solan-solan]

@rh101 Yes, I think that it can be marked as resolved, since there are described some way's to bypass the issue in the thread