welding info assert (during simulation)

welding info assert (during simulation)

snowcoder's picture
snowcoder
Wed, 08/26/2009 - 09:27

I'm getting following assert when I come near a certain area in one of my test scenes (hk 6.6.0):

.\Shape\Compound\Collection\ExtendedMeshShape\hkpExtendedMeshShape.cpp(553): [0x54654323] Assert : (thisObj->m_weldingInfo.getSize() == 0) || (thisObj->m_weldingInfo.getSize() > ( part->m_triangleOffset + (int)terminalIndex ) )

The assert also immediately gets triggered when I start up the VDB on that scene.

During creation hkpMeshWeldingUtility::computeWeldingInfo() returns HK_SUCCESS so it appears as if everything should be ok. I currently create the mopp and welding at run-time so it isn't any issue with incorrect streaming. If I don't create welding info, the scene works.

I'm wondering if you might be able to give me some hints about what data could be incorrect to get that assert, or what I might be doing wrong?

My code (which is based on the MeshWeldingDemo one):

hkpMeshWeldingUtility::ShapeInfo info;
info.m_transform = hkTransform::getIdentity();
info.m_shape = pMoppShape;

hkLocalArray shapes(1);
shapes.pushBack(info);

pMeshShape->m_weldingType = hkpWeldingUtility::WELDING_TYPE_ANTICLOCKWISE;
if (hkpMeshWeldingUtility::computeWeldingInfo(hkTransform::getIdentity(), pMeshShape, shapes, true, hkpMeshWeldingUtility::WINDING_IGNORE_CONSISTENCY) != HK_SUCCESS)
{
ASSERT(FALSE);
}

-----

I'd also like to sneak in a second question I've been thinking about, to avoid creating another thread :) When creating compound shapes with sub-shapes that align next to eachother, is it enough if the shells touch or do the actual shapes have to touch? For example the classic L shape, if only the shells touch in the corner, can something "slide" between the two shapes or will it be perfectly solid?

RSS Top
7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
JayAtHavok's picture
JayAtHavok
Wed, 08/26/2009 - 10:41

Hi snowcoder,

Not sure why the assert is asserting. What does your m_weldingInfo look like compared to your shape? Specifically what sort of size is it and what sort of size (as in number of triangles) is your shape? Based on your second question is the shape a compound shape with separate sub shapes? If you treat the sub shapes entirely separately is there any difference in behavior?

As to your second question, sub shapes are treated entirely separately when the collision detection algorithms drill down. So for your L shape that's touching on the corner, something could maybe slide between them depending on the size of the gap between the shapes, the size of the object in question, and the quality type of the objects involved. There isn't any "global" information stored that knows that the two L joined sub shapes should form an impenetrable seam.

Thanks,
Jay

Top
snowcoder's picture
snowcoder
Wed, 08/26/2009 - 11:57
Quoting - JayAtHavok Not sure why the assert is asserting. What does your m_weldingInfo look like compared to your shape? Specifically what sort of size is it and what sort of size (as in number of triangles) is your shape? Based on your second question is the shape a compound shape with separate sub shapes? If you treat the sub shapes entirely separately is there any difference in behavior?

The first question is an ExtendedMeshShape with only a single TriangleSubpart in it, nothing else. Sorry to confuse with the compound shape question, that was completely unrelated, just something that I've been thinking about.

The mesh in question:

input data part.m_numTriangleShapes = 5103
m_weldingInfo.getSize() = 4898
(VDB display info says 4898 triangles)

Is it possible that there are 232 degenerate tris, which are somehow causing trouble (allthought I thought the docs said that it handles those)?

-----

As for the compound shape question

Quoting - JayAtHavok There isn't any "global" information stored that knows that the two L joined sub shapes should form an impenetrable seam.

I was a bit unclear I think, what I meant was how shell (convex shape radius) comes into play in compound shapes. If for example I took the L shape with 2 boxes, and auto-shrunk them by the radius (to accomodate for the shell), there would be a gap betweem the actual boxes, but the shells would be touching. My question was if that's a no-no and the the actual box shapes (without radius) must be touching eachother, or if it will work equally good if only the shells touch.

Wish I could embed an image would have been much easier :)

