Placable Lag?

[Baaleos]

               @ Jenna,

I dont know if Funky covered it, but I think it was explained to me few years back that you could in theory have thousands of placeables in an area, and not get any server lag.

You might get client lag, from graphic usage - eg your graphics card might be taxxed.



However, if you were to add even a single npc to that area, the server would seriously suffer, because now those placeables, are not only existing, but an npc is 'seeing' them, and acknowledging their presense.



So, like all things, its all about balance.

NPC's + Placeables are ok, in moderation.
               
               

               
            

[Legacy_NorthWolf]

               Eh, I don't think he was trying to be patronizing. The original poster was looking for information on sources of lag and overkilling with the responses provides an explanation to them (and the rest of us).



On that note, I assume there's no actual hit to the server's processor when dealing with placeables crossing tiles so long as the placeable is walkable or NPCs aren't expected to pathfind through the area, then?
               
               

               
            

[Baaleos]

               Better to be too helpful, than not helpful enough? Eh? :-)
               
               

               
            

[Legacy_Inayity]

               These suggestions are mostly for people who like using a lot of placeables to construct a scene and want to avoid expensive pathing issues sometimes involved with that:

Know the pathnodes for the tiles you're working with.  Some areas of your tile are going to get much more attention from the engine than others, depending on their pathnode.  Work with the pathnodes instead of against them and your areas can have more placeables than might even seem reasonable and still allow players and NPCs to move through them smoothly.  If you don't have the time to really get into this you probably get away with using the rendertilepathnodes 1 command.

And OldMansBeard brought up something in another thread which I'm going to put in the context of this discussion:
A better way to get the flexibility you want, is to create your custom area in GMax/3dsMax, by all means using a kit of pre-constructed placeable elements if you like, then slice it into custom tiles and parcel them up into a custom tileset hak.That way, you can get the walkmesh right.

Most people are probably going to glaze over at the thought of this but it doesn't make it any less viable an alternative.  NWN can scissor the walkmesh for you on the fly but passed a certain point and, well I can't see the real walkmesh (WOK+PWK) using renderaabb 1 but I imagine it doesn't do any favors for pathing.  A handmade WOK is always going to be better than one cut up on the fly.
               
               

               
            

[Legacy_NorthWolf]

               More nice advice. Thanks, Inayity.
               
               

               
            

[Legacy_FunkySwerve]

               

Baaleos wrote...

@ Jenna,
I dont know if Funky covered it, but I think it was explained to me few years back that you could in theory have thousands of placeables in an area, and not get any server lag.

This is ...sort of true. Within the limits of practical application, it is pretty much true. There IS a cost associated with each placeable - remember, they're each an object, and each gets assigned an object id. You can see this effect by making a one-area mod, and setting up a heartbeat that adds 100 objects per iteration. Your mod will eventually crash, and much sooner than you might expect - you can up it to a thousand per iteration if you're impatient. Of course, no builder is going to use such a script - the point is simply that each placeable comes with a cost, if a small one, issues of poly count and perception aside. Static objects are far less expensive overall (though I don't know if they're actually 'zero' cost, or completely negligible, in terms of server-side impact - obviously they can still cause graphical lag client-side), which is why we go to pains to static everything we can.

Funky
               
               

               

                     Modifié par FunkySwerve, 22 décembre 2010 - 10:37 .
                     
                  

            

[Legacy_Invisig0th]

               FunkySwerve, always making new friends among the few remaining members of the NWN community. Nice work, buddy.

Another option that really should be mentioned in the static vs. nonstatic placeables discussion is the third option -- spawning in static placeables when the game runs rather than placing them using the toolset. In certain specific situations, this is a very useful tool. It's not entirely clear how the game handles spawned in nonstatic placeables, but what little we do know about this indicates that they are treated in a unique, hybrid manner, somewhere between maximum overhead (nonstatic) and minimum overhead (static). If for some reason you must choose between nonstatic placeables and static placeables that are spawned in via script, there may be benefits to spawning them in nonstatic. You don't get the full benefits of static placeables, but they clearly do not carry the full overhead of nonstatic placeables.
               
               

               

                     Modifié par Invisig0th, 24 décembre 2010 - 04:55 .
                     
                  

            

[Legacy_FunkySwerve]

               

Invisig0th wrote...

FunkySwerve, always making new friends among the few remaining members of the NWN community. Nice work, buddy.

Given your recent performance in the recent Lost Vault Content thread - to say nothing of the above - this is nothing short of comical. In case no one's told you, it's Christmas Eve. How about you ease off the grinchitude for 48 hours? Sheesh.

As to your substantive remarks, yes, you should absolutely be spawning in static places unless you need to interact with them further by script.

Funky
               
               

               
            

[Legacy_NorthWolf]

               I'm not sure I quite get what you're saying regarding the spawning in of placeables, Invis.That it's preferential performance wise to spawn static placeables in by script? Sorry, just the wording confuses me.
               
               

               
            

