Replies: 1 comment
-
Yes, this is correct, we need to add the serialization of the capacity. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I've been trying to serialize/deserializing btTriangleInfoMap to avoid having to call btGenerateInternalEdgeInfo at runtime, but its effects (eliminating internal edge collisions) don't seem to survive the serialization/deserialization process. I looked into it and found that, when btAdjustInternalEdgeContacts() tries to look up a btTriangleInfo in the btTriangleInfoMap after the deserialization to do the contact adjustments, it fails because the btTriangleInfoMap claims that there is no entry for the given key. The cause of this seems to be that the capacity of m_valueArray is not maintained through the serialization/deserialization process, and because this value is used as part of the hash calculation the same keys will get different hash values before and after serialization/deserialization. I tried setting the capacity of m_keyArray and m_valueArray to the correct value (should be equal to the size of m_hashTable, right?) manually after the deserialization and that seemed to fix the problem. So I guess the solution would be to just add code in btTriangleInfoMap::deSerialize() that sets the capacity to the right value.
Beta Was this translation helpful? Give feedback.
All reactions