just realized.

[eniko@mastodon.gamedev.place]

just realized. since block game's terrain is going to be finite*, i could conceivably solve the distant terrain issue by simply slowly generating all of the chunks (and LoDs) in the background over time 🤔

[cuddle_puddle@mastodon.catgirl.cloud]

@eniko@mastodon.gamedev.place will there be storage size concerns from this? (idk how small of a finite world you intend)

[eniko@mastodon.gamedev.place]

@cuddle_puddle what do you mean by storage size concerns exactly?

[oblomov@sociale.network]

@eniko @cuddle_puddle I was going to ask the same thing: how “finite” would the terrain be and how much storage is required for the whole world? Hundreds of megabytes? Several gigabytes?

[eniko@mastodon.gamedev.place]

did some experimenting and based on the current terrain if i bitpack it and then gzip compress it, a chunk averages 170 bytes, so i could store a world with 1024x1024 chunks (or 16,000 by 16,000 blocks) in 2.5 gigs at full resolution

or a world the size of gta5's map (5120 chunks squared) in 66 gigs

that's not bad at all tbh given that isn't occlusion culling underground chunks and is at full level of detail

[efi@chitter.xyz]

@eniko sparse octrees to the rescue?

[gabrielesvelto@mas.to]

@efi @eniko yeah, sparse octrees FTW

[dotstdy@mastodon.social]

@gabrielesvelto @efi @eniko I think sparse octrees are probably overkill compared to just rle on your chunks.

[efi@chitter.xyz]

@dotstdy @gabrielesvelto @eniko it would be overkill if there weren't libraries providing it already for free

[dougbinks@mastodon.gamedev.place]

@efi @dotstdy @gabrielesvelto @eniko In my experience for a file format bitpacking + RLE + compression will get you about as efficient storage as an SVO unless you also use some form of deduplication with an SVODAG, preferably symmetry aware.

The advantage of an SVO in my view is more for in-memory use, ray-casting etc, and chunking can reduce those benefits.