Does anyone have an idea how I can generate infinite blocks as a floor?

This is a READ-ONLY snapshot of the Godot Community Forums when TwistedTwigleg was the owner, which is hosted for archival reasons only. The current Godot Community Forums can be found here.

Some links may point to external websites, including the current Godot Community Forums. These websites are not associated with TwistedTwigleg.

Does anyone have an idea how I can generate infinite blocks as a floor?

Container

Hi,

I would like to have an infinite floor, and my idea would be to just place blocks as far as the eye can see and delete blocks where you can't see anymore. Only unfortunately I have no idea how to implement this. Does anyone have an idea?

(In Godot 4 Beta)

cybereality

I like to create a floor that is double the visible distance, with 2 areas that are the same. Then when you get close to the center, it snaps the position of the whole floor to plus half the size of the floor. This works well when you are moving in one direction (like an infinite runner). This way there is no creation/deletion, which can cause hiccups with the frame rate.

Pixophir

Well, I have an idea, but it is more involved and I am not sure if it can be done in GDScript (can fit into the scene tree), and even if it is a solution to your question which might be asking something much simpler.

Here's a sketch, interpreting "inifnite" as very big (tens or hundreds of thousands of units along sides), because infinite is such a lonely word, and that "blocks" means tiles of some extent that fit together to form a larger floor.

What's needed ?

Either store the data on disk, or generate it on the fly.
This depends on what type of data there is, and what it represents. Need more info.
A data structure to choose from.
Usually a tree structure that can easily and fast be traversed and chosen from. But can also be a linear structure if there aren't too many "blocks" = tiles.
A mechanism to determine what's currently visible to the camera.
This is called frustum culling. The frustum is the volume of the viewing field of the camera. Leaves from the tree data structure (more precise bounding volumes) are checked against the frustum each frame to determine if they are visible or not.
A mechanism to locate and load (or generate) relevant data.
Load the resource of what the frustum check has determined, keep it in memory, or drop resources that aren't needed any more. Optional: do this with some foresight.
Optional: Things in a distance don't need the same resolution as nearby things. Speed rendering up with a LOD algorithm (level of detail). Godot has something (new?) built-in, but idk if it fits this case.
Optional: Really huge extents of a floor (think 100.000s of units) will suffer from numerical precision problems very close to the camera. They will jitter. Similar problems will appear with depth range.
Implement a mechanism to keep distances small though the floor is huge. Rendering "relative to eye", that is putting the camera as the centre is one such method, but that is really advanced. Godot does not support this, this is actually where I fear the most that the approach might fail, or a lot of engine programming is necessary, including modifying shader vertex stages.
For the engine: a connection to environment, global illumination, physics, collision, etc., or roll your own physics/collision because I am not sure (yet) if the engine's implementation has the flexibility.

Now, that's the sketch. I am doing this for heightmap terrain in C++ currently, but on and off because I have other things to do. Will take many months to complete.

Container

Sorry, I probably forgot to mention I want to have this in 3D

Pixophir

Yeah, this is a 3D scene. Though in this approach a "floor" has no volume and just one surface that's visible and used to keep things from falling through.

How do you want to "floor" to look like ?

Container

Pixophir Just flat. Boxes with Kenneys prototype textures on them

cybereality

The basic idea I said would work in 3D as well, but the math would be a little more complex. The concept is that you break your level into chunks, which snap together. You could have a library of these pieces (like say 32 differernt variations) or generate them procedurally so they can match at the border. Then initially you load as many as can be seen on screen, let's say for 1km or something. As the player moves, you check the camera viewport (or frustum) and dynamically either remove chunks or load new ones. It's better if you keep a pool and just rearrange them, rather then actually creating/deleting, as this can cause slow down. It depends on your game how large the chucks would be. For a city game they could be a few blocks radius (depending on the detail). If this is a flying game, then maybe the blocks would be a 1km. It depends on the game.

Pixophir

That simplifies things greatly. Have a look at @cybereality 's approach resetting camera position after a while. Also the Godot built-in GridMap, whose limits would have to be explored when approaching "infinity". I am sure that there is a much simpler solution than the one sketched above.