id Tech 6 preview

A

AirRaid

id showed a short technology demo of the new idtech 6 to german
magazine gamestar. id is experimenting with Voxel/Raytracing graphics:

http://g.imagehost.org/0501/800x6001_prop.jpg
http://g.imagehost.org/0555/800x6002_prop.jpg
http://g.imagehost.org/0202/800x6003_prop.jpg
http://g.imagehost.org/0318/800x6005_prop.jpg
http://g.imagehost.org/0341/800x6006_prop.jpg
http://g.imagehost.org/0341/800x6006_prop.jpg
http://g.imagehost.org/0087/800x6007_prop.jpg

short video of the technology demo running at 60 fps on a Geforce GTX
280 on page 3
german: http://www.gamestar.de/hardware/specials/1956284/neue_id_software_engine_mit_voxel_grafik.html

auto translation:
http://de.babelfish.yahoo.com/trans...oxel_grafik.html&lp=de_en&btnTrUrl=Übersetzen

 
S

Skybuck Flying

Here is an idea how to do the transformations/animations:

Make a skeleton/stick figure/model for the monster.

Pre-calculate where all bounding/octree boxes are on skeleton stick figure.

Then when the stick figure animates... rotate the main octree boxes first.

Then when the rays enter the rotated boxes figure out which other boxes to
rotate as well... and rotate them.

This is why I would call this "dynamic-rotation".

The rotation is done as the scene is rendered.

This should prevent having to rotate/transform every voxel.

Untested idea but might work ! ;)

Bye,
Skybuck.
 
S

Skybuck Flying

Another approach to save a lot of rotations could be something like this:

The character is made up of boxes like arms, legs torso etc.

Each piece is a voxel-box. With possibly an octree inside of it containing
the model details.

Optionally these boxes could be connected with stick figure/joints but it's
not really required.

Now instead of rotating all voxels... instead only the boxes could be
rotated... then the entry point of the ray is calculated and then "rotated"
to align with the original box position which matches the voxel data.

This would illiminate a whole lot of rotations.

For the lightning every voxel that has been hit by a screen ray the light
calculations are done.

A ray is shot towards each light and the ray is traversed across all octrees
or whatever and those are entered as well to see if any other voxel obscures
the light be it fully or partially... this could influence the light. Maybe
surrounding voxels could be inspected as well for my shading information.

Alternatively multiple light points like a disc of light could be used to
create better looking shadow (?).

To speed up the tracing of the screen rays... for each bounding box it's
checked against some screen cone... if it cuts each other then it could be
part of the screen... so it must be checked/entered. This could become quite
expensive if there are many of these in the screen.

Some kind of sorting would be nice... maybe some bsp or grid traversing of
the bounding boxes.

This could be done the easy way of having simply space divided into a
grid... or maybe even octree...

Or maybe it could be done in a strange kind of perspective way... so that
everything falls into "screen-ray-cones"...

That last thing would be quite cool and maybe usefull.

This could prevent unnecesary processing of objects which happens to fall
outside of the ray cone... maybe a bit unlikely... so maybe not worth it.

The moral of the story:

1. If unlimited processing power is available then doing voxels is easy.

But more realistically:

2. If limited processing power available then things can become quite
complex real fast too ;) :)

Bye,
Skybuck.
 
S

Skybuck Flying

Also did you know that the game x-com: ufo enemy unknown actually uses
voxels ?

I know it sounds unbelievable... but this old dos game actually really used
3 dimensions voxels ?!

And you know what:

It used it for "laser/bullit" detection on the sprites.

Or maybe it was just 2d... but then that wouldn't be a true voxel would it ?
;)

I think it really was 3D after all because it could tell if you were hit in
the arms head... or what not... and the lasers came from all sides and
directions...

(And I can remember seeing the images.. slice by slice ;))

A little interesting thingy:

1. This was just done for bullit/laser detection.

2. It was probably a "lower resolution version" of the actual sprites...
like bounding boxes... but now voxel style.

That's kinda interesting...

This could be interesting for games too...

For example for physics part of the game...

When the bullits or shot and the lasers fired... then the game could go
into:

"laser/bullit" resolve mode...

Where a highly compressed form of hit detection is done to speed things up.

Color information and all that stuff is not needed...

Just a 1 or a 0 to indicate if something was there yes or no...

Here again it could be scaled down... because do you really need voxel
precision for bullits/lasers ?

You might get away with an approximation... just like x-com did.

So I think here are good lessons to learn from x-com ! ;)

The point is that reducing the ammount of information could be could for
bandwidth/cpu/gpu cache and all that stuff.

Bye,
Skybuck.
 
Top