HowTo Display a TGA & PLT on the same body part at the same time using TXI's "bumpreplacementtexture" command

[Legacy_Calvinthesneak]

               Ummm yeah... my 3d modelling skills don't extend that far.  I have followed various UVW tutorials and never gotten them to work satisfactorily for NWN.  Granted I have no experience save tinkering with 3ds.  I probably need to start from the beginning and learn all of this the right way.
               
               

               
            

[Legacy_OldTimeRadio]

               @Zwerkules Thanks for that!

@Calvinthesneak Since you don't have so much experience in the UVW aspect, you could always start out with your model just using TGA/DDS textures and then PLT-ize some of the textures later, when you're more comfortable.

One thing I like is that if I want to bring a model into NWN I can always bring it in as a "creature" so I don't have to deal with the PLT side of things.  If you look at c_yinnkeep.mdl it's your basic standard male but it is very easy to edit and doesn't have PLT textures.  No mucking around with separate body parts or PLT's or any of that.  Assuming what you took the screenshot of was a model with a (TGA) texture, you could get away with getting c_yinnkeep.mdl in G/Max, then resizing that new head till it was about the same size as c_yinnkeep.mdl's head, doing a ResetXForm on it, then just attaching the new head to the old one or, if you had named the new head correctly, you could attach it to the neck and delete the old head.

I was just doing this this afternoon as you can see the original neck peeking though.  My character wears the new head like a "helmet" but if you did the same thing on an NPC model like the one I mention above it's very quick:

In your case it gets a model in-game and then you can refine it if you still like the look or ditch it and move onto something else if you don't.  No worries about swapping around UVW mapping/PLT and that stuff unless you want to stick with the conversion, though the texture names might be too long and those just need shortening and re-application onto the model (drag and drop onto it) from G/Max.
               
               

               

                     Modifié par OldTimeRadio, 15 mai 2011 - 09:02 .
                     
                  

            

[Legacy_Estelindis]

               Yes!  Freaking revoluationary!  This opens up so many possibilities!  '>  (Please excuse the excess of exclamation marks - this is just that awesome.)  I wonder if this allows for transparency in the TGA texture?  There are lots of shortcuts one can take in order to create detailed-looking hair with many wispy bits if one uses a texture with transparency...

Incidentally, I've already PLT-ised the whole FR pantheon's symbols in my cloak collection, and it did take a very long time - plus I had to accept certain limitations due to the limitations of the PLT format.  This new method libeates us from such slavery.  Hurrah!
               
               

               
            

[Legacy_OldTimeRadio]

               

Estelindis wrote...
I wonder if this allows for transparency in the TGA texture?

Yep.  I don't have a screenshot but I had targeted another one of the exported Planescape:Torment animations onto one of your medallion's faces and the alpha seemed to work fine.  Also, in the video I link to, that animation also shows alpha transparency.

  There are lots of shortcuts one can take in order to create detailed-looking hair with many wispy bits if one uses a texture with transparency...

I'd love to see some hair using that sort of technique especially if it could be combined with danglymesh, which it should.  If you find that transparency settings you make on the AuroraTrimesh modifier are not being respected or behaving unexpectedly, remember that there are also alpha-related TXI commands which may be needed to get the desired effect.  And I guess if you were doing that you'd want to put those commands into a TXI file for the desired texture and not the sacrificial one.  Can't wait to see what you come up with!
               
               

               

                     Modifié par OldTimeRadio, 16 mai 2011 - 02:19 .
                     
                  

            

[Legacy_OldMansBeard]

               I can get transparent holes in tga overlays to work if envmapping on creatures is turned off in the client, but otherwise I just get shiny. Setting an envmaptexture in either or both of the txi's doesn't seem to override that.  Am I missing something ?
               
               

               
            

[Legacy_OldTimeRadio]

               

OldMansBeard wrote...
I can get transparent holes in tga overlays to work if envmapping on creatures is turned off in the client, but otherwise I just get shiny. Setting an envmaptexture in either or both of the txi's doesn't seem to override that.  Am I missing something ?

You're right, OMB.  I just looked in my own client and environment mapping was off.  A few days before getting into tinkering with this I had been working on a method of getting bumpyshiny onto a shield but I was running into a problem where I believed the envmap on the player (or the tileset or...(?)) was causing an unwanted effect which caused some bizarre problems with the GUI & game.  My blog entry "Shinywater on a shield- but not without problems" has a video attached which you can see the bumpyshiny effect and also the problem associated with it.  Anyway, I must've turned it off during those experiments and forgotten about it.  '>

