THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 21/12/2005 at 03:34, xxxxxxxx wrote:
Cinema 4D Version: 8.012
Platform: Windows ; Mac ; Mac OSX ;
Language(s) : C++ ;
I need to know more about the details of GeColliderEngine and GeColliderCache. For instance, are the 'Do...()' methods of GeColliderEngine destructive to the GeColliderCache 'triangles' in any way?
My process loops over a stepped movement (artificial incrementation of a Pos component value in Mg, not keyframed) to determine the contact point of two object sets (these could be two basic objects, two lists of objects, two hierarchies, two lists of hierarchical objects, etc.). So, first I determine the interpenetration (DoCollide) or distance separation (DoDistance). If there is no penetration and separation, I then step the source object 'towards' the target object and check for interpenetration (DoCollide) with a check for increasing separation (DoDistance) just in case they have not contacted (preprocessing checks for overlapping bounding boxes and triangles already done). If there is penetration, I then back up the source in continuous half-steps (step /= 2 for each step) until there is no penetration.
I am getting unexpected results if the source is moved/rotated between test invocations. I do GeColliderEngine::FreePairsList() after each DoCollide(). At this point, I have no clue as to what is transpiring.
On 02/01/2006 at 14:27, xxxxxxxx wrote:
I can't confirm this (at least not in 9.5; noticed now that you'd specified 8.012). If I put two cubes next to each other and do DoCollide() it's different (no collision) than if I give a matrix that would make them collide (many collision pairs). So the cache seems to survive DoCollide(), as expected. Could you post some code that shows the problem?
On 02/01/2006 at 17:18, xxxxxxxx wrote:
Long since resolved the issue, Mikael.
In the docs it states that the object's matrix should be 'orthonormal' which at first I took to mean 'unskewed' (orthogonal), not unitary. So I was just passing bad matrices. Now I see that the matrix passed to the collider engine need not be the actual matrix of the object - the object's matrix is applied to its points during collider cache construction and then made unitary. The position within the matrix passed to the collider engine is stepped.
Also, I realized that it is easier for the engine to work on one triangulated polygonal mesh, so the objects in each set are connected before processing. Don't know if this is strictly necessary, but much easier to conceptualize.