i want to ask for some explanation on this concept, and the implications of it:
The stealth tutorial uses animated doors, which work in a way i hadn’t expected:
Basically, the door is given a box collider (which i’d think would be enough for the purpose) but is also given a rigidbody, which is marked as kinematic and not using gravity.
The doors are opened and closed via an animation, which just moves the object to the side. translation, basically.
This sort of makes sense to me, but it sort of doesn’t, too. I have a number of (probably overlapping) queries about it:
Why is both a rigidbody and a box collider needed?
My preliminary googling of kinematic things indicates that they don’t register collisions.
2a. Given that, how is the player able to collide with them
2b. What’s the point in a physics object that can’t collide.
My experience in other mediums has been that animations are visual only, and don’t affect an object’s collision shapes. Is that untrue in unity? What’s going on here.
Can i make animations with real collisions? Could this be used, for instance, to make a swordfighting game with weapons that actually collide with each other, and player models, instead of making guesses with code and raytracing ?
First of all, a collider is considerably slower if you move it and it doesn’t have a rigidbody attached. My (feeble) understanding is along the lines that colliders without rigidbodies get more embedded into the physics system, or something like that - so moving them requires more recalculations and stuff.
Kinematic objects do register collisions, but they aren’t controlled by the physics system - just through script. The order is explained at the bottom of this page: Unity - Manual: Introduction to collision
Animations still move the object. Root motion does this for example - or, slightly more lightweight, the collider can be attached to the bone that moves. E.g, if on a character you attach a weapon with a collider to the hand bone, then that will follow the hand’s movement.
So in that combat example, you’d just attach the sword with a collider or trigger on it as a child of the hand bone. You might need a bit more detail to the system mind - perhaps using animation curves to determine when the sword can actually cause damage
thank you for that link oysterCAKE, it’s good at explaining a lot of stuff.
From what i read there, a collider without a rigidbody is classed as a “static collider” and these should apparently never be moved at runtime at all. Why then are we even allowed to move them? The page makes it sound like that’s not only slow and computationally expensive, but is apparently buggy and not properly supported.
I’m still not entirely clear on what a rigidbody is, or the difference between it and a collider, though.
What is a rigidbody without a collider? Is that even allowed/possible ?
A rigidbody is nothing without a collider, it needs one (or more than one).
I think the reason we can move static colliders at all is so we can generate environments at runtime. So you’d put all your stuff in place, the physics engine would re-do it’s static stuff, and then you’d leave it there so it doesn’t have to do that again.
what exactly do you mean? Will unity refuse to compile in that cirucmstance, or will these objects exist and be affected by forces, but not collide with stuff?
I could think of some uses for that, such as a ghost
To function as i’m planning, it’d need more than just the sword with a collider. I’m thinking all the characters involved would have a detailed body and limbs made of colliders, and they’d do all their movement with premade animations. Would all the collisions register properly when sword hits limb, or whatever?
Basically i’m interested in deep, total simulation here. that’s probably computationally expensive but i’ll happily sacrifice other unnecessary things like scenery, npcs, etc to keep the overheads down.
Yes, they will react to collisions, but I would advice on not relying on that. If you have a rigidbody as your body (rigidbody is the thing with mass) and a collider (or several, like in body parts) and animation on that, you would have to make sure that the character doesn’t fall over.
Instead: use a capsule collider for the whole body and body movement, disallow rotational changes (“freeze rotation” on your rigidbody prevents it from being affected by physics) and set up your body parts with seperate colliders on a physics layer, which doesn’t collide with the layer for your capsule collider, so the arm can move through your capsule collider. It can still collide with world or other arms, legs etc.
Edit: nonkinematic rigidbodys on your arms (so that they will “fly” in the hit direction) will be overriden by your animator, so ragdoll and animations at the same time are not easy.
While I’ve never tried it, I would assume that having a rigidbody without a collider would be the same as just not having a rigidbody. Like unity would just ignor it. I could be wrong about that though.
As for your animation driven collider heavy total simulation idea, you could definitely move the colliders round with traditional animations and get very acurate collision detection. What happens after that will be harder. Obviously you don’t want the pre-made animations to continue, so you have to switch to a sort of ragroll - IK thing.
Have you seen the game Gang Beasts? They are doing some very simulation heavy combat with a rather complicated IK system. As I understand it, they have to do multiple IK passes for each character for each frame in order to get them to respond to each other properly while wrestling. Might be worth you checking out.
Sorry, I’m a couple of years late to the party, but basically:
When you want to detect collisions between any 2 GameObjects in Unity, you need Colliders on both GameObjects.
You also need a Rigidbody on at least 1 of the GameObjects for the collision to register. The proper practice is to add a Rigidbody to anything that works with colliders.
Adding a Rigidbody will cause the object to exhibit physics behaviours, but if you make it a kinematic, that will remove the physics behaviour and leave only the ability to detect collisions.
