@Gruftlord - Ah, thanks!  Something interesting about these Atoms (I have a Dell Venue 8 Pro 2GB): They can't do NWN's shinywater but they definitely can (as you probbaly know) do bump-mapping a la NWshader.  NWN asks the gfx card if it support 20-30 specific OpenGL commands and if it can't that option will be disabled.  And to respond to something you said earlier, I also get the vibe that there's some brute-forcing going on.  That's probably not the best term for it, but I guess the right words would be that it's doing a lot of stuff "on the CPU" instead of the GPU.  I can't really see that too clearly with the tools I have but I believe a lot of OpenGL calls (IIRC 70%) that NWN makes have been depreciated for years and years.

@Gruftlord -  I don't know how to explain the following except I've seen it a lot on my computer: If you are not VSync'd (and I'm assuming you're not), it's pretty easy to drop go up and down FPS quite a bit...within a certain range.  If you are VSync'd, though, it seems like it's usually a little more accurate when you drop frames that there's something actually snarfing up those frames.  So if I got, say, 150FPS a second and I dropped to 130FPS in an area, I wouldn't assume that (whatever) ate up 20FPS until I actually had a vsync'd system at 60FPS go down to 40FPS.  I hope that makes sense.  That's just my impression.  I can't technically explain why that's the case or what factors would be invovled, if anything.  

@T0r0 - It could...but for what I wanted to know I didn't figure it would make a huge difference.  It could have if all the people who responded were VSync'd to 25FPS or something like that.  

@Frush - Damn!  This is, agian, with shinywater on, correct?

@Gruftlord - Interesting.  I'd looked at wrappers before and seen this one but I'm not sure how much it relies on specific NVidia commands.  There are a few other general wrappers out there, but they don't tend to work I think because NWN creates and destroys OpenGL "contexts" (read: "workspaces") and I suspect that confuses them.

@meaglyn - Indeed.

@AndrueD - Well, the DirectX might have something to do with something, but from everything I can see, NWN's graphical performance really has the most to do with OpenGL.  Because NWN uses OpenGL.  This aspect of it has, unfortunately, always caused problems or at least complications.  What happened is when Bioware was making NWN, they were working very closely with NVidia.  And so when it came to how they chose to draw things on the screen, they used the "NVidia way".  So when people ran NWN on ATI machines, performance wasn't typically up to snuff.  So Bioware sort of redid things and tried to make both work decently.  But this situation got even more complicated because ATI doesn't really do that great a job with OpenGL, on their end, either.  Fast forward years and years later, to today, and when it comes to shinywater (and not, say, run-of-the-mill graphics stuff that NWN does, and which both NVidia and ATI do fine), it's a real toss-up what's going to happen on a given machine.  I have two computers to test ideas out on but getting feedback from the community about how NWN is actually playing with a given setting (in this case with shinywater) is super informative.  If NWN used DirectX for drawing things on the screen, all this mess would be so much simpler.

@Thayan - Perfect!  Yep!  Thanks for going the extra mile with the screenshot.  That's exactly what you should be seeing and if that's coming in at anything over 40FPS, especially, that's telling me a lot about why NWN might be behaving poorly under some conditions.  BTW, if you're into this sort of thing, I'm assuming that the big difference between your card and mine is probably in the drivers and what the cards actually support versus what has to be done on the CPU.  That any "modern" card is getting the kind of performance you are says some good things about how much support (at least in your specific card & drivers, but also NVidia) some of the funkier/clunkier graphics functions of NWN still have on modern pc's.
 
