PolySoup problem

#1 Well you're going to have to post some log files or debug dumps before we can comment on what it could be.
It is is generally next to impossible otherwise unless some very basic issues are known with a resource etc...

#2 The debugger crashes at line 3374 of tsMesh.cc in TSMesh::prepOpcodeCollision()

if(mOptTree)
  return;

The debugger says "mOptTree CXX0030: Error: expression cannot be evaluated"

It only happens the second time that prepOpcodeCollision() is called, so something must be messing up the pointer between the first and second call.

I see that somebody else has encountered the same problem, but I cannot find a solution.

#3 The debugger crashes at line 3374 of tsMesh.cc in TSMesh::prepOpcodeCollision()

if(mOptTree)
  return;

The debugger says "mOptTree CXX0030: Error: expression cannot be evaluated"

It only happens the second time that prepOpcodeCollision() is called, so something must be messing up the pointer between the first and second call.

I see that somebody else has encountered the same problem, but I cannot find a solution.

#4 Hi...

I had the same problem.
I asked and nobody answered, so I tested it myself.

It seems like if the DTS shape is exported with collision boxes, TGE(A) will crash at the line mentioned above.
So, basically, you must export the DTS without collision boxes and everything will work just fine.
Only problem there is, is that you sometimes will get stuck in the shape, especially if you step on it.

I hope this helps.

#5 www.google.com/search?client=safari&rls=en&q=%22CXX0030:+Error:+expression+canno...

Among others, there's This MS kb article.

Quote:When debugging a C++ program, watching a global const variable in the Watch window of Codeview or the Watch window of Visual Workbench IDE Debugger yields the following error:
CXX0030: Error: expression cannot be evaluated
...
This is by design but is under review for future releases of Microsoft debug products. In Microsoft C++, storage of global constants is optimized for the purpose of saving space, so no debugging information is generated.

For more information, please see the following article in the Microsoft Knowledge Base:
115347 PRB: Debugger Cannot Watch Global Constants in C++ Programs

In other words, the problem appears to be not what your debugger says it is.

For what it's worth, I would try replacing the code thus:

if(NULL == mOptTree)
  return;

and see if that fixes it.

Gary (-;

#6 @ChunkyKs
Thanks for the input. Your code idea did not work, but I have more to play around with now.

@Sorin
I'll let the artist know. BTW, could the fact that players fall through the meshes have anything to do with the fact that players don't have collision hulls like all other objects? As far as I know, players just use bounding boxes for collisions. Not sure if that means anything in this situation.

#7 Yes, it could be.
But that's the point of pollysoup collision; it's designed to use per face collision (more precise), thus, eliminating the need for bounding box collision.
I'm assuming that there's some kind of problem with Oopcode or the integration of it in Torque.

#8 To fix the issue Frank mentions in TGE 1.5.2

In TSShapeInstance::prepCollision, find:

for(S32 i=0; i<hShape->meshes.size(); i++)  
     hShape->meshes[i]->prepOpcodeCollision();

... and change it to:

for(S32 i=0; i<hShape->meshes.size(); i++)  
     if(hShape->meshes[i])  
          hShape->meshes[i]->prepOpcodeCollision();

To fix the player collision issue:
In TSStaticPolysoupConvex::getPolyList, find:

S32 base =  list->addPoint(verts[0]);  
     list->addPoint(verts[1]);  
     list->addPoint(verts[2]);  
     list->addPoint(verts[3]);

...and change it to:

S32 base =  list->addPoint(verts[0]);  
     list->addPoint(verts[2]);  
     list->addPoint(verts[1]);  
     list->addPoint(verts[3]);

-trent