Looking for the "best" way of implementing a skin mesh on a PC. Thoughts?

[Legacy_OldMansBeard]

               OTR - I see, now, what you want to do. Just one thought - the parts-based base models - pmh0.mdl and so on, don't have to be invisible, they can themselves have visible meshes, which could be a skinmesh body, which would always display but could be (partially) covered the armour parts if an outfit is worn but otherwise would appear as is. Now, they only seem to allow dds/tga bitmaps, just like creature models which is a bit limiting but I seem to recall that in one of the last patches, creatures with appearance numbers above a certain number are allowed to have plt's instead. If that's right, defining a high-numbered part-based appearance might just do the trick.

(edit) - sorry, that's probably rubbish. I was thinking of the thing in 1.67 whereby parts-based races could use their own plt's instead of human ones. You would have to create a separate appearance for every skin tone and so on. Although if they all had the same race letter you would only need one set of parts. I'm rambling. I'll stop.

               
               

               

                     Modifié par OldMansBeard, 05 décembre 2011 - 08:54 .
                     
                  

            

[Legacy_OldTimeRadio]

               About putting a mesh on pmh0, exactly.  There were two problems I had with that method: First, the skin meshes didn't seem to work properly unless all bone nodes they were attached to were the 000 versions- like null arm, null bicep, etc.  Second, if I secrete a skin mesh with an assigned texture onto a p-model, how can I change the texture without eating up a new line in phenotypes.2da for each texture I would want to use?

There are some ideas I have about getting around the first problem but the second one seems to be a deal-breaker.  Maybe I'm missing something, though?  I probably won't be able to get a demo of anything out with the holidays but I'd like to keep kicking around the question and see what approaches we can think of.  Brainstorming is useful, even if a particular branch of thought doesn't wind up panning out.

If there are any lurking modders out there, the need to solve this problem could crop up in your future too and sooner than you think:  With the very recent additions of a topology selector,  custom target loader and clothing creator to the open source MakeHuman, it's going to get a lot easier for a single person to create lots of these full-body meshes from scratch themselves.

'>
               
               

               

                     Modifié par OldTimeRadio, 06 décembre 2011 - 12:52 .
                     
                  

            

[Legacy_OldMansBeard]

               A wild idea - haven't tried it (yet), assuming there's no way to get plt's onto base models: decompose the tga/dds bitmap into its RGB components, make three layers of skin, one for each component, (maybe a 4th layer underneath for white) and vary the skin colour dynamically by varying the alpha of each layer using three custom animations with alphakeys that shade up and down timewise, chopping each animation off according to the colour you want.

