World min/max height and chunks
XeonG opened this issue · comments
Strange problem with blocks stop properly at bottom and top of the min max height ...ie if you keep placing blocks to the top of the world, you will be left with a block with no top face.. unless you remove the last placed invisible block just above it. In the screenshot (http://i.imgur.com/83i0Prk.png) you can see their is another chunk above and it seems like blocks are being placed inside of it as there is hit detection on them, they just aren't generated in view anymore.
I have a 160 visible blocks from bottom to top...
And this is the world config settings
"maxY": 740,
"minY": -640,
default numbers I presume though they don't make much sense, can you shed some light on the settings for that.
I think there's nothing wrong. Because you gave me no description of your project setup I'll assume the following is happening:
Because your minY nad maxY are set to different values, the world is assumed to be of finite height. In your LoadChunkSimple script, your VerticalChunkLoad is set to 5 and you don't have FollowCamera enabled. Therefore, anything beyond 160 blocks (32 * 5) away from the world origin ([0;0;0]) gets hidden. Enable FollowCamera to make your world render around the camera instead.
Different games need different setup. Some want to have a static world displayed all the time, others want the same just with dynamic loading. Some want to have finite height, other want infinite etc. Although Voxe(lmetric) still has some room for improvement in this area, you can achieve most of these things simply by properly using load ranges and followCamera/minY/maxY.
You're back!
ok so I took another look at this, I see how the minY/maxY settings do actually work (just having follow cam off, made me think they had no significance.)
The problem as shown in the screenshot(maybe not so well) is still a problem though.. the engine is cutting off the top of last block face at the maxY, or bottom face for minY.. this shouldn't happen? those top or bottom faces should still be visible as the minY/maxY setting should prevent any further blocks from being placed above or below that setting? (or at least if the minY/maxY setting falls inline with a chunk size) so maxY = 64 and minY = -64 with chunksize at 32, would mean only 4chunks from top to bottom? (though currently it feels like I still place blocks beyond those Y height values, even though they are not seen.
It's kinda also messing with the AO generated aswel even though you can't see the blocks that are generating the AO past the minY/maxY.
"Different games need different setup. "
yeh I like flexibility.. though for the game I am trying to make I don't need infinite in any direction really.. makes me wonder howcome no min/max X,Z setting was ever added into the world data config?
Pretty sure that is actually the normal behavior of the engine. It assumes
that you shouldn't be outside of the world, and would never need to see the
top/bottom of those blocks. I might be wrong, but I'm almost positive the
engine is acting as it should be. Rendering those faces might be an edge
case that could be accounted for, but I cannot think of any reasons that
you would be able to see those angles in normal gameplay, save maybe a
bird's eye view.
On Sun, Sep 11, 2016, 7:22 AM XeonG notifications@github.com wrote:
You're back!
ok so I took another look at this, I see how the minY/maxY settings do
actually work (just having follow cam off, made me think they had no
significance.)The problem as shown in the screenshot(maybe not so well) is still a
problem though.. the engine is cutting off the top of last block face at
the maxY, or bottom face for minY.. this shouldn't happen? those top or
bottom faces should still be visible as the minY/maxY setting should
prevent any further blocks from being placed above or below that setting?
(or at least if the minY/maxY setting falls inline with a chunk size) so
maxY = 64 and minY = -64 with chunksize at 32, would mean only 4chunks from
top to bottom? (though currently it feels like I still place blocks beyond
those Y height values, even though they are not seen.It's kinda also messing with the AO generated aswel even though you can't
see the blocks that are generating the AO past the minY/maxY."Different games need different setup. "
yeh I like flexibility.. though for the game I am trying to make I don't
need infinite in any direction really.. makes me wonder howcome no min/max
X,Z setting was ever added into the world data config?—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#31 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGHiBQujoZDc7JWF2-qZ8BjeuJL381X2ks5qo-RYgaJpZM4Jos6m
.
"save maybe a bird's eye view."
well you can take minecraft as an example.. the player can build right upto the max world height of 256 and stand ontop of that block... can't place anymore blocks above that, and the last block placed has the top face shown...with creative and fly mode they can go below the worldgen and see the underside block faces.
i don't see any performance benefit to it working that way, just other problems with it. nothing that couldn't be worked around by preventing the player from placing a block at -/+ 1 from the existing Y height setting.. that way they never see such a weird behavior.
for my game it doesn't really matter its not a problem to work around, just something I noticed that seemed a little off.
Any block you place above minY already is empty/air. However, the issue here is that the game loads at least one more chunk that it displays (because of how the chunk engine works internally). So what will need to be changed is that the game should not generate any block not only beyond the max coordiante but no blocks for the edge chunk as well (with followCamera turned off).
However, even this thing may be configuration specific because some people might want edge block faces visible (bird view camera), some will not.
Right now you can work this around by not placing any blocks beyond the problematic threshold.