Game Development Community

TGEA 1.7.0 Beta 2 Bug - backwards sorting of tranparent elements

by Jeff Faust · in Torque Game Engine Advanced · 04/01/2008 (8:54 am) · 3 replies

The distance sorting of transparent elements is exactly backwards. The farthest objects are being rendered on top of the nearest.

The problem appears to be in the comparison function RenderElemMgr::cmpKeyFunc() located in renderElemMgr.cpp. Here is a partial fix, at least:
S32 FN_CDECL RenderElemMgr::cmpKeyFunc(const void* p1, const void* p2)
{
   const MainSortElem* mse1 = (const MainSortElem*) p1;
   const MainSortElem* mse2 = (const MainSortElem*) p2;

   // dynamic lights *MUST* be rendered after the base pass!
   if(mse1->inst && mse1->inst->matInst &&
      mse2->inst && mse2->inst->matInst)
   {
      S32 testA = mse1->inst->matInst->compare(mse2->inst->matInst);
      if(testA != 0)
         return testA;
   }

   [b]// FIXED CODE
   S32 test1 = S32(mse2->key) - S32(mse1->key);

   return ( test1 == 0 ) ? S32(mse2->key2) - S32(mse1->key2) : test1;[/b]
   /* ORIGINAL CODE
   S32 test1 = S32(mse1->key) - S32(mse2->key);

   return ( test1 == 0 ) ? S32(mse1->key2) - S32(mse2->key2) : test1;
   */
}
I believe the dynamic lights are properly compared but I have not verified this.

EDIT:
I'm also not certain about the change to the key2 comparison.
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine Advanced


Associate Jeff Faust
Faust Logic, Inc.
#1
06/10/2008 (9:42 am)
FOLLOW UP:

I revisited this code after answering another forum question. I became curious because the original cmpKeyFunc() described above (before my suggested changes) is also present in TGEA 1.0.3 although the backwards sorting behavior was not present in that version.

It turns out that the real source of this bug comes from a change in the way MainSortElem::key is assigned its value in the first place.

In TGEA 1.0.3, it looks like this:
// sort by distance
   elem.key = (gRenderInstManager.getCamPos() - inst->sortPoint).lenSquared() * 2500.0 ;
   elem.key = HIGH_NUM - elem.key;

In TGEA 1.7, like this:
F32 camDist = (gRenderInstManager.getCamPos() - inst->sortPoint).len();
   elem.key = *((U32*)&camDist);

The second approach improves the precision of the comparison but it leaves out the subtraction from HIGH_NUM. Consistent with its name, HIGH_NUM is a very big number and subtracting the values from it effectively reversed the sort ordering of the keys.

It's possible that this doesn't change anything, but with this new information, someone should review the above changes (now present is TGEA 1.7) to make sure that reversing the comparison order in cmpKeyFunc() does not produce different results from what was originally achieved by subtracting the key from HIGH_NUM.

Torque Owner Stefan Lundmark
#2
06/10/2008 (10:22 am)
We've always had a problem with flashing billboards if they were far away, although it was rare to see another object at that range so it wasn't a huge issue. Anyhow, took your changes into our 1.0.3 based build, and those issues are gone.

Looks like a good fix, and I'll let you know if anything turns up.

Torque Owner Brian Richardson
#3
06/11/2008 (10:43 am)
@Jeff:

Yeah, I think you're right. We should probably the distance we're calculating from the scene visible distance.

So like, it'd be:

F32 camDist = (gRenderInstManager.getCamPos() - inst->sortPoint).len();
   camDist = smSceneState.visibleDist - camDist; // Invert camera distance
   elem.key = *((U32*)&camDist);

So the key being that we keep camDist as small as possible to keep floating point issues in check. Then use the casting trick to keep all of the bits around. We may not actually have access to the scene visible distance in the render managers, so some other number may be needed here.

I checked the TGEA tree, and it looks like this was changed based on our conversation here. I didn't get around to changing it in Jugg though, since I didn't have time to test it back then. ;)