17 réponses à ce sujet

[DynV]

So I'm creating an Inn room and I've placed cushions over a carpet for a cozy resting area but the character now has to walk around cushions, which doesn't make sense to me, as if there's a similar setting IRL I'd surely walk on cushions (unless a women was looking  ).

As the property Walkable doesn't have a description on the toolset version 1.0.1765.0 I'm wondering what's the difference between using that, perhaps in combination with another property, versus Static false and Dynamic Collisions false.

Thank you kindly for your help

Hmm!  Isn't there individual thread options (subscription, signature, ...) on this forum? 

[kamalpoe]

Dynamic collisions basically means it can block you from walking there as long as it exists. But if it's destroyed, you can walk there. Think of a barrier.



Walkable means you can walk right through it.



The best way to handle is would be to make them all environmental objects. Environmental objects do not affect where you can walk.

[DynV]

kamalpoe wrote...



The
best way to handle is would be to make them all environmental objects.
Environmental objects do not affect where you can walk.

Thank you for that suggestion.

kamalpoe wrote...

Dynamic collisions basically means it can block you from walking there as long as it exists. But if it's destroyed, you can walk there. Think of a barrier.

Walkable means you can walk right through it.

I still don't know what's the difference that the OP queried:

DynV wrote...

[...]property Walkable (true) [...] versus Static false and Dynamic Collisions false.

[kamalpoe]

A static false and dynamic false object could be destroyed and still block walking. Walkable will never block walking.

[dunniteowl]

Walkable = True means you can walk right through it, it has no collision or walkmesh data used.

Dynamic Collisions = True means you can use it in the module area to block a pathway, but, if it is set to Destroyable = True, it will not bake into the walkmesh and characters can destroy it and then walk through where it once was.

Static = True I have no idea what that does. Normally when the word Static is used, it means something that does not move. Which is funny, because we call it static electricity when you get shocked from moving across the carpet and then touching something.

When you set things to Environmental Object, they do not bake their data into the walkmesh or provide collision data. If you use items as Environmental Objects and wish to have them block the walking of characters, you will have to edit the walkmesh with the Walk and No Walk tools in the toolset under Terrain Tools.

kamalpoe did actually answer your questions, I'm just not sure if he answered them in the way you asked. For that matter, I am not sure I did, either. J'espere aidez t'comprends. Sorry, that's the best I can do for my fractured French. "Hope this helps you to understand," is what I am trying to say.



dunniteowl

[Lugaid of the Red Stripes]

Everything's pretty much been covered already, but let me try to explain it all in basic terms:

Each area has a walkmesh that determines where a creature can move within that level. It's basically a big grid, where different parts can higher or lower, but nothing can overlap. So you can walk up the gentle slope of a hill, but you can't walk both over and under a bridge, you have to choose on or the other. The walkmesh is recalculated whenever you bake an area. Toggle the 'baked' button to see what the final, baked walkmesh looks like.

In exterior areas, you can modify the walkmesh directly with the terrain tools, but in interior areas the basic walkmesh comes from the tiles. The walkmesh can be further modified by placeables and walkmesh cutters.

Placeables can do two different things to the walkmesh. Most placeables simply cut an outline of themselves out of the walkmesh, so that creatures can't walk through the placeable. If you set the placeable to walkable=true, then the placeable won't modify the walkmesh and creatures can walk through it as if it weren't there. Some placeables, like bridges, curbs, balconies, some buildings, and the walkmesh helpers, have a built-in walkmesh that allows creatures to walk on top of the placeables.

So, it's easy to create a pile of cushions that the player can walk through, but it's more difficult to create a pile of cushions that the player can walk on top of. You can use a walkmesh helper, but unless the walkmesh helper is very close to the ground (0.1m), you'll just end up with a raised piece of walkable terrain disconnected from everything else. You could put an NPC on the cushions that way, but the player would be unable to reach them.



Placing lots of placeables in a single tile can mess up the baking process, so it's usually best to make all your placeables walkable (or better yet, environment objects), and use a walkmesh cutter to carve out an un-walkable area by hand. I tend just to leave them as is, to make pathfinding easier.



But what if you want to make a temporary block in the walkmesh, like a boulder obscuring a hidden passageway? That's where those static and dynamic collisions come into play. If Dynamic Collisions is set to TRUE, the placeable will block (collide) with any creature that tries to move through it. (Most creatures have dynamic collisions set to true as well, so that they don't get all bunched up in eachother's space). The pathfinding AI will take all this into account, and try to find a way around the block. To check the area blocked by dynamic collisions, turn on the c2/c3 data.

