You are here

New limits for NWN 1

30 posts / 0 new
Last post
DrA
New limits for NWN 1

I often get frustrated with some of NWN limitations, like polycount, texture sizes, etc. In the old days, when NWN was created, 512x512 tga was considered huge, and dds conversion was required. Models tended to be low-poly and chunky. Nowadays, with majority of hardware (graphic cards, CPU) you can use 2048x2048 tga without too strong game "hiccup".

I wonder, what the new limits are. How high polycount would you reccomend for:

- tiles

- placeables

- creatures

And what about texture sizes? Is it good idea to use uncompressed 512x512 or compressed 2048x2048? What are your experiences with hogh-poly models and textures of size 1024x1024 and above?

  • up
    100%
  • down
    0%
MysteryX

Older games typically cannot make use of extra VRAM.  The amount of things that can be stored in the VRAM is going to provide the bottleneck.  Things slow down when the video card cannot render from its own memory and has juggling the cache.  And then some games are better than others at managing the cache- some just slow down, some just become susceptible to crashing (I feel that the latter is the case with NWN, but I don't have the expertise to definitively pinpoint that sort of thing.)

I have read elsewhere (I'll try to find the link if I can) that people have tested the "Max Memory Usage" setting in the configuration file (a setting added in th 1.69 patch if I recall), and could not find any improvement beyond a value of 128.  If that's the case, that pretty much sets the upper limit on the size of content NWN can use.

I think the problem you have is not so much the size or complexity of any particular resource.  The problem is trying to stuff multiple big resources into the cache at once.

  • up
    100%
  • down
    0%
DrA

O.K. Thanks. Back to low-poly and/or smaller TGA's then. The only improvement "to do" seems the quality of textures.

  • up
    50%
  • down
    50%
bannor9

Actually, this has been discussed multiple times over the years.  You MUST remember that NWN1 was created to work in win95 and was expanded a bit to work with win98.  XP didn't really offer anything new for NWN.  Regardless, when NWN was created a 512meg vid card was the max you could find.  The multi-core processors are not truly used either, you can force nwn to use the 2nd or 3rd processor etc, but it will still only run on ONE cpu, regardless of the fact that you may have 8 cpus installed.  For CTP, when we were forcing as high as we could go, we never found ANY advantage to a 2048x2028 texture, 1024x1024 seemed to be the highest that the game could use.  Typically, 512x512 was truly all that was needed and having 1024x1024 was only providing a very minor improvement over the 512.  2048 never displayed at that level, regardless of what settings you attempted to use and thus just wasted bandwidth and disk space without really providing an improvement in game.

 

The game and toolset were created before higher graphics were even possible.  The engine was never upgraded to recognize the options of better graphics abilities and most definitely did not get upgraded to recognize the better vid cards.  It simply ignores stuff that it truly does not understand.




  • up
    50%
  • down
    50%
Tarot Redhand

It simply ignores stuff that it truly does not understand.

For which small mercy we should be greatful that it is so (comparatively) stable.

TR

  • up
    50%
  • down
    50%
DrA

Thanks for the info - so the 1024 is absolutly maximum, and not always needed.  Yes, I do remember first requirements for NWN1, but I'm not that tech/programm savvy and was hoping that with new hardware someone could do better.

"Actually, this has been discussed multiple times over the years." - that might be, but my interest in creating CC is quite new, so I've never looked into it before, and this info is not that easy to find now. Good, that you and other people, who know this stuff, are still around and heplfullsmiley

 

  • up
    50%
  • down
    50%
DrA

True. Another silver lining - this forces me to relay more on the quality of textures instead just bypassing it with high-poly models wink

  • up
    50%
  • down
    50%
MysteryX

I find that textures always look better rendered in-game than they look to me when I'm looking at them in Photoshop.  If you experiment, you may be surprised about how small they can go before you can perceive a quality loss.

  • up
    50%
  • down
    50%
VaultDuke

I worked on the bark skin texture for the community patch project, and when i did test high res versions, 2048px did show better image quality over 1024 on the cape. so the game is definitely using those textures. It may have helped, that i am forcing the game to use x8 anisotropic filtering through Nvidia settings.

aside from that though, others are right that it doesn't really make sense to try to upgrade the visuals too much, for the engine can't handle it. Personally i felt that polygon count tanked the performance much harder than texture resolution though.

 

 

  • up
    50%
  • down
    50%
DrA

MysteryX, Gruftlord,

Thanks for the tips. Well, that cleared the issue - if high-resolution is good or bad wink While it is possible to use lower-resolution textures and tile them, it's not the best thing for some of them (like dirt, smudges, organic). The solution seems to use low-res for patterns and 1024 or 512 for the other stuff.

Now, what do you think about polycount - how much is too much for tiles, placeables, creatures?

  • up
    50%
  • down
    50%
Symphony

I've been working on a client-side facelift hak, and having covered a lot of the other improvements, I've been looking into a "vfx" category to round up the set. Some poking around allowed me to start with something easy, the web effect, which was a shockingly pixelated 128x128 to begin with, seems like it gets a lot of mileage from being tiled and stacked. It sure doesn't end up nearly as pixelated in the game, so the game engine must be doing some resampling at higher zooms or something beyond my knowledge.

I'm not a modeler, at least I am not one yet, but I was able to tinker with the texture in GIMP and get something I liked out of it, and I'm pretty happy with the results in game. I'm hoping to go through a lot of the easier to access texturally based fx, like mist and lightshaft and snowflakes, rain, and see what I can do with a double/quadruple resolution and see what that does to the game performance.

For reference, stock web and my 512x512 upgrade are viewable below in before/after format.

https://drive.google.com/open?id=0B-yXVCjkegF5NUlqMVBmaVpzcms

  • up
    50%
  • down
    50%
Jedijax

It's kind of hit and miss. Seems to depend a lot on the system and the game. I'm going to share a little experience. Been complaining about NWN's freezeframing whenever a character comes into view, but never found the why and how to fix it. Recently, after adding a graphical overhaul to Mass Effect 2, the same thing started happening. Whenever a character comes into field of view, framerate drops to zero for less than a second, and the action comes to a halt as the fps quickly rise back again. I was furious about it, because the only game doing that to me was NWN, and now ME too? So I went about, determined to find out once and for all why this happens. Unlike the NWN matter, this time I seem to have nailed it down. See, there was no model upgrade in the ME2 pack; it was all textures, BUT, and this is key, they were mostly UltraHD textures. From what I gathered after reading lots of forums, the issue is VRAM allocation. See, we tend to think it's the speed of the gpu or cpu, or in my case the HD reading speed and such, but it seems to be a limitation of Video Memory. 

 

It is said textures are stored in VRAM whenever your game loads anything. So, the loading you see when you enter an area, is your VRAM storing the graphical resources of the area itself. BUT, characters, creatures, etc. are not preloaded in this way; they get loaded "on-demand" This means that their resources are stored immediately as they are about to come into view. Yhis is why your fps drops dramatically when they come into view, because the VRAM loads them in that instant. This seems ridiculous to me, but it's how things work to make things dynamic and less "loading" and whatever... Point is, having high resolution textures or high poly models, which are "heavier", makes the process more evident. This is why I am always urging people to share their experience with higher tier videocards and heavily modded games, to see if they see dramatically reduced choppines in this instance as a result of better hardware. 

 

Point is, I have a Gygabyte G1 GTX 970, supposably REAL 4 gigs VRAM, which is a modestly powerful card, and I still experience choppiness when creatures come into view, and reduced fps I think are related to textures greater than 1024x1024. Unfortunately, the lower you go, the more it shows. That's the tradeoff everytime. Things look amazing? Performance suffers. Game runs great? It looks horrible.

 

Now, if anyone can share their two cents, and or maybe has a way to fix this insufferable thing... please, do so!


  • up
    50%
  • down
    50%
DrA

Hi-res looks definitely better. I hope you'll share the experiences with game performance so there are some new clues th solve hi-res dillemma. For now 512x512 seems relatively safe choice.

  • up
    50%
  • down
    50%
DrA

Another interesting information:

"..characters, creatures, etc. are not preloaded in this way; they get loaded "on-demand" This means that their resources are stored immediately as they are about to come into view."

So, If I'm guessing correctly, hi-res textures are safer to use with things like tilesets, sky boxes then creatures? BTW, if I use 2048x2048 or even 1024x1024 resolution (compressed to DDS) with placeables, there's a 1-2 sec lag before they appear. So far, 512x512 for placeables and 1024x1024 for some parts of tile (both DDS-compressed) have worked ok. But then, the polycount was low...

 

Edit: new info - the tile count up to 3000 polys for special tile and up to 1500 polys for other tiles should be manageable for NWN1.

  • up
    100%
  • down
    0%
Qlippoth

IIRC, the way around that is to have creatures pre-spawned in another arra or something and copy or move them to where you want them to appear. I. This eay they "exist" and don't casue that hit when they appear regardless of how powerful yo R sustem is.

  • up
    100%
  • down
    0%
DrA

Simple yet good solution. Thanks a lot!

  • up
    50%
  • down
    50%
Jedijax

Well, that's kinda not how it works... See, the first part about tilesets is on point. You can use hi-res on those and you won't suffer the freezing, BUT, they still have a performance impact. As for the pre-loaded creatures and placeables, in my experience, the freezing isn't enacted when they are loaded, but when they come into your line of view, when they actually are perceived. You can even have seen them already, move a bit away, do some other stuff, and once you come back, and get them into your view, still experience the freeze. 

 

As for actual numbers, I'm using A GTX 970, a core duo i7 950 proccesor, and 18 gigs of RAM. This nets me drops on open areas down to 18 fps in a mid resolution. If I went 1920x1080 (which for some reason won't work in NWN) I get as low as 11 fps in said areas. Indoors, with low populated areas, I get 50-60 fps no probs, except during the "coming into view freeze", which, as I explained, drops your fps to 0 for a few tenths of second. Again, this is with a heavily modded NWN.

  • up
    50%
  • down
    50%
DrA

Another bit of info, thanks, Jedijaxsmiley

  • up
    50%
  • down
    50%
Qlippoth

My monitor and NWN don't like 1080p either, but if you make a custom 1910x1074 res it works fine. Not sure about quality if you use scaling thiugh. Excuse my typing, on a train on my phone.  

  • up
    50%
  • down
    50%
DrA

There's a chance, that this will work better with the new hardware :https://xoreos.org

But I'm not sure if it will work with CC and custom - made modules. Looks promising, though.

  • up
    50%
  • down
    50%
Jedijax

How did you do that?

 

  • up
    50%
  • down
    50%
DrA

@Jedijax,

Due to something changed in the Forums, every comment appears as a reply to the last one, no matter which comment you've wanted to reply. So I'm not sure - what exactly you are reffering to? Was it about my last comment or others, above?

Did what?

  • up
    50%
  • down
    50%
Jedijax

Oh, thank you for letting me know! I meant how did quli... qlui... u... guy with little dog in profile pic manage to set a custom resolution? Sorry!

  • up
    50%
  • down
    50%
Tarot Redhand

Edit display options in nwn.ini. Don't forget to back it up first. That's what I did to get full 1920 x 1080 Hd for my new monitor.

TR

  • up
    50%
  • down
    50%
Jedijax

Ah, thank you! Should have been more specific... See, I can get pretty much all resolutions, but they do weird things. Some put a kind of filtering bright screen, which makes blacks look gray. Others, as if the display can't handle them, are resized in 1920x1080i rather than p. Puppy profile contributor explained he set a very specific and uncommon res, and that's what I was wondering how. Perhaps the same as you did... gonna try it today!

  • up
    50%
  • down
    50%
OldTimeRadio
OldTimeRadio's picture

What are your experiences with hogh-poly models and textures of size 1024x1024 and above?

I've spent most of my time modding by testing the limitations of NWN.  Examining those limitations is not always a exact process because their are many vairables involved, like camera angle.  However, one good tip is that all static objects (non-animatable portions of tiles and also placeables set to static) are loaded into memory before the load screen ends and the new level is displayed to the player.  Not on the fly, and so won't cause load lag in a noticable way.  As I said, there are many variables at play, but the basic rule of thumb is that you can jam at least, say, 256megs of textures into a level (if not more) as long as they're attached to static models.  This is a render-quality spelljammer as a static placeable in-game and this (download (0)) is a 1 to 1 conversion of the town of Megaton from Fallout 3, converted to static tiles.  While the spelljammer is more of a test to see how many triangles a model can have (hint: way more than is actually necessary for any reason), the Fallout 3 conversion is more about textures.  Because of how that area was converted (ripped from DirectX, directly), each model has an unnecessarily unique texture that's at least 1024x1024 (if not 2048x204) in size.  I haven't cracked open the hak in a while but the number of texture files in there is....a lot.  FWIW, you can't display 4096x4096 images in TGA but you can if they're converted to DDS.

Performance-wise, I find it helps not to think about the performance in terms of models or textures, but scenes.  If you're viewing the scene via an old-style locked camera, for instance, with mostly static objects, your scene budget is pretty damned high.  If it's dynamic objects (for instance, creatures or NPCs), it's lower.  And, if it's part-based (especially robe-wearing) creatures, it's a lot lower.  

It's all about what's in the scene.

If one absolutely needs guidelines, any basic game-ready art guidelines (i.e. ~200-500 triangles for placeables, same for horde creatures and up to a few thousand for unique monsters) are fine.  The same rules can be more or less be safely disgarded with tiles...though it's important to remember that shadows treble (at least) the number of triangles drawn from an object, and are a FPS killer if turned on.

 

 

  • up
    100%
  • down
    0%
DrA

OldTimeRadio,

Thanks for this explanation, especially the static-dynamic parts. I didn't take THAT into account. The scene means that it's not only the particular CC but everything module builder puts into it (example-tileset+placeables+creatures). So I can build more complex (and memory-heavy) CC, provided I give a fair warning to the prospective module builder wink

  • up
    50%
  • down
    50%
Symphony

OTR, you and I really need to talk some time.

FWIW, I made some new skies I haven't posted on the vault yet, but, before converting to DDS, I made sure they looked okay with TGA. They are 4096x4096, and they rendered alright IG. 4096 seemed to be the size at which viewing the image at 100% seemed to match the IG representation. For whatever reason, half of the sky textures are ground, though, and don't seem to render IG, so, if some day soon I become a modeller, or decide to edit the skybox mdl's in text format.

I don't know how they respond to mipmapping, I'm not sure which of the resolutions is being used in game, and whether that ever changes during play.

  • up
    50%
  • down
    50%
Tarot Redhand

Having played with skyboxes a while ago I came to the conclusion that if you can see more than a quarter (vertically) of your texture, you are doing rather well.

TR

  • up
    50%
  • down
    50%
OldTimeRadio
OldTimeRadio's picture

As far as skyboxes go, I'm both super rusty and never really got the answers I was looking for when I investigated them.  Even after deconstructing them, I still remember scratching my head and thinking they were really hacky.  Like really, really hacky.  IIRC, Bioware had several different base models they used for the skybox model, complicating things further.  Sorry I don't have more useful information to share and Tarot's response rings true with me.  I know some people did do wonderful things with skyboxes, but never analyzed those models so I don't know if they got around the problems you encountered.

  • up
    50%
  • down
    50%