Difference in showtool and game engine LODs

#1 Update after some more debugging. In tsShapeInstance.cc at line 649 we have the following code.

bool supportBuffers = dglDoesSupportVertexBuffer();
   if (!supportBuffers || !renderMeshesX(ss,od))
   {
      // run through the meshes
      smRenderData.currentTransform = NULL;
      S32 start = smNoRenderNonTranslucent ? mShape->subShapeFirstTranslucentObject[ss] : mShape->subShapeFirstObject[ss];
      S32 end   = smNoRenderTranslucent ? mShape->subShapeFirstTranslucentObject[ss] : mShape->subShapeFirstObject[ss] + mShape->subShapeNumObjects[ss];
      for (i=start; i<end; i++)
         mMeshObjects[i].render(od,mMaterialList);
   }

When the camera is close to the shape in-game, "start" = 1 and "end"=1 so the "for (i=start; i
When I back the camera away just enough for the shape to dissapear, "start" = 2 and "end" still =1 so the "for (i=start; iNOT run and the detail level is NOT visible.

I have not further data yet, but I suspect the Blender dts is not flagging smNoRenderTranslucent or some other translucent related issue.

#2 Hmm, sounds like maybe the blender exporter is exporting incorrect detail info?

#3 If I hardcode the smNoRenderTranslucent variable to false, then all the LOD's get drawn. This implies that the smNoRenderTranslucent is not correct for Blender dts shapes.

smNoRenderTranslucent is set in void TSShape::initMaterialList() from the subShapeNumObjects count for each subobject.

Phew, quite a mouthfull. If that confused you, imagine how I feel...

Can anyone clarify this section? Where's the guy who wrote the code?

I'm trying to pinpoint whats missing from the Blender dts because that will help to find a fix for it.

#4 The guys who wrote this code worked at Dynamix and are now scattered throughout the gaming industry. :)

James Urquhart is the guy to talk to here; he's one of the people in the community who knows that code the best.

#5 Well ok, who needs them anyway when I fixed the problem... lol In Jame's defence, it seems the exporter was perhaps more accurate than 3ds Max version.

In tsStatic.cc near line 238 you need to change a true/false condition as shown below.

if (image->isTranslucent == true)
   {
      TSShapeInstance::smNoRenderNonTranslucent = true;
      TSShapeInstance::smNoRenderTranslucent    = false;
   }
   else
   {
      TSShapeInstance::smNoRenderNonTranslucent = false;
      TSShapeInstance::smNoRenderTranslucent    = false; // was true
   }

Blender models now work perfectly giving all LOD's and transparent faces work too.

I also tested with the Max Orc and it still works fine as well.

#6 That seems like it causes transparent stuff to get rendered TWICE potentially at a very bad time?

#7 I'm no expert but here is how I understand it.

In the above if (image->isTranslucent == true),

CONDITION (A)
with a translucent image it will render from
subShapeFirstTranslucentObject to subShapeFirstObject + subShapeNumObjects which seems to say it will render both translucent and normal images. (and thats original code)

CONDITION (B)
With no trunslucent images present it will now render from
subShapeFirstObject to subShapeFirstObject + subShapeNumObjects which is only opaque images.

Before the change, condition (b) was trying to render from the 1st opaque image back-to the address of the 1st translucent image which makes no sense to both me and Blender. Somehow it worked for Max models.

#8 So subShapeFirstTranslucentObject is always less than subShapeFirstObject?

The thing is that the render is done twice, once for opaque parts of the model then again, later, for the transparent parts. This is the proper behavior. The changes in effect here seem to result in the opaque parts being drawn twice (which may mess up Zorder on transparent things)!

#9 Let me break down what you are saying so that I can understand it better.

FIRST RENDER
Opaque parts get rendered by calling CONDITION(B). Only opaque parts get rendered.

SECOND RENDER
Both opaque and transparent parts get rendered by calling CONDITION(A).
This is the original part of the code, not the part I changed.

This means the original code is at fault for rendering the opaque parts twice?

Ben it's good that we discuss this because even if my logic is flawed, I still believe the Blender model LOD's are not being rendered due to some bad "logic" in the render section. The detail levels do exist in the shape and I stepped through the entire import section and checked the values and counts of subobjects, numsubobjects etc and they are correct per the model.

