21 réponses à ce sujet

[TheOneBlackRider]

Hello again.

This tilesetting starts to be fun, but sadly, I ran into a new riddle with a walkmesh.

I have this model with an upper and lower walkable part. Basically it is working but this issue makes no sense to me: When trying to walk onto the lower side part (leaves-definition) from the neighbouring standard NWN-terrain-tile, the toon would not continue walking onto my "new" tile. It works, if I enter from the long side and leaving the new tile in all (lower) directions.



The drop walk from the upper parts may be ok (also happenes in both directions - forgot the upper green arrow tips here), since it should be (and is) possible to cross onto a connected upper part tile. But I don't understand, why it does also stop the drop-walk along the long upper side. The pic shows a "not walkable" (=violett) definition, but I also tested it with something walkable (eg. dirt) - the toon won't "drop". Well, maybe it's because that lower part is still part of the same tile... (just guesssing).
The upper part-phenomen is not a problem (I just would like to understand it). But the lower side-part is a problem.
I even ran this model through the "cleanmodels"-tool, but still no change.

I encountered the same issue on a tile in a different set (not by me) and here the same thing: The walkmesh looks right, but the toon stops comming from the outside, but can walk off it from the inside.

Again hopeing for enlightment from you! :innocent:
Thanks.

Modifié par TheOneBlackRider, 13 juin 2012 - 08:47 .

[Zwerkules]

Is this a kind of wall? If so, the 'not walkable' should be 'obscuring' because a wall shouldn't just be not walkable but also block sight and missiles.
To find the cause of your problem, first turn your model so that you can take a look at the underside. If you have faces there facing down, that's what is causing your problem.
If not, did you perhaps move vertices around so that two of them that are part of the same face ended up at the same coordinates? That way a face is reduced to just an edge, but it is still a face and there's no gap in the walkmesh, so no error will be reported.
This will result in lines that can only be crossed from one direction. Since those faces are not visible, it is very hard to find them.
Click on a face near the part of the walkmesh you can't cross and then rights click it and select 'Hide (Mesh)'. Repeat this with all the faces there until you find a face that is so narrow that it is just an edge and remove that.

Those are the two reasons I know of that can cause the effect you're describing.

Modifié par Zwerkules, 13 juin 2012 - 09:52 .

[Failed.Bard]

TheOneBlackRider wrote...

Hello again.

This tilesetting starts to be fun, but sadly, I ran into a new riddle with a walkmesh.

I have this model with an upper and lower walkable part.

...

I believe that's the part that's the issue.  Despite how it may look, the aurora engine handles walkmeshes as a 2d plane.  You can't make a walkable area over another walkable area.

[Rolo Kipp]

<letting his hair...>

Zwerkules wrote...
...
To find the cause of your problem, first turn your model so that you can take a look at the underside. If you have faces there facing down, that's what is causing your problem.
...

In Max I like to select the faces and turn on "Show Normals". This puts a single blue "hair" pointing out of the face to show you which way it's facing. They should all be pointed up.

If a single face is pointed the wrong way, it really stands out, even if heavily textured.

If a whole bunch of faces point in similar directions, it looks like a crew-cut ;-)

<...down>

Modifié par Rolo Kipp, 13 juin 2012 - 11:24 .

[_six]

The engine can only reliably handle a walkmesh if no two vertices have the same XY location, regardless of Z component. So if those sides are totally straight, make them at an angle (moving the lower verts out by 1cm should be enough).

Technically it is possible to have several -faces- at a single point. Although the engine will only ever use one (upward-pointing) face for player movement, you can get away with some dodgy camera blocking stuff. But that's not relevant here so forgot I said anything.

What's worrying to me about your walkmesh is the faces at either side. If this is for continuous terrain, crosser or raise/lower tile then you should not fill in the sides. The walkmesh exists to give the walkable point at each XY location to the player, so filling in sides will confuse the engine muchly.

[s e n]

the trick with walkmesh stuff is to start easy (2 faces flat square tile) and then slightly change the geometry, seeing what happens step by step. another thing you can do is to open tiles from other cc creators tilesets as well as from original bioware tilesets, everyone has its very own and personal approach on how to make it work fine, also, different types of tiles lead to different techniques.

my suggestion is to keep the facecount as low as you can, welding verts, simplifying geometry and, taper faces that share same xy but different z coordinates. i found that engine confuses itself even in the reversed face camera blocking stuff six mentioned, if there is some xy vert share.

on the + side, making walkmesh is the stuff with what you really learn 3dmax and its utlis/plugins, and its fun too

last 2 things:
-when you have walkmesh issues on tile edges, alwyas double check edge verts (especially corner ones) coordinates, and fix em if they are not exactly where they should be (aka the edge, and remember adiacent verts should share same z value, you can imagine the shared edge as if mirrored from one of the two tiles that share it, or as close as possible if you are not a perfectionist.

-all verts have to be welded to work, this a common issue when creating woks from visible geometry: in the process of reducing and modifying it to create the walkmehs, you forget to weld a few verts, and thats where your issues come from

[TheOneBlackRider]

Ha! Always when I think, I made a step ahead in understanding all this and then see your (helpful) replies, I feel like, I still don't know much!


Thanks to you all! I've looked under the mdl and tried to locate faulty verts but I didn't spot any (which doesn't mean, that there aren't any!).

But all your replies pointed mi into a new direction and I did a new approach with just using one plane and payed attention to no vert beeing on to of another:


And now this model works fine!

For my first try, I first created a box, then the palne for the lower part, and (after adding the "Edit Mesh"-modifier) "Attached them". I bet, within this process, verts got stacked aso.
Solved now.

Now, this will be my next mdl:


And I found, that's pretty tricky to work arround a corner with just one plane...
I'll let you know, if I succed!

[Bannor Bloodfist]

You are still using the wrong face type for the vertical walls. Instead of type "7" (no-walk), use type "2" (obscuring) as _Six previously mentioned.

The no-walk face type was intended only for very limited use, specifically to mark spots on the floor that have other objects on top. IE, you put a small square of type 7 where a bush or planter might be. This alleviates the need for a more complicated walkmesh that has vertical blocking faces that are truly not needed.

Basically, ANY vertical face would be a type 2 face except maybe for low walls. Otherwise, you end up with the ability to shoot an arrow through a house and hit the creature on the other side without even being able to see them. Note; they can hit the player too which makes for very upset players when they are getting killed by creatures they can't even see.

[Zwerkules]

TheOneBlackRider wrote...

Now, this will be my next mdl:


And I found, that's pretty tricky to work arround a corner with just one plane...
I'll let you know, if I succed!

There's a way to create a walkmesh like that very fast. Create a 1000x1000 plane with 2 length and 2 width segments with its center at x=0, y=0 and z at the ground height of your tileset. Then convert it to an editable mesh and apply a walkmesh modifier to it.
Move the vertice in the middle of the tile and the two vertices at the middle of the edges where there'll be raised terrain in the adjacent tiles to the right positions. Let's say they are at -500, -200, 0;  200, -200, 0 and 200, 500, 0.

Now select all faces and enter 3 (for grass) as material id. Select the two faces that are to be the raised ones and enter 2 (obscuring) as material id (don't use 7). Keep them selected and from the field where you enter the material id scroll up until you see 'extrude'. Enter how many cm higher the ground should be (for example 500 for 5m) and press enter.

Now all the sides of your raised terrain will aready have material id 2. Remove the faces you don't need.
Select the two faces at the top of the raised terrain and enter the material id they should have (for example 1 for dirt).

As Six pointed out no two vertices should be at the same XY location. Move the three vertices of the raised part of your walkmesh a few cm away from the lower edge of your raised terrain. Instead of -500, -200, 500;  200, -200, 500 and 200, 500, 500 you'd move them to -500, -195, 500;  195, -195, 500 and 195, 500, 500.

You can use this method to make walkmeshes for the other kinds of raised terrain you need, too. Always select all the faces that should become the raised terrain, change the material id to 2 and extrude them, etc.

Modifié par Zwerkules, 14 juin 2012 - 06:11 .

[TheOneBlackRider]

Allright! I somehow forgot about that "don't use 7", because that first tile finally worked and I was heading for the second one. I will change that. Good, that this was pointed out again. Thanks again.
And I'll go for Zwerkules' way of creation next.It contains some (to me) unknown actions, so I might take another step forward.
You'll be informed.

[TheOneBlackRider]

That "extrude" worked like a charm! Great! Just what I wanted (I was going to try to do it with a 3x3 setting to get those raised edges, but the corner would not be a real corner then). Zwerkules, that saved me some time!

Sadly, I'm fighting with my good old friend "texture" again. Basically I did the following (modelwise): One tile 1000x1000 (raised platform). For the 2nd tile, I resized (=moving the verts) that part of the 1st mdl to 1000x500 (=half) and for the 3rd one, I resized the 2nd one to 500x500 (=1/4). Doing this, Gmax squeezes the texture, so tile-textures don't match, when put next to each other. Zwerkules wrote out a little tutorial once (for a misplaced roadtexture) but I just don't manage to get it right.
So: Is there a way to move verts (= rezize a plane/platform-box) without the texture beeing adjusted to the new (in my case smaller) shape?

Modifié par TheOneBlackRider, 15 juin 2012 - 10:50 .

[s e n]

if you dont collapse the uvmap it shouldnt stretch, by the way you just throw the uvmap on the mesh and give it same values, being sure to set the center gizmo like your previous one. this way you can also mass map all your grass meshes at once, being sure they keep the seam even if their tile root isnt at 0,0 (it should be at 1000 multipliers along the axes anyway for that to work)

[TheOneBlackRider]

I forgot to post my success! Thanks again for all your support. Special thanks to Zwerkules for that "raising"-tutorial.
As to the texturing, _sen pushed me into a workable direction (thanks), so now I created simple planes - also for the sides - instead of a box. Planes are quiet controlable for an elementary school level modeler.
Again: Thanks to all!

[Bannor Bloodfist]

Hehe... we all had to start somewhere, and the learning curve can be as steep as you want, although, typically steeper than you might otherwise think without tips being giving by other modders.

There is almost always something "new" to learn.

[TheOneBlackRider]

It's so good, that you experienced people are still around and find a minute to help! Just Great!
The more I look into the work of veterans, the more dwarfed I feel! Definitely has a potential for endless learning...

[Bannor Bloodfist]

Oh, sorry for this really late reply to this but there are some things you need to watch and set correctly.

The PATHNODE as defined in the tile(s) .mdl file needs to also be correct.

There are several tutorials listed on the site in my signature that may help with that. Some of the pathnodes look a bit confusing, they may work, but then again, they may appear to cause a toon to get stuck.

For a specific tile that has walkable sections on your upper and lower parts of a tile, but that are not truly connected, IE only the roof and street level are walkable, with a high wall/building face in between, you would need a pathnode that specifically handles that or your toons can get easily stuck.

Sorry,.I am not at home on my normal computer so I don't have access to the many different screen shots I would use to explain the different pathnodes available. Here is a link to the "Pathnodes" thread that is available in my tutorials section from the original CTP site now hosted on Harvest Moon. There are many tuturials in that same forum and a few others located in various other forums there as well.

[TheOneBlackRider]

Thanks for still checking on this, since this one is a bit older by now.
And meanwhile I managed all the tiles I wanted and have them integrated into the DLCR-project. All works fine.
And still: Those pathnodes were still a bit of a riddle to me (but since my stuff was behaving, I didn't dive any further into it). And the link to the "Pathnodes" thread clears quiet a bit.
So thanks for pointing me into that direction!

[Bannor Bloodfist]

Believe me I know how you feel when you first start looking at the actual shots of what a pathnode is.

Black is walkable though, and intersections to the edges are where most toons will attempt to walk onto a given tile. If there are not fairly direct connections to any other tile across an area, then the toon will get stuck and just stand around trying to figure out how to move around.

what is most confusing is looking at a given pathnode and seeing two separate bars that go from side to side, each with a single connection in the middle going to the outside edge. The particular path node I am referring to is the "C" (capitol C) pathnode. That is actually for a wall, OR for a raised tile. Can be used for either one. What it shows is that the toon can walk along the edge of the wall, on either side, but can NOT cross the blank white section in between. This would be the same on a raised tile... you can walk right up to the edge on the TOP side, but not be able to get down, OR walk right up to the edge on the lower / Bottom side and not be able to get up to the top.

The most confusing are the double lower case letters, and to be honest, those are seldom used. They were actually created by Bioware for Chandigar's original Aztec set. They really only work well with that set, at least, I have not seen any other builder make use of them.

That was an attempt by Bioware to help the community because at the time of that particular aztec set release, toons were getting stuck all over the set due to how Chandigar had created some strange walkable sections. That set was "patched" by Chandigar to use the new pathnodes with the help of the CTP... we told him which pathnodes to use for which complex tile etc...

Anyway, one way to learn the different pathnodes, is to do a search on "pathnode=?" and see what is applied to various tiles by the author of a given set. The more correct tilesets will use many of the various pathnodes, while the most incorrect sets will primarily use "Pathnode A" which is supposed to be used for a completely flat tile with nothing blocking any movement from any side... think a flat grass plane. However, tileset authors that have not learned how to apply the correct one, will use A as the default as it appears to work for many situations.

When you have a toon getting stuck, most especially followers of some sort, it is usually a bad series of pathnode assignments in the .set file. Doesn't take a heck of a lot of effort to correct, but you have to manually edit the .set file and assign the correct pathnode to each tile. Typically I do this by loading the tileset in the toolset and doing some painting of the various tiles to see if I can find the bad ones, OR finding an issue while playing and then investigating what tiles have the issue via the toolset again.

[TheOneBlackRider]

Thanks for further explanations.
But now, I a question comes up to my old brain... Maybe I missed the point or I'm a bit stupid...
Why those pathnodes, when possible movement is (also) managed via the walkmesh? I mean, I could create a walkmesh like in those screenshots above and use pathnode A and all works well. So why still fiddle with pathnodes, if the walkmesh does the right restrictions.

[Zwerkules]

TheOneBlackRider wrote...
Why those pathnodes, when possible movement is (also) managed via the walkmesh? I mean, I could create a walkmesh like in those screenshots above and use pathnode A and all works well. So why still fiddle with pathnodes, if the walkmesh does the right restrictions.

Because if you just use the pathnode A the npcs will get stuck. Let's say you have a wall that goes from the left side of the tile to the right side and used the pathnode A instead of C. When you control the toon and see the wall you know you can't just walk through it, but an npc is told by the pathnode that walking from the bottom of the tile to the top is possible and will try to do so. The walkmesh will block the movement when the npc reaches the wall, but the npc won't look for a way around the wall, because it 'thinks' there's a way through it. That way it will get stuck next to the wall.

[OldTimeRadio]

TheOneBlackRider wrote...
Why those pathnodes, when possible movement is (also) managed via the walkmesh? I mean, I could create a walkmesh like in those screenshots above and use pathnode A and all works well. So why still fiddle with pathnodes, if the walkmesh does the right restrictions.

Walkmesh decides where you can walk inside a tile.  If you click on a destination 4 tiles away, though, pathnodes give the game a good idea of how you're going to get from your origin to your destination without having to calculate the entire actual path- until you arrive at each of the tiles, which is where walkmesh takes over until you leave the tile again..

Walkmesh = Walking inside a tile
Pathnodes = Walking between tiles or going through multiple tiles.  Mostly concerned with where you're able to leave a tile and come into the next.

So you'll never really see the how pathnodes affect a tile just clicking inside a tile.  You'll see their effect clicking on other tiles, like a tile 3-4 tiles away.  Console renderaabb 1 and rendertilepathnodes 1 help view the pathing information when you're playing and can also be used to help place placeables in areas where they won't likely interfere with distance pathing.  It affects a lot more than players, too: NPCs who walk waypoints rely on having good pathing in and between tiles.  If they don't get it, things can become a CPU-hogging mess.

[TheOneBlackRider]

Again: Learned something!
(Sometimes I wonder, how all this special knowledge made it all the way from the Bioware-creators to you custom genius-people! Thank god, that the knowledge has been shared!)
I guess, I have to look into my creations again... (Seems to be a never ending stroy
Thanks to you all for the enlightments.