rouncer at January 23rd, 2011 06:58 — #1
if i store my world in 256x256x256 chunks right, and have a paletized 8 bit colour, that means a single plane of voxels 65536x65536 would take 16 gigs to store.
with an 8 bit x position, 8 bit y position, and 8 bit z position, and 8 bit colour.
65536x65536 of these.
so, this is way too big.
I was just about to give up, when I just realized, hey, what if i just store the world in slats of voxels on disk, then just store the 8 bit colour, then i could get it to around a quarter of the size!
So, my idea is for every 256x256x256 chunk, to store a flat plane instead of storing every individual voxel, i store a start position and an x length, y length and z length, and use the x and z lengths to make the plane instead of using points for every single location.
that means cube like shapes store really easily, but angled shapes sorta store in slits.
Could anyone take the compression further than this?
I realize I probably could then runlength encode the colour data too, or maybe even use some kind of lossy compression.
tobeythorn at January 23rd, 2011 14:11 — #2
Your ideas seems pretty cool so far. If I'm understanding correctly, you would store a 256\\^3 block as the volume of a plain intersecting a cube (assuming the block is solid and mostly planar?).
Here's one thing that comes to mind (I've never actually worked with voxels before so take with grain of salt). This wouldn't save you any disk space (is that your goal?), but would be useful cutting down on collision detections and rendering:
What about having level of detail substitutes for voxels, stored as a binary tree. You would have the level individual voxels, then you could calculate a 2x2x2 level represented as one bigger cube if sufficiently far from the camera. Then you would have the 4x4x4 level represented by one bigger cube if even farther from the camera. And so on. Then you could just load the parts of the world at the detail you would need as you need it.
Have you read GPU Gems 3. There's a cool chapter in there that I believe uses voxels:
Chapter 1: Generating Complex Procedural Terrains Using the GPU
Ryan Geiss, NVIDIA Corporation
rouncer at January 24th, 2011 09:58 — #3
Thanks for the reply.
Ill keep the idea to this at first, to keep things simple... then if I need to compress more later ill wait till then... ive got more things to do than just this at the moment.
That link is amazing!!! I hope to get something similar! Except mine wont be procedural, itll be 100% stored uniquely on disk.
I do have a chunk selection system very similar to what you suggested (And is in the link) already... really far chunks just zap off disk onto the screen in big hits, cause the voxels themselves are really large that far from the camera.
I just do it in hits of 256\\^3, instead of individually, which [individually] actually could be better? Ill think about it.