<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Blog, Engine.</i>
In my down time I've been looking at the light grid implementation and have been considering different ways to improve the accuracy (though I appreciate it's only designed for approximating ambient light).
One idea I came up with after looking at the way the light factor is applied (distribution from source block using the two dimensional attribution <tt>factors</tt> array) would be to use a method similar to a Marching Cubes algorithm.
While initializing the light grid, where currently a single sample point at the center of each block is used to determine the block's sector:
* Instead how about taking four samples (one for each corner of the block). This will (potentially) give us four different sectors.
* Examine these four sectors to see which ones are the same to approximate a "shape" for the block ie zeroth (all points are in a sector (any)) OR top, bottom, left, right, topleft, topright, bottomleft, bottomright when one or more sample point is not in any sector (it's in the void).
* block->sector is still choosen by the sector at the center sample point.
* Assign this "shape" id property to <tt>gridblock_t</tt>.
In LG_Update() where the light attribution factor is determined for each block being updated in the light grid:
* Instead of ALWAYS using a Zeroth distribution factor (from the <tt>factors</tt> array) - select a factors array based on the "shape" of the block being updated.
What are your thoughts on this?
If I'm right, the above method should greatly improve the accuracy of the lightgrid and help to reduce the amount of "bleeding light" between disjoint sectors.
I'm not sure but this approach should be scalable in the way that the HQ2X/3X etc, smart texture filters are (of course the current method is already scalable in that reducing the blocksize yields more accurate results).
BTW - What is the reasoning behind using a 2D block grid with "Z bias" (and not "real" 3D)?
Given this decision I presume that you have decided that either sector-over-sector won't be implemented in the 1.9.x series OR that you have a different method in mind for when it is (portals?)?