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.

[eniko@mastodon.gamedev.place]

realized that a safe way to "occlusion" cull chunks for LoD is to just skip any chunk that has no lighting. after all, it doesn't matter if you can look into a cave past the area where it's too dark to see anything

adding that little optimization gets me down to an average of 94 bytes per chunk

that's 1.47 gigs for a 1024x1024 chunk sized map, or 36 gigs for a gta5 sized map

and that's still at full res, so yeah, this'll do

[eniko@mastodon.gamedev.place]

if i fill every unlit non-opaque block with a black opaque block then the average goes down to 85 bytes per chunk

or 1.3 gigs for 1024x1024 chunks and 33 gigs for gta5 size

[eniko@mastodon.gamedev.place]

ohhh, if i flip the axes from xyz to xzy so that columns of blocks are contiguous it compresses a bit better, down to 75 bytes per chunk from 85 :D

or 1.17 gigs for 1024x1024 chunks and 29.3 gigs for gta5 size

and this is still at full resolution. if the first LoD is half the resolution then those would be somewhere south of 600 megs and 14.6 gigs respectively

[eniko@mastodon.gamedev.place]

oh oops i've been doing the gta5 map wrong. i thought it was 80 kilometers along each axis, but it's 80 kilometers squared, or 9 kilometers along each axis, or only 559x559 chunks

apparently botw's world is the same size

so actually full-resolution LoDs for a map that size would only be 357 megabytes. that's... basically nothing

[alwyvern@mastodon.social]

@eniko I sneeze more information than that

[eniko@mastodon.gamedev.place]

@ALWyvern i've seen gifs on kickstarter pages larger than that!