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
Currently the renderer pretty much does what a traditional painter would do with a canvas: start with the background and work your way forward, layer after layer, until you get to the most foreground elements.
This works, but it can be somewhat inefficient. Let's imagine for a moment that we are in a cave and the sky is absolutely invisible. The current renderer renders it anyway, as one of the very first steps in the rendering process.
Solution
Ideally, we'd render the foreground geometry first and, on a per-fragment basis, take advantage of the stencil buffer and reject fragments that would be behind a layer already rendered, i.e. fragments of the sky behind the landscape.
Even HUD elements and overlays might cover some small but not insignificant portion of the screen, hinting to some further potential performance savings.
Limitations
Some render nodes might be compatible with this way of thinking, but others might not. For example, it should be possible to -not- generate light shafts in the fragments behind a HUD element. But renderings that get blurred by blur nodes, for example, would be negatively affected by "black holes" in the input image, generating halos and artifacts around the HUD elements.
As such, care must be taken when evaluating the role of each node in this way of thinking: for some nodes it might make sense to render the full frame, with no stencil masks taken into account.
The text was updated successfully, but these errors were encountered:
On a maybe-kinda-sorta related note: there has been occasional talk about chunk occlusion and such, like in issue #1710 (huh, time really does fly).
As part of the Sectors world gen item in GSOC 2017 some more ideas came up on pre-generating world further away from the player, but without going through full and expensive chunk generation (somehow estimating distant appearance / opacity via examining noise and facets). So that might be a thing we could do at one point, helping lay the foundation for #319 (even older, wee)
In engine v2 we now have both sectors and zones (old name: surfaces). I suspect it isn't out of reach to pre-generate an entire surface zone (infinite worlds would also get cut into horizontally adjacent zones at some point) so you'd know in advance where there are mountains that will certainly block the sun even if you're out of chunk loading range from said mountains.
Wanted to link those two issues here since they might eventually impact what we can throw away / ignore.
Introduction
Currently the renderer pretty much does what a traditional painter would do with a canvas: start with the background and work your way forward, layer after layer, until you get to the most foreground elements.
This works, but it can be somewhat inefficient. Let's imagine for a moment that we are in a cave and the sky is absolutely invisible. The current renderer renders it anyway, as one of the very first steps in the rendering process.
Solution
Ideally, we'd render the foreground geometry first and, on a per-fragment basis, take advantage of the stencil buffer and reject fragments that would be behind a layer already rendered, i.e. fragments of the sky behind the landscape.
Even HUD elements and overlays might cover some small but not insignificant portion of the screen, hinting to some further potential performance savings.
Limitations
Some render nodes might be compatible with this way of thinking, but others might not. For example, it should be possible to -not- generate light shafts in the fragments behind a HUD element. But renderings that get blurred by blur nodes, for example, would be negatively affected by "black holes" in the input image, generating halos and artifacts around the HUD elements.
As such, care must be taken when evaluating the role of each node in this way of thinking: for some nodes it might make sense to render the full frame, with no stencil masks taken into account.
The text was updated successfully, but these errors were encountered: