Some Exception support

[Bird]

Crashes are deadly for my project since an artist might lose all his work. So I was wondering if it's possible to define another version of dgAssert that would throw an exception during runtime in release mode. I've been experimenting with the code below and the performance hit is not noticeable and it enables me to handle some unexpected errors without crashing. Would it be possible to add something like this in dgTypes.h ?

-Bird

Code: Select all

#ifdef DG_THROW_ASSERT
inline void onAssertFailure (const char * function, int line)
{
   std::ostringstream os;
   os << "Failure in " << function << " on line " << line;
   
   throw std::runtime_error(os.str());
}

template <typename T>
bool check ( T expression )
{
   return expression ? true : false;
}

#define dgAssert(x) {  \
      if(!check(x)) \
        onAssertFailure(__FUNCTION__, __LINE__); \
      }
#endif

[Julio Jerez]

oh you mean an runtime asset, that work in release mode?
since the assert is used on very critical path, I can make a compile time define that define that assert.
will that be ok?
or may adding a file were those define are set, and the end user can edoi then on their end.
I think I will do the config file, I can have ha tonight, and place some of eth define that are all over the code now and it is becoming hard to Rembert where the are.
I will do ta and the assert version. also place there the Simd and mutithred defines. there are some other so I will put the one I remember.

here is my question, how do you recover if the assert throw and exception? I can use that for the effect editor that I am writing.

[Bird]

o

h you mean an runtime asset, that work in release mode?

It's like that but it doesn't make the assert(x) or _ASSERTE(x) calls. Instead it throws an exception which I can catch on my end and prevent my LW plugin from crashing.

since the assert is used on very critical path, I can make a compile time define that define that assert.
will that be ok?

That would be great

here is my question, how do you recover if the assert throw and exception? I can use that for the effect editor that I am writing..

Well, it depends on where you are. For example my plugin crashes in release mode if I try to make this mesh a convex hull http://newtondynamics.com/forum/viewtopic.php?f=12&t=7967
Here's the code I use to catch the exception . The shape creation fails and then I can just remove the entity from the engine before Newton crashes and brings down my plugin.

Code: Select all

// onCollisionShapeChange
void NewtonScene::onCollisionShapeChange (NewtonEntity * const entity)
{   
   NewtonCollision * shape = nullptr;   
   NewtonCollision * collision = nullptr;
   try
   {
      const NewtonBody * const newtonBody = (NewtonBody*)entity->component->userData;
      if( !newtonBody ) return;

      shape = NewtonBodyGetCollision(newtonBody);
      if( !shape ) return;

      collision = newtonMeshOps_.createCollisionShape(entity);
      if( !collision )
         return;

      NewtonBodySetCollision(newtonBody, collision);   
      NewtonDestroyCollision(collision);
      NewtonDestroyCollision(shape);
   }
   catch (const std::exception& e) 
   {
      DB(e.what());
      if( collision )
         NewtonDestroyCollision(collision);
      NewtonDestroyCollision(shape);

      removePhysicsBody(entity->bodyID);
   }
}


And here's the output I see from my logger to let my know where it failed

INFO: Failure in newton::dgCollisionConvex::SetVolumeAndCG on line 1514

The big problem for me is that my users will undoubtedly try to add illegal/corrupt meshes that will cause problems for Newton. I can't prevent that. But this way I can keep my plugin working or at least have it quit gracefully without crashing LW.

-Bird

[Julio Jerez]

Oh I forget that bug. I will test tonight
that seems to be a numrical rounding error, let me chek that forst, teh conve sudl no generate that kind or errors ever.

[Bird]

Oh I forget that bug. I will test tonight
that seems to be a numrical rounding error, let me chek that forst, teh conve sudl no generate that kind or errors ever.

One thing I've discovered in that bug is that I can prevent the assert from happening by increasing the tolerance value in NewtonCreateConvexHull(). I'd prefer to keep tolerance at 0.0 though since accuracy is more important than performance in my project. I've hit that assert in various other meshes and each one requires a different tolerance value to prevent crashing.

I also found a mesh that crashes Newton in NewtonMeshTriangulate() but for some reason the OFF exporter isn't working on this mesh.

-Bird

[Julio Jerez]

no it should work with zero tolerance, let me check what is wrong with that mesh first tonight .

[Julio Jerez]

One thing I've discovered in that bug is that I can prevent the assert from happening by increasing the tolerance value in NewtonCreateConvexHull(). I'd prefer to keep tolerance at 0.0 though since accuracy is more important than performance in my project. I've hit that assert in various other meshes and each one requires a different tolerance value to prevent crashing.

Ok I fix that, it was not relate to tolerance. is was a local buffer that I have set too small, you are using high res mesh stress many of the algorithm, there were some local buffer that were set too small legacy from core 200,
basically I considered that a face will never have more than 64 faces, and you hull come out with some at 72 and 69, and that over run the buffer, there was a define to set that and the value was set a 2024 but that local buffer felt trough the crack.
I fix the all now and should no happens again. when you set the tolerance, those faces with very close point were collapse and they may just be under the old limit of 64. so that fixed because of a side effect.

I also found a mesh that crashes Newton in NewtonMeshTriangulate() but for some reason the OFF exporter isn't working on this mesh.
-Bird

on this, can you save the mesh as FBX? now I have a tool that can read fbx files, and fpx file can be save as polygonal meshes, I's like to test what is wrong there.

