I have the feeling that this system wont do any arches or tunnels!
Why not? When you delete a block ( an invisible one) you would tell the chunk to update. If the chunk’s small enough, it won’t be that tough on the CPU. You could even tell it to recalculate a certain area if you knew how. The main problem right now’s the start-up time vs. loading in the meshes dynamically. If I use LibNew to create new meshes to alter, it takes (for some reason) Logic %, which makes it inefficient. If the chunk data contains too many faces, then it takes too long to actually start the game.
EDIT: It doesn’t work with tunnels right now because I’m using simplex noise to generate the land height, and then creating blocks back down to baseline. It works fine, but it won’t add any tunnels yet to be sure.
EDIT 2: HUH. After deleting the spawner object (not the chunks themselves), the logic drops down significantly! 
EDIT 3: I think I figured it out. It was having trouble traversing the scene graph, which is a bit disheartening, but also a bit good. Let me explain.
Because I added a cube for each, well, cube in the game, I ended up with a huge amount of cubes in the scene graph. When I had the Spawner look for chunk objects to create, it had to slog through thousands of cubes, which is bad. The good thing is that it was just this action alone that made it slow - if I never use sce.objects, but rather keep track of objects myself, the game should remain smooth.
Additionally, I could delete the invisible cubes after they’re formed into chunk data - there’s no reason to keep them around. I could replace them with Python objects in a 3D array in the chunk to give the chunk the data that it needs. Then, if the player needs to interact with the ground, he would look at the position he’s on or is looking at, then check the chunk’s data.
This is turning out to be quite interesting.
Welp, I got pretty far. I could continue, as the system does pretty much work, but placing the chunk data mesh freezes the game for a few seconds each time it’s called. It would be nice if it took an argument of percentage - like you could load up, say, 10% each time you try to use the function. That way, I could load up a portion of the mesh until it’s ready, and then replace the mesh, not freezing the game. Oh, well.
You could try splitting up the chunks into smaller pieces. Then just detect when you’ve used up all the faces in a chunk placeholder and load another piece of the chunk.
Most of the time you probably aren’t using or don’t need even half of the faces you have in a full chunk “fodder” object, so this might be a good optimization regardless of the chunk loading times.
Yeah, you’re probably right. If I made simply 5x5x5 chunks instead of 10x10x10, it might be worth it. In fact, perhaps 4x4x4 would be better, as it probably should be even numbered. Anyway, I’d have to look into implementing some sort of face culling system into the game… Maybe I should spawn each cube, then delete each face that is a neighbor to another cube, have the chunk data construct itself around the cube faces, and then destroy the cubes and the faces to just be left with the chunks.
- You could add steps to your system so it runs one fodder cube per step.
- As said before you could have more, smaller fodder meshes,
- you can replace the original cubes with empties, then delete them within each step;
- Map your fodder object in a library, each entry will contain a cube {index:[GlobalVertexPosition/4]}( index: average vertex position in each cube), possibly this could allow you to add 3d geometry, like tunnels. You deal with the cubes instead of vertices(well, the vertices are dealt with in a function during the step).
Edit… - For different looks, use vertex color to determine a texture or material(although I tried the material part, the result was not very convincing)
With step 4, you could use this technique for other thing, like adding vegetation and extra detail in a terrain mesh.
This is a very interesting research!
- It does that already.
- Yeap.
- That might be smart. Spawning the cubes isn’t really the slow part, but I don’t think I was planning on keeping the real cubes in there.
- I’m not sure I get you. If I’m dealing with a single object, then I’ll be dealing with the vertices - if I deal with several cubes, then I might as well just use the cubes themselves, right?
- The looks should already be pretty easy - each vertex of the fodder mesh copies the UV values of the cubes that are created. The fodder mesh and the cubes both share a single image, which would contain each texture available in the game. So, if I spawn sand, dirt, grass, rock, and metal, the fodder mesh will appear the same.
This is indeed interesting, as I didn’t really think that such a thing (many, many objects) was possible in the BGE before now.
He Solarlune. Your technique would fit very well into digging games/tunnel building.
Btw. you do not need to have everything into one large object. It would be sufficient enough to have e few large objects. With LibNew() you can make individual copies of a predefined mesh. So you can create larger areas with multiple fodders.
As a side effect you decrease the loading time a lot.
I was using LibNew for each fodder mesh. Replacing it was taking a bit too long, though, so I think I might need to scale down the size of each chunk.
But what did you mean about larger areas with multiple fodders - not one fodder per area?
You already did that. Cool.
I mean exactly that.
One fodder per area
-> multiple areas = large area.
Seems I’m not telling anything new 
Beside that I think this technique can be used outside of “voxels” and “cubes” as well.
- I’m not sure I get you. If I’m dealing with a single object, then I’ll be dealing with the vertices - if I deal with several cubes, then I might as well just use the cubes themselves, right?
I mean , you map the mesh according to cube location or group vertices in the cube in one index. so you move the group instead of vertices.
This could be good in case your mesh makes a forest! Each tree needs a maximum size/space, then add the space to a library. If you list your empties in my step 3, and sort them somehow, you can use their index to access a group of vertices from the library. The library will search for all vertices in that space and move them to the target location (this might require a bit more logic, slowing the system down…).
Since I haven’t got your script yet, I can’t tell if this will improve or not. But can be useful when it comes to use many objects in a single mesh(I’m using it for my game, well at least planning)!
Hey solarLune this is looking really awsome! is there any way of getting a .blend of what you have so far to experiment with?
Hey, everyone.
@Monster - Yeah, it could be used for other things - really, for any in-game placeable objects. You might even be able to do something similar with large-poly dynamic objects (like spheres that roll about). When they’re resting, flatten the sphere mesh into a sphere fodder mesh, and delete the original spheres. Then, if you need to change it, you could ‘unflatten’ it - that’s something that I haven’t done yet, though.
@torakunsama - Hmm. I still am not so sure of what your idea is, though I can tell that you would know about huge numbers of polies in a game.
@mrn - Thanks. I don’t plan on keeping this under wraps - it’s not a novel technique, so I’ll probably open-source this whole project.
Welp, good news. The UV settings transferred correctly, which is good. Also, I sped up the Flatten code - now, it stays pretty stable while generating each chunk (45FPS sometimes, 15 other times). However, I don’t think it’s generating a chunk each frame. It would be faster overall, but it also would have a much worse FPS. Each chunk is now just 4x4x4 rather than 10 or 20. I also got rid of the code to create cubes to the ground - it wasn’t really working correctly, and it was just adding new cubes, anyway, so I dropped it.
I just now saw the FPS on that screenshot - 80% Rasterizer isn’t going to cut it, so I think I might double the chunk size. More chunks = less strain on the Rasterizer.
EDIT: The two holes in that screenshot are more than likely caused because of a bug that I used in my usage of simplex noise to generate the land. I’m using the X and Y of the blocks, which sometimes can be negative, creating those holes.
Weird. Did another test, and it was 60 FPS with 15% or so on Rasterizer. Weird. 486 chunks at 64 (4x4x4) blocks - 186624 faces… Maybe it’s the limits of my graphics card to keep the meshes in its memory. Looks like I would have to both do some face optimization, as well as possibly loading and unloading chunks that are in memory…
@torakunsama - Hmm. I still am not so sure of what your idea is, though I can tell that you would know about huge numbers of polies in a game.
Let’s suppose, you fodder mesh is made out of trees, now these trees have various vertices and you will not place trees, instead of cubes in a scene in realtime(in my case).
The mapping will index each tree in the fodder by the cubic space it occupies. So when laying the trees down, you’ll get a position in the terrain and place a tree there, the tree is the group of vertices you’ll retrieve using the dictionary.
In a fodder where the there are 4X4 trees the first tree will be occupying the space (-15,15) thus:fodder= {0:(-15,15)}, so fodder[0] will select the vertices occupying the space between(-16 to 14, 16 to 14). Each index will correspond to a tree.
Also I’m interested in you simplex noise function!
I see now. I was going to use a similar technique for recalculating changed portions of chunks. Like you said, assign cube indices (either game object cubes or just Python custom class ‘cube’ objects) to vertices for the fodder mesh. When I need to delete a ‘cube’, it would reflatten that area of the mesh. It might be a bit more complex than that, though, especially if I’m just allocating enough faces to deal with surface cubes, and not depth cubes.
I didn’t write the simplex noise function - I got it from here. For some reason, I found it kinda difficult to download - for some reason, I didn’t try to just copy the text. 
could u upload the blend of what u have so far?
*** Moderation ***
moved from Game Engine Support and Discussion
*** End of Moderation ***
cool thanks!