Interesting discovery about PWK's

[Legacy_Zogg]

               Now, this may well be old hat to custom content creators, but anyway...

I was working on a set of large boulder pile placeables, and was frustrated that, if they were positioned with the PWK below the walkmesh of a tile, a character could path right through them. I had wanted to be able to adjust their z-axes for a bit of variety, and also to place them on uneven terrain and still have them block character movement.

So, I went into MAX and cloned all the geometry of the boulder piles, then linked all the cloned parts together into one mesh. I renamed this mesh to PWK and added the Aurora placeable modifier, then parented it to the pwk dummy just like I would do with any other PWK mesh.

The result was that the placeable could be placed at any z position, and only the part of the PWK that sat higher than the tile's walkmesh blocked character movement.

This also works with placeables that have PWKs with more conventional geometry. For example, I took a basic Bioware crate and raised the PWK mesh to the top of the model. The crate could then be buried to any depth in the ground, and still block character movement. It's a minor thing, but it does allow quite a bit more flexibility in positioning placeables.

Like I said, this may not be anything new to those familiar with making custom placeables, but maybe it may be of interest to some nonetheless.
               
               

               
            

[Legacy_NWN_baba yaga]

               i think i know what you mean but can you put into one sentence again please and upload someting usefull for us to check it out.
               
               

               
            

[Legacy_Bannor Bloodfist]

               All he is stating is that if you create a REAL pwk, one that actually reflects the shape of the object in question (instead of a plain flat plane that lots of folks create because it is so easy to create), then, your PWK object affects geometry of the object instead of the flat section of a simple flat plane pwk.

This has been stated many times in the past.  A wall placeable can have a flat pwk that just blocks movement, but if you move that wall below the z of the tile it is placed on top of, the pwk no longer affects player movement as it gets ignored.  However, if you actually make a WALL shapped pwk, the wall can be adjusted upwards/downwards of the base tile ground plane and it will still block movement/shooting through it.  This gives you the ability to have a single wall placeable that can be used as a tall wall or a short wall (in height) and not have to waste space with multiple placeable creations.

It all depends on how the original pwk was created for the placeable.  If it is created to actually match the geometry of the object, great, it will work as expected.  If, however, it is created as a simple flat plane (the lazy man's way of creating placeable pwks, and seems to be the 'norm' for a large amount of content available on the vault) then that pwk can be placed in such a way as to actually NOT work if the flat plane is dropped below the z level of the underlying tile.
               
               

               
            

[Legacy_NWN_baba yaga]

               ok bannor, and again i have to read trough to much... thanks for that m8;) there is no new info and nothing of advantage in the end?

p.s. im just asking questions....like eric glenn beck cartman said:D
               
               

               
            

[Legacy_Bannor Bloodfist]

               a realistic pwk (actual shape of object) is better than a flat plane pwk.  Except for trees, which should have a single column for the trunk of the tree)
               
               

               
            

[Legacy_s e n]

               ps: is that true tath having height extruded pwks is only half a success meaning, for examples... cones... a gargantuan icecone set topdown...the larger non walkable zone is its base, and the radius gradually reduces, like all good cones, with height, till the radius becomes virtually zero, and so also the pwk section should... if you move the cone along the z axis.... but it doesnt work and the movement on large cone base xy values... so, is that controlled by verts, meaning i can make sections of cones and have the pwk work in synch with smaller cone sections, or no matter the section, it will cause issues?
               
               

               
            

[Legacy_Tiberius_Morguhn]

               

Bannor Bloodfist wrote...

All he is stating is that if you create a REAL pwk, one that actually reflects the shape of the object in question (instead of a plain flat plane that lots of folks create because it is so easy to create), then, your PWK object affects geometry of the object instead of the flat section of a simple flat plane pwk.

This has been stated many times in the past.  A wall placeable can have a flat pwk that just blocks movement, but if you move that wall below the z of the tile it is placed on top of, the pwk no longer affects player movement as it gets ignored.  However, if you actually make a WALL shapped pwk, the wall can be adjusted upwards/downwards of the base tile ground plane and it will still block movement/shooting through it.  This gives you the ability to have a single wall placeable that can be used as a tall wall or a short wall (in height) and not have to waste space with multiple placeable creations.

