Combining 6 height fields to describe a volume

[Skybuck Flying]

Hello,

To save memory requirements and also some computation requirements the
following idea could be interesting:

Instead of describing a volume with voxels in full 3D, instead 6 height
fields are used.

The volume is like a box/cube, it has 6 sides.

Each side receives a height field.

This reminds me a little bit of the Terminator 2 technique were cube mapping
was used to make the terminator shiny (?!?).

Instead the height fields describe from their perspective/side how deep the
first voxel is.

By combining 6 height fields and applieing some logic it should be possible
to determine if a voxel is present or not at a certain coordinate by
simplieing examining all 6 height fields.

The height fields work or could work like "boolean operations".

If any of the height fields "overrule" the others than that's what happens,
it gets overruled.

For example the rule could be: if one of the six height fields indicates
that the voxel is empty/hull/transparent then that's what it should be, it
overrules all others.

By coming these 6 height fields the volume could also have some gaps here
and there, so it doesn't necessarily have to be a shell only.

For visualization purposes these height fields could also be overlayed with
texture fields/maps.

For example if the height fields/volume is turned/visualized into 3D
boxes/pixels/voxels then each voxel/box's side could receive a color from
one of the height fields.

Additional logic could be used to indicate if a certain height field is to
be used yes or no. For example the back and the front height/texture fields
could be used for front and back panel of the box. Depending on surrounding
voxels or logic a certain choice could be made to make it more visually
pleasing and could be experimented with.

Also some smoothing of voxels/boxes could occur if they are within a certain
color range which could be considered part of the same material/sub object,
perhaps even normals could be calculated from it to smooth it even further.

A special c/c++ or delphi oo class could be made which simply queries the
object/volume to know if a certain coordinate has a voxel yes or no and what
it's color could be.

To the user the object appears as if it was a volume, but inside it simply
queries the height fields + some logic to come to a conclusion/decision.

I myself don't really have a good working ray tracing engine or volume
rendering engine, so these ideas have little value to me but they could be
interesting to others.

I'm also quite tired *sigh* and might not have the energy or time to spent
on researching this further, but perhaps this idea could inspire others to
give it a try.

Perhaps I might try myself as well ;)

The hope is that this might bring "volume rendering" for games a step closer
;)

Bye,
Skybuck.

[Skybuck Flying]

If this is indeed a new technique/idea then perhaps it could be called:
"volume side mapping" a sort of spin on "cube mapping" ;)

Bye,
Skybuck.

[Nicolas Bonneel]

Le 26/12/2011 11:11, Skybuck Flying a écrit :
> If this is indeed a new technique/idea then perhaps it could be called:
> "volume side mapping" a sort of spin on "cube mapping" ;)
>

if you really care about the true volume (ie., not an exterior surface),
then you need much more than 6. You can then apply a tomography problem
(like a Radon transform) to get the volume from the N projections.
Hoping to transform a 3D problem to 6 2D problems is somewhat naive.

PS: why posting that to nvidia or delphi ng ?

[Skybuck Flying]

This idea is ment for the "exterior surface".

It offers an alternative to triangles/meshes/polygons which usually describe
game objects.

The adventage of this voxel-like approach could be:

1. Somewhat more easy construction of 3D objects by drawing 2D pictures by
2D artists.

This reminds me of 3D Studio 4.0 extrude/lofter feature with 2D shaper and
in 3D shaper/lofter (F2 !?).

2. Potentially quick ray traversing through the volume to detect
collisions/intersections.

The balance is:

Intersecting the ray with each box versus traversing the ray through voxel
space.

If the volume has more filled voxels than it takes voxels to traverse to hit
voxel, then the traverse approach should be quicker than trying to intersect
the ray with each filled voxel.

3. Reduced memory consumption, those more characters/objects/spaceships/etc
can be stored in graphics memory if using cuda for traversing for example.

4. Even further reduced memory consumption versus storing
boxes/triangles/indices/polygons/verteces etc.

5. Potentially more efficient computations versus octree, perhaps octrees
are slower. No traversing of octrees is needed to query individual
coordinates. Querieing individual coordinates is reduced to 3 or 6 lookup
operations, also very consistent performance.

6. Clipping rays to the volume box to skip having to traverse the entire ray
through space offers more performance gains.

I wouldn't call this idea naïve, on the contrary, using 3D volumes to
describe exterior surfaces would be naïve.

This idea is pretty smart to conserve memory and computations.

This idea could be accelerated by nvidia cuda, and a prototype could be
created in Delphi.

This idea could perhaps even be implemented in fixed function hardware for
even more acceleration ?

Bye,
Skybuck.