@Pauler - ok, and do you only store these chunks in memory? What I'm saying is, I have an ArrayList which stores chunks, at the moment it stores all the chunks in my game, which, obviously is a big bottle neck and this isn't how to do it. I believe you only add chunks to memory when you can see them and remove the ones you can't?

For instance, if you have 64x64 chunks, this in my game is (64x4096 blocks) x (64x4096 blocks) = 524288 , now unless you got a decent graphics card with a good deal of memory, memory will run out. My gfx card is an Intel 3000 HD, so not very good, uses shared memory I believe??

What I am getting at the moment in my game is, say with 16x16 chunks, runs fine, but once all chunks have been seen, the game slows down and CPU usage goes to 64%...If I then reset my camera position back to 0,0,0 the CPU usage drops back to 19% - any ideas what this could be?!

@Pitbuller - Not using that formula anymore, didn't seem to work for me. Thanks anyway.

@Vermeer - Your project(s) inspire me ;-) I was thinking of putting a thread in for the dynamic loading - basically run a thread, check if chunk is in view or not, if not, remove from memory (active chunklist array).

@Roquen - dynamic array - thus back to an ArrayList? This would only be faster if used object indexes - thus say object 10 would be index 10, will have a think about this as need fast look ups.

Just added frustum culling but finding using the distance formula better...

As anybody else implemented frustum culling in their voxel project and how does it fair overdoing a distance check?

I think I will use frustum culling for other objects in my project, not for the voxels, will stick with distance formula.

Frustum culling is dead cheap. Distance formula can't be faster than it if you use it right. Draw call is at least magnitude slower than any sane bounding box frustum culling method that you can ever write.For iOs project I frustum cull every particle as optimization.(Sphere frustum test. Even this is better than distance checkl) This was faster than rendering them all with one draw call even before any simd optimizions.

Frustum culling is dead cheap. Distance formula can't be faster than it if you use it right. Draw call is at least magnitude slower than any sane bounding box frustum culling method that you can ever write.

To use the cubeInFrustum, it states to supply the centre of the cube and half the size which is what I'm doing in my code. Must admit, I don't think it is working as it should though, maybe I've got the x,z and size wrong - I'm taking it that X is half the width and Z half the depth of the chunk - my chunks being 16 blocks wide and 16 blocks depth, you can see I just times the x by 8 and z by 8.

The thing about frustum culling is that you should need to check a very small percentage of regions. At a logical top level you're checking against 5 gradient space (one less since far and near are offsets), quickly planes will drop away as a child region is either totally inside or outside and you're finally left with none to check.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org