Jump to content
  • Advertisement
Sign in to follow this  
Bombshell93

Voxels Dos? Donts? Implimentations?

This topic is 2506 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Okay to put it simple, I want to experiment with voxel based rendering.
I've done mild research on voxel-based rendering before but nothing to heavy.
I'd just like to know if there are any simple mistakes I'm likely to make that I could avoid?

I'm also unsure on any papers about implementations, what has worked best? what has looked best? what is genuinely interesting? That sort of stuff.

So far all I have is a concept on storing Voxels.
first a bool and a number, true = voxel, false = blank space. The number indicates how long there is still voxel or blank space, Then another series of numbers assuming after the length of each number voxel turns to blank space and visa versa.
As well as an octree structure using this same system for the world to allow faster culling of objects.
The main problem I see with this is different colours will require another storage, but I may think of a better way of approaching that later.

EDIT:
okay, so I've got how I want to store the voxels. a bitwise octree structure with the bottom elements being chunks of RLE marked with an enumerable identifying the type of chunk (only 1 material? colour switching RLE? material switching RLE? or others in case I want to play with other compression techniques.) to allow dynamic compression and precision of the objects and world.
The issue I'm having is in the octree part. how would I safely approach a class within itself? so I can control the resolution of the octree structure, elements within elements until the bottom element where elelments are replaced with the chunk.
I'm assuming this can be done with a void pointer and a value to tell anything using the object what its pointing to (an array of elements or a chunk)

Any and all help appreciated,
Thanks in advanced,
Bombshell

Share this post


Link to post
Share on other sites
Advertisement
As far as storage is concerned a bool is 8 bits, so you should consider using a tightly packed format. Conveniently, 8 bits is awesome for octrees - 8 bits indicating the presence of child nodes in the tree. As far as colour is concerned, you could have a 2nd tree that denotes whether the child has a colour variation from the parent.

Share this post


Link to post
Share on other sites
8 bits!? so a bool is a byte? I figured with it being true or false it'd only need 1-bit? what are the other 7-bits used for?
unless I'm misunderstanding and 8 bits is the minimum that can be reserved, I could understand when computing but I figured memory would allow tighter packing.
back on subject if 8-bits is minimum reserve for memory and or disk I will make an octree system then.
On the subject of colour thats the kind of Idea I'd go for, low precision colour values per element, by time you get to the bottom elements you've got a precise colour value.

Share this post


Link to post
Share on other sites
When doing a not-false check on a bool, any of the bits can be 1. If you explicitly check (boolval == true) then it will only pass if the 1st bit is 1 and all other bits are 0.
This is why its not a good idea to cast an int to a bool.
The reason for it is mostly to do with type alignment. In C / C++ type sizes are only ever measured in bytes, not bits.

Yeah, doing a delta encode of the colour would allow you to get quite precise as you approach the leaf nodes.

Share this post


Link to post
Share on other sites
I wrote an article on voxel terrain here. It's primarily taling about smooth voxel terrain (through Marching Cubes) but much of it is directly applicable to 'cubic' voxels as well (e.g. Minecraft, Voxatron, etc).

I also have a library here which can handle a lot of the details for you (both smooth and cubic meshes supported).

Share this post


Link to post
Share on other sites
thanks,
I notice you store values quite heavily per voxel. Lets say I want it to be flexible with its resolutions. On the subject of data structures, would it be worth holding the Material ID in 4-bits allowing 16 Materials local to the container. Have voxels held in 4-byte structures at the bottom of an octree. I'm sure if I work it right I could have it scale bits to Materials too. E.G. if a container only has 1 material, 1-bit per voxel. using bitwise operations of course.

Still wanting to keep as much out of memory as possible, would it be a stretch to only load in lower elements as you read them? freeing up and reusing memory as it goes along?
I'm thinking on a scale of 2048 cubed. if used purely graphicly, that should cover a nicely detailed object around the camera, but of coarse even if 1-bit per voxel it would work out as a GB of memory (not taking into account the memory used for the octrees and material data).

Share this post


Link to post
Share on other sites
With a good compression scheme or format you should be able to have your voxels take up less than a bit of memory depending on how many there are. This will depend on how good your voxel format is. An ideal format would use less memory per voxel the more there are. There shouldn't be any per voxel data stored, not even a bit.

Share this post


Link to post
Share on other sites
thats the idea behind my original idea, size depends on complexity rather than density. I suppose I could mix that with an octree system to eliminate blank space.
basicly each number marks how long the blank space lasts or how long the voxels last, scan-line of coarse so you don't need a new set of numbers for each Z or Y (assuming X is the direction for scanning)

Do you think this would work? only when there are very thin objects with small spaces between each other would it work out less effective than a bit per voxel.
I could use different integer types for different scales of object. I could even use bitwise operations to mark the numbers true = 16-bit and false = 8-bit as long as I store them all in a byte array, so I don't have to have a massive gathering of pointers.

Share this post


Link to post
Share on other sites

8 bits!? so a bool is a byte? I figured with it being true or false it'd only need 1-bit?


Smallest addressable unit is a byte. So a boolean value may be represented with a byte. BOOL however may be 32 or 64 bits.

what are the other 7-bits used for?[/quote]

In C and C++, bool is false if the value is 0. It's true for any other value.

For manipulation of individual values, a single bool must be loaded into register, which is may require access to 64 bytes of memory at worst. Smallest supported unit that can be manipulated in register on x86 is a byte, so having a single bit doesn't really change anything.

Usualy solution is to represent 8 voxels in a byte. Or, represent a cube of 4x4x4 voxels in 64 bits or 8 bytes or 1 register on 64-bit machine.


Of course, none of that matters much, since true/false voxel space isn't going to be interesting, unless it's done per-material. For example, you have one voxel space for rock, one for water, one for ....

Instead, it's better to define voxel as a byte that can have 256 distinct values. 0 can then be empty space.

Share this post


Link to post
Share on other sites
What you're describing is run length encoding, which I've heard of some voxel engines using... I think voxlap used some form of it. That's one of the few successful voxel engines I've seen, so maybe it would be a good idea to use RLE, but there's also other compression methods and formats that could work too.

If you want low memory voxels, search around for different compression methods and see if you can find one that can work with how you want to render your voxels.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!