Document occlusion culling classes and settings #57889
Conversation
Calinou
force-pushed
the
doc-occlusion-culling
branch
from
7ea9fe6 to
5dd006f
Compare
doc/classes/OccluderInstance3D.xml
Outdated
| </brief_description> | ||
| <description> | ||
| Occlusion culling can improve rendering performance in closed/semi-open areas by hiding geometry that is occluded by other objects. | ||
| The occlusion culling system is mostly static. [OccluderInstance3D]s can be moved or hidden at run-time, but doing so will trigger a background recomputation that can take several frames. It is recommended to only move [OccluderInstance3D]s sporadically (e.g. for procedural generation purposes), rather than doing so every frame. | ||
| The occlusion culling system works by rendering the occluders on the CPU in parallel using [url=https://www.embree.org/]Embree[/url], drawing the result to a 160×90 buffer then using this to cull 3D nodes individually. In the 3D editor, you can preview the occlusion culling buffer by choosing [b]Perspective > Debug Advanced... > Occlusion Culling Buffer[/b] in the top-left corner of the 3D viewport. |
There was a problem hiding this comment.
The occlusion buffer size is not fixed, it depends on the "rendering/occlusion_culling/occlusion_rays_per_thread" project setting (I now see this may not be a very explicit setting name, we could change it). The resolution is chosen so the number of pixels in the occlusion buffer is approximately (rays_per_thread * cpu_physical_threads). This means CPUs with fewer cores will use a lower resolution, in an attempt to keep performance costs more even across devices.
There was a problem hiding this comment.
I can't see a reference to the number of physical CPU cores, only logical CPU cores (which is the default number for ThreadWorkPool):
- https://github.com/Calinou/godot/blob/5dd006f7042bc62e8fdc2aa28ee2f8ed432acdad/servers/rendering/renderer_viewport.cpp#L158
- https://github.com/Calinou/godot/blob/5dd006f7042bc62e8fdc2aa28ee2f8ed432acdad/core/templates/thread_work_pool.cpp#L50
(Not that I think your statement is incorrect, but I don't remember Godot being able to return the amount of physical CPU cores present on a system. This would be a good feature to add, but it's a topic for a proposal 🙂)
There was a problem hiding this comment.
Right, I got physical/logical cores mixed-up :)
Calinou
force-pushed
the
doc-occlusion-culling
branch
from
5dd006f to
b960412
Compare
|
I added documentation for the |
Calinou
force-pushed
the
doc-occlusion-culling
branch
from
b960412 to
dee43ea
Compare
This salvages the documentation improvements from #50408, on top of adding some new changes.