Faces +AO on bottom/top of world not being shown
XeonG opened this issue · comments
re: #34
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 ruins 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
The top of the world should no longer be a problem since: 6d0e955
If needed, I might add a setting for bottom of the world as well.
As for the performance issues - any numbers measured in the editor are meaningless. Performance needs to be measured on a release-mode executable.
The performance problems LoadChunkSimpleUpdate does translate to release mode.. if it takes 4ms in editor and I half it to 2ms by alternating the chunks it processes every frame.. ie 801~ chunks in the list to process every frame is alot.. but doing 400 one frame and the other 401 the next does work pretty well.
Editor or release build compiles of the 4ms and 2ms editor builds show up in noticable fps increase on the 2ms build .. so that halfing of the chunks processed every frame translates.
anyway that was my attempt to improve the performance on it as 4ms per frame for me is a lot and i think for a 2.5ghz (kinda avg laptop) clocked cpu that 4ms would be even higher. I'm sure is other even better ways but I left at that cus I'm not sure where the project stands in terms how that area might still change etc. so I just make small tweaks that can be updated with your changes easier.
Editor or release build compiles of the 4ms and 2ms editor builds show up in noticable fps increase on the 2ms build .. so that halfing of the chunks processed every frame translates.
I'm sorry but this part is written in a way I can't understand. What I gathered is that processing half of the chunks per frame translates into better frame time. I find that logical.
Personally, I don't think that processing 800 chunks per frame is an issue. Even if it was thousands it should still be fine for it's just a simple iteration over a list of chunks, doing bitwise operations and inserting jobs to thread pools. Only more time demanding operations there are are edge synchronization (done once before geometry is generated) and building geometry. However, these do not happen when idle so let's just ignore them for now.
My results for LoadChunkSimple.Update() for 1043 chunks (frustum culling turned off) are:
Editor >> 1.8 - 3 = ~2.4 ms
Release >> 0.5 - 0.7 = ~0.6 ms
I'm running a Xeon 3.40 Ghz. That's essentialy the same CPU as you have, just 36% faster. Given Update() runs on the main thread I'd expect your results to be 4 ms tops for the editor and 1 ms for the release build.
Even though this iteration can be simplified it can never be skipped completely for there's always something that needs to be evaluated.
I added Features.DontRenderWorldEdgesMask flag for you: 7eea563
You can use it to influence which chunk edges are rendered at your world's borders. By default it's just the "up" side.
What I meant by the laptop was targetting an average cpu like speed of that, so the 4ms in editor for me would be even worse on a lower clock speed.. I don't have a laptop just desktop i5 that is overclocked above that so feel like I'm seeing 4ms, and being like, that is a lot just for seeing chunks and not even a big view distance.
I'll do some more testing of editor/release builds to compare again.. it is a bit naff how unity doesn't provide better release build debugging tools like being able to get the same in editor like stats.. for cpu/gfx counter etc...so my testing on this was a while back but your editor and release differences are not like mine because I was just going by average fps framecounter differences half the chunks being processed resulted in higher fps average and wouldn't it be nice if this could be taken further to increase performance.
"Personally, I don't think that processing 800 chunks per frame is an issue. Even if it was thousands it should still be fine for it's just a simple iteration over a list of chunks, doing bitwise operations and inserting jobs to thread pools. "
well I still disagree, i think its pretty inefficient to be checking over the same 1000's of chunks every frame its worse the more you increase the view distance.. instead of just the nearest ones and only ones further away in some other list array that gets checked for changes little less often. Because you want to see the chunk geometry of something loaded up 6+ chunk blocks away.. but you don't care to see every individual update on it being checked every single frame.. its just inefficient and greatly reduces the view distance you can attain.. I experimented with 16 and 32 sized chunks last year.. and honestly felt somewhere inbetween the two would have been ideal for both distance and chunk rebuilding speed for average hardware of today like 24chunk sizes but can't have that.... so ended up sticking with 32 sized chunks even though they are slightly slower to rebuild on block changes... because once again view distance and shear amount of chunks added to the process loop every frame with 16 blocksized chunks for about the same render distance at 32, caused a lot more cpu time to be wasted everyframe, and depending how much else is going to happen in game that could be a problem... so if you see what I mean it is inefficient and not exactly an elegant way of doing things almost brute force imo.. so you do need good hardware just to use the voxel engine.. not sure on the minecraft approach but its alot better what ever it is both for client and server in average cpu usage. So I still think its something that could be looked at for a performance boost at somepoint.
"I added Features.DontRenderWorldEdgesMask flag for you: 7eea563
You can use it to influence which chunk edges are rendered at your world's borders. By default it's just the "up" side."
Will check it out thanks.