To remove the block, the placeable has to be both walkable and non-static. A non-walkable object would permanently cut up the walkmesh, even after the object had been destroyed. Static objects can't be destroyed, I don't think they even run scripts, nor can they be accessed through scripting. If all that's set, all you have to do is use DestroyObject in a script (or have the PC bash the thing to pieces) to get rid of the block and allow creatures to pass through. (In practice, it's usually better to use a collision box or ball to do the blocking, and a non-colliding placeable for the visual.)



Other fun facts: Placeables can block the camera and LOS, but environment objects don't.

Many placeables do unexpected things to the walkmesh, so make sure they're turned into environmental objects (e.g. chandeliers, rugs, any low-laying object).

More than a few unwalkable placeables in a tile will often cause the whole tile to become unwalkable.

[DynV]

Lugaid that was very informative.  Thank you so much!

Lugaid of the Red Stripes wrote...

Placeables can block the camera and LOS, but environment objects don't.

Searching for "LOS" on this forum (NWN2 section) yeilded nothing. 

[dunniteowl]

LOS = Line of Sight.

dno

[Kaldor Silverwand]

Lugaid of the Red Stripes wrote...
But what if you want to make a temporary block in the walkmesh, like a boulder obscuring a hidden passageway? That's where those static and dynamic collisions come into play. If Dynamic Collisions is set to TRUE, the placeable will block (collide) with any creature that tries to move through it. (Most creatures have dynamic collisions set to true as well, so that they don't get all bunched up in eachother's space). The pathfinding AI will take all this into account, and try to find a way around the block. To check the area blocked by dynamic collisions, turn on the c2/c3 data.
To remove the block, the placeable has to be both walkable and non-static.  A non-walkable object would permanently cut up the walkmesh, even after the object had been destroyed. Static objects can't be destroyed, I don't think they even run scripts, nor can they be accessed through scripting. If all that's set, all you have to do is use DestroyObject in a script (or have the PC bash the thing to pieces) to get rid of the block and allow creatures to pass through. (In practice, it's usually better to use a collision box or ball to do the blocking, and a non-colliding placeable for the visual.)

The bolded statement above is not correct You can have a placeable be a block by having it set to dynamic collisions and non-static. It does not need to be set to walkable. Non-static objects do not permanently affect the walkmesh. Static objects do.

In my King's Festival campaign I use boulders to block access to secret passageways. They are set to dynamic collision, they are not walkable and they are not static and they are not environmental. When destroyed the space they were in can be walked through just fine.

Regards

[Lugaid of the Red Stripes]

KS: Do you ever bake the area after placing them? That's the only reason to set them to be walkable, so that they don't result in a baked-in non-walkable terrain mesh.

[DynV]

Just like the Dynamic Collisions description is "If set to true, and the object is non-static, the object will have collision and the player will not be able to run over or through it.", I'd very much like to see a description for Walkable.

Edit: While writing this Lugaid replied, I suppose the description would be "Insure that baking doesn't make a hole in the walkmesh with the object even if other settings would have a similar result." ?  By similar result, I mean same area blocked.

Modifié par DynV, 18 septembre 2010 - 07:01 .

[Lugaid of the Red Stripes]

The baked walkmesh is calculated when you build the area, then at run-time, as you're playing the game, the engine looks at objects with dynamic collisions and calculates on-the-fly how they affect the walkmesh. So the baked walkmesh is permanent, can't be changed in-game with scripts, and dynamic collisions can be changed (that's why they're called dynamic) in-game.



The 'walkable' property set to true simply means that the toolset doesn't consider this object when baking the walkmesh. It doesn't consider Environmental Objects, trees, or doors either, and Kaldor adds that it also doesn't consider non-static objects (he's right, I tested it).

[dunniteowl]

So as a point of standardization: For something you wish to block until destroyed, it should be set to:

Dynamic Collisions = True

Walkable = False

Static = False

And that way you know you're creating something that won't change the baked walkmesh, but, when destroyed or removed, will allow someone to walk by on the walkmesh. Until such a time as it is destroyed or removed, it will block with it's collision data.

That sound about right?

dunniteowl

[Kaldor Silverwand]

Yes

[Kaldor Silverwand]

Pardon me fogginess. Aye, matey.

[SkywingvL]

To clarify --

There are two types of 'collision' processing here:

1) Static collisions. Static collisions are intersections tested against the baked walkmesh produced by the toolset. Only the walkmesh and the object trying to move (i.e. the creature) are involved in static collisions; the engine doesn't even look at the placeable (or whatnot) that is being 'walked on', just the walkmesh data laid out by the toolset. Effectively, an object that is a static collider is burned into the map itself at baking time; the engine doesn't even look at the original object, just the imprint it's left on the walkmesh as it was baked.

