14 réponses à ce sujet

[Xeneize]

I just finished my first area, however the people testing it report flamerate drops, especially DM client-side where DMs crash completely if they throw up a huge battle with loads of spellcasters.

 

How do I go about making the frame rate of the area better?

[kamal_]

 a huge battle with loads of spellcasters.

That's generally bad for framerates, unless your PW is using PainofDungeonEternal's CSL ai, which most likely it's not.

 

Also bad for performance:

not cleaning up the walkmesh (baking tends to leave jaggies in the walkmesh, you want to manually clean those up with the no-walk brush and then rebake)

too many trees/seeds

too many lightsources, especially if they cast shadows (shadows are dynamic...)

too many object with shadows enabled

too many complex vfx (probably would be bad, next actually tested)

lots of placeables (convert things to environmental and use walkmesh cutters)

too complicated ai (for example my full commoner ai can bog things down, which is why I had to make the generics version)

[K Kin]

Didn't Tcho's make a video on how trees/seeds don't effect framerate?

[Xeneize]

What is generally a good frame rate?  And what is this PainofDungeonEternal's CSL ai about?

[kevL]

And what is this PainofDungeonEternal's CSL ai about?

CSL - Common Script Library

Pain used to operate a PW, Dungeon Eternal, that was PvP. He learned massive amounts about the underlying game and wrote/pulled together a huge library of #includes and scripts with an aim to smooth and enhance the entire scripting language. Little bugs and holes are fixed, objects can take and use extra parameters, additional functions can sanitize character names to ASCII, etc.

Among the files are replacement scripts for the AI. This is a barebones stripped-down AI for mass combat. I haven't tried it (because i haven't made a mass combat, but will definitely when the time comes.) - let's say 50 NPCs can do combat in an area without appreciable slowdown that would be caused by script calls.


From Kamal's List I'd say the worst offender you're getting is spell VFX. The special effect files for buffballs, eg, slow down my computer a lot and personally i have all buff-vfx blanked completely. (Although a dream/goal of mine is to create sparse buff-vfx ala NwN1 - and it would likely need to be done for hit-vfx in mass combat also.)

Shadows and what cast them, how they interact with light-sources and placeables, plus placeables (static/dynamic) vs. environmental objects, and trimmed walkmeshes are other things to look at.

 

What is generally a good frame rate?

Have players try the area with their shadows all turned off, to see what happens

[Xeneize]

Well we're talking of a 20x20 area that will be the main city hub. Perhaps having most placeables and envirhomental objects set to cast no shadows nor receive them will be a good idea? Trees as well.

[kevL]

i'd change shadows gradually. Try setting some objects to not receive shadows, see what they look like on the ground, then maybe turn off some tree shadows(?), see that that looks like - until you got a hang on how things go

remember to try things IG, 'cause TS rendering can get funny,

[Xeneize]

I run a great horse... nothing lags me player side... however on the DM client... while I don't 'lag' I freeze for several seconds during epic battles where there's loads of spell slinging.

 

I get that generally it's a bad idea to do that.

[kevL]

hm I don't have experience w/ the DM client :\

sounds like, since things are generally ok with the player-client, something specific with the DM-client is wonky. (it wasn't given the importance it should have got, in Nwn2, btw) but why it might bork-out on spellcasting Idk.

[Dann-J]

The six second round cycle for a creature seems to start when they first spawn into an area. If you manually place creatures in an area, or spawn them en masse from a script or encounter trigger, then their rounds will all be pretty much synchronised. If all of those creatures decide to cast a spell in the same round, that's a lot of VFX all trying to spawn in a very short period of time (likely in less than a second). Not to mention every creature running its heartbeat or end of combat round script near-simultaneously as well.

 

Spawning them in smaller groups, each separated by a second or two, might help to unsynchronise their rounds, so they don't all act like a well-rehearsed flash mob. Spawning each creature individually, with a brief delay after each spawning (such as 0.5 seconds) might be even better.

[kamal_]

Also you can use the area property "creature cache" to preload the critters in the area instead of loading them on spawn. It improves the stutter when spawning creatures.

[Lugaid of the Red Stripes]

Spam in the message window is also a great source of lag- you might want to try out the DM side to see how many messages are popping up and how quickly.

[Xeneize]

Does 'Complicate Walkmesh' include walkmesh cutters, or it is only the walk/nonwalk tools?

[rjshae]

Does 'Complicate Walkmesh' include walkmesh cutters, or it is only the walk/nonwalk tools?

 

You can make walkmesh cutters a lot more complicated than they need to be, which results in more faces along the edges. I try to keep them simple--say on the order of 4-8 sides, which may result in the unwalkable area being slightly larger than it could be. But the effect on game play from the larger unwalkable area is usually negligible.

[Tchos]

Dann had an excellent suggestion about the use of the walkmesh cutter with Snapping turned on so that it sticks to the edges of those polygons, which has the extra benefit of not getting characters caught on the edges.

 

Anyway, you generally want the unwalkable area to be a little bigger than it looks like it should be, because when you're standing at the edge of it you may end up with part of your body looking like it's embedded in the table, due to the character being wider than the origin point that it uses to calculate where the character can stand.