[Julio Jerez]

also I have a question?
does lighwave have a free SDK for exporting and importing files like autodesk FBX?

[Bird]

Ok I fix that, it was not relate to tolerance

I tested it here and there's no problems. Thanks for the fix!

does lighwave have a free SDK for exporting and importing files like autodesk FBX?

FBX export is not exposed in the LW SDK. But the latest version of LW does have import/export tools for FBX and Collada and an Alembic importer.

Here's the mesh I'm having problem with exported to FBX using LW.
http://hurleyworks.com/downloads/spoon.zip

I hit a problem with this mesh( and some others ) when I try to convert the convex hull geometry data to my own format so I can draw it in LW. Here's what I do

Code: Select all

NewtonCollision * collision =  NewtonCreateConvexHull()
NewtonMesh * newtonMesh =  NewtonMeshCreateFromCollision(collision);
NewtonMeshTriangulate(newtonMesh);

Sometimes I hit dgAssert (leftOversOut.GetCount() == 0) around line 1292 in dgMeshEffect1::Triangulate(). Sometimes I crash reading the data using NewtonMeshGetFirstVertex and NewtonMeshGetFirstFace.
It's always possible this is a bug in my code .... but there's plenty of other meshes that my codes handles perfectly so it's not my first suspect.

-Bird

[Julio Jerez]

ah ok. I was able to load the mesh without problem in the model editor. That tool btw is in folder ..\newton-dynamics\applications\modelEditor\Win32
of teh sdk download. you can use it to try models before you send then to me.
for now on we can just use the FBX for sharing data because it is more powerful than OFF and support general polygonal faces,
which means the data do not change when is exported or imported.

this is how the mesh looks in the editor

widget.png (61.58 KiB) Viewed 5280 times

I see that the mesh is tiny, that suggest a rounding off error.
I will see what is wrong tonight, I will add a command to call the convex hull creation and see what the error is.

[Bird]

Cool! That should make life easier. I think you're right about scale being the problem. I made a new model at a bigger scale and it works fine.

-Bird

[Julio Jerez]

Bird I pasted this code in the FBX loaded

Code: Select all

NewtonWorld* const world = ngdScene->GetNewtonWorld();
NewtonMesh* xxx = instance->GetMesh ();
NewtonCollision* collision =  NewtonCreateConvexHullFromMesh (world, xxx, 0, 0);
NewtonMesh* xxx1 = NewtonMeshCreateFromCollision(collision);
instance->SetMesh (xxx1);
instance->ConvertToTriangles();

and I did not get any error. this is what the convex looks like, the tolerace is set to zero, and no scale

convexSpoon.png (34.98 KiB) Viewed 5267 times

There is only one difference, and that is that the FBX does make some transformation to the mesh, basically the Autodesk SDK, try to second guess what the application wants and
transform the mesh so that it looks like the loader expect. his may change the want the vertex are arranged and remove the error.
This test many no be valid, I think that debugging this king of stuff the OFF is a better, because the OFF you get out what you put in.
can you save the Off and send to me?

[Bird]

This test many no be valid, I think that debugging this king of stuff the OFF is a better, because the OFF you get out what you put in.
can you save the Off and send to me?

No I can't, the OFF save doesn't work for this mesh. Here's my code below. The NewtonMesh * returned from NewtonMeshCreateFromCollision() has m_points = 0 and the OFF file just contains this

OFF
0 0 0

If I make a larger scale version of the spoon in LW Modeler though, it works fine.
-Bird

Code: Select all

void NewtoncScene::exportToOFF (const BodyID & bodyID, const String & path)
{   
        PhysicsBodies::iterator it = bodies_.find(bodyID);
   if ( it != bodies_.end() )
   {
      PhysicsBody::Ptr pBody = it->second;
      if( pBody && pBody->component )
      {
         const NewtonBody * const newtonBody = (NewtonBody*)pBody->component->userData;
         NewtonCollision * const collision = NewtonBodyGetCollision(newtonBody);
         NewtonMesh * const newtonMesh = NewtonMeshCreateFromCollision(collision);
         NewtonMeshSaveOFF(newtonMesh, path.getCharPointer());
         NewtonMeshDestroy(newtonMesh);
      }
   }
}

[Bird]

Sometimes I hit dgAssert (leftOversOut.GetCount() == 0) around line 1292 in dgMeshEffect1::Triangulate(). Sometimes I crash reading the data using NewtonMeshGetFirstVertex and NewtonMeshGetFirstFace.
It's always possible this is a bug in my code .... but there's plenty of other meshes that my codes handles perfectly so it's not my first suspect.

Ha! I found the problem and it was in in my code...

I was using NewtonMeshGetVertexCount(mesh) to obtain the expected vertex count and then used that number to pre-allocate my own vertex buffers.Then I iterate through the NewtonMesh vertices using NewtonMeshGetNextVertex() to obtain the vertex positions. That worked most of the time. But for this mesh and some others, there are more vertices found by iterating than the number that NewtonMeshGetVertexCount() returned so my buffers were overflowing which was the cause of the crash. I fixed it by iterating first to learn the actual number of vertices to expect but shouldn't NewtonMeshGetVertexCount() give me the proper number? I tried NewtonMeshGetPointCount() and doesn't work either.

-Bird

[Julio Jerez]

NewtonMeshGetVertexCount() should indeed give the correct vertex count.