Hi everyone,
Please have a look at here: https://playground.babylonjs.com/#1ASENS#362
I left in a couple of commented lines. Idk what is going on there.
Codewise getTarget() returns a PrePassRenderTarget which is just a slightly modified MultiRenderTarget. The .textures array of the MultiRenderTarget holds a bunch of Textures.
If there is a Texture and I get back from .readPixels something that looks like an array of colors, then I think this should be usable as a texture.
Also, I initially thought this has something to do with ParticleSystems. We could not find a solution so that there might actually be a bug.
Best wishes
Joe
1 Like
@Joe_Kerr, what are you trying to achieve ? this might be simpler than using the pre pass depending on your needs.
For instance getting DepthTexture for SoftParticles or PositionTexture (or Normals) into GPUPicking.
There is indeed the DepthRenderer or the GBuffer. But assume the PrePassRenderer is already active in the scene from DeferredLIghting. Adding the DepthRenderer on top costs 1 extra draw call while the GBuffer doubles all draw calls.
This part might change a lot pretty soon-ish as @Evgeni_Popov has some great plan for it. I would suggest to potentially not using it fully now. That said if it works for your defered work, it should be fully ok here.
1 Like
Ok, I see.
Also pinging @Heaust-ops FYI
2 Likes
Your problem is that you can’t read and write to the same texture. When you set the depth texture as the diffuse texture of the material, during the render pass, this texture is used both in read mode (as the diffuse texture) and in write mode (written by the prepass renderer):
1 Like
Thanks for the explanation @Evgeni_Popov!
Just to shed some light on it: Setting the PrePassRenderer’s depth texture as diffuse texture was to simulate the issue when I wanted to get its depth texture into a particle system shader.
You should be able to use the depth texture with a particle system shader, because the latter does not use the prepass renderer and so does not write to the prepass renderer textures.
2 Likes
Oh! If you could have one last look at this playground, this would be awesome: https://playground.babylonjs.com/#1ASENS#365 The inspector shows a plausible depth texture so the setup should be alright, I thought. The conditionals do not trigger errors. I do not see what is wrong.
Oh wait second, there is a console warning now:
WebGL warning: drawArraysInstanced: Texture level 0 would be read by TEXTURE_2D unit 0, but written by framebuffer attachment COLOR_ATTACHMENT1, which would be illegal feedback.
Is this what you described above? So I tried this: https://playground.babylonjs.com/#1ASENS#366
It uses the DepthRenderer depth texture for the particle shader but also has the PrePassRenderer tagging along. In the Inspector there is a texture “prePass_Color” which shows the particles! Is this a bug?
I was wrong, because even if the particle system shader does not write to the depth texture, the latter is still bound to the framebuffer by the prepass renderer, which is enough to trigger the error…
I think you should either only use the depth renderer if you only need the depth texture, or the geometry buffer renderer if you also have to generate other textures (normal, position, etc), but not use the prepass renderer.
Awww, there goes all my hope 
Thanks for your patience and looking into it @Evgeni_Popov.
I am swicthing the “Solved” state - hope you do not mind @sebavan.
1 Like