firstly I gotta post the standart shit...
I'm not responsible for any damage...blah blah
I tend to write anyhing in small letters as I'm lazy and as I'm used to it
from chatting
(my ICQ is 18468966 contact me if ya like...preferably if you got a job for
me... :)
and I'm german...so don't bother me with grammer mistakes...many ppl said my
english is ok..
my english teacher highly disagrees...I dunno..
argh..who's gonna read that anyway...

I code basically 3d engines..and anything else you might need to make some
game...

In the last 2 years I spended coding some indoor/true outdoor portal and
heightfield based environment engine
which also features hierachically bones animated objects,chrome+lightmapping
and much other shit...
look at www.ethos.cx for some shots+demo..thought it's outdated...I'm not
responsible for updating it...

lately I started coding some wingcomander like space sim for exilesoft...
they offered me some neat job in the us..but I gotta finish school
first..sadly..

anyhow..

the basic topic of my techfile wil be algos dealing with implementation of
3d rendering for hardware based rendering...

I see no real future for software...
who has an old lame cpu (as me..p133) has to buy a 3d card to have any
chance for reasonable framerates..
and if ya bought some newer pc lately it probably has a 3dcard included
anyway..and if not you should also buy
some 3d card..as it is faster and looks better..ad the 75bucks for a
voodoo1(my card)

and there have been many egs for softrenderers around...we don't need
another one..
well..I actually wrote some softrenderer some time ago..it was slow but
interesting to learn from...

Everything I post here is far from being perfect (probably) and maybe I
wrote it in the lae evening...
so don't flame me..I won't flame you either...
any comments or quests are welcome...send em to softcore@t-online.de

the first api I used was directx..but that was in executebuffer time..
so I switched to glide fastly...
it is my favourite one..at least for useability
sadly it is doomed to die out...
3dfx's strange politics...and the bad circimstance that M$'s win is the
leading system and that dx supports all cards lead to this...
I doubt M$ will learn from em..too bad...

I'm rather common to all 3 raster apis so I'll post egs and code snips in
c++ and the api it was originally made in

I sended some landscape/particle demo to Lionhead and they were realy
impressed...so I guess that might be interesting to some ppl...
I'll assume standart 3d maths knowledge..and I won't use matrices...

Landscape
The landscape renderer draws up to 300.000 trias/sec on my p133 with voodoo1
which is actually nice...

the idea is reather simple and derivered from voxels(somehow)...

I load some grayscale image representing the heights...
then I create some kinda linked list...

a part (the landscape is devided into rectangular parts)
looks about like this:

struct LandScape
{
BYTE * heightfield;//guesss what
WORD LeadId[4];//contains the indices of the lanscape parts
touching this part in North(=[0]),
Est,South and West
}

The render func has to know in which landscape the player actually is...
then it starts by rotating (to viewpos) ONLY the edges of the actual
landscape

Let'S say the rotated Edges are Rot_Edges[4];

//Rot_Edges[0]=upper left
//Rot_Edges[1]=upper right
//Rot_Edges[2]=lower left
//Rot_Edges[3]=lower right

Now we can adress every point of the heigtefield(in viewpos)
by adding the VLeft and VDown to the Rot_Edges[0];

eg:

Vector pos=Rot_Edges[0]+VLeft*5+VDown*4;

pos now has the value which is corresponding to the
heightfield[5][4](grayscale)
but in viewpos...

as you see you save the rotations for all points(but the 4 edges) no matter
how many points these are..

but yet it would be flat..we need to add the height...
so we add (heightfield[5][4]*UpVector) to pos and store that for every
vertex in a cache...
you can make the res of the heightfield rather high as you can very simply
add LOD to this..or you can easily make
it render the tris back to front r other way around...as well as you have
easily stripes

certainly we do start rendering at the row whiches zvalue is closest to
us...
we don't want trias behind us...
alse we stop rendering if the act row's z value is smaller 0 (behind us) and
both VLeft.z and VDown.z are smaller 0//we'll never get positive again
analog for similar cases...(row reached right screenborder and VLeft.x>0)

now we rendered this actual heightfield..but the the parts touching this
part are missing...
so we simply check weather the northern edge of this actual landscape is not
cliped away fully..
if that is the case that part has to be render either...
you can do that recursive as well as with some stack...
set some max renderdepth and be shure not to render parts several times...as
two parts you render might lead to the same also visible part..mark that
somehow the heightfield can be easily changed so holes in the scape due to
explosions are no prob..(in realtime)
for me vetex shading was enough..as it is outdoor only...
save the second pass for detail map or maybe some texmixing methos to avoid
doubled texs... I avoided it by having one unique 256*256 texmap per part...
not the nicest way but rather fast...blurryness of close polys is
acceptable...

at my homepage (www.ethos.cx) you can see some shots how that looks...I
guess the vulcano pic will still be there..

Particles
I was talking about that vulcano...what is a vulcane without erruption....
boring...

this is rather forwad + easy but many ppl were very impressed....
so I'm gonna describe it...

This document may not be reproduced in any way without
explicit permission from the author and flipCode. All Rights Reserved.
Best viewed at a high resolution.
The views expressed in this document are the views of the author and NOT neccesarily of anyone
else associated with flipCode.