If you wanted to take a stab at tinkering, these were some untested ideas I had about what kinds of things might be tried to either remove an envmap or negate it in relation to my problems with the shield which might be applied to the problem of envmap on the 32-bit TGA mesh.  You're probably more familiar with how some of these work than I am but I'll toss them out anyway:
* isenvironmentmapped- Boolean, I assume, maybe can set to false to turn off?
* envmap - directed to a purely transparent TGA
* cube - TXI with cube 1, filerange 6 pointing to TGA's 0-5 which are also purely transparent
* alphamean - Zeroed out alphamean added to TXI for the above cube and envmap suggestions.  I haven't used this one much, I believe that would make it as transparent as possible.

And, of course, anything which might be applied via an AuroraTrimesh modifier.

If a workaround via TXI can't be found to get rid of that envmap, and if the problem really is caused by the default environment map listed in appearance.2da, then it might require making a new phenotype with ENVMAP set to "****" or testing with a creature appearance without an ENVMAP to at least see if the idea is going in the right direction  Hopefully it won't come to having to make a new pheno just to solve an envmap problem but there's a fallback system for phenos which might be able to get around the worst of it.

Don't have too much time this morning to test these ideas out and some of them migth just be flat-out wrong suggestions but my RL took a turn for the ultra-weird yesterday so I'm a bit scatterbrained at the moment:  I'm selling a bit of property with a building on it which is next to my house.  And there's a buyer who seems really interested in it.  So interested, it turns out, that he was driving by the property at 3AM Sunday morning and noticed there was someone breaking into the building.  He confronted the burglar, thinks the burglar might have a gun, drives off and calls the police.  Police come and arrest the burglar and all the day before the buyer is to be shown around the property for the first time, today! 
               
               

               

                     Modifié par OldTimeRadio, 16 mai 2011 - 02:54 .
                     
                  

            

[Legacy_s e n]

               

OldTimeRadio wrote...

If a workaround via TXI can't be found to get rid of that envmap, and if the problem really is caused by the default environment map listed in appearance.2da, then it might require making a new phenotype with ENVMAP set to "****" or testing with a creature appearance without an ENVMAP to at least see if the idea is going in the right direction  Hopefully it won't come to having to make a new pheno just to solve an envmap problem but there's a fallback system for phenos which might be able to get around the worst of it.

i think 2da edit to disable evironmental maps on the creature is the only way to get transparencies on creatures, correct me if im wrong
about an year ago i tried to cook a water texture that has both reflection (envmap) and transparency layer, but i couldnt succeed, it seems the alpha layer of the tga is used for transparency as default (if there is no txi info), but if you add a txi to tell him to reflect the envmap or whatever other effect, the txi gets informations from the alpha layer and so your transparency will go to BLEEEPP!
               
               

               
            

[Legacy_OldMansBeard]

               

OldTimeRadio wrote...
...

* isenvironmentmapped- Boolean, I assume, maybe can set to false to turn off?
* envmap - directed to a purely transparent TGA
* cube - TXI with cube 1, filerange 6 pointing to TGA's 0-5 which are also purely transparent
* alphamean - Zeroed out alphamean added to TXI for the above cube and envmap suggestions.  I haven't used this one much, I believe that would make it as transparent as possible.
...

I've tried three of those -
isenvironmentmapped 0
envmaptexture <a completely transparent tga>
alphamean 0
in txi's for both the sacrificial and the real textures and - it doesn't turn off shiny. '>

For my purposes, turning off the envmap on the appearances would be no hardship - provided I can do the opposite  and provide an envmap when I do want shiny.
               
               

               
            

[Legacy__six]

               I did some messing around with this with Project Q, when we were trying to create a wearable masks item type. Getting armour parts to use tga textures instead of plt is pretty easy - as well as this method, you can also just name the model incorrectly internally and it will confuse the engine into using whatever textures you specify instead.

Getting such a model to support alpha transparency, is a different matter. TXI files' alpha settings are completely ignored for this - as is the envmap column in baseitems.2da. The only way to remove shininess appears to be to disable it on the entire creature from appearance.2da. Which means you then have to edit the colour palettes to have no alpha channel, or else your metal armour becomes transparent.
               
               

               

                     Modifié par _six, 17 mai 2011 - 02:36 .
                     
                  

            

[Legacy_Builder_Anthony]

               Im very confused but ummm................Go team! '>
               
               

               
            

[Legacy_OldTimeRadio]

               @_Six Thanks for the alpha information and...the renaming trick, I thought that only allowed for all TGA only?

@ OldMansBeard I didn't do any experiments removing the envmap in the phenotype.2da and then trying to add it back via TXI.  If you can make that process work for you, let us know.  I tried a number of different TXI commands and some model trickery but I couldn't get the texture to switch to transparent which is unfortunate.  My understanding of the portion of the TXI system which bumpreplacementtexture is a part of would indicate that it still might be a possiblity via TXI.

