Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Octtree etc. will work for sure, but another possible way to solve your specific problem might be to store to add an <code>usigned char visible</code> to every cube object. The value of the <code>visible</code> field is calculated as following:</p> <ul> <li>if the right side (looking along the x axis) has no neighbor, then the first bit (1) will be set.</li> <li>if the left side (looking along the negative x axis) has no neighbor, then the 2nd bit (2) will be set.</li> <li>if the front side (looking along the z axis) has no neighbor, then the 3rd bit (4) will be set</li> <li>... and so on, so that you have 1 bit for each of the 6 sides of a cube</li> </ul> <p>Whenever the player digs a cube away, you have to update the <code>visible</code> field of all of it's neighbor cubes.</p> <p>So, but how will this help? If a cube has a <code>visible</code> value of 0 then it's easy - the cube will be never shown. But let's say the cube has a <code>visible</code> value of 1. Then the cube (might) only be visible, if <code>Xplayer &lt; Xcube</code>. The other sides work similar, and I think such a function which decides if a cube might be visible will be quite fast and is able to skip a lot of hidden cubes.</p> <p>The disadvantage of that, is that this test is only a per-cube test and you can't skip complete groups with that. So, maybe an octtree (for skipping complete regions) and such a visible field like described here, for skipping the high number of hidden cubes (Since such cubes are stacked, the number of hidden cubes will be much higher than the number of the visible ones) inside that region might be a good solution.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload