autocollision - how does it work

[krystianoo]

basically, title

can a laggy player go thru a large .dff/building that uses autocollision (as if collisions werent there)? does autocollision cause lag? is it in any way worse than .col files? (in terms of performance, not in terms of actual 'collision quality')

[PunkNoodle]

You can use autogenerate instead of none. That will generate the collision, but will need more processing power which some player might not have.

Heh, I was avoiding that.
The autogenerate option will create MANY small colision boxes that will complete the whole 3d model (.dff), but this, like you said, requires more processing power... and considering players' posibilities...
My suggestion is to not use the autogenerate option, so you will have the benefit of more players.
(instead of a big box of colision, you create thousands of small boxes to replace that big box, so there will be more things to be streamed and etc)

If you want my opinion, avoid it unless really needed, it's a huge fps eater.

[jWeb]

TL;DR Yes, you are going to pay for using auto-collision.

Auto generated collision models are as good as regular ones in therms of collision accuracy. Basically that's as accurate as the physics engine can get.

Performance wise though... That's an entirely different story. Because they're not as optimized as the manual ones. So they're using as much polygons as the models. Which defeats the purpose of having separate collision models in the first place.

Take this building for example. As you can see it has holes for windows, doors and some rings around it to give it some shape and sense of realism. And this is a very (manually) optimized model for the amount of detail it provides.

But when you perform the collisions. Obviously you don't need those. Wtf will the player do near the edges those windows or doors. So you can simplify your collision shape to a very primitive one like this:

Which means that the physics engine doesn't have to perform calculations for all the details of the original model. But just a simple shape of it.

And since the actual models in the Vice City game don't even have this much detail. In some cases, all of this can be simplified to a simple box. Not even a triangle mesh. So the collision computations are even faster.

I've even seen roofs made of a couple spheres. Like the gate from the golf club. If you look close. Actually those are in effect only if you're in a vehicle if I remember correctly. Because then you need even less collision detail. As long as the vehicle is large enough to not slip through the spheres. Like this:

So it uses the spheres when you're in a vehicle or larger object. And the regular object when you're on foot or in a smaller object that can fit in smaller places.

And in reality. The player is just a sphere in the shape of a pill (ie. a capsule), walking around. So the capsule is the one that receives the collisions and not the player model. Kinda like this:

And you actually move the capsule when you walk around and not the player. The player model is just placed inside the capsule and plays the right animation to correspond with the capsule movements (like a pupet). It's all an illusion. And pretty much every game uses this technique because calculating the physics for a constantly changing/animated 3d model is not very wise on performance.

Here you can see the illusion in greater detail. In the first image the capsule is still but player running animation is played while the ground bellow it also doesn't move.

However, in the second one. The capsule keeps remaining still still. But now the ground is moving. And you're given the illusion that the player is running because the grown bellow moves at a speed that matches the animation. So in the game you'd actually think it's the player you're controlling. But in reality it's the capsule. The player is also another model like every other model in the game. Except it's wrapped around a biped skeleton with some weighs that define how much area they can deform and that skeleton is animated which forces the polygons in the range of those weighs to be move according to their "bones". Thus the therm "skeletal animation".

Well, in the game it's the capsules that moves an not the ground but you had to see the effect. The capsule is still frozen and because of that, the player doesn't move at all. But you're still under the illusion that it's running. And kinda how games trick you.

And if we're really technical. You're still under another illusion. Because in your video card. Your camera doesn't move around the world. But rather the world is moving around the camera. So yet again, another illusion that you don't even realize. So that statement above is not entirely true. But like I've said. Only if we get really technical.

And you can even imagine the player running like that and the capsule hitting a wall and making the player play the 'bump' animation (if there is one). And you keep on thinking that the player is the one that hit the wall.

And even the player itself is not used for collision testing. But rather small boxes that make up the shape of the player. Imagine that the player is made of card-boxes and you'll understand it. And when you shoot the player in the head or arm. You just shoot the box that surrounds/makes up that part of the body. Which is why you can shoot/touch/hit a few cm/in above the actual model and still hit it. Because you hit the box around it.

In simpler therms. The game goes at great lengths to keep the models simple. Because complex collision models are going to cripple the CPU and make the game run like sh!t.

Which means, that having highly detailed collision models for the stuff around the player is a total waste of performance. Because the capsule doesn't even fit inside those small details to even need collision testing there. And to answer your question. Yes, auto-collision uses the original model as the collision model. Or a very close approximation of it. It all depends on the implementation. Like if it performs some simplification for the meshes before turning them into collisions and such. So if there's no manual or automatic optimizations gong on. Then there's obviously more stress on the physics engine and thus on the CPU. Which results in what you call "Lag".


Getting into more detail about how physics engines work. They sometimes come with some optimizations. For example. Wrapping the actual collision model into a sphere (kinda like the player is inside that capsule). Since spheres are easy to calculate if they collide because all they have is a position and radius. So if no other object is colliding with the sphere then there's no point in testing for collision with the actual model.

Some more complex physics engines will even partition the 3 dimensional space. They group objects that are close and perform collision only for objects in the neighbor. Thus evading even further wasteful collision testing.

Anyway, this was probably out of the scope of this topic but it doesn't hurt to know how they work so you know what's the pest choice you can make.