Pilvinen
commented
5 years ago Like I've explained before it's categorically impossible for this to work because we're not using a full octree where all the blocks are stored in the nodes.
In our case each of our octree nodes contains either a chunk of blocks or alternatively a material reference, in which case all of the blocks in the chunk are of one material, for example dirt.
If you divide the screen into 16-64 tiles and shoot rays from those you have to consider what you are hitting:
On one hand you have the octree where no distinction is made about what kind of data it contains. Therefore it cannot be determined whether you should see through the chunk or not to the next chunk by looking only at whether octree nodes are occluded by other octree nodes.
To make a determinations about occlusion you would have to consider actual block data unless you are only interested in checking for octree nodes with material reference (ie. "this is all dirt and therefore you cannot see through this"), but you would need to read the material and check whether it's opaque.
On a block level, inside a chunk, where it can be determined whether you can see through the chunk or not, the block data cannot be traversed like you could traverse through a full octree (and do very cheap determinations on what to draw and which branches to drop).
It needs to be studied how the chunk data can be efficiently raycasted. However I do not see how dividing the screen into tiles could be beneficial. I need more information on that.
Plan is to divide the screen into 16-48 tiles and possibly shoot rays from them to determine which chunks to draw. Though this may need to be talked over to get a more concrete plan.