Hi!

I'm using Havok 7.1 R1

I'm setting the FP control word to raise exceptions on NaNs & denormals.
And I'm getting QNaNs inside hkpMeshWeldingUtility::computeWeldingInfo
Is this normal? Havok full debug isn't warning anything other than advising I should do this offline.

The full stack trace is:

>	Distant Souls.exe!hkAreTrianglesEqual(const hkpTriangleShape * triangle0=0x033ff4d0, const hkpTriangleShape * triangle1=0x033ff6d0)  Line 140	C++

 	Distant Souls.exe!hkpMeshWeldingUtility::computeWeldingInfoMultiShape(const hkTransform & meshTransform={...}, hkpShapeCollection * mesh=0x0928f660, hkpWeldingUtility::WeldingType weldingType=WELDING_TYPE_ANTICLOCKWISE, hkArray & allShapes={...}, bool weldOpenEdges=true)  Line 361 + 0x13 bytes	C++

 	Distant Souls.exe!hkpMeshWeldingUtility::computeWeldingInfo(hkpShapeCollection * collection=0x0928f660, const hkpBvTreeShape * bvTree=0x092865c0, hkpWeldingUtility::WeldingType weldingType=WELDING_TYPE_ANTICLOCKWISE, bool weldOpenEdges=true)  Line 258	C++

 	Distant Souls.exe!TLW::GameObjectType::createMeshShape(const TLW::BasicShapesParam & shapeParam={...})  Line 227 + 0x14 bytes	C++

It's happening with some (not all) of my meshes, so I wanted to know if this is expected behavior or not (i.e. Havok expects a few NaNs and handles them gracefully, except this time the HW is raising an exception first)

May be I'm doing something wrong (I doubt it since the sample code is very clear and simple) or if there are certain requirements about the vertex/index data I'm not aware of (i.e. no degenerate triangles, memory padding after a few vertices, memory alignment, etc).
The simulation runs as expected, shall I note. But it's troublesome to have QNaN exceptions in that place when I enable them while trying to catch potential bugs overall in the app.

Just in case, the code I use to build up the MOPP is:

#include "UnDeclareDebugNew.h"

hkpExtendedMeshShape *meshShape = new hkpExtendedMeshShape( /*shapeParam.fRadius*/ );

#include "DeclareDebugNew.h"
for( size_t i=0; i
{

	hkpExtendedMeshShape::TrianglesSubpart part;

	part.m_vertexBase		= &shapeParam.vertices[i][0];

	part.m_vertexStriding	= sizeof( float ) * 3;

	part.m_numVertices		= shapeParam.vertices[i].size() / 3;
	part.m_indexBase		= &shapeParam.indices[i][0];

	part.m_indexStriding	= sizeof( unsigned short ) * 3;

	part.m_numTriangleShapes= shapeParam.indices[i].size() / 3;

	part.m_stridingType		= hkpExtendedMeshShape::INDICES_INT16;
	meshShape->addTrianglesSubpart( part );

}
hkpMoppCode* moppCode = hkpMoppUtility::buildCode( meshShape, hkpMoppCompilerInput() );
#include "UnDeclareDebugNew.h"

hkpMoppBvTreeShape *retVal = new hkpMoppBvTreeShape( meshShape, moppCode );

#include "DeclareDebugNew.h"

hkpMeshWeldingUtility::computeWeldingInfo( meshShape, retVal,

											hkpWeldingUtility::WELDING_TYPE_ANTICLOCKWISE );

moppCode->removeReference();

meshShape->removeReference();

Where shapeParam.vertices[i] is of type std::vector, and shapeParam.indices[i] is of type std::vector
There are no special considerations in the memory alignment of those containers (afaik std::vector should make them 4-byte aligned in an x86; but haven't checked yet).
The vertex data is copied first from an Ogre mesh file, which is rendered correctly.

So, I would like to know if this is expected behavior, a fixed bug from Havok, or an error on my end I should start worrying about.

Thanks in advance.
Cheers
Matias