[Legacy_FunkySwerve]

               He's simply saying to spawn in placeables as static wherever possible - a corollary to using statics as much as possible in general. It tends not to matter much when spawning them in, because in practice, you're likely to be spawning them out again, or getting rid of them by some other means (as with useable loot placeables). This is the case with pretty much all the spawned-in places in our mod, including the pillar of skulls on page one of this thread.

Funky
               
               

               

                     Modifié par FunkySwerve, 24 décembre 2010 - 10:59 .
                     
                  

            

[Legacy_Jenna WSI]

               Really no need to argue guys.

And is there anything that explains pathnodes and pathfinding at the basic levels? Really new to understanding it and we do use placables in bunches to create a scene.
               
               

               

                     Modifié par Jenna WSI, 25 décembre 2010 - 04:23 .
                     
                  

            

[Legacy_Inayity]

               

Jenna WSI wrote...
And is there anything that explains pathnodes and pathfinding at the basic levels? Really new to understanding it and we do use placables in bunches to create a scene.

The short, convenient answer (assuming the reader knows nothing about WOKmeshes, pathnodes or pathing):

There are two types of pathing in NWN and whether it's the first type or the first and second type combined depends entirely on where a player or creature is moving to:

The first type is intra-tile and involves pathing inside the confines of an individual tile.  For this pathing the WOKmesh is consulted.  The WOKmesh is very granular and specific about what triangles on the mesh can and cannot be traversed, any special effects to play (like puffs of dust) when they are traversed, or whether they block line-of-sight, etc.  A WOKmesh is part of the 3D model of each tile and although it is invisible to the player in-game, it can be revealed by using the debug console command renderaabb 1.  Here is a sample WOKmesh for a tile and to simplify things we'll say that green means walkable and gray means not walkable and line-of-sight blocking:


The second type is inter-tile and it involves pathing between two or more tiles.  For this pathing the pathnodes are consulted, a path is plotted and then the WOKmeshes for each tile are consulted as the actual traversal takes place.  Inter-tile pathing + intra-tile pathing = "full path", the actual path that the PC will attempt to take.  A pathnode is very general and merely identifies where the exits on a tile should be.  It does not know exactly what is between the start and the destination, only generally how to get there.  Individual pathnodes have to be programmed into the engine but there are about 30-40 to use, each describing some combination of exits from a tile.  A pathnode is defined in that tileset's .SET file, one pathnode for each tile and a rotation because the tile might be rotated.  A general indicator of the tile pathing in an area can be revealed by using the debug console command rendertilepathnodes 1.  Here are a few tiles from Rural and the pathnodes (and their names, which are letters) for them:


Remember pathnodes tell the engine about exits from a tile.  The black lines are an oversimplified indicator that it is expected that the more granular WOKmesh will allow pathing into the tile from a particular side and (if the black lines connect) will allow an exit from a particular side.

Now I'm going to say something that's not entirely true*.  But, like classical mechanics in physics, it's going to get you most of the way there.  And that's this: If you put down placeables in the white areas of your tiles, as described by the pathnodes, you will have a much lower probability** of interfering with pathfinding than if you place them where the black lines are.  Within about 2 game meters or so (each tile is 10 game meters on a side), anyway.

Here are four pathnodes, let's pretend these represent 4 tiles next to each other in a 2 x 2 area:


Consider the right side of pathnode I and the right and top sides of pathnode H.  In those examples what I describe (about placeable placement) should become a little clearer because the entire rigth side of those tiles is not expected to provide an exit.  So, if the player is traversing them the you will have much better luck putting down more placeables on their right side than on their left, tops (at least for I) or bottoms.

** Why did I say probability instead of certainty?  Because inter-tile pathing results in the "full path" which is both the generality of the pathnodes about how to get there and the granularity of the WOKmesh.  Also, for an area to traverse that's filled with something like the A pathnode (at least) you can easily walk diagnally across tiles without the pathing being obvious.  How all this gets calculated depends on the starting spot the player is in, the number and shape (equilateral or something close to it versus a Scaline) of the triangles, non-walkable spots on the walkmesh and any on-the-fly modifications because of placeables or moving creatures.  For instance, a bunch of long thin little triangles can really screw with the pathing algorithm.  Bioware tiles are usually made from the pathnode on up and have good WOKmeshes.  Usually.  Your mileage may vary with community content, depending on how much care they give to such things.

* Ok, well if that's not entirely the truth, what is the truth?