Which led me back to the "logic" of the render section. If my explanation of the render logic is flawed then help me find what it should look like so that Blender models get displayed correctly.

#10 What should be happening:

FIRST RENDER
Opaque parts get rendered by calling CONDITION(B). Only opaque parts get rendered.

SECOND RENDER
ONLY transparent parts get rendered by calling CONDITION(A).

This is what the original code did (based on the flags).

I suspect a bug in Blender, as the DTS code was originally written exclusively for the Max exporter. All subsequent exporters are, essentially, derivatives of the Max ur-exporter. The Max code is almost by definition correct. ;)

BTW - happy you're taking the time to understand this issue. Hope we can get everything working right. :)

#11 Creative debugging. I placed the Max Orc (as a static) and a Blender static in the game with no other shapes in the area. The Max and Blender shapes were also far appart with the camera in the middle so that it could only see one or the other of the two shapes.

Then I added the following code to the tsShapeInstance at the point mentioned futher up in this thread, this was done to show the values "live on screen" in the racing mod, as I moved the camera closer and further away.

S32 a,b,c,d,e;
	  a = mShape->subShapeFirstTranslucentObject[ss];
	  b = mShape->subShapeFirstObject[ss];
	  d = mShape->subShapeNumObjects[ss];
	  
	  ////////////////////////////////////////////////////////
	  GuiTextCtrl* pTextCtrl;
	  if (Sim::findObject("LapCounter", pTextCtrl))
	  {
		  char sss[200];
		  sprintf(sss,"detail=%d num obj=%d 1st-obj=%d  1st-tlobj=%d",ss,d,b,a);
		  pTextCtrl->setText(sss);
	  }
	  ///////////////////////////////////////////////////////////

With the Orc, the ss detail level stays on 0 no matter how far the camera is moved away. Even so, the LOD displayed on screen does seem to change, but is admittedly VERY hard to perceive the change with the Orc.

The Blender model I'm using is a simple cube which changes color with each detail level.

The Blender model: detail level ss changes as expected with camera distance.
subShapeFirstObject always equals the detail level ss value
subShapeNumObjects = 1, which is correct for this model
subShapeFirstTranslucentObject = 1 because it's set to = subShapeNumObjects in TSShape::initMaterialList() shown below.

S32 start = subShapeFirstObject[ss];
      S32 end = subShapeNumObjects[ss];
      subShapeFirstTranslucentObject[ss] = end;

Question 1: Why does the Orc detail level not change?
Question 2: Why is subShapeFirstTranslucentObject set to = subShapeNumObjects when in the original CONDITION B the following occurs.

CONDITION (B)
With no trunslucent images present it will now render from
subShapeFirstObject to subShapeFirstTranslucentObject which is only opaque images.

Thus for detail level 2 it will try and render from 2 to 1 ??

If only the Orc details levels changed I'd have something to compare it to.

#12 P.S. it's easy to blame the Blender exporter but that will not fix it. In order to find where to fix the Blender exporter, the problem needs to be well understood first.

#13 Are you sure the right TSShapeInstance is updating the text field? It could well be the server instance that's doing it... :-(

#14 I'll look into it but my first thought is howcome it works for the Blender model? Surely the same theory would apply.

Can you briefly explain the render situation regarding client and server. I thought all renders are done by the client, so would the server "thread" even be going through that section?

Another logical deduction is that for the Blender model, if subShapeFirstObject[ss] was zero for each detail level instead of being equal to the detail level number, then the Blender LOD's would all display as well. I'm looking into that right now as being the most promising lead so far.

#15 It could also be another tsshapeinstance in the scene, which would clobber your debug code nicely, I think.

The server does some animation setup tasks so it can properly resolve stuff that depends on the current animation state, like where you're aiming. Just read the code, there's nothing terribly magical and it's likely to be different for each object.

#16 ...

#17 ...

#18 ...

#19 ...

#20 Way to go Joseph! I did try your last suggestion S32 end = subShapeNumObjects[ss] + start; and it does render all Blender detail levels as expected.

Makes good sense to me.

Fixing the Blender exporter would likely be the best long term approach because a lot of people who don't have the source code still won't be able to use Blender LOD's until an 'official' engine update is made.

Hopefully Ben will say a few words.