Culling nodes

[Ian]

This is how they are setup

Code: Select all

void __thiscall PRO_Culling_Node::initHWCullingNode(PRO_Culling_Node *this, __int32 a2)
{
  PRO_Culling_Node *v2; // esi@1

  v2 = this;
  if ( *((_DWORD *)this + 29) == 1 )
  {
    PRO_Clear(*(char **)this, 0, a2 + 32);
    **(_DWORD **)v2 |= 0x200u;
    **(_DWORD **)v2 |= 0x100u;
    **(_DWORD **)v2 |= 0x10u;
    **(_DWORD **)v2 = **(_DWORD **)v2 & 0xFFFFFFFE | 2;
    *(_DWORD *)(*(_DWORD *)v2 + 24) |= 0x1000000u;
    *(_DWORD *)(*(_DWORD *)v2 + 8) = PRO_GetIEEEFloat(0, 0);
    *(_DWORD *)(*(_DWORD *)v2 + 12) = PRO_GetIEEEFloat(0, 0);
    *(_DWORD *)(*(_DWORD *)v2 + 16) = PRO_GetIEEEFloat(0, 0);
    *(_DWORD *)(*(_DWORD *)v2 + 28) = (PRO_Get16BitFloat(0x49742400) << 16) | *(_DWORD *)(*(_DWORD *)v2 + 28) & 0xFFFF;
    *(_DWORD *)(*(_DWORD *)v2 + 28) = PRO_Get16BitFloat(0x49742400) & 0xFFFF | *(_DWORD *)(*(_DWORD *)v2 + 28) & 0xFFFF0000;
  }
}

The blend/culling radius is some strange 16bit float format

Code: Select all

int __cdecl PRO_Get16BitFloat(int a1)
{
  return (PRO_GetHWFloat(a1) >> 15) & 0xFFFF;
}

Code: Select all

unsigned int __cdecl PRO_GetHWFloat(int a1)
{
  int v2; // [sp+Ch] [bp-1Ch]@1
  int v3; // [sp+14h] [bp-14h]@1
  unsigned int v4; // [sp+18h] [bp-10h]@1
  int v5; // [sp+1Ch] [bp-Ch]@5
  int *v6; // [sp+20h] [bp-8h]@1

  v6 = &v3;
  v3 = a1;
  v2 = a1;
  v4 = ((a1 & 0x7F800000u) >> 23) - 127;
  if ( (signed int)v4 <= 31 )
  {
    if ( (signed int)v4 < -31 )
      v4 = -31;
  }
  else
  {
    v4 = 31;
  }
  v4 &= 0x3Fu;
  v5 = 4 * (v2 & 0x7FFFFF);
  return v5 | a1 & 0x80000000 | (v4 << 25);
}

If we can figure out this strange float format? Should be able to extract usable node distances

[Bart]

Just saw your commit. Looks like you've got it figured out -- nice work!

[Ian]

It nearly works, think it's broken for negative exponents, ie small numbers :p
Should be easy enough to fix

The 0x7FFFF we saw loads of. I think that's like float max, but the 16 bit version
Not entirely sure when that is used, probably when there is no geometry associated or something

Should probably add, 16bit numbers have no bit for sign, so are always positive.

[artman999999]

Without wasting too much of your time, what does this do?

[Ian]

Basically the nodes contain a bounding box around the geometry. We can use the bounding boxes to throw out geometry which isn't visible. Not really needed for us since we can render pretty fast on modern hardware ..
But we can also use that information to infer a min/max of the Z values, and thus set proper clipping planes, rather than the current state of guessing 1 set of near/far values for all games and all scenes.

Means hopefully we can eliminate z fighting in harley, and clipping problems in scud and other games
That's the theory anyway :p
I am pretty sure this is what the actual hardware is doing.

[Ian]

Well.. here is what the data looks like when drawn



other levels are hard to see because there is simply too much data
but it seems to work okay

[Bart]

Very nice work! But it looks like the letters are outside of the box? Maybe this doesn't matter in practice but what about cases where the camera is actually inside of a culling node box? I imagine that will be an issue with level geometry, for example.

[Ian]

I don't know
I know we can use this info to set a far clipping plane, not sure how yet we could use actually use it for a near plane. You are right, we might just end up in a giant box

[Ian]

I'm gonna try actually culling the data based upon these nodes, see what happens :p
Maybe will get a performance speed up on ghetto hardware

[Bart]

Any luck with setting up near/far planes?

Also, I'm not sure culling is worth the effort. If you play around with Nik's 3D debugger, you'll see that the games do a good job of culling in software already. Very little invisible geometry is present in the scene graphs.