@Gruftlord - Yep, the shadows system in NWN is really accurate (for shadows in a 3D game) and also really "expensive".  Raw polygons don't seem to be don't seem to be, though.  The big dip when loading horses and PC's can mostly be attributed to uncompiled models and, because NWN draws basically everything you're looking at (whether it's behind something or not), anytime you're not using the default camera angle (i.e. console command "unlockcamera 0"), you're going to get slowdown ranging from "unfortunate" to "unplayable".  BTW, what kind of FPS are you getting with shiny water on in an area, generally? Or do you not notice any kind of hit, at all?

@Thayan - This is a great surprise, actually!  If this is really doing shinywater, those are pretty awesome results.  No need to play around with video settings, as long as it's really displaying shinywater.  NWN should be running like a dream for you all across the board, right?  I am mostly testing on an AMD K53TA-BBR6 (with a Radeon) and I'm topping out at 18-24 FPS nomatter how little shinywater is showing.  I've looked at the low-level OpenGL calls going to the card during shinywater and it's not doing enough work justify eating up 40fps (my card usually runs at 60fps), so I'm trying to understand why it always seems to drop that low.  I'd also love to know if you get similar performance from your home machine.

@AndrueD - Perfect.  So it sounds like you're getting about 50-ish FPS when you can see shinywater on your screen too, yes?

Thanks!  You were getting 90FPS with shiny water on?  What kind of video card do you have in your machine, if you don't mind me asking?

EDIT:  Thanks for the help, everyone!  I'm good for NVidia, would love some more ATI folks' data!    

All you have to do is be in a basic area with water and have shinywater on.  Like this.  But you don't have to be by a big body of water or anything.  As long as you can see any amount of water on your screen, you're good.  It also doesn't matter if the shinywater looks good or if it's borked.

Then hit the tilde (~) to bring up the console, type in fps and hit enter.  It'll spit back a number.  Without moving the camera, maybe type it a few times to get an idea what the range is.  Or you could use the command trace fps, which'll print a live fps count in the lower left hand corner of your screen.

Doesn't matter what your resolution is or anything else.  

I just want to know what that FPS number you get is.  Don't worry about the number being super precise, but if (for instance) it's 28-29, say 28-29 instead of 30.

Thanks!

Edit: I'm guessing that it's never going to come back higher than 30.  I'd like to see how accurate that guess is.

I don't know how the 3D vision thing works but this may be an artifact of just using a large, hollow model.  Let me explain: The skybox may be large but the actual center of the model (the invisible model base) may be quite close to the player, residing in the center of the area.  If some program is trying to consider how close or far away an object is, there's a good chance it may consider the (invisible) model base as its center and not the part we actually see.  In such a case, it could lead to bad conclusions about how to display the model.  There are also one or two funky things about how skyboxes are drawn (or, actually, how things are drawn after skyboxes) which might confuse the logic in a stereoscopic viewer.

Just a guess.  

Though not in this case, but occasionally true static lights (or, potentially, negative lights) can come in handy.  Upside: A lot cheaper than regular lights.  Downside: Only light static geometry.  Because of the vertex lighting (and depending on how complex the geometry is), they can either look pretty neat or downright awful.  Settings, Example Scene, look you can achieve.

Just skimming so I'm actually not 100% sure what's being talked about but I want to say that Thrikreen's unreleased "Art Tools" or updated version of NWMax might have had a feature like this in it:
 

 I believe that someone here in the past, has created some sort of macro for word, or office, or some-such whereby you put in the names of the various terrains, and it automatically does the various combinations for you, spitting out the names of the tiles etc.

 

I don't think I've ever seen such a thing with my own eyes, had my hands on it, just either casusally mentioned by OldMansBeard or someone at CTP (maybe during a NWNPodcast) or a teaser screenshot from one of those two projects of ThriKreen's.

Okay, found a little bit more info.  From looking at the code in IDA Debugger, shininess doesn't mimic how other model commands are processed.  When NWN is reading in an ASCII model and hits a command like ambient or rotatetexture, it will call a subroutine to filter the rest of the line of text to gather the data it's expecting.  So if it's ambient, it's going to call a subroutine which checks for three floats worth of data.  For rotatetexture, it'll call a subroutine which scans for boolean data like "0", "1", "true" or "false".  Shininess is the only command that doesn't call a subroutine and, instead, looks like this.  I.....dunno.  I mean, I'm not sure if that's a coder "short circuiting" it to make it inoperable or maybe just building in the search function into the string search for the command.

FWIW, the way shininess is done is the same in nwmain.exe, processmodels.exe (the leaked internal Bioware compiler) but, interestingly, not in the standalone NWN model viewer.

Tchos: A week or two ago I came across some guy's basic custom content guide for NWN2 and everything was much more clearly laid out.  I know the alpha channel can be used to reflect an environment map or transparency but in a situation where you have an RGBA and R, G, and B are black but the alpha has a grayscale in it (and you have no environment map), the alpha will pick up light.  Like this.  I think that's how the model was set up, anyway.  Out of curiosity, does that look like what you'd think of when you think of a specular map?  See, it's like so much crap is rolled into the same thing with the way NWN does lighting that it can be kind of difficult to pick something apart and say "Am I looking at something new or just something old but displayed in an unusual way?"

Does anyone have an example of either of these doing anything in any context- such as trimesh, danglymesh, animesh, etc.?  All I'm looking for is a basic example, like where you set shininess to 1 and it does something different than if set to 26, or if the specular color shows up somewhere.  I wrote them off a long time ago but I do occasionally see them in models now and then.  I think the last time was on one or both of the non-official DLA gemstone golems.

I did some tests yesterday and it didn't seem like either of the settings were even getting fed into OpenGL.  The only thing I saw was specular, but that was coming in from lights and it didn't seem to be something that you could control but was, in fact, a duplication of the light's Diffuse settings.  But that was it.

Anything?

Thanks!

I'm not sure why you think that an NWN:EE couldn't be backwards compatible.  Existing models use one texture per mesh in a model.  Two if you have an environment map or a bump map.  An enhanced NWN would have support for more maps than that.  Additional maps could even be used to  define materials for PBR.  Those meshes with additional maps would be displayed with additional effects and those which still had the one texture would be displayed the same as they always have, same as in NWShader.  If they wanted to, they could certainly muck with the models but normal maps are going to be an easier way of adding detail and at a lot less expense.  

I suppose there is always the possibility that Beamdog could pick some method of enhancing the game which would slash and burn everything to the ground...but I don't find that likely or plausible.

The biggest fear would be that any NWN:EE would be updated with modern 3d graphical features. i'm not sure anyone would want to risk investing in a NWN:EE while changing so little graphically so it does not break any custom content. I can see the benefit from adding multi core support, steam cloud integreation, gamespy replacement and the like. but i fear it would be bundled with bump mapping and physically based rendering.

I also used worry that an enhanced edition might potentially cause problems for existing custom content but, based on what I know now, I can practically guarantee it would be impossible for a situation like that to come to pass.  So, the scenario of an EE "breaking" existing custom content isn't even an issue.

The parts of the game that a (basic) graphics engine update would touch would have very little to do with how custom content is made but a lot to do with how it's expressed, visually.  So, for instance, in a hypothetical "typical" NWN:EE, it's very likely that all the creature and tile models would be exactly the same as they are in the NWN:Diamond that people buy off GOG.com nowdays.  There might be _additional_ files (like bump maps or additional texture information) that would cause enhanced functionality to "kick in", but it would definitely not be a big change across the board.  

NWN already has functions inside of it to do bump mapping and rudimentary physically based rendering but, for the most part, these commands appear to have either been disabled in the renderer or do something but do it inefficiently.  As far as rudimentary PBR goes, some examples are the specular and shininess model settings and TXI commands like specularcolor, isspecularbumpmap and isdiffusebumpmap.  Even if these things were enabled, they're still pretty primitive.  We're talking specular stuff on a per-mesh level as opposed to having a specular map, but it's still stuff that's already in NWN.

@Valgav - NWNX development has always moved along a lot more briskly on the Linux side.  I mean, at least for the last 8+ years.  As far as I know, there also may be some technical reasons why this is the case.  I have, in the past, set up Linux servers and clients and it's not that hard.  Though it's unsupported, I'm reasonably sure that you can still download and utilize NWN in-a-box (which uses Virtualbox) from here.

AFAIK, fog doesn't and can't work like that in NWN.  If I understand what you're requesting, what you want would be "volumetric fog" and something like that would pretty much have to be done with a special shader.  Otherwise, that's more the realm of rendered CGI rather than game art.  However, you could certainly fake it with light halos, but those are going to have to be things you add into a scene by hand or to models.  I think fxpa_dot1.tga or fxpa_flarel.tga attached to a light with the right settings (or possibly emitter settings) would allow it to be "colored" by the light it's attached to and you shouldn't have to deal with self-illumination issues.  I mean, you can probably edit the settings of the existing models and/or TXI's you're already working with to at least get rid of the self-illuminated nature.

Moreso, you could probably mix dynamic (light) placeables and scripting to create some pretty nifty-looking dynamic scenes if you wanted.

Edit: FWIW, here's Sunjammer's package from the new Vault.

@Grani - Currently?  The other place where you'll still find it is on the Beamdog forums- though it's slowly getting better.

@Asymmetric - Re: Your comment about "But I have no idea how they could go about it."  You're totally right about the tiles, for instance.  Like, even if Beamdog had a NWN:EE on their plate there's the matter of updated character and monster models and the tilesets.  I spend time specifically thinking about how one would go about overhauling the game with as little work as possible and after a really long time kicking it around, I at least came up with an approach for tilesets.  

The actual number of unique geometry elements in a tileset is usually really low.  I don't know how this would work in Blender, but in Max what you can do is run a script to identify all unique geometry in a scene and then turn them into instances.  So, if you had all the tiles in a tileset completely loaded up, you'd run that script (there are a lot of them floating around) and, for instance, all the barrels in the tileset (nomatter how they were oriented) would become one instanced object.  Then you just replace any one of the instanced objects and all of them in the scene change.  So you could up-detail a whole tileset pretty quickly using that method.  Obviously, there would be lots of straggler unique geometries, but I think they'd be vastly outweighed by the same old objects that the Bioware modelers cut and pasted across tiles.  I had the idea a few months ago but I had enough problems loading up the whole tilesets that I just put it on the back burner.  I would love to see somebody play around with this idea, though.  I did a bunch of little tests and it seemed like a "viable" option.

Out of curiosity, did you look over the D20 gun system?  I can't remember if they addressed this or not.  Waaaay back in 2007, a guy named HorredThePlague sort of popped up out of nowhere and rewrote at least part of how the D20 gun system worked before disappearing back into the aether.  And from what I recall (it's been a long time), it was pretty comprehensive and might either A) shed some light on your issue, however dimly, or B) at least show you another way to go about acheiving what you want.  Can't make any promises, tho, and it requires a lot of reading between the lines and piecing things together.  The last time I personally mucked with it was about six years ago (when I retraced Horred's steps for my own perverse amusement) but I want to mutter something about making a new ammotype for the sounds.  I kind of cringe hoping I'm not pointing you in the wrong direction.

Anyway, if that's something you want to look into, you might want to either contact Vanya Mia on the NeverwinterVault in the D20 section, check out how the gun system works in D20 or (if it's still possible to get access) register on the old D20 forums and check out this thread by Horred.  If, for some reason, you become enamored of the D20 firearm system, I outlined a very rough history of it here.

@Lilura - I agree about the "lack of awareness" and even the bias against NWN because of the original campaign.  What I also find really strange is how deeply it's dismissed in certain circles, almost as some kind of ****-up, when it won six dozen awards including "actual awards" like a Bafta and several GDCA (industry) awards- not to mention being used by NATO and the US military for training.

Edit: LOL, word starred by the forum software is not the one you might think.

@Frith5 - It looks like it was basic enough to just switch one texture per tile- which would have done fine to swap the ground texture out.  I'm not investigating this too much but if me or somebody fleshes this out and it turns out it could just do the one texture swap per tile, it probably would have been good for variations but not huge deviations.  For instance, you can swap a regular ground out for a snowy ground...but the trees still wouldn't have snow on them.

@Shadooow - That's a good point but do you happen to know whether or not that texture replacement "just works" or whether you have problems with people seeing the old texture if they join or enter the area after the switch is made in either single player or multiplayer.  

Ninja-Edit: Since I made a demo of this very feature (which, ironically, I don't actually have anymore), I decided to check out the thread and see what I forgot.  It appears that it wouldn't work on a tile, at least at that time.  Do you happen to know if something was updated or changed since that was posted?  

Humorously, a little down in that same thread, VirusMan actually mentions replacetexture.2da and I liked his message (4 years ago?) and forgot all about it, lol.  His message doesn't appear to be indexed by Google, either, which is a special kind of frustrating in its implications.

If I were in that situation (and assuming it uses a standard hakpack like CEP), I'd get some CC skills under my belt, customize the sh*t out of it with custom content tailored for the module, then release it as a standalone adventure.  The funny thing is, people are still buying NWN and they're still playing NWN.  But multiplayer has always been a relatively small percentage of the NWN player base.  The old vault had a survey about it, and something like 10x as many people played SP modules as MP, maybe more.  Looking at the download count for Gladiatrix III from the new Vault, for instance, seems like people are still interested in SP.

Just my 2 cents.  

Yeah, even a really "weak" enhanced edition would help enormously.  If Beamdog/Overhaul even sneezed on NWN as far as an EE goes, that would at least put it on Steam, probably with a Steam Workshop, and with some basic (but sorely needed) graphics engine improvements like shaders and VBO's- a modern way of dealing game models.  If they did just that, it would actually be quite a coup for the community from the standpoint of what that would allow custom content makers to make.

Without being overly somber about it, it's getting harder and harder to imagine that Beamdog is going to be willing/able to pick up a NWN:EE project in a few years when things presumably "open up".  No fault of their own, of course, just kind of how business opportunities present themselves.

I think you're getting anim mesh confused for danglymesh but I hear the rest of what you're saying.  Just to be clear, the reason why I think there's more to it than just the "Replace_tex" texture hook, itself, is that there is a GFF field for the area (.ARE) file called  Tile_ReplaceTex and a .SET file line called ReplaceTexture.  I managed to delete enough regkeys so that the NWN Toolset BETA installed on my machine and, wading carefully through legacy bif's resources, I was able to locate the replacetexture.2da but it was exactly the copy as we have it today.

Speaking of the BETA, lots of interesting stuff in there including many self-decribed "test" models in ASCII.  Looking over it just since last night, there are some really choice bits, including a node patch (as opposed to trimesh) model, an ASCII file which uses a precursor of the ASCII format we have today and a bunch of TXI's for doing bumpy-shiny on bodyparts (specifically) and some other esoteric material.  I can't imagine any of that stuff would run in the game though- the ASCII command simply don't exist for it in 1.69- but it's interesting to look over.

Makes it a bit more irritating to wait for any enhanced edition which may or may not come out in the future.  So many promising things apparently just out of reach.

Yep, I see what you're saying.  I tried several meshes with the replace_tex bitmap on them and it appears to grab the first mesh in the node hierarchy with "Replace_tex" as the bitmap and ignores the other meshes.  But it's still a good idea.  Looking over the model again, I noticed that it's anim mesh.  Can't really tell how important that particular bit is.  I'm probably going to keep plugging away at the thing I was looking at for the other thread, but if anyone wants to look at it more, shoot me a PM and I'll see what I can rig up for ya.