I see… So what if I need my Ninja to have both the “walking” abilities of the character control and the precise collision shape (among other capabilities) of the DAC?
Just to make sure - In my case I have 2 Spatials each having only one physics control but the thing is that one Spatial (the Node) is the parent of the other Spatial.
Do you consider it as a “model with multiple physics controls”?
OK I found out that the problem is that the CharcterControl’s collision shape is responding to the DAC collision shape (makes sense) and because they are attached to each other and close enough we have an endless reaction between those two Physics controls.
When I move the child Spatial a few meters from its parent Node so the collision shapes doesn’t touch each other I don’t get this endless reaction of course.
So I thought maybe Inheriting from CharacterControl and override some methods to avoid reacting to the child Spatial’s collision shape will solve the problem.
Maybe anyone knows where can I found the method responsible for the CharacterControl reaction to the “ground”? Good chance it is using Ray Casting for its calculations and I just need to put the code ignoring some of the objects…
If the character’s shape is penetrating a responsive collision object by more than m_maxPenetrationDepth, it gets displaced in the normal direction by 20% of the penetration distance.
You might be able to use collision groups to disable interaction between the character’s collision shape and the DAC links. But a much cleaner solution would be to use ignore lists (coming this weekend with Minie v1.7).
I thought CharacterControl’s behavior is independent of DAC’s settings and as you say happens in native Bullet code.
So DAC’s collision groups or Ignore lists will affect CharacterControl’s behavior? It will be great.
The other option I see is just not to use CharacterControl at all and write a replacement control (not sure if I succeed going this path) Or maybe try changing Bullet’s implementation to support ignoring some collision objects.
Nice challenge
Both CharacterControl and DynamicAnimControl are based on Bullet collision objects. Collision groups and ignore lists are both implemented at the collision-object level.
So yes, those settings affect the behavior of physics controls.
I still suspect the best way to combine walk/jump/obstruction behaviors with DAC is simply to extend DAC. But I haven’t tried that yet, so follow whatever course makes sense to you.
OK, so using collision groups I was able to combine CharacterControl with DAC in the same model and make it function as expected (see below video).
The trick was to set all static “ground” objects to be in a different collision group and make sure all Character Controls are set to collide only with that group.
It’s working. What I don’t understand is how am I not seeing a regression in the behavior of Vehicle Controls (I’m using advanced vehicles) and when switching to Ragdoll mode? They interact correctly on my static objects even though they (the static objects) are now belongs to a different (non-default) collision group…
Don’t know but it’s working.
What I don’t understand is how am I not seeing a regression in the behavior of Vehicle Controls (I’m using advanced vehicles) and when switching to Ragdoll mode? They interact correctly on my static objects even though they (the static objects) are now belongs to a different (non-default) collision group…
Vehicle wheels detect supporting surfaces using ray casts, and ray casts don’t care about collision groups.
The vehicle chassis should care, however, particularly if you flip the vehicle over.