Glad you asked!  Like a couple of the geniuses who originally designed NWN, Dr. Mark Brockington (Bioware's 'Lead Research Scientist' on the NWN project) wrote a few extremely informative articles about the inner workings of Neverwinter Nights which include information about his pathfinding algoritms and how NWN uses Level of Detail for the AI/pathfinding. 

By Mark Brockington:
Level-Of-Detail AI for a Large Role-Playing Game
BTW, the LOD he describes for AI in this paper appears to directly map to the Get/SetAILevel functions in NWScript and give you a much clearer idea of what impact they have, especially in regards to pathing.

Pawn Captures Wyvern: How Computer Chess Can Improve Your Pathfinding
I assume the tree he talks about is the BSP tree in the WOKmesh but I don't know.
               
               

               

                     Modifié par Inayity, 26 décembre 2010 - 08:03 .
                     
                  

            

[Legacy_Invisig0th]

               

NorthWolf wrote...
I'm not sure I quite get what you're saying regarding the spawning in of placeables, Invis.That it's preferential performance wise to spawn static placeables in by script? Sorry, just  the wording confuses me.

Your best performance for a placeable is always going to be when the placeable is placed in the toolset and flagged as static. The fact that the game engine only expends minimal effort dealing with these has severe drawbacks, however. You cannot create or destroy these placeables, or interact with them in any way. For all intents and purposes, they treated as part of the tileset during gameplay. They are indeed "static" in the strictest sense of the term.

However, static placeables that are created via a script from a blueprint are treated very differently by the NWN Game engine. For starters, you can create and destroy such placeables. If your need to manipulate the placeable via script is limited to these and a handful of other basic scenarios, and if you really can't achieve the desired effect using static placeable placed ahead of time in the toolset, then using this technique may be useful. And if someone is very serious about ratcheting down placeable lag as much as possible, like we are discussing here, the fact that spawned in static placeables involve less overhead than non-static, non-usable placeables can also make a big difference.

An example would be creating a tree placeable that can't be interacted with directly by PCs, but which will "burn" and be destroyed if a fireball goes off nearby. Static placeables placed in the toolset at design time definitely will not work, since you literally can't destroy them using a script. A non-static, non-usable placeable would certainly work, but that's an awful lot of extra overhead when all you are doing is applying a brief VFX and then destroying the placeable. With spawned-in static placeables, it's quite easy to do all this with minimal overhead.

FunkySwerve wrote...
He's simply saying to spawn in placeables as static wherever possible - a corollary to using statics as much as possible in general.

Actually, that was not what I was saying at all. The next time someone asks me what I mean, you may want to take some time to think about how unlikely it is that you understand what I mean better than I do.
               
               

               

                     Modifié par Invisig0th, 26 décembre 2010 - 08:00 .
                     
                  

            

[Legacy_NorthWolf]

               Inayity: Thanks for the lengthy explanation and links. I've been playing around with the render console commands but I'll admit I had relatively little understanding of how NWN did pathfinding until I read that. I sort of wish they let you define your own nodes, admittedly.



Invis: Ah, I see now, I think. Sort of niche like you said, but I suppose I could imagine situations that would be useful in.
               
               

               
            

[Legacy_kalbaern]

               

Invisig0th wrote...

NorthWolf wrote...
I'm not sure I quite get what you're saying regarding the spawning in of placeables, Invis.That it's preferential performance wise to spawn static placeables in by script? Sorry, just  the wording confuses me.

Your best performance for a placeable is always going to be when the placeable is placed in the toolset and flagged as static. The fact that the game engine only expends minimal effort dealing with these has severe drawbacks, however. You cannot create or destroy these placeables, or interact with them in any way. For all intents and purposes, they treated as part of the tileset during gameplay. They are indeed "static" in the strictest sense of the term.

However, static placeables that are created via a script from a blueprint are treated very differently by the NWN Game engine. For starters, you can create and destroy such placeables. If your need to manipulate the placeable via script is limited to these and a handful of other basic scenarios, and if you really can't achieve the desired effect using static placeable placed ahead of time in the toolset, then using this technique may be useful. And if someone is very serious about ratcheting down placeable lag as much as possible, like we are discussing here, the fact that spawned in static placeables involve less overhead than non-static, non-usable placeables can also make a big difference.

An example would be creating a tree placeable that can't be interacted with directly by PCs, but which will "burn" and be destroyed if a fireball goes off nearby. Static placeables placed in the toolset at design time definitely will not work, since you literally can't destroy them using a script. A non-static, non-usable placeable would certainly work, but that's an awful lot of extra overhead when all you are doing is applying a brief VFX and then destroying the placeable. With spawned-in static placeables, it's quite easy to do all this with minimal overhead.

FunkySwerve wrote...
He's simply saying to spawn in placeables as static wherever possible - a corollary to using statics as much as possible in general.

Actually, that was not what I was saying at all. The next time someone asks me what I mean, you may want to take some time to think about how unlikely it is that you understand what I mean better than I do.

 Sorry to say, but you are wrong and despite your passive agressive responses and snide retorts, you might wish to actually read some of Funky's posts thoroughly and with an open mind at least once.

To the point though. Static placeables can indeed be destroyed and often are in many a PW or module  because builders overlook the possibilty. They just don't disappear until PCs leave and re-enter the map. They can ... and often are destroyed though. You can also destroy them vis script whether spawned in or not. They just don't update their appearances (or lack of) when destroyed because they are static.