It all depends on how the original pwk was created for the placeable.  If it is created to actually match the geometry of the object, great, it will work as expected.  If, however, it is created as a simple flat plane (the lazy man's way of creating placeable pwks, and seems to be the 'norm' for a large amount of content available on the vault) then that pwk can be placed in such a way as to actually NOT work if the flat plane is dropped below the z level of the underlying tile.

I would contest that its less the "lazy man's way" versus the way that Bioware did most if not all of their placeables for the original NWN and its expansions.  Since many authors template Bioware work to begin their own, its easy to see how this has been carried on.    Also, is the sub-engine that handles walkmesh calculations and pathing able to cope with complex geometries (ie. a clone of the placeable itself)?  It's possible that the rendering and walkmesh sub-engines (for lack of a better word - maybe sub-systems) have been tuned way differently.  Can't say without digging into the code......
               
               

               
            

[Legacy_Bannor Bloodfist]

               Your question is not real clear, let me see if I can clarify what would happen with a cone.

The engine would block all movement for the radius of the cone if that cone was set to non-walkable/obscuring etc.  so, what I see happening there is more like a cylinder.  To be completely honest on that though, I have not tested such a cone.  I do know that it would block all walking across the entire radius/circumference of the cone for the pc, but it MAY allow you to shoot arrows/magic across/over sections of the cone.  For that you would have to test to be sure.  You could end up with a cylindrical blockage or the cone shape you created.  Either way, the pc/npc can not cross that area, but an arrow or magic blast might depending on the vectors.  I don't think anyone has ever attempted to test with a cone shape to see if arrows/magic can get around it.

I know that it will treat a solid wall type object as solid if the wall extends upwards in the positive z direction, where if you just had a flat section (under the wall object) it would only block pc/npc movement and prevent them from walking across that section while it would still allow arrows/magic to flow across the space.
               
               

               
            

[Legacy_OldTimeRadio]

               First, I like your idea of raising the PWK above 0 Z and how it affects a placeable's ability to be partly buried.  Maybe I'll do some hunting around to see if I can find a MaxScript which will help make bounding-box PWK's if something like it doesn't already exist in VelsTools.  Anybody know?  That might help strike a better balance for what you're looking for than cloning the geometry, outright.

In regards to the separate issue of full geometry cloning as PWK, I've seen this done mostly for TheGeorge's NWN2 placeable conversions.  It 'works', but I had heard anecdotes about the complexity of the PWK's causing crashes and I believe CEP had simplified the PWK meshes for some of the NWN2 placeables in order to correct the problems caused by that method. 

There are also a few big drawbacks to using this method on a large scale, aside from anecdotal reports of crashes or instability:
Doubles file size: Since the geometry of the model is represented in the PWK, the PWK takes up as much space as the model.  This basically doubles the file size of what's required to utilize the placeable.

Doubles loading time & PWK can't be optimized: A large model can be compiled externally and any delay caused by the loading and processing of the model can be largely negated.  This cannot be done for a PWK, to my knolwedge.  It must remain in ASCII and be processed on the fly by the game as the model is loaded, which is much slower than the processing time for a compiled model.

More complex PWK geometry means more complex pathfinding, more CPU used: NWN uses dynamic pathfinding, which is why you can walk anywhere there is a walkable surface- as long as there is a walkable path to get there.  Same with NPC's, monsters.  There are no hidden 'tracks', at least for pathing inside a tile.  This freedom is expensive CPU-wise as the game must dynamically plot paths around objects as destinations are selected.

All pathfinding takes place as a series of straight lines. By reducing a PC to a disc with an arrow on it,  one can see just how much more pathfinding is required to navigate around complex PWKs versus simpler ones.    Once a destination is selected around each of these objects, all rotations reflect a change to a new straight-line path.  The shorter the time between rotations during navigation, the more individual straight line paths compose the "full path"- which is all of the little straight-line segments which represent the path from start to destination- and the more CPU time needed to calculate them.  The objects are a 4, 5 & 20-sided PWK.  All placeables are placed at the center of individual tiles, set as static and the full-object PWK method is used, though it makes little difference if I would have flat planes with 4, 5 & 20 sides:


For simple shapes like a four or five-sided PWK, you can see the pathing is very "easy", requiring few rotations of my PC and indicating the path is mostly composed of long stretches.  Because of how the dynamic pathfinding works in NWN, though,  there is a "hugging" effect and that causes more comples PWK shapes to cause much more pathfinding and CPU use.  You can see this on the 20-sided cone in the form of many rotations.  I left the smoothing off the cone so you could see how the pathing is affected by the faces.

BTW, when that cone is sunk into the ground the same number of faces are still in play when something tries to path around it- so it's just as wasteful nomatter how much of it is sticking up throgh the ground.  I'm sure at some point this ceases to be as much of a problem as it sounds, though.

The first two points about file size and inability to optimize (through compilation) are probably already dealbreakers for me but it's the pathfinding aspect that concerns me the most .  And in all of these tests, relatively simple geometry was used. 

Using Z-arbitrary cross sections of cloned placeable geometry as a PWK is just asking for trouble when used with any kind of regularity, IMO.  In an environment with multiple objects trying to path (like players, creatures, NPC's) the worst drawbacks of this method stack up plenty quick. 

With all that in mind and regardless of whether a 3D or 2D PWK is used, a less complex proxy of the visible geometry would always seem to be a better way to go.  We feed all sorts of data into NWN and some of it we can be sloppy or excessive with- like pure geometry.  But some care must be taken when feeding PWK data into the engine because it is actively utilized and referenced by the engine during play- even when the placeables are set to static.
               
               

               

                     Modifié par OldTimeRadio, 01 mars 2013 - 03:41 .
                     
                  

            

[Legacy_Bannor Bloodfist]

               Yes, exactly.  However, a flat pwk is a waste as well.

Best bet is to not clone the geometry of the object, but to create a shape, as simple as possible, that reflects the general shape of the object.  2 faces per side type.  Cone/angled etc, with as few faces as possible.  In fact, a pyramid reflects the general affect of a cone, while only requiring 4 faces.  It is perfect? No, but it approximates the shape of the cone it replaces.

Really complex shapes are basically useless as the object affects walkable location finding from the base or widest parts of the object.  A simple box for a very complex object is better than a flat plane though for targeting purposes.

What is all boils down to, is how realistic you want your objects to affect targeting, and path-finding.  The engine can, and does, calculate for each face, but are all of those faces really necessary?

This is where low-poly generation is important, and 99% of the time, it is assumed by any serious cc creator for nwn.  The lower the poly count, the easier the engine handles it.  However, this doesn't mean that low poly is always the answer either.  Some things, creatures for example, (pcs/npcs/creatures) should be higher poly.  Even then though, high poly does NOT mean it is actually better looking.  It is a blend of poly count and proper texture application that determines how good any object/creature is in game.

My complaints about how the Placeables are generally created is that no thought has been given to what the object actually is, most of the placeables available are using the simplest, 2 faced, flat plane, to block walking.  No thought given to targeting etc.  No thought has been given to the objects actual geometry etc.

With tile creation, I typically clone the meshes of the buildings/geometry etc, into a single wok object, THEN edit that wok to weld all the verts, and finally remove useless faces wherever possible.  Wherever possible, I generate that wok to match as closely as possible, the actual shape of the building/terrain that is being represented, but with vastly reduced face counts.

This should be done when it makes sense for any placeable object.  Of course, creating a complicated shape for a candle placeable is a waste, since that placeable is typically already placed on top of a non-walkable table top surface.  But when creating a wall placeable, that walls geometry should be matched within reason, to reflect the height and thickness of the wall to block targeting.

All of it matters, some much more than others.  Simple placeables that hang off a wall, say a torch, don't need a real pwk, nor would a picture that is designed to be "hung" on a wall which should already have a non-target-able surface.  

However, say you have a statue placeable, it SHOULD block targeting as well as walking.  It does not need to have all the shapes of the statue though, a simply pyramid will likely cover it or a full sized box in worst case.  It should NOT have a flat plane non-walkable surface though, as that allows targeting right across it as if it didn't exist.

So, general thought about purpose AND size AND shape of the placeable object determines what sort of PWK it should have.  The past history of just using flat planes for everything is what my complaints are about.
               
               

               
            

[Legacy_FunkySwerve]

               I'm with OTR on this one, completely. Mindless adherence to MOAR is a recipe for disaster.

Efficiency aside, I actually find the Bioware style more flexible to build with - I can put the places anywhere, and drop some invisible objects for pathblocking if desired. Obviously, that can pose a threat to efficiency as well, but only to the extent you need it to create a given effect.

Here, for example, is a bridge of bone I made to connect the two spires of Abysm (Demogorgon's lair - and yes, the bridge is a departure from PnP):



It uses this technique, and winds up using a lot of placeables - but not so many that it affects performance:



Had the authors of those places (acaos and myself, taken from a stock bioware placeable, reskinned, enlarged, and rotated) done full pwks, this bridge couldn't be, since the bones are not completely flat (nor should they be). The pwks would extend above the tile in multiple spots, creating bizarre blocks in the path, instead of half the character's foot passing through the top of the place. You could lower them to the point where none of the place would be above the tile, but then the characters would be levitating on most parts of the bridge - it looked terrible.

So, not only is the Bioware style more efficient than the 'REAL' style, it's also more useful. AND costs less dev time to do. Hands down winner.

In regards to the separate issue of full geometry cloning as PWK, I've seen this done mostly for TheGeorge's NWN2 placeable conversions.  It 'works', but I had heard anecdotes about the complexity of the PWK's causing crashes and I believe CEP had simplified the PWK meshes for some of the NWN2 placeables in order to correct the problems caused by that method.

Indeed the CEP did. Acaos redid them completely to the simple ground models using a program, and I error checked them by hand (as a favor, I'm not with the CEP, I just wanted him to use that time doing things for HG '> ). Likewise, the 1000+ placeables I ripped from bioware tilesets for the CEP use two-dimensional pwks that approximate walkable area (which varies, with objects with overhangs. Anything else just doesn't make sense.

Funky
               
               

               

                     Modifié par FunkySwerve, 22 novembre 2011 - 09:12 .
                     
                  

            

[Legacy_s e n]

               o lol then lets create flat woks for tile walls cuz that way cpu usage is less intensive
               
               

               
            

[Legacy_s e n]

               Bannor i think you're right, probably the engine flattens z axis values so for complex meshes like boulders and such its not doable the trick of adjusting z axis in tileset and get correct pathfinding in game, no matter the pwk mesh is sliced or not...
               
               

               
            

[Legacy__six]

               Matter of opinion. I can think of many cases where a half sunken placeable that is nevertheless walkable would be useful, particularly if its an unusual shape. Personally and with stuff by other members of Project Q I advocate a compromise where a 25cm ish trapeze shape is used instead of a totally flat pwk. That way you can place it in any non-Bioware tileset that isn't 100% flat and it won't have the blocking issues that the flat style have, but you can still place stuff above and below the walkmesh to be walkable.

When it comes to that bridge, well, I'd say its more of an exploit for convenience' sake than a genuinely useful feature. Something like that really should be part of the tile. But if it helps you keep haks down to CEP only or whatever other limitation you place on yourself then its fair enough I guess. I've found modern systems struggle more with the way NWN handles emitters than they do with technical bad practise involving walkmeshes anyway.
               
               

               

                     Modifié par _six, 23 novembre 2011 - 01:16 .
                     
                  

            

[Legacy_FunkySwerve]

               

_six wrote...
Matter of opinion. I can think of many cases where a half sunken placeable that is nevertheless walkable would be useful, particularly if its an unusual shape.

No, not just not a matter of opinion. Of course, I too can think of many cases where full pwks might still be useful. The point is, the normal pwk is almost always going to be MORE useful, because the builder can tailor the walkable area easily in just about any way they want, instead of having his hand forced. The small amount of time you might save by not placing an invisible place or place is more than offset by the reduced potential utility. Not hard math, even if you don't consider the huge differences in efficiency.

_six wrote...
When it comes to that bridge, well, I'd say its more of an exploit for  convenience' sake than a genuinely useful feature. Something like that really should be part of the tile. But if it helps you keep haks down to CEP only or whatever other limitation you place on yourself then its fair enough I guess. I've found modern systems struggle more with the way NWN handles emitters than they do with technical bad practise involving walkmeshes anyway.

Technical bad practices? Lolz '> Obviously we do it to stay hak free, to get the most we can out of vanilla NWN + CEP. Static places are baked into the area walkmesh when it's loaded, so the bad practice, if any, is larding them down with unnecessarily large meshes - the results of which we don't have to speculate about, as OTR already noted.

As for the bridge being an 'exploit' and not a useful feature...please. I take it you haven't tinkered with editing area files yourself? There's a handy thread on it somewhere on this board. It allows you to do all kinds of useful edits to tilesets that the toolset doesn't. Even if using something other than bioware-provided tools makes it an 'exploit' in your book (though that's a novel and bizarre use of the word, one that encompasses custom models as well, to say nothing of NWNX), it doesn't speak to its usefulness. If it weren't useful, we wouldn't be doing it in the first place, as I would think is sort of obvious. '> It allows us incredible creative freedom, as that bridge illustrates beautifully, without the costs associated with additional haks.I must admit puzzlement as to your characterizaiton - please feel free to clarify.

Put even more simply - what we did with that bridge, doesn't cause crashes. The more-complex way of doing pwks you are advocating, has been shown to. How you call the former a bad practice, but not the later, is incomprehensible. Could you elaborate on your definition of 'exploit' and 'bad practice? The way you're using them makes no sense at all to me.

Funky
               
               

               

                     Modifié par FunkySwerve, 23 novembre 2011 - 04:15 .