Alphakeys on skins certainly work (I've used it before) although NWMax doesn't understand them. Whether the transparency would work over 3 or 4 layers, I don't know. I'll try it out and report back.

(edit -added)

Well, it sort of works. I have a skinmesh creature with the multiple skin layers, that changes colour dynamically between red and green via yellow when it plays a custom animation; chopping the animation at half time leaves it permanently yellow.

I haven't managed more than two colours yet, though. Need to fiddle around with layers and alphas 'n stuff.

OMB
               
               

               

                     Modifié par OldMansBeard, 06 décembre 2011 - 03:54 .
                     
                  

            

[Legacy_OldTimeRadio]

               Very innovative idea!  I read it this morning and I didn't "get it" but now I see what you're talking about.  Deliciously brilliant in the way we have to be to get things to work as we'd like!

This might be off topic because of how environment maps are applied to the player model and how that eats up 2da lines, but I'd had some good success with a technique to use a solid envmap to fake a "one layer PLT" effect.  What I do is take a TGA without an alpha, add one in GIMP, "Decompose" the image so I can edit the channels, copy the red channel (say) into the alpha, invert the alpha and then (and this takes quite a bit of time, for me) carefully white-out (solidly or with a brush) all parts of the alpha I don't want to pick up the influence of an environment map.  Then I can tint the creature (I've only used this on creatures) via appearance.2da instead of having to generate new, full, textures.  One model, one texture, many color results.  So these are all the same texture, just using different environment maps as defined in new 2da lines: A, B, C.  The eyes, mouth, claws and back scalesare fully whited out in alpha (so no envmap coloring is picked up) while belly has been carefully blended so the original coloring comes through a bit more naturally.

That specific method I describe yields really impressive results and I was kicking it around as a possibility if some other ones failed.  It would still eat up phenotype.2da lines, unlike your idea, but it's something I've thought about as a "next best", fallback, option.  It's only good for saving space on models and non-PLT textures at the expense of 2DA lines, though, so really I guess it comes down to being used best on tails or appearances.  Anyway, I wanted to throw out the idea, even though it might not necessarily be a useful tool in your train of thought but just on the off chance it did...like somehow your alpha trickery in conjunction with the influence of an environment map to...I don't know...I guess it wouldn't be able to produce a third color like in real life, but...

We are limited to 99 phenotypes, correct?  I think various community modifications have eaten up about 25 or so of those...(?)

The more I'm poring over the content I might be using and looking at how different things would play out, I guess this would really come down to a fairly small number of "nude" base skin meshes and do any other meshes as robes through which the "base" p-model or tail-based "underskin" would physically punch through.  Which would make sense in the context of "I am using this armor slot because I am wearing clothing or at least clothing more substantial than underwear". Edit: It just seems very wasteful in most situations, though.  Even though it's being done on the GPU, the deformation on unseen verts is still being tracked.
               
               

               

                     Modifié par OldTimeRadio, 07 décembre 2011 - 01:23 .
                     
                  

            

[Legacy_OldMansBeard]

               Your envmap trick sounds cunning. Maybe a combination of ideas would work best. I'll leave the alphakey idea with you, I don't need it for the robes I'm doing at the moment. On your last point, I agree it seems wasteful to cover up patches of skin verts but if you think about it, at worst, it's only as bad as having  twice as many characters in the scene so maybe it's not too horrendous.

I didn't know about "MakeHuman" - it looks good. If what I'm doing is obsolete before I've even finished it - great ! The NWN world will be an _even_better_  place '>
               
               

               
            

[Legacy_OldTimeRadio]

               Thank you for sharing alpha key idea!  As far as the skin mesh verts go, you're right about the load and also GPU manufacturers are notoriously clever with how they do things so there may be some automatic optimizations the GPU executes in such circumstances whcih I don't even know about. 

MakeHuman and things like it definitely are nice.  As are procedual texture generators- lord knows I've tested just about every one of them.  But as a person who has spent a lot of time looking for timesaving panaceas, and even cobbling together a couple of my own attempts with MaxScript, for example, I have yet to find anything which procedurally replicates artistic talent or modding skill, heh heh.
               
               

               
            

[Legacy_Rubies]

               Since I haven't actually sliced this model up yet to test it, and am still a tad distracted with swapping these bones around (and redoing some of the weighting... and... okay, I just got really distracted with fixing it up), how does NWN treat bodyparts? I heard something a -long- time ago about it treating skinmeshes and shadows and... something else differently, but it seems pretty unlikely to me, and I definitely know it treats shadows pretty normally. Just figured I'd make sure. '>
               
               

               

                     Modifié par Rubies, 08 décembre 2011 - 03:47 .
                     
                  

            

[Legacy_OldMansBeard]

               Skinmeshes cast shadows as usual, unless you turn them off deliberately of course. Danglymeshes tend to have broken shadows, or none, depending on what kind of model it is.
I'm adopting a scheme whereby the base models (pmh0.mdl and so on), contain low-poly trimesh shadow meshes and all armour parts and robes have shadows turned off. So the figure casts the same shadow regardless of what is equipped in the body slot, which isn't quite right sometimes but near enough for me. It means shadows are cheap in terms of processing load and I don't have to worry about jagged edges, concavities and whatnot in the parts and robes.
               
               

               
            

[Legacy_Rubies]

               It definitely sounds more efficient to use the underlaying bones, essentially, as shadow boxes; I've had my shadows disabled on skinmeshes but my bones are too basic to consider using as shadows, so maybe I'll have to improve those instead. Makes sense, though!
               
               

               

                     Modifié par Rubies, 08 décembre 2011 - 05:41 .
                     
                  

            

[Legacy_OldTimeRadio]

               @OldMansBeard

OldMansBeard wrote...
You can't do the whole body with one skinmesh if you use lots of extra bones because there's a hard limit of 17 bones per skin. What you can do though, and what I do, is to use several skinmeshes within each model. You need to disguise the joins somehow - perhaps a belt at the waist and so on, but otherwise this works fine with no apparent lagginess.

I just wanted to correct something I mentioned earlier about modifying normals on multiple skin meshes in order to fix the visual discontinuity caused along the seam between the two.

If you take a look at this thread (which covers the topic) and then search for "However when I followed the steps Michael did, it worked:", you'll see the process I really meant to direct you to.  I still haven't played with it very much but I'm going through my notes as I code these procedures into MaxScript (as much as I can, anyway) and realized I'd initially misdirected you.

Sorry about that. (!)

Edit: Oh well, possibly for naught.  I can get the seam effect addressed in Max but it's not doing well in NWN.  It might be that it's because the seam is smack in the middle of a highly distorted bit of skin.  I'll keep tinkering.  If anyone finds a way to get this or some other method to help those seams go bye-bye, please post here or PM me.

Edit: Well, figured out a way to seam him without him seeming seamed.  Or close enough, anyway.

               
               

               

                     Modifié par OldTimeRadio, 18 décembre 2011 - 01:13 .
                     
                  

            

[Legacy_WebShaman]

               Impressive!  Keep it up.
               
               

               
            

[Legacy_OldMansBeard]

               

OldTimeRadio wrote...
Edit: Well, figured out a way to seam him without him seeming seamed.  Or close enough, anyway.

Looks good. I was thinking of writing something to falsify the vertex normals in binary model files but then I thought, "I might as well include my own model compiler while I'm about it" and then I didn't get around to doing it.
               
               

               
            

[Legacy_OldTimeRadio]

               @Webshaman Thanks!

@OldMansBeard Thanks and I know what you mean about planning something and then for whatever reason just not getting around to it.   Or the worst, for me, is jumping through 9 hurdles only to find the 10th just doesn't seem possible- but you're still afraid to blow away all the work "just in case" some miraculous solution strikes in the future.

I have made some good progress, though the screenshots below might not indicate it.  What you're seeing in the first one is a skin mesh body applied as a tail.  The nicer looking skin, the white mask face and white diaper-looking thing are all part of that and it's supermodeled into a_ba.  The second shot is the same setup, only wearing a robe.  Really, the only thing magical is that the tailnode in pmh0 has been moved to 0,0,0.  It may appear that something cooler is going on, but it's not.  If you load the toolset and apply one of the creatures as a tail to an existing human (or whatever) it will look like they're riding piggyback because the creature "tail" is being applied at the tail node, which halfway up the body, in the back.  Moving the tailnode in pmh0 to 0,0,0 just causes the tail's root and the main model's root to be applied in the same place, hence the overlay.


And normally I should think it would probably look better if it weren't for the fact that I'm experimenting with a different way of incorporating the skin (and even non-NWN bones) into NWN.

When bringing a skin mesh and skeleton into NWN, there are basically two roads you can take: You can discard the skeleton and reweight the skin manually to a an existing NWN model or you can try to keep the skin weights and bones intact.  Because it would save so much time, I turned to and old but clever idea I tinkered with before I was able to weight skin meshes:

1. Scale up the skeleton and skin as close as you can get them to an existing NWN model
2. Align all NWN-bones (in the base NWN model) to their functional facsimile in the new skeleton.  So align neck_g to the "neck" bone in your new skeleton, rfoot_g to the "right foot" in your new skeleton and so on.
3. Then attach each of the facsimile bones to the NWN bones you just aligned with them.

I'm obviously skipping stuff about resetting xforms and so on to get the idea across.  What you're left with is a NWN model which acts as a subskeleton for the skeleton you imported and you don't have to touch the existing skin weights at all.  When rbicep_g moves, so does the imported skeleton's equivalent (because it's attached to rbicep_g) and the skin deforms perfectly.  Everything just "works".  It's brilliant.

Until you come to a player model that you want customizable.  After you follow the steps above, the coup de gras should be as easy as generating a new p-model (or overwriting pmh0, which I did because I'm lazy) using the new locations of your body parts (torso_g, lshin_g, etc.) and the existing armor parts, head, etc. should just...snap into place.

Not so, apparently.  I think there's something I'm missing about cumulative rotation of the difference between the two skeletons and I think it has to do with more than just the potential difference in rootdummy placement. 

It's a divergence from what I intended but it would be an incredible timesaver and if I can fix whatever my current problem is and then codify it in MaxScript, anyone could do it without having to deal with skin weights- as long as the skin came with a weighted skeleton to begin with.

Edit: I should add (because it's probably not obvious) that there were a few good reasons I've taken this detour to see if it pans out, aside from just being much quicker & easier.  The main one is that the skin-over-skin idea of a skinmeshed tailmodel wearing a robe requires some damned-fine tolerances as far as vertex weights go and I can't reproduce that manually between two meshes.  At least the ones I'm currently working with, anyway.  It's basically skin-tight on skin-tight.  There were some other things like needing to import the skeleton to get fingercurl on the hands that also took me a little farther down the rabbit hole than I plannned.
               
               

               

                     Modifié par OldTimeRadio, 20 décembre 2011 - 08:24 .
                     
                  

            

[Legacy_OldMansBeard]

               I don't know if this is the right answer, but try setting all orientations of all parts to zero in the tail and the base model and the supermodel(s) before you assemble things.
               
               

               
            

[Legacy_OldTimeRadio]

               

OldMansBeard wrote...
I don't know if this is the right answer, but try setting all orientations of all parts to zero in the tail and the base model and the supermodel(s) before you assemble things.

Thanks for the tip!  I took a step back and went over all the MaxScript and found some problems, including a few related to orientation.  I was also neglecting to break my NWN skeleton apart before matching positions of the analog bones in the new skeleton, so child objects in the NWN skeleton which were positioned before their parent were being thrown off when the parent was positioned because they were attached. D'oh!  I'm still having problems with node placement for dynamic body parts and I'm going to spend some time making sure I understand what happens to those nodes once they get hitched up from pmh0, say, into a_ba and beyond.

I'll be honest, there are a lot more moving parts in crafting this thing "perfectly" (i.e. without having to touch a_ba, etc., if possible) than I anticipated.  I've been doing a little experimenting with things like the Skin Wrap modifier so that if I have to back off a "have your cake and eat it too" approach, I still might be able to keep the whole thing automated. 

But...I really like having my cake and eating it too, damnit!  '>

Question: Outside of the rootdummy, does anyone know of any reason why position keys need to exist on regular *_g geometry in a_ba, etc?  Put another way, if I blow out all position keys I find (other than those on the rootdummy) on a_ba, am I going to be shooting myself in the foot?