Top
JayAtHavok's picture
JayAtHavok
Wed, 08/26/2009 - 14:37
Quoting - snowcoder
The first question is an ExtendedMeshShape with only a single TriangleSubpart in it, nothing else. Sorry to confuse with the compound shape question, that was completely unrelated, just something that I've been thinking about.

The mesh in question:

input data part.m_numTriangleShapes = 5103
m_weldingInfo.getSize() = 4898
(VDB display info says 4898 triangles)

Is it possible that there are 232 degenerate tris, which are somehow causing trouble (allthought I thought the docs said that it handles those)?

-----

As for the compound shape question

Quoting - JayAtHavok There isn't any "global" information stored that knows that the two L joined sub shapes should form an impenetrable seam.

I was a bit unclear I think, what I meant was how shell (convex shape radius) comes into play in compound shapes. If for example I took the L shape with 2 boxes, and auto-shrunk them by the radius (to accomodate for the shell), there would be a gap betweem the actual boxes, but the shells would be touching. My question was if that's a no-no and the the actual box shapes (without radius) must be touching eachother, or if it will work equally good if only the shells touch.

Wish I could embed an image would have been much easier :)

Hi snowcoder,

The assert you're getting is letting you know that there's less welding info than triangles. I'm not sure if it's a degenerate triangle problem or something else. Try finding the smallest subset of the mesh that still causes the assert. If you can get it down to maybe a dozen triangles that assert but aren't degenerate, I should be able to track down the issues from my end.

As to the convex radius question, the shrunken shape + convex radius shape is assumed to be a new shape as far as collision detection is concerned. So your convex radius boxes will be touching. Well, the edges of the box + convex radius are curved instead of nice square edges, which might cause problems. If the object you're colliding against it has lower quality type, it might tunnel through. If the object has higher quality type (critical, for instance), it shouldn't slip through the seam though actual results may vary depending on allowed penetration depth and the like.

Hope that helps,
Jay

Top
snowcoder's picture
snowcoder
Wed, 08/26/2009 - 21:32
Quoting - JayAtHavok The assert you're getting is letting you know that there's less welding info than triangles. I'm not sure if it's a degenerate triangle problem or something else. Try finding the smallest subset of the mesh that still causes the assert. If you can get it down to maybe a dozen triangles that assert but aren't degenerate, I should be able to track down the issues from my end.

After a few hours of trying various things I got it working.

I added a degeneracy check to pre-filter out bad tris, however no matter how I tweaked the values the weldInfo.getSize() differed from the input tri count, which always led to the assert. Finally I replaced my own IsDegenerate code with a call hkpTriangleUtil::isDegenerate() in order to be 100% guaranteed to catch what havok considers degenerate. Lo and behold weldInfo.getSize() finally ends up equal to input tri count and the assert is gone.

Maybe the documentation that says "as well as handling degenerate triangles gracefully" should be updated that it doesn't necessary apply to welding ;)

Thanks!

Top
JayAtHavok's picture
JayAtHavok
Thu, 08/27/2009 - 09:39
Quoting - snowcoder

After a few hours of trying various things I got it working.

I added a degeneracy check to pre-filter out bad tris, however no matter how I tweaked the values the weldInfo.getSize() differed from the input tri count, which always led to the assert. Finally I replaced my own IsDegenerate code with a call hkpTriangleUtil::isDegenerate() in order to be 100% guaranteed to catch what havok considers degenerate. Lo and behold weldInfo.getSize() finally ends up equal to input tri count and the assert is gone.

Maybe the documentation that says "as well as handling degenerate triangles gracefully" should be updated that it doesn't necessary apply to welding ;)

Thanks!

Hi snowcoder,

Glad you figured it out. Knowing that it was degenerate triangles causing the problem I dug through our bug database and there are some issues logged against that. It should be fixed in future versions of Havok, so keep an eye out for HVK-5176 in the release notes.

Take care,
-Jay

Top
snowcoder's picture
snowcoder
Thu, 08/27/2009 - 11:36

Good to know, thanks. Allthough it will work fine as it is for me, I was going to pre-filter out degenerate tris anyway, now I just ended up adding it sooner rather than later :)

Top

Login to leave a comment.