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 🤔
also i could only store visible faces to reduce storage, since at distance you don't exactly need to know about blocks that are inside walls
Questa voce è stata modificata (2 settimane fa)
Matthew likes this.
cuddle puddle
in reply to Eniko Fox • • •Eniko Fox
in reply to cuddle puddle • • •Oblomov
in reply to Eniko Fox • • •Eniko Fox
in reply to Oblomov • • •Eniko Fox
in reply to Eniko Fox • • •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 (nap pet) 🦊💤
in reply to Eniko Fox • • •Gabriele Svelto
in reply to Efi (nap pet) 🦊💤 • • •Josh Simmons
in reply to Gabriele Svelto • • •Efi (nap pet) 🦊💤
in reply to Josh Simmons • • •Doug Binks
in reply to Efi (nap pet) 🦊💤 • • •@efi @dotstdy @gabrielesvelto 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 Fox
in reply to Eniko Fox • • •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 Fox
in reply to Eniko Fox • • •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 Fox
in reply to Eniko Fox • • •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 😁
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 Fox
in reply to Eniko Fox • • •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
AL Wyvern
in reply to Eniko Fox • • •Eniko Fox
in reply to AL Wyvern • • •