Hi there,
I’m attempting to implement a multipass splat system in order to handle deferred reflection shading in a gsplat. So far I’ve managed to get it that the splat instance is rendering into a separate buffer with the correct rastertizations required by the algorithm by modifying the main splat fragment shader to output to the buffers. When doing this however, it seems each splat’s orientation or something like this is going off. I’m not entirely sure what could be happening but vs the main camera they are looking fuzzy. I’ve attached an example that shows the output of the main camera behind the multipass textures.
I’m implementing the multibuffer logic very similarly to this PlayCanvas Examples and only modifying the splat main shader code to output to the buffers, everything else is the same as the default splat shader used in playcanvas engine. Also, the multi render pass camera is rendering correctly when rendering to the main viewport. I’ve also setup the render textures to match the size as the viewport so would imagine it should all just match.
Any help or guidance in fixing would be greatly appreciated!
Thanks!
Here is a video which shows the issue more clearly
We only orient splats for a single camera per frame. And so if your camera looks at splat scene from a different direction, only the first of those cameras will render them correctly. Is this what you’re doing?
Thanks for the response @mvaligursky
Currently I have it that the textureCamera that is rendering the splat to multi targets, is also following the transforms of the main camera. It seems something funny is happening only when rasterizes to the render target.
If the cameras are effectively the same, we should expect that they should match correct? Below shows their transforms + matrices + target texture sizes (main camera being app.graphicsDevice.width/height)
I’d be worth trying to set up your texture you render to to be the same size as the main framebuffer. I think we only update viewport parameters one time, and the error in your video feels like it could be scaling related.
You print some viewports there, but I’m not sure what they mean. Are they the same already?
Ah actually, you mentioned in the first post viewports match.
I think the best way to investigate this would be to capture a frame using SpectorJS (chrome plugin), and compare render to texture with rendering to the framebuffer. Shaders should match, and so compare the uniforms, to see what’s different.
Thanks @mvaligursky
Indeed, this is what I’ve been doing. The viewport_size variable listed above is the output of app.graphicsDevice.width and height, and the one below is the output of the texture size that I’m using. Seems like something else could be happening.
I agree, it feels like something to do with scaling
Thanks! Let me give this a bash and see if I spot anything
Thanks @mvaligursky for the suggestion! Didn’t know about SpectorJS, really useful tool!
I’ve just had a look at the uniforms being passed to the COLOR_ATTACHMENT_1 and Canvas Framebuffer and it seems like they do match (attached a picture of screenshot of the canvas frame buffer uniforms to the left and render targets to the right). Must be something else going on.
1 Like
when you use spector js, run your app with a debug engine, it will give you a lot more info on what is happening.
1 Like
Ah, thanks for the help @mvaligursky
SpectorJS helped me to see that I was flipping the Y on the created textures. This is seemingly what was causing the issue!
Looking way better now
1 Like
This looks really interesting @tonetechnician!
If you can, please keep us posted on your progress. I’m wondering whether some of this might benefit the engine and/or SuperSplat!
