I'm interested in raytracing/casting voxels, and I noticed that people usually only talk about giving the voxels color attributes, and sometimes normals. It seems to me that along with color and normals you would also need specular and glossiness values, maybe even full color specular and other values if you wanted a full range of materials. Yet I haven't seen these talked about in regard to voxel rendering. Also, I imagine that even with sparse data sets this would add up very quickly.
1
Voxel attributes
Started by Chris_F, Dec 14 2011 08:59 AM
10 replies to this topic
Ad:
#4 Senior Moderators - Reputation: 4722
Posted 14 December 2011 - 10:10 AM
Sure, but voxels are already infeasible for most games, even without storing a bunch of per-voxel dataI thought about that, but the lack of specular variance would make for dull images I think. Maybe sufficient for a simple Stanford bunny demo, but for a game?
If you are using a sparse-octree representation, it isn't necessary to attach specularity data to every voxel. You can integrate it with the octree to store specularity with the highest common ancestor - that will give you decent compression, except in areas where the specularity is badly stippled.
Tristam MacDonald - SDE @ Amazon - swiftcoding [Need to sync your files via the cloud? | Need affordable web hosting?]
#5 Members - Reputation: 743
Posted 14 December 2011 - 10:36 AM
Sure, but voxels are already infeasible for most games, even without storing a bunch of per-voxel data
This research isn't for a game that will be released tomorrow. I'm forward thinking.
How would SVO compare, memory wise, to things like sparse virtual textures, which are already in use?
#6 Moderators - Reputation: 3960
Posted 14 December 2011 - 10:43 AM
I thought about that, but the lack of specular variance would make for dull images I think. Maybe sufficient for a simple Stanford bunny demo, but for a game?
eh?
If you used a byte to store the 8 then you could have 256 materials with 256 different specular values. Go up to 16bit and you have 65k materials open to you.
In short; what are you talking about willis?
#7 Members - Reputation: 743
Posted 14 December 2011 - 12:09 PM
I thought about that, but the lack of specular variance would make for dull images I think. Maybe sufficient for a simple Stanford bunny demo, but for a game?
eh?
If you used a byte to store the 8 then you could have 256 materials with 256 different specular values. Go up to 16bit and you have 65k materials open to you.
In short; what are you talking about willis?
256 unique materials. Yeah, you could use up all of those with 256 unique specular values, but there are potentially other attribute values you'd want too. It's like comparing a 256 color GIF to a 24-bit PNG.
#10 Members - Reputation: 244
Posted 15 December 2011 - 01:09 AM
Voxels!!! Yes, I love this subject!
Im writing an engine right now, its just about feesable, Id say next generation of video cards and itll be ok to go for it, ive got really good detail going and its running fairly ok on my gtx480, im still working on my geometry tools, havent got up to materials yet.
Equal detail to megatexture, its about 8 times worse, stream speed and store amount... my own approximation.
Im really proud of mine, im going in geometry tools first, so its like making zbrush or rather 3dcoat modeller except it goes for the precision of floating point numbers in all directions, so its pretty cool.
id say a byte accessing a material table would be the way to go, like whats been said already - but remember 20 gigs at least for the finished environment/terrain compressed to utter hell, thats unfortunately the case for voxels... thats the main problem, everything else will remedy itself the next couple of years, actually getting started now isnt a bad idea!
(screenshot is screen space calculated normals, no normals are stored as of yet, but should be if you want to hide the blockiness to an acceptable level)
Another problem is if you want to animate, rigid animation is fine, just softbody animation means the cubes are going to have to bend somehow to get it to happen, its really cutting edge theory, i bet its possible tho.
Im writing an engine right now, its just about feesable, Id say next generation of video cards and itll be ok to go for it, ive got really good detail going and its running fairly ok on my gtx480, im still working on my geometry tools, havent got up to materials yet.
Equal detail to megatexture, its about 8 times worse, stream speed and store amount... my own approximation.
Im really proud of mine, im going in geometry tools first, so its like making zbrush or rather 3dcoat modeller except it goes for the precision of floating point numbers in all directions, so its pretty cool.
id say a byte accessing a material table would be the way to go, like whats been said already - but remember 20 gigs at least for the finished environment/terrain compressed to utter hell, thats unfortunately the case for voxels... thats the main problem, everything else will remedy itself the next couple of years, actually getting started now isnt a bad idea!
(screenshot is screen space calculated normals, no normals are stored as of yet, but should be if you want to hide the blockiness to an acceptable level)
Another problem is if you want to animate, rigid animation is fine, just softbody animation means the cubes are going to have to bend somehow to get it to happen, its really cutting edge theory, i bet its possible tho.
#11 Moderators - Reputation: 13458
Posted 15 December 2011 - 01:16 AM
Physically speaking, the "specular mask" (index of refraction) value is roughly constant within any one type of material, while the "specular power" (glossiness) value is a measure of the variance of the normals at a sub-pixel level (this value wouldn't be needed in "regular" renderers if our normal-map resolutions were high enough).
So if you've got an awesomely detailed hierarchical voxel representation, you don't need "specular power" at all (as long as your hierarchy can tell you the variance of the normals below any node), and you don't need "specular mask" if you know what type of material it is.
Also, you don't need full colour specular except for materials that are conductors, and fortunately, conductors happen to always have an albedo of zero -- so you can use your regular albedo colour storage area to store their multi-spectral specular mask (IOR) value.
Regarding the "only 256 material types" thing -- instead of thinking of this as a GIF with 256 colours in it's palette you can also think of it as an array of 256 materials, each of which could consist of several layered 1024x1024 textures at 32bpp. The voxel can index this array, and then you can derive UV coordinates from the voxel's position.
The only problem with using bytes to index material types, is they don't interpolate or average into a hierarchy.
e.g. if mat#0 is rock, mat#1 is grass and mat#2 is sand, then a node that has two 'rock' children and two 'sand' children will average towards the value of 'grass', which makes no sense.
N.B. This technique was used in the STALKER series of games including the ability to interpolate material-ID values -- they worked around it by carefully arranging their materials in a particular order where this "invalid" interpolation looked good!
So if you've got an awesomely detailed hierarchical voxel representation, you don't need "specular power" at all (as long as your hierarchy can tell you the variance of the normals below any node), and you don't need "specular mask" if you know what type of material it is.
Also, you don't need full colour specular except for materials that are conductors, and fortunately, conductors happen to always have an albedo of zero -- so you can use your regular albedo colour storage area to store their multi-spectral specular mask (IOR) value.
Regarding the "only 256 material types" thing -- instead of thinking of this as a GIF with 256 colours in it's palette you can also think of it as an array of 256 materials, each of which could consist of several layered 1024x1024 textures at 32bpp. The voxel can index this array, and then you can derive UV coordinates from the voxel's position.
The only problem with using bytes to index material types, is they don't interpolate or average into a hierarchy.
e.g. if mat#0 is rock, mat#1 is grass and mat#2 is sand, then a node that has two 'rock' children and two 'sand' children will average towards the value of 'grass', which makes no sense.
N.B. This technique was used in the STALKER series of games including the ability to interpolate material-ID values -- they worked around it by carefully arranging their materials in a particular order where this "invalid" interpolation looked good!
