87 réponses à ce sujet

[MerricksDad]

Do you have bumpy shiny water set in the video options, or does this type of bump map potentially work independent of that option? I'd love to test your exact files on my machine and see if they do anything. I've just tried 100 combinations of crap and it all came out as crap. White crap. nothing else but white. No bumps. No color change. No texture overlay. Just white.

 

I was also wondering if in NWN it might only work on certain model types? I'm using it on an S type creature. Maybe I should try more variety. Do you get any activity on creature textures?

[OldTimeRadio]

In this case I don't have it turned on.  I don't think it requires it (I hope not) but I'm going to go back and start removing things from the scene to see if I have anything else which might be affecting my work.  I'm assuming you're not using an ATI or NVidia but something like an Intel?

 

As far as the effect goes, if it works like I expect there is a pretty big chance it might only work (or work best) on certain model types.  I havent' tried creatures, just a placeable in this case.  I didn't fill out my notes completely but I did reference that it seemed to work best with a non-static model.  Not sure if that's accurate though.  The problem I'm currently having is that I'm can't worm an envmap into the equation to (presumably) get that detail so I might try a Hail Mary with this on a creature/player item and potentially (if it worked) try to make placeables out of creatures like Excimer-500 (?) did in CEP- then picking the "color" that's one of the envmaps.

 

I'll post something to play with in a bit or at least have an answer as to (seemingly) what the requirements are.

[MerricksDad]

I seem to have run across the same threads you did (containing Darth_sapiens), and the recent breakthroughs on TXI bumpmapping (the black specular head example). I'm closely watching that thread, as well as this one, to figure out what we can and cannot do, and what is inherently different between the two. I see they are looking for details related to the compiled model files, and I hope that doesn't limit us here with NWN.

 

Anyway, drooling as always. But going back to reading more on simple mocap with my two cameras.

[OldTimeRadio]

Okay!  In order to hopefully make this understandable to the most people who might want to play with it, I included some specific things.  First, grab the file here and unpack it to your override:

  Load up the toolset, make an "Interior Torch-Lit Only" area, place down an Armoire as, say, non-static and then test the module. 

 

You should see something like this.  Do you need to set it up like that?  Nope.  That's just going to show off the effect with the least light interference.  The main thing is you should be seeing something on the surface of the model and that something should change when you alter the bumpmapscaling line in tx_ice06bmpmp.txi.

 

Included in the archive are:

fx_placeable01.mdl - Placeable light with removed flare

placeables.2da - Modified LightColor, LightOffsetX, LightOffsetY and LightOffsetZ for position of fx_placeable01.mdl, above

plc_a01.mdl - Test placeable model ("Armoire" in the toolset)

tx_ice06.tga - Texture applied to plc_a01.mdl

tx_ice06.txi - Contains "bumpreplacementtexture tx_ice06bmpmp"

tx_ice06bmpmp.tga - 8-bit grayscale texture

tx_ice06bmpmp.txi - Contains "isbumpmap 1" AND "bumpmapscaling 3"

myenvmap.tga - Unused, but there if you want an envmap to test with

example.txi - File that came with official Aurora export scripts/plugins.  Portions may be apocryphal.

 

Other than the txi commands, any other settings you might see (like in the model) are probably incidental so don't hesitate to change setting and see what happens.  The light settings in placeables.2da aren't necessary to see the effect but (based on reading of example.txi) may be necessary to pull the most out of whatever is possible.  The choice of light settings in fx_placeable01 also might not be optimal.  I just don't know.

[MerricksDad]

No bumpmapping displayed on Mobile Intel Chipset 4 Express version 8.10.15.1808.

 

But....have you played around at all with

bumpintensity

The reason I ask is that somebody had mentioned they thought bumpmapscale might actually be thickening the bump mapping, not making it deeper/higher, more like a blur effect. I was wondering if bumpintensity might be the one that makes height appearance more vivid.

[OldTimeRadio]

Here's an updated kit which includes an animated Aurora light moving around the surface of the placeable:

 

It looks much better/clearer than in the video below (I probably need to crank my encoding bitrate a bit higher)...

 

@MD - Hrm, I'm kind of surprised by that because the effect doesn't seem to require having shinywater turned on.  I just played around a bit with bumpintensity and it looked like it didn't do anything.  I'll probably play with it more as I poke and poke.  From at least what I've seen so far, bumpmapscaling 3 and up gives a pretty recognizable surface, even at a bit of a distance.  It all depends on how nice the grayscale map is, too.  I've tried isdiffusebumpmap and isspecularbumpmap and I'm not sure what effect those commands have, either.  I'm kind of flying in whatever direction I want at the moment, mostly still trying to get the same sort of effect I can get with light, with an envmap.

[Darth Sapiens]

Wow guys, this is really cool, I'll be pointing my Kotor threads to this pretty soon, I'm gonna test some of this in my game see if I can get it working, from what I can tell, at least with Kotor ing game and the nwn binary model formats, this has some relations to the smoothing group data in a model, its actually funny how much stuff is still in Kotor from nwn, like vfx that aren't used in kotor. Keeping tabs on this thread from here on out

[OldTimeRadio]

Relatively minor informational update for anyone else playing with the effect:  If you have a bump map that isn't very bumpy (using Revinor's ancient one from here), the bump mapped bits can look good but the poor vertex lighting can make other parts of the texture look bad.  This is what we have to deal with a lot of the time in regards to lighting, anyway, but I thought it was worth mentioning.  Notice how much better the lighting is on the peak of my mesh when I have a stronger bumpmap as opposed to a simpler one? 

 

@Darth Sapiens - Hopefully there is some there  there that both communities can get some use out of! 

[Fester Pot]

Hrm. Very interesting. If it was longer and spun slower, you could create a simulated lighthout swath of light across the area, could you not?

 

FP!

[OldTimeRadio]

Yep.  But two things: First, to make a full-scale lighthouse beam might require so many point lights (NWN can't do cone lights) that the effect might not work/look right and second, the thing I'm fiddling with is really light sensitive and (at least with what I know right now) you give up texture color for surface detail.  So, a cutscene to a miniature (as in, requiring less lights) under very specific lighting conditions (as in, interior torch-lit only) might work.  Cool idea, BTW!
 
Edit: If you grab the tester from this post, extract it to your override, rename placeables.2da to placeables.bak and drop in this plc_a01.mdl, you can kind of get an idea what that might look like-ish.  You'd want to drop down an armoire in an interior torch-lit only area to see the effect best.

 

Edit 2 1/14/15: No luck, still.

[MerricksDad]

Just to keep this thread going, I noticed that Darth Sapiens has these two TXI commands listed in addition to that bumpintensity I was thinking about:

specularbumpintensity

diffusebumpintensity

Perhaps in conjunction with isspecularbumpmap and isdiffusebumpmap, they might actually do something you can see?

 

Also I noticed there is a difference between the bumpmaptexture and bumpreplacementtexture commands in KotOR. Perhaps those commands allow for modification of a different bumpmap than that which we force in with bumpreplacement commands. But perhaps they are set to 0 to begin with, so that is why bumpmaptexture seems to do nothing? Speculation only, since I can't test this at all.

 

With this other stuff I have been working on with the animated texture via filerange, I am also looking at and wondering about forcecyclespeed, and anglecyclespeed. I wonder if a speed was given in ms like some other graphics programs do, instead of fps, that these two might have some effect?

[OldTimeRadio]

Definitely still chipping away at this, but because it's difficult to break out of the bumpyshiny pipeline, I'm trying other ways of getting "there".  Based on string dumps from the NWN-related Bioware executables, specularbumpintensity and diffusebumpintensity do not exist as TXI commands in NWN but they do in KotOR.  Those string dumps are very useful.  I use some other files, too, including the official Bioware export scripts, the Witcher export scripts and leftover "trash" files leftover in various Bioware games.  A couple of good examples that come to mind are "oldgrassinfo.txi" and the *.mat/*.txi files leftover in Jade Empire.

 

I'm trying to reconstruct how bumpyshiny was likely done, and I have to presume based on the bumpyshiny alignment sanity check that it was, and then try to reconstitute that.  And then hope that the functionality 1) did make it into release and 2) it's still there.  I'm thinking simply during the process of trying to do that, I'll probably come across at least a couple of interesting things. 

 

Like that filerange stuff.  For instance, when I first started messing with that, I mapped fnt_dbcs onto a sphere and  I came across a phenomenon where it appeared that not only had one of the dbcs texture "pages" loaded as a texture, but that a second page had loaded as an envmap.  Unfortunately, I immediately began mucking with variables, the situation changed, and I wasn't able to get back to the spot where I could reproduce it, again.  The idea being possibly that filerange might be a way of loading up texture0-3 or somewhere short of that, and get some kind of bumpy goodness.

 

Speaking of bumpy goodness, I believe I may have gotten a little closer to the effect in the first post in this thread.  This document reads like something the Bioware guys were probably using as a playbook for bump mapping and shadows, including some non-obvious things like the bumpy-shiny alignment check MaxScript code (a snippet of which is how I found the doc in the first place):

 

 

And these two, maybe:

 

 

 

Demo used in that document, BTW, can be found here.  Took forever to track down, but I wanted to make sure I had the exact textures so I wouldn't hose something unintentionally by using an incorrect bit depth or something silly like that.

 

Anyway, not a whole lot of progress but still definitely churning. 

[OldTimeRadio]

With this other stuff I have been working on with the animated texture via filerange, I am also looking at and wondering about forcecyclespeed, and anglecyclespeed. I wonder if a speed was given in ms like some other graphics programs do, instead of fps, that these two might have some effect?

 

Might anglecyclespeed require distort 1 and distortangle 1 prerequisites?  "Distortangle 1" searches in the Omnibus could yield a few examples.

[OldTimeRadio]

1/30/2015: Quite a bit of testing behind me, some of it sort of obvious and some of it really reaching and still nothing.  I've started to give an update a few times since my last post but I wind up thinking "Might as well just try more tests" and put it off.  For the last week or two I've been using the IDA Interactive Disassembler to look over things and most of what I experienced will be most accurate if I speak in terms of shaders.  Which are just tiny (in NWN's case) bits of code which do stuff like the bumpy-shiny effect or skinmesh stuff. 

 

Bumpy-shiny: I'm far, far from an expert or even an amateur when it comes to looking at the stuff I see in the disassembler but between my testing and the things I've seen there, the regular bumpy-shiny shader stuff is locked down tight.  Through testing, it appears locked down tighter than KotoR.  One good example of this was trying to reproduce a test in the Deadly Stream (KorOR) forums where at least the red and alpha channels of a texture were having an effect on a Bioware-compiled "bumpy" model.  I could not reproduce that in NWN.  About the only thing I could find some flexibility in was the fact that bump maps don't have to be 8-bit grayscale- they can be 8-bit color images but the net/net is still exactly the same as though it were grayscale.  While the shader may be written a certain way which might imply more functionality, it's like the code is only allowing a few, very specific, things through.  And I think it sticks in the data it wants for the rest.  If I could pinpoint where that is, maybe it could be opened up somehow.

 

isbitmap 1: The problem I'm having with the isbumpmap 1 isn't that it's some rare bird- you can apply that effect to any grayscale bitmap to get a normal map in-game to pretty much anything- and I mean anything.  There are a couple of "to look at more" folders in my override with things like isbumpmapped environment maps, which the game will happily do.  And that's the problem with TXI's: The game will apply that isbumpmap effect (and, I'm sure, lots of TXI effects) on anything you could throw it at.  Until it doesn't want to.  Same with cubemaps, for instance.  My goal was to try to get the cubemap and the isbumpmap to work together in the same way that the shinywater routine does.  Nothing outside of bumpyshinytexture seems to activate the bumpy-shiny shader and, as I said above, when it does you're funneled into that boring "frozen" effect.

 

So what about bitmap/texture0 and texture1/2/3?  Where do they fit in?  Is some of the above possible from a modeling and not TXI sense?

As the KotOR community seems to have proved, and as my research into the export scripts and the code of Torlack's model compiler has indicated, there's probably something going on at the binary model level that no one in NWN or KotOR has been able to reproduce that deeply effects the bumpmapping thing- but nobody's sure what it is yet.  For instance, while the KotOR community may be able to alter a bumpmap on a Bioware-compiled bumpmapped model, they aren't able to produce a custom bumpmapped model from scratch. 

 

Decompiling "blows" whatever it is/was away. 

 

My attempts to break down this wall a bit, with test models like this showed that I could add 4 textures into a model, compile it successfuly with the Bioware internal model compiler and view the binary information confirming I had added certain data more or less correctly via NWN Explorer Reborn 1.63 on the Raw Model & Raw Model Hierarchy tabs.  That specific one is only hooked up to load 2 different textures, but if you look at mesh_b on it, you'll see the differences.  Oh, and the sucker does load the extra textures and I can confirm that with my OpenGL debugger.  But it still just displays the 4t0 texture and none of the others, independent of whatever strange blending options or other trickery I might try.  So far.

 

As an unexpected aside, I'm incredibly non-plussed by what passed for bump mapping in KotOR to begin with.  I can play the game and I'm not far into it but I've yet to see anything that's even remotely impressive, bump-map wise.  There was a turn to the direction of consoles (the XBox in this case) that Bioware took KotOR and Jade Empire and I get the vibe from a few different things, that using envmaps took precedence over bumpyshiny stuff because they were catering to the lowest common denomenator, hardware-wise.  I own Jade Empire, but I still can't get it to run on my system.  I couldn't find anything that stood out bump-map wise from the HD videos of gameplay I could find.

 

Right now, I'm still playing with the 4-textures thing and where that might lead and, also, what kind of costs are associated with baking a large number of normals into the model itself while stripping all other information away.  Check this out- given the space requirements of non-compressed (AKA non-RLE-encoded) bitmaps, it might be that stuffing the faces into the model itself might not be much more taxing than an equivalent bitmap-based normal map solution.  No idea though, it's just a hunch I still need to try.

[Bannor Bloodfist]

It sure sounds like you have attempted to beat this process to death and back.  You are definitely making a very valient attempt at getting bump map working despite the broken or deliberately blocked aspects of the aurora engine.

 

I sure wish you luck and sincerely hope that you will eventually pull that rabit out of the hat.

Modifié par Bannor Bloodfist, 08 février 2015 - 04:00 .

[NWN_baba yaga]

You know what I wonder...

Why no responsible dev. who KNOW it comes by and just tell us what they did and how it can work. It would be so simple but i sense they have some kind of sadistic tendency...

whatever. Your dedication is truly inspiring

They wouldnt even talk about the source code so their ignorance or dislike to help us was always something i thought is a disgusting trait of personality. And yes i´m sure about that!

[s e n]

we should seriously think about talking with bioware guys about starting some huge crowdfunding campaign to give the nwn community a new toolset based on  modern graphics and world building (dragon age, witcher, assassin's creed series for comparison) and the easyness of use for tileset making and scripting of our good old aurora engine toolset.

[Draygoth28]

+1

[OldTimeRadio]

@Bannor - Thanks for the encouragement- I know you know how tedious this stuff can get.  I appreciate it!

 

@NWN_baba yaga - Ha!  You'd think they would, right?  Four months after NWN's release, the number 1 question (literally!) in a list that Bioware had asked the custom content community to send them was "There appears to be support for up to four textures per node. What's this all about?"  Despite inviting the community to ask, Bioware remained completely silent on that and many other questions which were not just asked but asked multiple times.  Very strange.

 

@S E N - Love the idea but I don't think it's going to happen.  There was a thread this last summer on the Baldur's Gate forums, along with an AMA that Beamdog did and it shed some light about what EA/WotC are going to do with NWN...which is to say, mostly nothing.  At least for a few years more.  Trent at Beamdog/Overhaul has tried more than a couple of times in the past to get his foot in the door with a potential Neverwinter Nights overhaul but right now, everyone who has a say (if they bother to reply at all) wants to keep a Neverwinter Enhanced Edition from happening because it would likely confuse people about the Neverwinter MMO.  As far as I know, he's still trying (on occasion) to feel the situation out.  He'd "rewrite the renderer, "Director's Cut" the storyline and jack hard into the community for ideas on where to go."  Two months ago, he made it pretty clear that Beamdog/Overhaul had even tried to license the Aurora engine to use in a new project, but that they would not consider licensing the engine.  I wrote him, personally, to ask if he felt they'd ever let Beamdog/Overhaul license the engine for new projects.  His response: "Outside of NWN, I doubt it."  To license a remake of Baldur's, I think Beamdog had to fork over a cashier's cheque for $100,000.  Probably five times that much, if not ten (which is about what I believe CD Projekt had to fork over to use Aurora for Witcher), to license a NWN:EE.

 

And that's from a guy who's on the inside, knows everyone involved, etc.  I doubt we could raise the kind of money to actually get noses twitiching.

 

But I love the thought! 

 

The way I see it, the more we keep making awesome with the Aurora engine, the more it keeps the fire kindled under the bottoms of people like Beamdog to keep trying to license it.

[OldTimeRadio]

I had initially meant to post this a little while back but I was dealing with a split tooth for the last three weeks and now that I've gotten that taken care of and am pleasantly overmedicated, I have the time and inclination to write this all up.

 

Well, I got some good news and I got some bad news. 

 

The good news: I've managed to wheedle my way into unexplored territory by getting a bumpy-shiny (static) object not to be transparent.  So, bumpy-shiny water, hold the water.  This not the best example possible but you get the idea.  Top layer (2) is the goods:

 

The numbers (well, at least 1 and 2) are important.  They denote the order in which each of the meshes was drawn.  So, in the model (as seen on the Raw Model Hierarchy tab of NWN Explorer Reborn), it looks like this:

 

 

I found out that IF you had multiple mesh objects which were bumpy shiny you could cancel the transparency effect on at least the second mesh IF you also applied a blending of punchthrough in the TXI file of the texture that invokes the grayscale bumpmap texture.

 

You can download the model, textures and TXI file HERE, with a forewarning that the pack is sloppier than usual.  I've included some extraneous files for completeness but, really, the chain of things coming off mirror1.tga is, I believe, the important bit.

 

The bad news:  Unless "Enable Environment Shadows" are turned on in the graphics settings, the effect appears to negatively impact the display of other game objects, chiefly by (as long as it is visible) blowing away the subtle angle-based shading for shadows and transparencies, such as the puffs of dust one creates when walking over certain materials:

 

 

Okay, so this effect is ultimately not viable.  You give up way more than you get in return.  IIRC, I believe the problem only occurs at certain zoom levels and angles which is very similar to a problem I had putting shiny water on a shield about four years ago. 

 

But that aside for a moment, there was always been a scuttlebutt which basically went something like this: "NWN doesn't have bumpmapping because the devs couldn't get it quite right".  Is what I'm seeing, above, evidence of that?  Did they have a similar issue?  I don't think so.  Here's why: If one opens up an OpenGL debugger and examines the actual commands being sent to the card while drawing plane #2, you'll notice that it takes two draw calls, the first resulting in a plain white plane and the second "overdraws" it with the shiny effect. 

 

Here's a screenshot of that first draw call and a screenshot of the second one.  There's arguably some interesting stuff going on with the first call but it's the second, responsible for the shiny, that's really interesting.  Note the use of all 4 textures (0-3) and how different combinations of them are made active (glClientActiveTexture) in a specific order.  Those are not there by mistake.  Those are there to achieve a specific effect.  Although it reads/appears as though it's just switching from one texture to another, from what I've read there's a sort of composite (for lack of a better word) effect that happens when doing it.  Now, as I've already mentioned upthread, you can load those mythical "four" textures, 0-3, into memory but without knowing what those draw calls are intended to yield, I don't know what to stuff in some or all of those texture slots or (potentially) what bit depths or blending modes they'd need and whether or not they'd display properly under a non-NVidia card, if they did.

 

As much as I'd be interested in at least a little more dabbling, the dance steps in that second draw call are well-beyond my ken.  IMO, only someone with a PKPeachyKeen level of OpenGL programming/understanding could "get" what's going on, what's supposed to happen.

[Zarathustra217]

Actually, I wonder if they ditched it because of the issues with ATI cards? (not to mention various on board, usually Intel cards) They never got shiny water to work right with Radeons (which is a similar way of post processing/pixel shading) and doing the significant effort of implementing bumpmaps would be hard to justify if the majority of players wouldn't be able to use it.

[OldTimeRadio]

Well, the first part is a bit sticky to address, the last part of your comment nailed it, at least based on this interview GameSpy did with Scott Greig at Bioware:
 

GameSpy - While the number of polygons that an engine can process in realtime is bound to increase, several other technologies are available that can increase the visual aspect of a game, including such items as bump-mapping, "true" reflection and environment mapping, detail texturing, and dynamic level of architectural detail. Will your next-generation engine incorporate any (or all) of these, or any other "next-gen" architectural/environment effects?

 

Scott - New technologies are always exciting to play with, but they should really only be added if they actually add to the game play experience. There is also the problem of the lack of hardware support for the latest features. For example, some of the latest video cards support per-pixel environment mapping. This feature is really great. It finally allows for realistic metals, not just Terminator 2 like chrome effects, but more realistic texturing effects. The problem is, by the time our game will ship, less than 20% of players would have hardware that supports this feature (Ok, I just made up that number). We are then faced with the option of either, not using the feature, or having to implement two systems and two sets of artwork. It then becomes a choice of can we afford the cost of the extra work required to add a feature that only 20% of the players will get to see. These are the types of problems that occur every time you look at new technologies. In the case of Neverwinter Nights, we managed to avoid this problem by creating a new technique that closely approximates the per-pixel environment mapping available on latest cards, but still works on the older video cards too. Most of the time, we are not so lucky.

[OldTimeRadio]

I inadvertently discovered that there's a hidden cubemap in NWN which doesn't exist as file but is generated via an algorithm.  It's always generated by the game, nomatter what, and sits in memory with all the other textures.  It looks something like this:

 
Since I didn't want any rainbow cubemapped objects, I didn't investigate it much.  But, going through some notes of mine I came up with this page and found out this cubemap is called a "Normalisation Cube Map".  Turns out, it's not just for making things rainbowy.      From what I understand, it's for helping the game figure out how much to correctly perturb a surface normal when used in conjunction with a bumpmap.  They work together.  
 
So normally I would assume that the normalisation cube map above is an under-the-hood thing as part of what-passes-for-bumpmapping in NWN.  Something that's maybe blended into the existing equation of grayscale bumpmap + cube environment map (ttr01__env as an example) but it turns out that it can be accessed simply by referencing the texture NormCubeMap.
 
Which I found very interesting because it implied, at least, that there would be a reason to invoke it separately from ASCII.  About the time I noticed all that, I also noticed that in the demo example I link to at the page above was a complete tangent space normal map (a typical modern normal map which has a blue tinge) except it wasn't in RGB format, it was an 8-bit image.  Still looks like a typical normal map though.  Now, NWN requires its bump maps to be 8-bit and we usually assume it means grayscale but that's not necessarily true.  Turns out, the bumpmap can be color and, in this case, it would make even more sense (in retrospect) that NWN could process a typical tangent space normal map, just with less fidelity than a more modern game.
 
I also noticed that when I used one of these 256 color normal maps, they look slightly better than grayscale ones, but not by a whole lot.  Both grayscale and indexed colors show up as grayscale when not bumpmaps, with the natural grayscale one looking considerably muddier and the 256 color map having a bit more contrast and being sharper.
 
So I don't know what to make of that. I played More KotoR to try to get a feel for something to shoot for, bumpmap-wise, or a clue or something and all I can really say is the bumpmapping in KotoR I and II (from what I've seen) looks absolutely terrible.  If anyone can point to a spot in KotoR I or II or Jade Empire that actually has bumpmapping that looks good, I mean even remotely good, somehow let me know or send a screenshot or something.  All I've been able to pull up so far looks more or less exactly like crappy frozen shiny water in NWN.
 
Anyway, there's a funny twist to all this.  I've spent so much time messing around with different textures and color channel combinations in order to coax out some alternate bumpmap effect that I've randomly come across some non-bumpmap texture methods which look way better than they should.  I'm not really sure if I can put it better than that at this point.  "They just look better than I think they should."  I guess this translates into unexpectedly nice dynamic highlights for a 2D texture.  This is a rough WIP example of what I'm talking about.  Even though it's missing what I hope is a clever envmap addition, it still just...looks....a....little...better...than...it...should...
 

 
This is not a filtered texture.  It's not like the textures in NWNCQ, for instance.  What it is, is a high quality (but only 256x256 resolution) 32-bit tangent space normal map whose color channels and alpha have been broken apart and then rearranged or copied into other channels in a very specific way.  The method I'm using apes Dragon Age: Origin's normal map format, where the normal map's Red channel (lit normals along the X-axis) replaces the Alpha and the Green channel (lit normals along the Y-axis) then replaces the existing Red and Blue channels.  
 
All that seems like an exceptionally strange way to compose a texture to be honest, but I'm going with the flow.  Right now it looks like what's happening is I'm baking the highlights and lowlights while the midrange is transparent...or something.
 
Anyway, there are a ton of other variables both in the model and texture which could be at play so it may take a while to suss out.

[Verilazic]

I can't recall ever seeing any flat surface anywhere in NWN that looks that... non-flat.

[OldTimeRadio]

It's a pretty neat effect, if I can figure out how to tame it.  BTW, I do a lot of talking about blue-tinged tangent space normal maps.  Just to be clear, this effect is not blue tinged or anything like that, that was just the color of the backing I had behind it.  Here's a red backing with a purple light, for instance.  Probably a hideous color combo but...

 

That backing is going to be replaced with an environment map, probably a colored version of something like this, when I'm done figuring out why those highlights work how they do.  If I'm lucky, it'll come together as a 1-2 punch of visual trickery and misdirection.  Make the eye think there's something there when there isn't.