richardbiely / Voxelmetric

An efficient voxel framework for Unity3d

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Do not display faces for the bottom of the world

richardbiely opened this issue · comments

Currently, bottom faces of blocks at the bottom of the world are rendered even though nobody is ever going to see them. Don't create geometry for them.

6c78a00

Faces no longer generated at the bottom of the world. Can be influenced via worldConfigs's "renderBottomWorldFaces".
Collider no longer generated at the bottom of the world.

commented

Are you sure this works.. I tried multiple settings with "renderBottomWorldFaces": true, and false in the default.json world config

and there is no difference.. it also seems related to the same problem as #31

top of the world:
http://i.imgur.com/0Gn5Kc8.jpg (gameview)
http://i.imgur.com/oJBdIAJ.png (editor)

bottom of the world:
http://i.imgur.com/Rfs39tW.jpg (gameview)
http://i.imgur.com/8vT3UAE.jpg (editor)

this is with follow cam on, and also had change the default Y for those screenshost.. world saves delete on different tests aswel...
"maxY": 124,
"minY": -124,

So you can still place a block on the invisible chunk layer that is directly below or above the last max/min y and it ruines the geometry aswel as adds the AO... isn't there a better way to do this. Even if this was a worldedit selection and part of the block selection went off the max/min y height.. and you set it too stone, then you would want the last block top/bottom face to be seen, and any other block above/below that are out of the world bounds to not be effecting previous block that is above/below it. At this point the geometry showing for the top of the world preferred for me, not so much as the bottom, but the option doesn't work either way.

For the camera I could just have it checked to make sure any block above min/max y height don't get placed, and do this check before the problem starts to occur at the Y height... but this change is really best sorting out in the engine more directly no?

And in both case, you got an entire layer of invisible chunks adding to the overall number of chunks that get checked in LoadChunkSimpleUpdate both for the last layer of chunks on the top and bottom of the world, and depending on the what chunk horizontal chunk load radius, default scene its set at... 8 which means around 145chunks on this bottom/top layer that are never seen (yet adversely effect the chunk above/below negatively visually) and are still checked per frame...on the default scene LoadChunkSimpleUpdate takes around average 3ms.. every frame... this is on a overclocked i5, on lower end cpu this would be even worse, like worse than minecraft (which I know you hate it being compared too but the performance cost per frame isn't so great :( ) This is what really needs to be reduced imo, while block add/remove changes to a chunk prioritized in the loop