76 réponses à ce sujet

[FunkySwerve]

Calvinthesneak wrote...

This is a very interesting read. I'm currently trying to patch up an old module and I didn't know the hit of static vs non-static plc's.

I'll keep it in mind and Funky, those screenshots are awesome.

We went so far as to leto every single place in the mod that didn't need to be otherwise to static, and our builder's mod is full of staticed (and scriptless) resrefs of every standard and cep placeable appearance. It makes a difference.

Funky

[Eradrain]

Um.  I don't know if you're patronizing me, or if you genuinely think that I don't know this stuff.

What's the difference between me and Six, where when I say something you disagree and take my post apart quote by quote, but when he says the same thing, you defer to his presumably superior knowledge?  Is it because he has a Hall of Fame tag?  Because so do I.  Is it because he's been active in the custom content community for years?  So have I.  I've also hosted, adminned, DMed and played on a number of diverse servers.

Being told that there's a difference between graphical lag and connectivity lag is just an insult to my intelligence.  Disagreeing with what I say with little more reason than a copypasta of some tutorial you wrote and another reference to how fantastic your server is, is just in poor taste.

I'm done with this thread.

Modifié par Eradrain, 20 décembre 2010 - 10:14 .

[FunkySwerve]

Eradrain wrote...

Um.  I don't know if you're patronizing me, or if you genuinely think that I don't know this stuff.

I'm not patronizing you - based on your post, you clearly thought I was talking about graphical lag with regard to placeables, when I've been trying to tell you about the SERVER component of placeable lag:

Eradrain wrote...
I was talking about load times.  This thread is about client-side lag, right?

You were also mistaken about graphical lag being the 'lion's share', about bottlenecks always being the connection rather than the serving machine, and 'lag having to come from client-side issues', among other things. I went to some pains to point out your errors, if you go back and look.

What's the difference between me and Six, where when I say something you disagree and take my post apart quote by quote, but when he says the same thing, you defer to his presumably superior knowledge?  Is it because he has a Hall of Fame tag?  Because so do I.  Is it because he's been active in the custom content community for years?  So have I.  I've also hosted, adminned, DMed and played on a number of diverse servers.