2) Dynamic collisions. Dynamic collisions are performed against collider meshes that are a part of a placeable's model instead of the static walkmesh produced by baking. If the placeable being collided against goes away, then that space can be inhabited by other objects, such as a creature trying to walk by. A dynamic collider doesn't have its associated walkmesh baked into the map at bake time; the walkmesh considers the ground there to be walkable.

Now, if a placeable is flagged as walkable, then the toolset doesn't bake it into the walkmesh and the game engine ignores it for dynamic collision intersections even if the placeable weren't static.

If a placeable is flagged as static and not walkable, then it will behave as though it were a static collider (as outlined above).
If a placeable is flagged as not static and not walkable, then it will behave as though it were a dynamic collider (also as outlined above).

One additional point worth mentioning is that the underlying pathfinding system itself only knows about the walkmesh; it doesn't have any concept of dynamic colliders. When the toolset bakes the walkmesh, what it's actually doing is creating instructions that tell the engine a complete path for how to get from any walkable point in the map to any other walkable point. Now, because dynamic colliders don't get baked into the walkmesh, the pathing instructions baked into the map don't take them into account and thus may lead to objects trying to walk through a dynamic collider.

If the collider exists, this of course fails. There is some basic heuristic based retry logic in the engine to help NPCs 'feel their way around' a dynamic collider like this, but it's not as robust as the baked pathing instructions.

What this means is that relying heavily on dynamic collisions is likely to make objects behave unintelligently in pathing (not to mention causing your players headaches if they try and use click to move). Thus, it's best to use them sparingly, such as when you want to temporarily block a hallway with something that you would like to destroy later on.

Some additional points for the technically curious:

- Static collisions are much faster for the engine to handle than dynamic collisions.  In fact, most of the time the engine doesn't have to do anything to make sure that static colliders are honored, because the toolset's precomputed pathing information (created during area baking) always moves objects around static colliders.  In contrast, dynamic collisions require comparatively much more expensive mesh intersections if they come up in pathing/movement.
- The difference between a .trx and a .trn file is that the .trx is the baked walkmesh, with the pathing instructions embedded and with static colliders 'cut out' as appropriately.  The .trn file doesn't have walkmesh from static colliders merged in.  Both files also contain the terrain mesh for exterior areas.
- Static colliders have a 'WALK' mesh in their MDB(s) describing how to merge them into the underlying terrain (or interior tile) walkmesh.  This is used by the toolset to produce the final .trx walkmesh data.
- Dynamic collisions don't use the 'WALK' mesh in a placeable's MDB(s), instead they use the C3/C2 meshes.
- Environment objects aren't considered for line of sight or collision processing of any sort.  They are purely decorative.
- Doors also participate in collisions similarly to how I have described above.  If a non-static door is closed, it's a dynamic collider; if it is open or destroyed, then it doesn't collide with anything.
- Placeables created on the fly by the DM client are never static placeables.  In fact, you can't modify the properties of a static placeable (or an environmental object), or even create a new one, except during design time in the toolset.
- Walk across sound effects come from the walkmesh itself, so making a placeable a dynamic collider will prevent it from altering the walk across sound effects (from whatever the default terrain that the placeable was placed on).
- The Client Extension has several useful tools to help you better understand how the engine will interact with your walkmesh.  It contains a feature that lets you view the walkmesh of a map directly in its Area Map window (click on the Area Map window and hit T to cycle through terrain detail levels until you see the walkmesh, which is drawn as a series of purple triangles).  Diagonally shaded purple triangles represent regions that are not walkable.
- The Client Extension also lets you examine what paths objects will take from point to point.  Hold down CTRL and move the mouse on the CE's Area Map window to see how an object would move from your location to the target location based on the walkmesh.  A red line indicates that there is no reachability.
- Similarly, the Client Extension also lets you check how the game will calculate line of sight from where you're standing to another point; hold down X and move the mouse on the Area Map window.  A red line indicates no line of sight.
- For the particularly adventurous, the NWN2 Datafile Accessor Library (C++) contains code to interact with the raw walkmesh (and other collision meshes) in their on-disk form.

Modifié par SkywingvL, 20 septembre 2010 - 02:43 .

[DynV]

That was amazing SkywingvL !

I love that you went through the pathfinding system. ; I'll now avoid using dynamic collisions as much as possible (mostly used for containers, can't access inventory if static) placing a collision box/ball over it with Static property ending up blocking almost the same way but affecting the walkmesh thus pathing.

Modifié par DynV, 20 septembre 2010 - 04:12 .

[Kaldor Silverwand]

No reason to use collision boxes for containers or other objects you want to interact with. If you want them destroyable then leave them dynamic. If you do not want them destroyable then make them plot items and use a walkmesh cutter around them. They can still be interacted with as long as they are near the edge of the cutter. Destroyable items should not be in a walkmesh cutter because if they are destroyed the PCs will still be unable to walk to where the destroyed item was.



Regards