Hi i'll try to make this a comprehensive post.
My name is Jason and I'm currently dusting off my 'old' nwn2 dvd's the oc and two expansions are loaded/and playing well now that i've got direct x 9.c on there.
http://www.tweakguides.com/NWN2_9.html
this is a link to a tweak guide that i found useful.
I've worked on a team of two in the past writing story and helping in audio design/play testing a mod for nwn2. I've also spent several hours on with the toolset maybe a couple hundred.
yet, i have some unfinished business to do. I wish to play the oc over while working on my mod we'll call it 'ED'.
my question is this:
what game play tips and tips for builders can someone give me in regards to 'setting it up' for best results?
for example: turning off vertical sync helped a lot with frame rate. changing the graphic resolution in the toolset helped with graphics. oh...that reminds me, my system is fine for running toolset/game.
os 7
8 gig ram
4800 ati cards of which i use one at a time.
another example of a tip i had to use to play lord of the rings on max graphics was: to install riva tuner...and up my fan speed on my graphics from 25 to 90 percent.
i've read through the toolset guides, i even read partially through the lexicon...and i plan to eventually use lilac souls script generator for custom scripting.
but i'm missing something...aside from 'motivational' speaches of stick to it ness..WHAT CAN I DO TO MAKE IT A SMOOTHER GAME AS WELL AS CREATION PROCESS?
SINCERELY~ Jason aka shmity72
Optimization of nwn2..
Débuté par
shmity72
, nov. 10 2010 02:28
Retour en haut
#2
Posté 10 novembre 2010 - 02:56
painofdungeoneternal
-
- Members
- 1 799 messages
Get client extension, also get good custom content like kaedrins which also addresses lacking features, tonyk's AI and rpgplayer1's fixes ( which are in kaedrins as well ).
I'd also suggest the OC makeover edtion since it updates that to use features from SOZ and MOTB.
Other than that, that is a good site to review and follow.
I'd also suggest the OC makeover edtion since it updates that to use features from SOZ and MOTB.
Other than that, that is a good site to review and follow.
Modifié par painofdungeoneternal, 10 novembre 2010 - 03:04 .
#3
Posté 10 novembre 2010 - 03:05
shmity72
-
- Members
- 10 messages
i've heard only good things about tonyk's AI.
#4
Posté 10 novembre 2010 - 03:41
dunniteowl
-
- Members
- 1 559 messages
Some other things to consider are how the shadows are rendered in the game. IN playing, you can go into the graphics options screen and set up the number of shadows to be rendered and how they are done. There are other posts somewhere around here that details this and I cannot recall at the moment how best to suggest to set this up, but casting shadows and point lights are the biggies in terms of performance.
Now, in the toolset, you can set a lot of things up to do some shadow casting and rendering as well that will increase the playing performance and impact on the game, independant of those user selectable graphics options.
IN the toolset, you can take trees, building placeables and things like fences/walls and go into their properties and set the cast and accept shadows functions to reduce shadow rendering times (which means reduced processors and graphics processors loading effort) and these functions are pretty clear (oddly enough, these ones are clearly labeled and function as you might expect based on the terminology used for them.)
I believe I have a post in the Toolset forums that specifically addresses this and I would be happy to find it for you sometime soon, just right now I am on an older laptop with a phenomenal 256MB of RAM and getting this thing to perform at all is a bit of a trick. So multiple pages/tabs is not something I am inclined to do with this particular machine.
Additionally, with the toolset, you can take building placeables and lots of other placeables assets for interior or exterior areas and change them to Environmental Objects. You will then have to set up the walkmesh to cut out these items (if you don't wish the characters to pass right through them) as if they were objects in game that affect the walkmesh and collision boxes. EOs do not take up as much render space or hold as large a memory footprint in the game's files because they are not fully collisioned, nor do they use their base walkmesh data, thus reducing their load on the game. Of course, this is balanced out by the fact that in so doing, you now have a bit more work to make them 'work in the scene' as a builder. An EO building does not have useable doors or entrances, so that's another consideration.
Still, doing these sorts of things can reduce the load on the machine playing the finished module and as such, should improve overall performance during play. There are other tricks, though honestly, these are best asked and discovered in the Toolset Forums where such issues actually make more sense to ask. No worries about having it here; just that you'll most likely find some information already directly related to this in the Toolset Forums and thus may help you to reduce your searching as well as prevent redundant posts.
Other things to look out for is to make sure that your custom content has compatible .2da's and that you check to ensure that there are no conflicts in the naming conventions or line numbers for the custom items. This can lead to people complaining that textures or models are messed up, cause module crashes, or 'break' your module during play. And while these things do not impact directly performance in terms of machine load or smoothness of graphics, they certainly do have a direct impact on the players' perceptions of the quality of their experience while playing your efforts to entertain and engage them.
And welcome back to the madness.
dunniteowl
Now, in the toolset, you can set a lot of things up to do some shadow casting and rendering as well that will increase the playing performance and impact on the game, independant of those user selectable graphics options.
IN the toolset, you can take trees, building placeables and things like fences/walls and go into their properties and set the cast and accept shadows functions to reduce shadow rendering times (which means reduced processors and graphics processors loading effort) and these functions are pretty clear (oddly enough, these ones are clearly labeled and function as you might expect based on the terminology used for them.)
I believe I have a post in the Toolset forums that specifically addresses this and I would be happy to find it for you sometime soon, just right now I am on an older laptop with a phenomenal 256MB of RAM and getting this thing to perform at all is a bit of a trick. So multiple pages/tabs is not something I am inclined to do with this particular machine.
Additionally, with the toolset, you can take building placeables and lots of other placeables assets for interior or exterior areas and change them to Environmental Objects. You will then have to set up the walkmesh to cut out these items (if you don't wish the characters to pass right through them) as if they were objects in game that affect the walkmesh and collision boxes. EOs do not take up as much render space or hold as large a memory footprint in the game's files because they are not fully collisioned, nor do they use their base walkmesh data, thus reducing their load on the game. Of course, this is balanced out by the fact that in so doing, you now have a bit more work to make them 'work in the scene' as a builder. An EO building does not have useable doors or entrances, so that's another consideration.
Still, doing these sorts of things can reduce the load on the machine playing the finished module and as such, should improve overall performance during play. There are other tricks, though honestly, these are best asked and discovered in the Toolset Forums where such issues actually make more sense to ask. No worries about having it here; just that you'll most likely find some information already directly related to this in the Toolset Forums and thus may help you to reduce your searching as well as prevent redundant posts.
Other things to look out for is to make sure that your custom content has compatible .2da's and that you check to ensure that there are no conflicts in the naming conventions or line numbers for the custom items. This can lead to people complaining that textures or models are messed up, cause module crashes, or 'break' your module during play. And while these things do not impact directly performance in terms of machine load or smoothness of graphics, they certainly do have a direct impact on the players' perceptions of the quality of their experience while playing your efforts to entertain and engage them.
And welcome back to the madness.
dunniteowl
#5
Posté 11 novembre 2010 - 01:20
BigfootNZ
-
- Members
- 131 messages
Heres another performance booster ive tried after fiddling, not sure what it would break in the OC but for modules built around it it should work fine.
Ingame the engine doesnt 'remove' characters that are out of visibility like in NWN1, in NWN1 if the character was beyond a certain distance or was around a corner (by that i mean in a separate tile to the npc and there was no line of sight) the engine would effectively remove it visually. NWN2 however doesnt do this for teh most part and it also has much further distances involved... to the point where you can with a default clipping range have NPC's running around visible as tiny people in the distance, which even with LOD can lower your FPS alot, especially since the engine has to work on these objects AI and the like as well, and the further your away the more of them you can get inscreen at once.
(Build an interior with two seperate singel tile rooms next to each other but not linked, stick a monster in one and the player start in another and load it up you see just your room and no monster, now set that area up to reveal all the map on load... now you can see the room, but the monster is also visible as well, which if it was NWN1 wouldnt happen, you've got a NPC with no line of sight now being visible and taking up GPU. Create a set of tunnels with no doors seperating them and place npcs around within, do the fully revealed map and you'll find that you can see all the npcs... why they do it this way is mind boggling, the engine seems to only recognise blocks to visual line of sight if a door is seperating various tiles from each other)
Now the key here that I found was in the Ranges.2da this 2da handles the distances certain things run at if you will, you have the Spell ranges that the Spells.2da uses (ie P, T, S, M, L). That being said the ones I found of use are the PercepRng values, primarily the PercepRngPlayer row.
What this rows values do it as follows, the secondary column can be ignored as with the name column as i havent found them to have any impact ingame what so ever. The primary range column however handles the max distance creature objects are visually despawned for the player, by this I mean if you look at NWN1 if a creature or non static placeable went beyond a particular distance from the PC they will visually fade out, in NWN2 this works the same (although i dont believe it does so for placeables) the problem is in NWN2 the distance is far far to big. In effect the default value of 50 can almost put a creature at the edge of a 150 clipping plane and still have it being visible (dont take my numbers as exact since I havent done a huge amount of testing at the long ranges)... the thing is, there is no reason in being able to still see a creature at this range it just bogs down your graphics card with unnecessary tris and verts to crunch through.
What I do is I set this primary range value for the PercepRngPlayer to 30 (im assuming this is in meters ingame since it seems to line up with the toolsets co-ord system, ie a PercepRng of 30 is the same as a distance of 30.0 in the toolset) and what results is that creatures and npcs 'fade' out far sooner freeing up the cycles your GPU would normal need to render them.
Now you have to realise that from what i can see NWN2 continues to render characters and creatures even if they are being covered totally by other geometry on screen ... why, I dont know, but if you place say 5 NPCs behind a large brick wall and stand your character on the other side ingame and set your camera so the wall fills your screen hiding the NPCs completely you get no real difference in FPS what so ever, which you'd think should happen, instead the engine is wasting your GPU on things that are effectively invisible to the player (most other games ive played dont share this odd issue).
You'd also have to set up the other PercepRng values in the 2da to match up with the new player distance since you dont want npcs being able to react to a player before the player can see them etc.
There is a slight down side to this and its an odd bug, some creatures and npcs DONT fade out, ive tested it and I cant come up with what criteria it takes for these npcs to end up being perma visible outside the new perception range, it doesnt seem to be linked to their own perception ranges and is mostly completely random between module restarts (Although they still are effected by the areas clipping plane so its all right for the most part). Thankfully most of them do fade out at the new distance so while it is 'buggy' per say it still helps reduce the GPU's over head rendering and dealing with more meshs than it really needs to. The distance you would use for these new ranges would be up to personal taste, I prefer 25-30 max, but this might be a little short for some people although its still a good distance ingame.
Not sure what the Combat, Min, Max PercepRng rows are for, havent found any thing in fiddling with them ingame yet.
Also, make sure you keep each tile and object or creature so it is only being effected by only 3 lights max, preferably less ive found this to help alot in performance.
Another thing i find interesting is I once replaced all the speed trees in an area with static placeable trees that had a higher polygon count than the speed trees, and interestingly I gained a decent boost to my FPS in that area... the speed tree animations I guess are a real resource hog, so maybe they arent so 'speedy' after all, you also dont have to worry about the tree seed limit and you can rotate them
... heck you could even have some of the larger placeable trees animated slightly and you wouldnt get that annoying 'all trees swaying at the same time and direction' you do now.
Another thing i think is a problem with NWN2 in general is the over use of separate placeables, each placeable is I assume a new draw call so where a single complex placeable with a single texture would be one draw call, 10 separate placeables in the same configuration with individual textures would be 10 times as many draw calls and as such 10 times the work. Places like the Samarach Bazaar merchant stalls comes to mind where you have large numbers of unique placeables bogging down your GPU all over the place not to mention each one would also have to have its shadows worked on individually where as a single complex placeable with various smaller parts of the mesh grouped together and set as 'dont cast shadows' in Max would only take a singel draw call and a single go at the shadows cast by it... if that makes sense.
Another idea Ive had for my own material is setting all LOD meshs to non shadow casting, and having all tertiary LODs for things like weapons and Shields and even armor accessories reduce to a single small polygon UV'd to a tiny portion of the texture map. Since the tertiary LOD only kicks in at a very long range and as such the player will hardly notice it, but being able to remove/reduce all weapons, accessories and shields to a handful of polygons would give a nice boost to long clipping ranged areas (Although I dont know how a custom perception range distance would impact LODs, I have yet to test if it scales with the new Perception ranges although i dont think it does). Id also do this for small placeables even going so far as reducing things like candles, and any other objects of a similar size to a single polygon (visible face facing down) on their secondary LOD mesh, while it might not see like alot, it all adds up and the player will never notice it. After all do you really have to render the items on a desk at over 50 meters? they are invisible almost as is at that distance but stil taking up valuable GPU draw cycles and polys, verts.
While none of those are really practical for just a module maker like the OP its something many should consider and one of the reasons I think Obsidian was lazy with NWN2. Also Dunniteowl I dont think EO's reduce GPU load, but given how dependant NWN2 seems to be with CPU it still makes a big difference.
Edit:- i thought of another one... if you make 2 areas and place an npc in area 1 with a script on its heartbeat that sends a message to the PC and you place the PC in area 2, you'll notice that the NPC sends the PC the message per heartbeat, what this means is that placed NPCs are active and running even while the PC is not within their area, if you have alot of placed NPCs in a module this could quickly add up and hamper your CPu id guess. So its best to use spawned NPC as must as possible for things like fights since they are only populated when needed and then killed by the PC, id even go so far as to make it so unimportant static clone npcs like city guards would be spawned at locations only when a PC enters their area and on leaving an area these guards are then destroyed... im not sure what real impact this has on performance but im sure it has some.
Edit2:- After fiddling with Ranges.2da somemore today and using some of the Debugmode commands ive figured out what the Secondary range column is for as well as putting one or two things I didnt fully understand into perspective, what i thought was a bug with perception is actually perfectly fine from a logical stand point.. I think ill write up a little Thread discussing it in the Custom Content forumn tommorrow.
Ingame the engine doesnt 'remove' characters that are out of visibility like in NWN1, in NWN1 if the character was beyond a certain distance or was around a corner (by that i mean in a separate tile to the npc and there was no line of sight) the engine would effectively remove it visually. NWN2 however doesnt do this for teh most part and it also has much further distances involved... to the point where you can with a default clipping range have NPC's running around visible as tiny people in the distance, which even with LOD can lower your FPS alot, especially since the engine has to work on these objects AI and the like as well, and the further your away the more of them you can get inscreen at once.
(Build an interior with two seperate singel tile rooms next to each other but not linked, stick a monster in one and the player start in another and load it up you see just your room and no monster, now set that area up to reveal all the map on load... now you can see the room, but the monster is also visible as well, which if it was NWN1 wouldnt happen, you've got a NPC with no line of sight now being visible and taking up GPU. Create a set of tunnels with no doors seperating them and place npcs around within, do the fully revealed map and you'll find that you can see all the npcs... why they do it this way is mind boggling, the engine seems to only recognise blocks to visual line of sight if a door is seperating various tiles from each other)
Now the key here that I found was in the Ranges.2da this 2da handles the distances certain things run at if you will, you have the Spell ranges that the Spells.2da uses (ie P, T, S, M, L). That being said the ones I found of use are the PercepRng values, primarily the PercepRngPlayer row.
What this rows values do it as follows, the secondary column can be ignored as with the name column as i havent found them to have any impact ingame what so ever. The primary range column however handles the max distance creature objects are visually despawned for the player, by this I mean if you look at NWN1 if a creature or non static placeable went beyond a particular distance from the PC they will visually fade out, in NWN2 this works the same (although i dont believe it does so for placeables) the problem is in NWN2 the distance is far far to big. In effect the default value of 50 can almost put a creature at the edge of a 150 clipping plane and still have it being visible (dont take my numbers as exact since I havent done a huge amount of testing at the long ranges)... the thing is, there is no reason in being able to still see a creature at this range it just bogs down your graphics card with unnecessary tris and verts to crunch through.
What I do is I set this primary range value for the PercepRngPlayer to 30 (im assuming this is in meters ingame since it seems to line up with the toolsets co-ord system, ie a PercepRng of 30 is the same as a distance of 30.0 in the toolset) and what results is that creatures and npcs 'fade' out far sooner freeing up the cycles your GPU would normal need to render them.
Now you have to realise that from what i can see NWN2 continues to render characters and creatures even if they are being covered totally by other geometry on screen ... why, I dont know, but if you place say 5 NPCs behind a large brick wall and stand your character on the other side ingame and set your camera so the wall fills your screen hiding the NPCs completely you get no real difference in FPS what so ever, which you'd think should happen, instead the engine is wasting your GPU on things that are effectively invisible to the player (most other games ive played dont share this odd issue).
You'd also have to set up the other PercepRng values in the 2da to match up with the new player distance since you dont want npcs being able to react to a player before the player can see them etc.
There is a slight down side to this and its an odd bug, some creatures and npcs DONT fade out, ive tested it and I cant come up with what criteria it takes for these npcs to end up being perma visible outside the new perception range, it doesnt seem to be linked to their own perception ranges and is mostly completely random between module restarts (Although they still are effected by the areas clipping plane so its all right for the most part). Thankfully most of them do fade out at the new distance so while it is 'buggy' per say it still helps reduce the GPU's over head rendering and dealing with more meshs than it really needs to. The distance you would use for these new ranges would be up to personal taste, I prefer 25-30 max, but this might be a little short for some people although its still a good distance ingame.
Not sure what the Combat, Min, Max PercepRng rows are for, havent found any thing in fiddling with them ingame yet.
Also, make sure you keep each tile and object or creature so it is only being effected by only 3 lights max, preferably less ive found this to help alot in performance.
Another thing i find interesting is I once replaced all the speed trees in an area with static placeable trees that had a higher polygon count than the speed trees, and interestingly I gained a decent boost to my FPS in that area... the speed tree animations I guess are a real resource hog, so maybe they arent so 'speedy' after all, you also dont have to worry about the tree seed limit and you can rotate them
... heck you could even have some of the larger placeable trees animated slightly and you wouldnt get that annoying 'all trees swaying at the same time and direction' you do now.Another thing i think is a problem with NWN2 in general is the over use of separate placeables, each placeable is I assume a new draw call so where a single complex placeable with a single texture would be one draw call, 10 separate placeables in the same configuration with individual textures would be 10 times as many draw calls and as such 10 times the work. Places like the Samarach Bazaar merchant stalls comes to mind where you have large numbers of unique placeables bogging down your GPU all over the place not to mention each one would also have to have its shadows worked on individually where as a single complex placeable with various smaller parts of the mesh grouped together and set as 'dont cast shadows' in Max would only take a singel draw call and a single go at the shadows cast by it... if that makes sense.
Another idea Ive had for my own material is setting all LOD meshs to non shadow casting, and having all tertiary LODs for things like weapons and Shields and even armor accessories reduce to a single small polygon UV'd to a tiny portion of the texture map. Since the tertiary LOD only kicks in at a very long range and as such the player will hardly notice it, but being able to remove/reduce all weapons, accessories and shields to a handful of polygons would give a nice boost to long clipping ranged areas (Although I dont know how a custom perception range distance would impact LODs, I have yet to test if it scales with the new Perception ranges although i dont think it does). Id also do this for small placeables even going so far as reducing things like candles, and any other objects of a similar size to a single polygon (visible face facing down) on their secondary LOD mesh, while it might not see like alot, it all adds up and the player will never notice it. After all do you really have to render the items on a desk at over 50 meters? they are invisible almost as is at that distance but stil taking up valuable GPU draw cycles and polys, verts.
While none of those are really practical for just a module maker like the OP its something many should consider and one of the reasons I think Obsidian was lazy with NWN2. Also Dunniteowl I dont think EO's reduce GPU load, but given how dependant NWN2 seems to be with CPU it still makes a big difference.
Edit:- i thought of another one... if you make 2 areas and place an npc in area 1 with a script on its heartbeat that sends a message to the PC and you place the PC in area 2, you'll notice that the NPC sends the PC the message per heartbeat, what this means is that placed NPCs are active and running even while the PC is not within their area, if you have alot of placed NPCs in a module this could quickly add up and hamper your CPu id guess. So its best to use spawned NPC as must as possible for things like fights since they are only populated when needed and then killed by the PC, id even go so far as to make it so unimportant static clone npcs like city guards would be spawned at locations only when a PC enters their area and on leaving an area these guards are then destroyed... im not sure what real impact this has on performance but im sure it has some.
Edit2:- After fiddling with Ranges.2da somemore today and using some of the Debugmode commands ive figured out what the Secondary range column is for as well as putting one or two things I didnt fully understand into perspective, what i thought was a bug with perception is actually perfectly fine from a logical stand point.. I think ill write up a little Thread discussing it in the Custom Content forumn tommorrow.
Modifié par BigfootNZ, 11 novembre 2010 - 04:22 .