The difference is that he's talking about things I don't know about, and could well be right - I defer based on that, because I'm interested in learning, and because what he's saying makes a good deal of sense to me (and was corroborated in part by Frith's reply, as well). It could in fact be used to improve that tutorial, though I don't know if that's on the table with the lexicon folks - at a minimum it helps me make decisions about intelligent design practices down the road.

I'm unaware as to the number of years either of you has in the community, or the hall of fame tags you do or don't have. In fact, I've had disagreements with Project Q in the past over their view of the CEP, so if anything I would have cause for bias against six (it's right in his sig, I have no idea if you're with PQ as well), though I try to avoid that, since harping on personal issues is not the purpose of these forums - he's been very professional as well, and helpful to boot. Put more simply, he appears to know what he's talking about, while you're making some assertions I know to be incorrect - hence the difference in response.

Being told that there's a difference between graphical lag and connectivity lag is just an insult to my intelligence.  Disagreeing with what I say with little more reason than a copypasta of some tutorial you wrote and another reference to how fantastic your server is, is just in poor taste.

I'm done with this thread.

The paste was meant to help clarify the topic, since you were confuting the server/client-side divide with connecttion/graphics/server lag issue - something I often do myself, as they're easy to talk about in the same breath - I was not insulting your intelligence. Likewise, I set out my various hosting experiences in response to your notion that the bottlecap is always on the connection side, to demonstrate that that very often is not the case (and to reinforce the importance of considering server lag). Taking that as 'another reference to how fantastic my server is', says a lot more about you than it does me - specifically, how well you take someone showing you to be wrong. Alternatively, if you're talking about the player counts, you were the one who raised that topic, not I - I was simply setting out our specs, for comparative purposes. Either way, if you post on these forums, you should be prepared to learn (and, as a corollary, to be mistaken) - I know I do on a regular basis, and already did, in this thread. I have a tendency to talk about large models as 'high-poly', and there's an obvious correlation, but the point about animations being the lion's share of the problem with horses was an important distinction. Being wrong isn't a character flaw, though how you react to it can be.

Funky

[Baaleos]

Not wanting to jump in the line of fire or anything, but another 'pro' about Funky being overly cautious, in describing the issue in too much detail rather than too little detail, is that it helps others who come onto this topic, wanting an answer to a similar issue.



Just because his answer may have been unintentionally patronizing to you, doesnt diminish the usability of the information he is providing.



A few years ago, I didnt know about lag caused by placeables and the interactions between them and npc's who view them etc (AI etc), until I stumbled onto a Post that Funky made on the topic.



Just because you already knew the information being provided, doesnt mean everyone did.

Also - remember, he was trying to help, lets keep hostility down to a minimum, or at least to PVP games.

[Jenna WSI]

Wow, came back to lots of good info here, thanks..

[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.

[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? :-)

[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.

[NorthWolf]

More nice advice. Thanks, Inayity.

[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 .

[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 .

[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

[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.

[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 .

[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 .

[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 .

[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 .

[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.

[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.

[Invisig0th]

kalbaern wrote...
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.

You are quite correct to point this out. My mistake. I probably should have made a side mention of this, saying that you can technically "destroy" such placeables, but that this does not behave as one would expect, and that almost no one uses it for that reason.

Regardless, that piece of obscure trivia does not actually contradict my point: that static placeables placed using the toolset behave very differently than placeables placed using scripting at runtime. In fact, you have only further supported how very different the two varieties of static placeables are.

The fact that static placeables created using a script work very differently than both static placeables in the toolset and nonstatic placeables is irrefutable. It is also irrefutable that using static placeables created with a script is one way to reduce the game engine overhead of placeables.

This information is obviously very important to include in a detailed discussion about reducing placeable lag. It would be a disservice to the discussion to fail to mention them. As it turns out, that's exactly what your buddy did above. If people provide incomplete answers, then it is up to the other community members to fill in the gaps. I'm very sorry if that upsets you.

Modifié par Invisig0th, 26 décembre 2010 - 10:01 .

[kalbaern]

Invisig0th wrote...

kalbaern wrote...
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.

You are quite correct to point this out. Unfortunately, this doesn't actually contradict my point that static placeables placed using the toolset behave differently than placeables placed using scripting at runtime. Rather, you've only further supported my assertions here. Thanks for throwing in that bit of fairly useless trivia, though. I should have said you can't destroy such placeables in the way that one would expect.

However, the fact that static placeables created using a script work very differently than both static placeables in the toolset and nonstatic placeables is completely irrefutable. It is also irrefutable that using static placeables created with a script is an effective way to reduce the game engine overhead of placeables, and is therfore extremely important to include in a discussion about reducing placeable lag.

I'm very sorry that neither you nor your buddy managed to mention any of this important information above. But unless you're claiming that this info isn't relevant at all, then you're wasting your time and everyone else's.

You're own example claimed that a static placeable could not be destroyed and you went on to give an example of a burning tree. Your premise is wholly false, you simply refuse to ever be wrong on any given topic and constantly respin things and often contradict yourself when doing so.

Whether or not a placeable can be destroyed is dependant soley on two things, how much damage it sustains if not also set to plot and whether its set as plot to begin with. Not seeing a placeable disappear when destroyed isn't a bug or glitch. Its a simple builders error instead. The builder should make sure anything that can be destroyed is never set to static. All "static" does is set the appearance data to be sent once to the PC and not every time they come back into perception range of it. This also means that destroying it changes nothing "visually" onscreen, but its still gone I can assure you. Experiment using a static placeable with a heartbeat and you'll see for yourself, the hearbeats cease whether seen or unseen when its destroyed, not when it "disappears".

As for "Funky" being my buddy ... heh. He often irks me and I doubt we'd ever be pals. That doesn't matter though. I  respect him and his opinions and advice enough to hear him out at least. I've learned a ton from him and many others over the last 5 years. And unlike you, I can learn from others and don't feel the need to belittle or insult them simply because they point out an error or they disagree with me.

[Invisig0th]

Wrong and wrong.

The specific example I described is a tree that will burn and subsequently be destroyed WHILE PCS ARE STANDING THERE.  You absolutely cannot do that with a static placeable placed using the toolset. By your own admission, the PCs would have to leave the area and come back for the tree to disappear -- which obviously sucks. On the other hand, it is trivial to create a static placeable created via scripting and then run a script to "burn" it (using VFX) and then destroy it afterwards. And it will disppear when destroyed, whether the PCs are in the area or not. Srike one for you.

You should also note that the destruction of the tree in this example is being PURPOSEFULLY delayed vis scripting to allow the tree to burn for a while. The intention is to burn it, not make it explode! You cannot do something like that by merely relying on the hit points of the tree and the immediate incidental damage  -- it must be scripted. I'll be happy to provide a sample script if you don't understand. Strike two for you.

Your "rebuttal" here makes is quite clear that you didn't understand my example at all. Not even a little bit. Please read the thread more carefully before posting next time.

When you have something positive to contribute, please do let us know. As for your personal feelings about me -- please send me a PM telling me all about it. But please stop spamming this thread with that nonsense.

Modifié par Invisig0th, 26 décembre 2010 - 10:46 .

[kalbaern]

Invisig0th wrote...

Wrong and wrong.

The specific example I described is a tree that will burn and subsequently be destroyed WHILE PCS ARE STANDING THERE.  You absolutely cannot do that with a static placeable placed using the toolset. By your own admission, the PCs would have to leave the area and come back for the tree to disappear -- which obviously sucks. On the other hand, it is trivial to create a static placeable created via scripting and then run a script to "burn" it (using VFX) and then destroy it afterwards. And it will disppear when destroyed, whether the PCs are in the area or not. Srike one for you.

You should also note that the destruction of the tree in this example is being PURPOSEFULLY delayed vis scripting to allow the tree to burn for a while. The intention is to burn it, not make it explode! You cannot do something like that by merely relying on the hit points of the tree and the immediate incidental damage  -- it must be scripted. I'll be happy to provide a sample script if you don't understand. Strike two for you.

Your "rebuttal" here makes is quite clear that you didn't understand my example at all. Not even a little bit. Please read the thread more carefully before posting next time.

When you have something positive to contribute, please do let us know. As for your personal feelings about me -- please send me a PM telling me all about it. But please stop spamming this thread with that nonsense.

Your retort is laughable if only because you'll claim I never sent a private PM. Infact, I attempted such over a week ago in regards to another thread and you'd had my login listed as blocked. Don't worry, that puts me into the same group as "Funky" and others you disagree with and is reward enough.

[Tyndrel]

Thanks Inayity, that was fascinating and very informative.