[x3d-public] RenderedTexture support

[Andreas Plesch]

Hi Michalis,

thanks. I am looking into the cubemap examples at
https://github.com/castle-engine/demo-models but could not locate
sofar a GeneratedCubeMapNode example.  (I also get an openssl
initialization error on win10 latest view3dscene and may file an
issue).

The way I understand x3dom uses rendered texture as a normal gl
texture is that it create an fbo with an attached, newly created
texture and keeps references to both, the fbo and the gl texture. Then
it renders into the fbo which populat the attached texture. Then it
uses directly the kept reference to the texture as gl texture for
shapes rendered to the screen.

For composed cube map texture, it creates a gl cube map texture and
populates the faces with gl.texImage2D() from normal memory (after
loading the images). texImage2D() does not allow for specifying
another texture as source for a cube map face. Since the rendered
texture is only available as a gl texture reference or as the fbo with
the attached gl texture, I first thought that it would be necessary to
transfer the gl texture to main memory by a slow readPIxels() call and
actually some format conversion. But then I found that CopyTexImage2D
let's you use the rendered texture fbo with the attached texture as a
source for a cube map face directly.

This probably does a copy operation but it seems GPU internal only and
is certainly fast. I may be missing something since it would be
preferable to just use a reference.

So this is option 2.

I did see a few copyTexSubImage2D() in the linked castle code but I
did dive deep enough to put all together,

gl.FramebufferTexture2D looks promising. I think what you are suggesting is:

1) create a fbo just for the cube map
2) bind the fbo
3) bind the cube map texture
4) use glFramebufferTexture2D to attach the rendered texture(s) to a face
5) unbind

Hm, that would be great since it would be probably mean no further per
frame operations necessary.

Thanks, I will try that,

-Andreas





On Tue, Jan 16, 2018 at 10:08 AM, Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>  2018-01-16 13:21 GMT+01:00 Andreas Plesch <andreasplesch at gmail.com>:
>> Hi Michalis,
>>
>> oh, apologies, I had somehow overlooked the cubemap component
>> documentation:
>> https://castle-engine.sourceforge.io/x3d_implementation_cubemaptexturing.php
>>
>> It looks like ComposedCubeMapTextureNode does not take RenderedTexture
>> as field values since RenderedTexture is not  derived from Class
>> TAbstractTexture2DNode ?
>
> It is also a consequence of our current implementation:
>
> - ComposedCubeMapTexture is loading texture contents from normal
> memory (RAM), always.
> - RenderedTexture contents "live" only on GPU, they are never copied
> to normal memory.
>
> To enable using RenderedTexture as a side for ComposedCubeMapTexture
> we would have to
>
> 1. grab RenderedTexture contents to normal memory (slow), only to
> later load it to ComposedCubeMapTexture.
> 2. or copy texture contents from RenderedTexture to
> ComposedCubeMapTexture side on the GPU (I'm not sure, but there's
> probably some function for this).
>
>> This is understandable since GeneratedCubeMapTexture is available.
>>
>> So I probably should try to implemenent GeneratedCubeMapTexture. All
>> the pieces should be already there.
>>
>> An advantage of using ComposedCubeMap with rendered textures is that
>> it is possible to only make a subset of the faces dynamic for
>> increased efficiency. After all, each face needs a render of the
>> scene.
>>
>> x3dom has a pingpong shader pass which may be helpful for recursive
>> mirror effects.
>>
>> x3dom also generates a fbo for each rendered texture and I learned how
>> to use it for the composed cubemap via gl.copyTexImage2D() which seems
>> to work well. Does castle use another opengl function ?
>
> We do not use glCopyTexImage2D. Instead, we're doing something more
> efficient (as far as I know): we just use the OpenGL(ES) texture as an
> attachment of FBO using glFramebufferTexture2D. In case of cubemap
> texture, you can specify which side is attached.
>
> This way, the rendered image goes straight to the (cubemap) texture,
> without the need to perform any copy, even on GPU.
>
> Regards,
> Michalis



-- 
Andreas Plesch
Waltham, MA 02453