|
|
| Post Number: 1
|
Silicone_Milk 
Group: Member *
Posts: 390
Joined: May 2006
|
 |
Posted on: Jul. 05 2009,10:40 |
|
   |
Over the past few months, along with the other ideas that have been floating around in my head, I've been playing with voxels on paper.
I just had an idea concerning voxels that I wanted to get written down somewhere where I wouldn't lose it.
The idea:
Let's say we have an octree consisting of a Root and 8 children nodes.
Each child node contains a voxel grid of lets say... 256 x 256 x 256 voxels. This can be quite costly if we allocated at most, 4 bytes per voxel (one integer)
We're looking at ~67108864 bytes. For one node. Of 8 nodes in the tree. That's 64 MB of memory for a single node. Ouch.
That's assuming we store every single voxel in the voxel grid while the node exists.
Now consider storing only the surface area of the voxel grid. The forumla for this would be (((6 * (256 * 256)) * 4) resulting in a total of 1.5 MB of memory per node. I believe this comes out to roughly 2.34% of the original memory footprint.
The concept here is that we don't need to know about the interior of the voxel grid (ignoring physics interactions for a cement block filled mostly with cork or something absurd like that).
When we attack the outside of the voxel grid, we can simply move a voxel towards the center of the grid rather than turning it off to expose the next layer. As the concave shape becomes more complex, more voxels will have to be turned on due to the interior layers not actually existing.
In a nutshell - store only the surface of a voxel object in memory and acquire new voxels where holes would form from damage to the object.
*Note - Treating voxels as entities in the sense of simply moving their position instead of toggling visibility sort of defeats the concept of voxels. They *should* be treated as pixels in the sense that they don't move. They always exist.
This is just a late night thought. Don't read too much in to it.
Back to thinking.
Edited by Silicone_Milk on Jul. 05 2009,19:25
|
 |
|
|
| Post Number: 2
|
carnage
Group: Member *
Posts: 435
Joined: Apr. 2007
|
|
Posted on: Jul. 05 2009,16:18 |
|
 |
an interesting idea. The main problem I can see if you only store the outer layer of voxels is the fact you don't have any data about the colour or material of the inner voxels once you get though the outer layer
You could get round this perhaps by using some kind of default colour/material based on what weapon damaged the surface etc
|
|
|
|
| Post Number: 3
|
Silicone_Milk
Group: Member *
Posts: 390
Joined: May 2006
|
|
Posted on: Jul. 05 2009,19:32 |
|
|
Yes I had thought about the inner material as well. This technique could only really be used for simple objects where
a.) we can assume that the object is a single material type or
b.) we can use a rule set to change material type based on depth into the voxel grid
It should also be possible to implement the voxels in binary form and use some sort of volumetric texture to apply the materials. This could save memory as the texture can be reused as many times as we want without having to store a copy for every object.
If we implemented the geometry as binary we would only need ((6 * (256 * 256)) bits. (48 kilobytes) assuming we store *only* the surface area and simply apply a 3D texture to the voxels.
Storing the entire grid in binary voxel form would be (256 ^ 3) of bits ( 2 megabytes)
I'm debugging my octree code right now (my algorithm is screwed so it's splitting into 4 children after the tree goes about 3 children deep). I'll see how this surface area storage of voxel data works out.
|
|
|
|
| Post Number: 4
|
kat
Admin
Group: Admin
Posts: 1325
Joined: May 2006
|
|
Posted on: Jul. 09 2009,01:10 |
|
|
So how is id tackling the use of Voxels? I've not really looked into it too much but isn't there a lot of talk about idtech 6 using Voxel rendering for world objects? In addition to carnage's comment, isn't the whole point about using voxels that you're creating 'volume' rather than a 'skin'. So, what advantage would a skin of voxels have over polygons and high resolution artwork?
Also what level of detail are you assuming in what you mentioned above (high-res normal map generation type detail or something more akin to a mesh with 20k polygons)? Is it absolutely necessary to have to store that much data? Or could you do some sort of fixed LOD levels or something?
--------------
Admin
|
|
|
|
| Post Number: 5
|
Silicone_Milk
Group: Member *
Posts: 390
Joined: May 2006
|
|
Posted on: Jul. 09 2009,03:16 |
|
|
iD is dealing with voxels using something called a Sparse Voxel Octree. Not really sure how the hell that's supposed to work but basically only physical stuff is stored (air is not stored, etc....)
The point is that current models are rendered with polygons which are surfaces. If you try to dig in to it you either get a hole and the 2-dimensional aspect of the polygon shows, or you have to run an algorithm to subdivide the object and generate more triangles to deform the surface.
Even with a "skin" using voxels, the voxels can be offset to be able to deform the object without having to create new data.
lod is definitely possible and is a strong point of octrees. But with traditional lod methods for polygons several meshes per model need to be created to swap between. The point of lod in a polygonal world is to keep rendering speeds playable. I suppose the concept could be applied to a single voxel model to stream in chunks of the model to render based on where you are in the octree.
Anyways, I've refactored my octree code and it's evolving quite nicely I think. It's templated now so it can contain any sort of data (voxels, polygons, numbers, strings, etc....) I'm just working on reworking the logic of the insertion functions so it stops making unnecessary checks where I can simply "assume the state of" and call it good.
|
|
|
|
| Post Number: 6
|
kat
Admin
Group: Admin
Posts: 1325
Joined: May 2006
|
|
Posted on: Jul. 09 2009,17:13 |
|
|
If I have a voxel cube although the 'volume' of the cube is stored as data, the tech only makes use of what's seen? Is that correct? Its not pulling the numbers for the volume into use all the time despite only the skin being visible?
--------------
Admin
|
|
|
|
| Post Number: 7
|
carnage
Group: Member *
Posts: 435
Joined: Apr. 2007
|
|
Posted on: Jul. 10 2009,00:06 |
|
|
just think of voxels as the logical step for bitmaps to move into 3D, instead of 2D pixels on the screen you have cubes that take up volume of space
the octree idea is that a cube of space can be divieded into 8 smaller cubes of space, like one square pixel can be divideed into four smaller pixels
Because in 3d we account for perspective we cant garantee that one voxel takes up one pixel, a pixel of a distant object could be hundereds or thousands of voxels. The advantage of using the octree is that we only need to go as far down the octree untill we find the smallest relevant voxel (that can be pre defined in colour based on the sub/child voxels)
Combine with the fact that octrees have a very ridgid orgonisation in space its very easy to sort them into a front to back or back to front order for rendering
You can almost think of this optimisation in a similar way to mipmaps on current 2d textures, the graphics card only concerning itself with the smallest relevant texture, no need to render a 1024x1024 image on a triangle only a few screen pixels big
A few hurdels are the fact that this makes it very good for static scapes but moving object can be a challenege, and things like thin wires that may not take up an entire higher up voxel, so as you move away the wire ither becomes much thicker or disapears
you could represent higher voxels that have large amounts of missing/blank child voxels using transparency, but this is of course not compatable with silicones voxel shell idea. Thinking about the transparenty, that method might give something similar to a AA effect if the voxel resolution is high enough
And as you mentioned cat, because we cant see the detail of far of voxel we dont need as many child levels from the octree so you could theoreticaly stream more detailed versions of voxel octrees as you get closer to them, similar to the mega texture
|
|
|
|
| Post Number: 8
|
Silicone_Milk
Group: Member *
Posts: 390
Joined: May 2006
|
|
Posted on: Jul. 25 2009,00:04 |
|
|
Hey so just to let you guys know, although there are no screenshots, I haven't just abandoned this project.
It ties in to other projects I've mentioned in the past and is going to be part of my "experimental suit" (OGRE rendering backend with my various ideas implemented as plugins)
I'm still tweaking the octree code and am also taking a look at kd-trees since the nearest-neighbor lookups are easier to deal with.
Also thinking about implementing a trilinear filter through a pixel shader as a post-process effect to smooth the "pixel" look you get through the use of low-resolution voxel grids.
The voxel research is the most important personal project on my plate right now since implementing a voxel renderer will allow me to play with other ideas I have (remember the procedural terrain/texture thread I wrote?)
|
|
|
|
| Post Number: 9
|
Silicone_Milk
Group: Member *
Posts: 390
Joined: May 2006
|
|
Posted on: Jul. 27 2009,09:46 |
|
|
Ugh..... overflowing the stack.
I'm beginning to dislike C++....
|
|
|
|
| Post Number: 10
|
Silicone_Milk
Group: Member *
Posts: 390
Joined: May 2006
|
|
Posted on: Jul. 28 2009,04:46 |
|
|
Decided to adopt Boost and replaced all the raw pointers with some self-managing smart_pointers.
Stack overflow fixed (was calling an infinitely recursive function (whoops!)).
Seems to be constructing a tree properly but I'm trying to make sense of what I'm seeing (node count is slightly off)
|
|
|
|
|
|
