Bounding a Character to a Walking plane

Started by
8 comments, last by matches81 18 years, 1 month ago
We have the standard 3D character on 2D (pre-rendered 3D) background game. In Blender, we create a walking plane. This plane is then imported into the game engine and is used to bound the 3d character. For simple square walking planes, the algorithm would be simple: if ( pos.x > minx and pos.x < maxx and pos.z > minz and pos.z < maxz ) // allow the move else // don't allow the move But I am looking for theory on the best approach if the plane is not a square. I was thinking that everytime the character attempts to move, I shoot a ray from her center point (offset by the distance she will move) perpendicular to the "floor". If I intersect the floor, then the move is allowed. If there is no intersection, then she is attempting to go outside the bounds created by the walking plane. Does this sound about right? Can anyone think of simpler ways to do this? Not that this is difficult, but there may be ways to make it simpler and thus faster. Any help would be great.
Advertisement
Controls would probably be smoother, if instead of simply Disallowing movment, you let the player bump into the border then slide along its edge.

shooting a ray to the floor? why make it so complicated, if collision detection is limited to a 2d plane, represent everything in 2d. why bother dealing with a z axis? Sure, the character model is 3d, but rendering graphics and collision detection are separate issues.
Z depth is important. Even though the background is 2D, it will have virtual depth (think of games like syberia and still-life). The character will be able to walk behind objects and such, this depth affect can be achieved by using a technique like billboarding. Simple planes with pre-rendered 3d textures place in the scene at a specific depth. But they will be placed in a way that corresponds exactly to their corresponding location in the prerendered image so that when you overlay the billboard on the background image, they align perfectly.

Again, maybe I am off the mark here. Hopefully this clears up what we are trying to accomplish. It just seems really simple to have the graphic artist create a plane in 3d that will define the boundaries of the character.
does every scene contain only a single 'walking plane'?
is this plane aligned with the world's xy coordinate plane?

ifso, then 'ray shooting' is a simple matter of ignoring the z dimension

so... if not already, it is advantageous to align the world coordinate system with the 'walking plane' since that allows you to do cheap projetion of the character position onto that plane, esentially reduces to a 2d problem

when I refer to Z I mean 'height above the floor', not Z-depth/camera distance BTW
ahhh .. ok. i understand. we are new to this, which is why i asked...i'm glad i did.

there is only one flat plane per scene and yes it is aligned with the xz plane (xy in your case)
ok .. i posted a screen shot of the problem (please forgive the ugly graphics .. i used ms paint). the image shows the walking plane (from above looking down). it is more than a simple "is the point the user clicked on in the plane?" question.

Plane

as you can see, the red point is "in the plane", but there is a wall blocking the player. this should result in the player taking a different path to get to the red point.
Looks like it's basically a 2d problem (as has been suggested). If your character doesn't move too quickly, IMO the easiest solution would be a discrete circle vs. line segment test, which can give you natural sliding collision response, among other things. This wouldn't be too hard to implement (the first thing you'll need is a function that finds the closest point on a line segment to a point).
Ok, well the issue in the drawing...

EDIT
yeah, what jyk said, is easy if your character moves only in small steps
However, if your interface is: 'click anyplace on screen and character walks there automatically' then:


I am a big fan of Portal Engines, so to solve that I would:

note that the problem does not occur if the 'walking plane' is convex
-as long as it is convex, then any two points within it can have a straight line drawn between them, and walking from A to B is easy

so to build floorplans like the one in your drawing, I'd split the 'room' up into smaller convex sections (called 'sectors', in Portal Engines)
each convex sector joins to a neighboring sector by sharing and edge called a 'portal'

if you limit sectors to have only 3 sides each(or some other constant) it also becomes easier to check if a point is within it or not(triangle test is easy); however this also trades off with the level artist having to create more of them manually to get complex room shapes

if both points are in the same sector, a straight line path works fine
if points are in different sectors. You'd have to search from the start sector, to the neighboring ones, to find a valid connection to reach the one with your end point, then you walk in a series of line segments from one sector to the next passing through the portals (smoothing out this path is a separate issue for later)


so the idea is, by defining your level structure (walking plane) using a data structure like this, you can come up with simpler collision detection schemes, as well as have useful information about how to find paths between different locations
thanks for all of your feedback ... now to beat a dead horse :-) (i can't help it...i find this so interesting), check out the following link:

Still Life Screen Shot

Here's how we believe this scene was implemented:

1) pre-rendered background
2) low poly models to become barriers (these are placed around the desk where the guy is on the phone and around her computer [bottom])
3) this is the part that has gotten us...the computer area at the bottom we believe to be not only a low poly model for barriers, but also another plane angled to be perpendicular to the camera .. they would then cut out a portion of the pre-rendered background in the shape and size of the plane and place that on that plane as a texture with transparencies. This is what will allow her to appear to walk in front of and behind the desk.

Does this sound reasonable, or does anyone have any guesses as to how a scene like this is done?
Quote:Original post by pbergeron
thanks for all of your feedback ... now to beat a dead horse :-) (i can't help it...i find this so interesting), check out the following link:

Still Life Screen Shot

Here's how we believe this scene was implemented:

1) pre-rendered background
2) low poly models to become barriers (these are placed around the desk where the guy is on the phone and around her computer [bottom])
3) this is the part that has gotten us...the computer area at the bottom we believe to be not only a low poly model for barriers, but also another plane angled to be perpendicular to the camera .. they would then cut out a portion of the pre-rendered background in the shape and size of the plane and place that on that plane as a texture with transparencies. This is what will allow her to appear to walk in front of and behind the desk.

Does this sound reasonable, or does anyone have any guesses as to how a scene like this is done?


1) should be the way they´ve done that, otherwise I´d be quite surprised
2) if you mean that the low poly models act as some sort of collision objects, I´d guess that might work

3) I guess simple alpha transparency could do the trick. The texture for the desk "plane" contains an alpha value for every pixel that determines how transparent that pixel is, allowing also for glass and other transparent things.
Using alpha transparency simplifies cases like the desk quite much. You simply render the background first. After that you render the character at a depth corresponding to its position. Finally you render all the other objects. If the object (like the desk) has transparent portions you will "automatically" see through them. So there´s no need to copy any part of the background or determining whether the character is in front of the desk or behind it.

This topic is closed to new replies.

Advertisement