Re: [Opde-devel] Getting it straight

[Filip V. <f.v...@ce...>]

Hi!

Exactly.

this is what I found out too. I'm starting to think that there is no PV=
S at all, and the renderer thus must be very optimised.

Yesterday, I found out that the last 16 bytes of cell's header is Bound=
ing sphere of that cell. I will have to look more into dynamic PVS gene=
ration, or something close to this. It must have something to do with t=
he visibility tests.

I guess we could make a speed up if we tested the cell's bounding spher=
e to the view frustum first, but maybe not. The main problem is that mu=
ltiple portals lead from cell A to cell B in some cases, and the proble=
m that I can see a cell through two paths (when there are cells beyond =
this target one). If these weren't true, we could mark the visited cell=
s, doing them only once per frame.=20

The polygon cutting is the most expensive routine in the rendering proc=
ess. It does take ~600ms to render one frame in some cases (for example=
 the first mission of thief2, looking from the tunel near starting poin=
t).

4 -> I didn't know that. It seems to clear out things a bit. I allways =
wondered why dromed creates 4 polys per one face on the basic 16x16x16 =
cube... Does that help us with the UV shift problem? I can't put the pi=
eces of the puzzle together right now...

I'll have to study the rendering algorithms a bit  I guess...

Dromed is very unstable, that's true, I sometimes can't even save the e=
dits I've done (I found out that using text commands works better and s=
eems more stable). I guess we could start a dromed replacing project if=
 we'll find out the rest of the data structures... But let's finish opd=
e before, shall we? :)

I'm sending a copy of this mail to the opde-devel, to have an archive o=
f the discussion on the right place...

Bye,
=46ilip
_____________________________________________________________
> Od: gea...@co...
> Komu: Filip Volejnik <f.v...@ce...>
> Datum: 20.07.2006 01:51
> P=F8edm=ECt: Getting it straight
>
>Hi Filip,
>
>I've been chipping away at the WR chunk, trying to get what we know
straight in my head. So far, what I've figured out is that:
>
>1. Each "object" in the WR is a cell. This cell (or, as I've learned f=
rom
HL2 mapping, a "leaf") is a convex area of space, defined by a number o=
f
planes.
>
>2. Each plane holds a number of polys, which hold the actual render da=
ta.
>
>3. A poly which intersects another cell is not drawn and is turned int=
o a
portal by dromed. These portals help determine what cells are visible a=
t
any given time. The way I figure it works is that any portal visible to
the camera though the current cell's portals will cause the seen portal=
's
cell to be drawn. This recurses though all visible cells. This may be w=
hy
we haven't found a PVS, it may be generated realtime.
>
>4. The texturing of polys is restricted to the range of 0-255 for u an=
d
v. Any texture repeats 0< or > 255 on any given plane are created by
surface subdivision. This subdivision seems to crash dromed if more tha=
n
255 polys are generated per cell. As I play around with dromed, I can g=
et
it to crash quite regularly. (You know what, we should forget about
replacing the dark engine and instead write a replacement for dromed. W=
e
would be adored by all. ;) )
>
>
>So, any additional info I've missed or am wrong about, I'd like to hea=
r
it.
>
>Thanks,
>Joe
>