Walking on walkmesh.

  • Thread starter Thread starter Akari
  • Start date Start date
Status
Not open for further replies.
A

Akari

Guest
Does anyone have idea how to write walking on walkmesh or know how it was done in FFVII and other games? I just don't know algorithm... they way I wrote it is too buggy and not universal.

Please help.  :oops:
 
Greetings Akari.

My Suggestion for the walkmesh walk is probably a bit simplistic.
First you need to create a 'walker' or something that rests on the mesh.
I suggest an AXIS (XYZ thing) to start with.  This is just a series of lines.
You have initial start points etc. already right?  So you need to compute the next walk point by seeing if the point you are going toward is within the walk mesh.  I recomend the simplest method first, checking each polygon (2 dimensionally IE vertically) to see if the walker is within it.  When a hit happens you stop checking the walkmesh.  If no hit happens the walker stops moving. You need to compute a step point I believe.

FF7's walker has a 2d point and direction.  The object walking gets drawn based on what polygon it's within (IE it's translated XYZ wise to the point it intersects the walk mesh).  So if its facing one way and you start 'walking' that direction compute the next step point based on that.  If it is within the walkmesh then move the difference by each frame for a step.  Next if it falls outside the walkmesh, then truncate the location to within the walkmesh (IE CLIP it to the walk mesh by faking the current location to the end point is a line).  If you are up against something you 'slide' along it.  IE you project a displacement along the edge of the walkmesh based on the distance you would move on the edge of the walkmesh if you made that step.  This creates the sliding affect.

Using the old direction buttons to orient the walker you have thus 8 directions at 45 degree angles.  You set the direction based on the direction of the buttons. Speed is a factor of weather the run button is being pressed.

Cyb
 
two cents...
remember that entitiy models have a root bone that runs from the "floor" to the center of the model (usually). The "bottom" of the root bone is what's tested against the walkmesh.
 
If you are up against something you 'slide' along it.
Click to expand...
Not forgetting the SLIP opcode to modify this behaviour.

You will also need to take into account the "I" value for each poly, that is, an identifier (as far as I know). It becomes particularly important for such functions as the ladder opcode which requires an I-value for the triangle found after climbing, otherwise a crash will occur. I've also had some nasty crashes trying to switch a walkmesh with an entirely new one and I have a feeling it's to do with expected values of I somewhere in the script.
 
Walking on walkmesh has been implemented. And it seems working quite well :-P
Now I working on gateway =)

Do some one has info about last parameter in trigger?

struct Trigger
{
    Vector3 point1;
    Vector3 point2;
    Vector3 pos; // place where char will apear after transfer.
    S16 destindex; // index in maplist
    U32 unknownl; // 0x84848484 ot zero ?
};
 
Last edited:
My Suggestion for the walkmesh walk is probably a bit simplistic.
Click to expand...
Simple solutions are not always wrong!
First you need to create a 'walker' or something that rests on the mesh.
Click to expand...
That is actually what many (most?) games do. You may see a fully animated figure, but most of the collision detection and resolution is done on an ellipse, capsule or cylinder.
You have initial start points etc. already right?  So you need to compute the next walk point by seeing if the point you are going toward is within the walk mesh.  I recomend the simplest method first, checking each polygon (2 dimensionally IE vertically) to see if the walker is within it.  When a hit happens you stop checking the walkmesh.  If no hit happens the walker stops moving. You need to compute a step point I believe.
Click to expand...
There is one optimisation you can do: The characters in FF7 can not jump (except in scripted sequences), so you'll never really leave the walkmesh. So you find a current triangle, and check if the motion vector crosses any of its edges. If it does, you check if there is another triangle sharing the edge, or if it is a border edge. You can precalculate that information when loading a walkmesh. If there is another triangle that triangle becomes the new current triangle, if there isn't the motion vector gets clipped by the triangle edge, or you can implement some slide behaviour. You only need to do a full search if you teleport to a new position.
(I'm sure this is something you thought off as well, but I thought I should mention it anyway.)
 
Akari: Woo!
Mickey:
I hadn't thought of it, that's why it's always good to have more than one person looking at a problem ;)

All:
All right, we have some interesting possibilitys here.
The train yard section adjacent to sector 7's train station has some interesting things in it.
There are 2 locomotives and 1 car (3d models).
Being the enterprising and goofy person I am I was playing with these (after cloud finishs reactor 1 and Tifa's bar sequences).
Observation, the trains are part of the walkmesh OR add and subtract to sections of the walkmesh.  Either way you can WALK on the car. I know you can walk INTO the trains so they are part of the walkmesh in someway as well.

Cyb
 
Hmm, just some fast thoughts (I don't know the map name for that section so I can't really check it):
If the walkmesh contains all the walkable areas in the map, wouldn't the walkable areas in the train and car be already included in the walkmesh?
If not, then the game must check collisions on the train and car meshes too.
I don't really see the problem here.

On a side note:
I know there are some map viewers for the prerendered part. Has anyone tried to draw the walkmesh on top of it to see if it matches?
 
As far as I know we aren't entirely sure how the walkmesh scales (/camera zooms) to fit the background. That said if you check the unknown camera value which Kero had down as a potential scale value, it would seem that the smaller fields have smaller unknown values whereas something like the ancient forest has a much larger value.

Akari: another update for you on the Wiki which might fit in with what you're currently doing, I figured out what IDLCK does (a walkmesh/edge-related op).
 
Akari: another update for you on the Wiki which might fit in with what you're currently doing, I figured out what IDLCK does (a walkmesh/edge-related op).
Click to expand...
Hmmm.. may be this is how they handled train graveyard =)
I'll check this tomorrow.
 
It's definitely how they did things like the clock hands in kuro_4 (where you have to control the clock hands to move to different rooms, obviously the remaining hands can't be walked on but the walkmesh is still there), and things like elevators where you can get on but not get off whilst the elevator is moving (that one in Junon, for example, the exit to the elevator is still there but should not be accessible until the OFST has reached the top of the elevator shaft).
 
Interesting: It looks like they handle the trains with a trigger and a jump.  (IE you move to point A jump to point B and hide the model in the train).
After the first train is moved the little 'gate' marker to climb up disappears. I think they clip that after the train is moved.
I was hope (vainly I guess) that one could do something interesting to the walk mesh. Well in any case.
The models used in the field for objects are in the Field file right?
Back to eyeing those files again (heh).

Cyb
 
Status
Not open for further replies.
Back
Top