Skip to content
This repository has been archived by the owner on Jan 29, 2024. It is now read-only.

Voxel World Illumination #7

Open
zauberparacelsus opened this issue Jun 9, 2018 · 0 comments
Open

Voxel World Illumination #7

zauberparacelsus opened this issue Jun 9, 2018 · 0 comments

Comments

@zauberparacelsus
Copy link

With a voxel world module, it might be useful to consider alternate GI schemes. The current ones in Armory seems to fall into one of two categories: they are either (A) assume premade levels or (B) rely on computationally-expensive geometry.

With a voxel world, it may be more useful to create a more specialized form of global illumination. Minecraft appears to use form of baked global illumination which is rebaked when blocks and lights are added or removed. It also uses just two channels. One channel represents the amount of light received by local scene lights, while the other channel represents the amount of light received from the sky (including the sun and moon).

Though, what minecraft does is all very naive, because (A) the illumination in one block is based on the light in an adjacent block, (B) the light is uncolored, and (C) direct light from the sky only goes downward.

For Armory3D's voxel world, something loosely based on minecraft's lighting could be implemented, with a few differences:

  1. Instead of the "adjacent block" approach, the module could just use baked GI, which is re-baked when lighting changes are made.
  2. The baked light would be stored in RGBA form. The RGB channels would store the colored light coming from static lights, while the A channel would store the amount of light received from the sky. It would be a simple intensity value which would be multiplied with the light from the sky, avoiding the need to rebake with transitions in weather or time of day.
  3. As an optimization, a whole chunk (a 16x16x16 grid of blocks or whatever) could be marked as not receiving any light from the sky, and being fully shadowed in relation to the sun or moon.

I am hoping that such a system would have a lower performance cost compared to the usual GI methods. Though I don't know as much as I would like about rendering, so consider this armchair rambling. Hopefully it's still useful though :P

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant