I need to do a simple operation in my application, very common in certain techniques, but for some reason I can’t find how to do it in the Three Js framework.
The operation is basically render to a certain renderTarget, and the take the depthbuffer and stencil buffer bit data and blit them to another renterTarget for using them there.
As far as I understand, a renderTarget is kind of a wrapper for a FBO, with all the necesary functionlatities that comes with it. But in the documentation I can’t find any function related to this specific operation, something that really makes me wonder, because, as I said, It’s a very common operation.
I know that you can take the depth texture of a render target and reuse it in another render target as a texture, but I don’t want that, I want to do the standard blitFramebuffer operation using as mask, for example, the GL_DEPTH_BUFFER_BIT and GL_STENCIL_BUFFER_BIT.
So my question can be simplified as this:
How can I achieve blitFramebuffer operation in Three JS? There must be a way
So if what you are saying is true @dubois , I will need to directly handle webgl myself asking the renderer for the context, but that gives me another question. How can I get the renderTarget framebuffer IDs? Because I’ll need them for telling which is Draw and which is Read.
I think this is next to impossible to do with three.js, for this very reason - i don’t think you can obtain the frame buffer’s id from the depths of WebGLRenderer . When working with WebGLRenderTarget the renderer creates these buffers and never exposes them.
If you are wondering, there is no specific intent behind this design. It was just done this way and only a handful of people ever tried to do this.
Thank you for your time @dubois , I will take a good look to that thread and I’ll see If i can get something from it. I really think ThreeJs should have a desing that would let you access webgl objects IDs whenever you feel the need because then, they are just limiting the extense of the api utility.
Oh i agree 100%. Back in the day, most of the internals were accessible, and webgl resources would be slapped onto the wrappers. So for example there would be something like myTarget.__buffer. Now these are all stored in internal, encapsulated cache and cannot be accessed from outside.
Three is unfortunately not geared towards people that work with the low level APIs. I’m not that familiar with webGPU but i hope a more modern API may influence different design decisions for three.