Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rendering Front to Back #3073

Open
emanuele3d opened this issue Aug 17, 2017 · 1 comment
Open

Rendering Front to Back #3073

emanuele3d opened this issue Aug 17, 2017 · 1 comment
Labels
Topic: Rendering Requests, Issues and Changes related to lighting, meshes, camera, etc.

Comments

@emanuele3d
Copy link
Contributor

emanuele3d commented Aug 17, 2017

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.

@emanuele3d emanuele3d added the Topic: Rendering Requests, Issues and Changes related to lighting, meshes, camera, etc. label Aug 17, 2017
@Cervator
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Topic: Rendering Requests, Issues and Changes related to lighting, meshes, camera, etc.
Projects
None yet
Development

No branches or pull requests

2 participants