Question about models in games.
polycounter lvl 11
Hi!
I'm just curious: If you have a model in a game, without the proper scripts you would be able to walk right through it, is that right? So if you want collision on that model, how would that work? How does it work in modern games? How did it work before?
Can anyone explain this to me? I've always thought that there was some sort of rough shape made out of boxes that corresponds with the shape of the model, am I way off? If not, what would this shape be called?
Thanks.
I'm just curious: If you have a model in a game, without the proper scripts you would be able to walk right through it, is that right? So if you want collision on that model, how would that work? How does it work in modern games? How did it work before?
Can anyone explain this to me? I've always thought that there was some sort of rough shape made out of boxes that corresponds with the shape of the model, am I way off? If not, what would this shape be called?
Thanks.
Replies
But yes, the very basics of it is that it is a rough low poly shape that matches the silhouette of the in-game model. The creation process is simply imagining just how accurate - and simple - the collision needs to be so that the player bumps into the object and it seems realistic.
Unreal accepts custom built collision, it can automatically create very simple collision based on the object, or the designer can always go in and place blocking volumes. It all depends on the object and how it is used and where it is in the level.
What would one usually call this shape? My friend insists it's called a skybox, but somehow I doubt that.
A collision mesh is generally refered to as... a collision mesh, or collision geometry, or collision shapes, or even just 'collision' on its own if you're lazy.
Your friend is either misinformed, or deliberately messing with you.
http://en.wikipedia.org/wiki/Skybox_%28video_games%29
Yeah, he is misinformed.
Thanks again!
From a purely technical standpoint you're actually dealing with two issues here.
One is collision detection, and the other is collision response.
Collision detection is simply determining if any part of object A intersects or touches any part of object B. How precise this is has a number of methods, but the simplified collision mesh is the usual way these days. Often a collision detection scheme will work inwards on an object, starting with its bounding box (box containing every point in the model), as that is a simpler check, and if that collision check is positive, then the more finely detailed mesh(s) or primitives are checked.
Earlier 3d games often used a single collision primitive instead of a collision mesh, a cylinder was common, as well as a sphere. Both are mathematically simple to check against in terms of other bodies or lines, and so are fast to use.
with sprite games there are a number of ways to do it. some simply define a region relative to the sprites origin as the hitbox, or just use the bounds of the sprite. Checks are just line vs square or square vs square.
Per pixel collision detection can be done with a routine to get sprite color at location. If sprite A's bounds are over sprite B's then get the pixel in sprite A that is closest to the origin of sprite b. Translate those coordinates into sprite B, get the color in B at those coordinates, if its transparent/masked, no collision, if its not, a collision occurs, and you go from there.
A collision in this way is just a true or false outcome, what the game DOES with that is the tough part.
Applying damage, halting movement, all sorts of things happen in regards to collisions, but none of them are automatic.
The math behind it all, like most basic things in games, is relatively simple 3d geometry that looks a lot more imposing than it is. If you feel like learning it there should be plenty of web resources for it, or just ask and the thread can go that direction
That made my right eye twitch.
This made my right eye explode.
killingpeople: Sorry about your eye.