You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Godot v4.3.stable unknown - Manjaro Linux #1 SMP PREEMPT_DYNAMIC Thu Oct 10 19:03:24 UTC 2024 - X11 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3060 (nvidia; 560.35.03) - Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz (6 Threads)
Issue description
Currently working on creating a foliage setpiece for a VR application
Due to the extremely limited fill-rate and performance of the style of mobile tiled renderer based GPU in most standalone headsets, I'm running into a performance ceiling from overdraw in areas with lots of leaves
When this sort of area covers the screen performance slows down considerably. It doesn't when using an opaque material on the same mesh.
To try and reduce performance hit I have separate meshes that fill the core of the tree, these meshes have a very simple opaque materials and are as cheap to draw as possible.
In order to actually reap the benefits of this though, this fill mesh NEEDS to be rendered before the leaf meshes. Unfortunately upping the render priority above zero, doesn't make the fill object render first. In my case the leaves draw first according to renderdoc
The same thing happens when building to VR and capturing a frame in renderdoc remotely from the headset.
In fact if I up the render priority from zero the filler mesh doesn't even render until all the way at the end of the opaque pass right before the sky is drawn!
Since I was using light-map GI I also tested whether or not the dynamic vs static lighting option made any difference to render order, and it appears that it doesn't.
Basically I have no way of making these fill meshes render before the leaves and this completely nullifies any possible performance gain since the leaves have already been drawn and have no way to compare against a depth buffer that doesn't exist.
Steps to reproduce
See above explanation
Minimal reproduction project (MRP)
alpha-clip.zip
This should be enough to test and see that the Render Priority and Sorting Offset are not affecting the render order as expected.
The text was updated successfully, but these errors were encountered:
Tested versions
Godot v4.3.stable
System information
Godot v4.3.stable unknown - Manjaro Linux #1 SMP PREEMPT_DYNAMIC Thu Oct 10 19:03:24 UTC 2024 - X11 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3060 (nvidia; 560.35.03) - Intel(R) Core(TM) i5-8600K CPU @ 3.60GHz (6 Threads)
Issue description
Currently working on creating a foliage setpiece for a VR application
Due to the extremely limited fill-rate and performance of the style of mobile tiled renderer based GPU in most standalone headsets, I'm running into a performance ceiling from overdraw in areas with lots of leaves
When this sort of area covers the screen performance slows down considerably. It doesn't when using an opaque material on the same mesh.
To try and reduce performance hit I have separate meshes that fill the core of the tree, these meshes have a very simple opaque materials and are as cheap to draw as possible.
In order to actually reap the benefits of this though, this fill mesh NEEDS to be rendered before the leaf meshes. Unfortunately upping the render priority above zero, doesn't make the fill object render first. In my case the leaves draw first according to renderdoc
The same thing happens when building to VR and capturing a frame in renderdoc remotely from the headset.
In fact if I up the render priority from zero the filler mesh doesn't even render until all the way at the end of the opaque pass right before the sky is drawn!
Since I was using light-map GI I also tested whether or not the dynamic vs static lighting option made any difference to render order, and it appears that it doesn't.
Basically I have no way of making these fill meshes render before the leaves and this completely nullifies any possible performance gain since the leaves have already been drawn and have no way to compare against a depth buffer that doesn't exist.
Steps to reproduce
See above explanation
Minimal reproduction project (MRP)
alpha-clip.zip
This should be enough to test and see that the Render Priority and Sorting Offset are not affecting the render order as expected.
The text was updated successfully, but these errors were encountered: