A second type of "bumpmapping" possible but not yet discovered. (?)

[Legacy_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.

               
               

               
            

[Legacy_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 '>
               
               

               
            

[Legacy_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!  '>

               
               

               
            

[Legacy_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!

               
               

               
            

[Legacy_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.

               
               

               
            

[Legacy_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?

               
               

               
            

[Legacy_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. 

               
               

               
            

[Legacy_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.

               
               

               
            

[Legacy_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.

               
               

               
            

[Legacy_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 .
                     
                  

            

[Legacy_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!

               
               

               
            

[Legacy_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.

               
               

               
            

[Legacy_Draygoth28]

               +1
               
               

               
            

[Legacy_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.

               
               

               
            

[Legacy_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.