However, by attaching an emitter I was able to get transparency off my alpha with an object attached to my test head model.  I didn't think that was going to fit the bill for what you were probably working on so I rode the wave of transparency available via emitter and surfed right into a transparent chunk!  This functionality may just be limited to the head (though I tend to doubt it) and from all my scans of the Omnibus, I was under the impression that an emitter could not be strapped to a bodypart, at all. So...



Upper left is regular geometry attached to the head model, using the bumpreplacementtexture TXI and suffering from shinyalpha.  Lower right is emitter attached to the same head model, invoking a chunk where the chunk is just a regular model with Transparency Hint set to 1.  Oh, to save you and anyone else some time getting into this, HERE are the files to drop into your override folder and test out.  The file otr_nwn1.txi is spurious and should not be necessary.  It was left over from testing and just slipped into the archive by mistake.  You may also see some unusual things in the model itself, like certain naming conventions and an a-node.  I don't think they are necessary for success here, just more scraps leftover from my testing.

I haven't had time to ponder what all this means but the above may represent a full-featured alternative to the bumpreplacementtexture method.  I'll bet each method has some little differences which make them more attractive than the other, given the task.
               
               

               

                     Modifié par OldTimeRadio, 18 mai 2011 - 01:10 .
                     
                  

            

[Legacy_OldTimeRadio]

               Update: Well, bumpreplacement texture definitely has its advantages in a situation like this: Emitter chunks, even when the emitters are attached to their model base via a dummy, don't seem to pass on rotation  to the chunk they invoke.

For instance, with the head set up in the way I have in the archive I link to, do a bow emote.  There is a continuous orientation alignment with the ground and so the emitter chunk cube never rotates.  Even positionally, the movements are a result of the basic emitter Inherit and not truly the correct position changes one would hope for, I believe.

Both the BioWare Export Scripts and NWMax leave a bit to be desired when it comes to clarity about how inheritence works but NWMax seems to imply Inheritence might be cumulitive instead of exclusive:

I'm using NWMax Plus (which is closely based on NWMax) and I'm not sure which of my setting changes during testing "took", given the "last configuration change wins" way NWN reads ASCII models.  For instance, if you have Ambient and Diffuse set to one thing in the Blinn material applied to a mesh and have set Ambient and Diffuse (in material override) in the AuroraTrimesh modifier, I believe both are still written out but the AuroraTrimesh override settings "take" because they're written out later in the ASCII file.  I just noticed this difference after my testing was done. 

I gave a serious try at getting around this by trying to animroot the box on mychunk.mdl as neck_g and that didn't seem to affect anything, even when I'd imported the pmh0 hierarchy into mychunk.mdl and replaced the neck_g dummy with my neck_g box.  Nor by supermodeling it into a_ba.  Even after importing the animation names for c_antoine.mdl (which, I believe, is all of them) into mychunk.mdl's model base and deleting the actual animations.

I've never done anything like this with supermodeling or animrooting but technically I don't see why it wouldn't work to cause my mychunk.mdl to behave like the geometry which is actually attached to the modelbase itself.  If I'm communicating what I tried to do clearly enough, is there anyone who is familiar enough with exactly what I'd have to do to get the simple box in mychunk.mdl  to act like, say, neck_g via supermodeling or animrooting?

My goal is just to have the box in mychunk.mdl have the same movements as the geometry which I'd attached to my head model's Aurora Base and which I use the bumpreplacementtexture method to change the texture of.  If there's some less-complex way to go about this, I'm all ears.  I really don't want to actually have to have keys on the box in mychunk.mdl, that would just eat up way too much space for what it yields, I believe.
               
               

               

                     Modifié par OldTimeRadio, 18 mai 2011 - 03:35 .
                     
                  

            

[Legacy_Estelindis]

               Thanks for the updates, OTR.  This continues to be a very interesting thread (and NWN continues to be a very finicky game to work with, in certain respects).
               
               

               
            

[Legacy_OldTimeRadio]

               I was working on another project (think "emitter goggles") and I unexpectedly found myself staring at this same problem of alpha on an emitter that I also needed to inherit movement from the bodypart.

I haven't resolved the emitter chunk's alignment issue but for the standard emitter the relevant settings are:

Update: Single
Render: Billboard to Local Z
Inherit Properties: Inherit (only, none other checked)
Under Start and End:
Size X (some size, in meters)
Size Y (some size, in meters)
Just below that, Birthrate of 1 and Life Exp of -1.0
Identify a texture by name and I think that's it

Or you can download the head I was using in testing here, just look at the settings on AuroraEmitter001, which is the child of Dummy001.  Textures used and anything else would be in a download link upthread.
               
               

               
            

[Legacy_GianniAgn]

               ....
               
               

               

                     Modifié par GianniAgn, 25 mai 2012 - 11:49 .