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

[Legacy_OldMansBeard]

               

OldTimeRadio wrote...
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?

AFAIK, only the rootdummy should have positionkeys. On anything else, they would pull the skeleton apart which would only make sense if you wanted the poor creature to explode. So I'd go for it.  That said, though, I am using positionkeys in my skinmesh robe supermodels, but only on special bones that simulate movement of loose cloth that would otherwise have been done with danglymesh. That's not in the regular supermodels.
               
               

               
            

[Legacy_OldTimeRadio]

               Thank you, OMB.  After partly throwing myself at the problem of removing position keys from the a_ba model (there are lots, unfortunately) I stopped and went over absolutely everything again.  I realized that I'd gone wrong in leaving the tail node attached to pelvis_g in my doctored PMH0 and once I attached it to the AuroraBase directly (and positioned at 0,0,0), the overall orientation probelms resolved themselves.  So the overall orientaiton issues in the first two screenshots in my previous post have been resolved.

I say "overall orientation problems" because a new issue has cropped up regarding orientation on individual armor bits.  Those bits are positioned correctly after my fix, and that's good, but their orientation is still that of the old pieces.  For instance:

All nodes are positioned correctly but since, for instance, the neck node has been moved a few game inches forward, the spinal "line" fails to point at the new neck node and instead points straight up- where the old neck node used to be..  I tried addressing this with a LookAt rotation constraint in Max on the Z-axis and it would have solved the issue...

But there's a feature of supermodeling which is normally the coolest thing around.  It tosses rotations.  That's the best way I can explain it and this is the third project where I've run across this behavior.  If you load up PMH0 and then select torso_g and rotate it (maybe so it looks like they're doing a deep bow), save it and load the game you'll notice your character looks fine.  Import that same PMH0 and you'll see it's still just as messed up as when you saved it.  Change the position of torso_g (or anything else) and you'll see it reflected in-game.

This issue with orientation..it's "fine" at the pivot point but the farther away from the pivot point, the more pronounced the difference.  Which is why it shows up so prominently at the top of the torso when the bottom of the torso looks fine- it's because the top of the toso is farthest away from the pivot point.  I'm seeing similar behavior on the other armor parts.

So then, instead of touching a_ba I may have to get creative with what the body part nodes are used for or just make the first template armor in such a way that it doesn't show off the problem. 

We'll see who wins that battle.

Despite this all sounding like bad news, if anyone's still reading here's a video showing just how nicely the stuff that's working, works.  That's cloak 2 and robe 5.  I'll continue what I can to make sure that the cloaks remain compatible but we'll see about the bones which make up robes 5-9.  Other robes have their own skeletal structure and would have to be converted separately.  I'm not entirely sure that's worth it, because almost all material I'll be converting would be converted to perfectly-fitting (crosses fingers) robes, anyway.

I'm still planning on using neck as face and head as hair.

And Happy New Year to everyone!
               
               

               

                     Modifié par OldTimeRadio, 31 décembre 2011 - 10:18 .
                     
                  

            

[Legacy_OldMansBeard]

               Looking good, OTR.

For the benefit of other people who might be reading this - the static orientation of parts in the base models and supermodels really only matter for skinmesh bones. In-game (and in the toolset), the orientations of the parts are always controlled by the animations - defaulting to "pause1" if nothing else is happening - so the static values are more or less irrelevant. You might see the static model briefly during scripted phenotype switching but only for a moment before the animations are reapplied.

Static orientations matter for skinmesh bones, of course, because the static shape of the skin is matched to the static orientations of the bones and the deformations are computed relative to that. That's why we have to get them right.

And a Happy New Year from me too '>
               
               

               
            

[Legacy_Sylrae]

               I remember someone had a playable Kobold Mesh at some point, where some body parts weren't affected by armor and such. Couldnt you just make a non-replacable skinmesh as part of the standard phenotype like that?
               
               

               
            

[Legacy_OldTimeRadio]

               

Sylrae wrote...
I remember someone had a playable Kobold Mesh at some point, where some body parts weren't affected by armor and such.

I don't think I have seen that kobold.  Do you have a link?

Couldnt you just make a non-replacable skinmesh as part of the standard phenotype like that?

If I understand you correctly, I could.  Absolutely possible and I think that's how I actually started out in my very first experiments. The drawback would be that the skin would be locked into each p-model and would not be changeable via scripting.

I'm open to counter arguments on the matter either here or via PM.  There are a lot of moving parts and I've caught myself making terrible planning errors on several occasions.  I don't think this is one of them, though.  We'll see.

The advantage of doing player skin as a tail over impregnating each p-model with a skin & texture is that (among other things) I have a lot more tails at my disposal than phenotypes.  While the limit is apparently 99 phenotypes there may come a day when even 99 available phenotypes...does not seem generous enough.


               
               

               
            

[Legacy_Sylrae]

               ... This may be a stupid question, but why can't you just replace the default phenotype?

Here are the kobolds: http://nwvault.ign.c...s.Detail&id=734
They have the model rigged up so that there are no shin or foot slots, and it uses the bottom half of the kobold legs. I believe they did the same with the heads, but its been a long time.

Point is they have parts that are fixed.

Just curious, why would you ever need more than 99 Phenos for each race?

I would think the simple solution would be to make yous skinmesh as a fixed thing, that replaces the default Phenos. Sure I can see adding more phenotypes, but I can't see you needing more than 5 or 6 to basically cover all builds (since height is standard by race.)
               
               

               
            

[Legacy_OldTimeRadio]

               

Sylrae wrote...
... This may be a stupid question, but why can't you just replace the default phenotype?

Not a stupid question.  As I said, I did.  It just wasn't the method which gave me the most options.  Easiest, yes.  Most configurability, no.  See upthread for more specifics.  I shoot for what I want it to do and try to have a fallback plan if I can't.  I don't know how it's going to shake out.

Here are the kobolds: http://nwvault.ign.c...s.Detail&id=734
They have the model rigged up so that there are no shin or foot slots, and it uses the bottom half of the kobold legs. I believe they did the same with the heads, but its been a long time.

Point is they have parts that are fixed.

This is fine if you want to use regular geometry but I want to use skin mesh as the player's "base" appearance.  So I need bones to deform that skin.  But the existing bones are in slightly the wrong place.  So I break the NWN skeleton, move the joints to where the new skeleton's joints are, attach appropriate new skeleton bones to old skeleton bones and then reattach the NWN skeleton's bones to each other.  Depending on how much I can squeeze out of the nodes as armor parts or adornments, that switcheroo may not be necessary.

Just curious, why would you ever need more than 99 Phenos for each race?

For this project?  I won't.  NWN is all models and nodes and data and special cases to handle nodes or groups of nodes and data in certain ways.  But just because something is called a "tail" or a "body part" or a "spell" or a "phenotype" doesn't mean it's really that.  It's whatever we want it to be that might also be suited by the available parameters of those things.  If you look at a simple lamppost placeable but instead see a spaceship that takes off and lands you can turn it into one.  So, I'm trying not to do anything (if I can) that's going to consume a lot of phenos, unnecessarily.  I or others might want to do clever things in the future in which chewing through phenos can't be avoided so better to conserve them if I can..

I would think the simple solution would be to make yous skinmesh as a fixed thing, that replaces the default Phenos. Sure I can see adding more phenotypes, but I can't see you needing more than 5 or 6 to basically cover all builds (since height is standard by race.)

See above.
               
               

               

                     Modifié par OldTimeRadio, 12 janvier 2012 - 07:59 .
                     
                  

            

[Legacy_OldTimeRadio]

               Too bad, looks like head-as-hair is not going to work in a situation like this simply because the head animations (and something about how the model is applied to head_g node, oddly) don't seem to make it suited for using as hair.  On the left, below, is a neutral standing pose with head as hair and neck as face.  That odd placement I thought was related to a similar problem I had had with necks but I don't think that's the case.  Even if I could get around that, a good old-fashioned yawn rips everything apart- which you can see on the right.

I'm looking at the Omnibus, specifically an excellent thread entitled "Visible open-face helmets and the like - possible?".  There are still a few of you around who participated in that thread and I doff my cap to you all for such great information.

Anyway, I hate this part of modding NWN because this is where things become inelegant out of necessity.  Thinking out loud...what about snarfing up a shoulder node for my hair?  I believe Rubies mentioned something like this early on.  Or possibly both shoulders for, one for the face and the other for the hair?  I'm thinking they don't have rotations in the a_ba supermodels so they'd be "safe", presumably.

Keeping the neck as a separate model is necessary (instead of attaching it to the body skin) because it uses a separate texture.  However, head tracking opens up a seam where the neck meets the body and while I thought this was not going to be a problem after some initial one-off tests, I was apparently wrong.  I could attach the face to the mesh and try to do a texture atlas which would merge both the body texture and the face texture together but I've got at least 25 faces per gender and at least 8 different skins (levels of hairyness) for the males.  Not to mention something like 9 different female body shapes.

So the sheer number of combinations starts to stack up plenty quick if I were to try to do them as one-offs.  Not really a huge problem for personal use but there are some very generous people in the Sims 2 community, permission-wise, and it would be so nice to release this for the general availability so everyone could enjoy it.  And in a way that wasn't unnecessarily bloated.  Still, I guess you can only color so far outside of the lines before you go off the page entirely.
               
               

               

                     Modifié par OldTimeRadio, 13 janvier 2012 - 10:54 .
                     
                  

            

[Legacy_Kalindor]

               However, it does make very nice abstract art...
               
               

               
            

[Legacy_OldTimeRadio]

               

Kalindor wrote...
However, it does make very nice abstract art...

LOL, yeah I was definitely getting a Hendrix vibe off that hair while I was working on it, heh heh!
               
               

               
            

[Legacy_Lord Sullivan]

               @OldTimeRadio

Can't you just adjust the neck part in the animations that create the seem? Like to get the vertices
of the bottom to stay in place while the rest moves?
               
               

               
            

[Legacy_OldTimeRadio]

               

Lord Sullivan wrote...
Can't you just adjust the neck part in the animations that create the seem? Like to get the vertices
of the bottom to stay in place while the rest moves?

Good idea but I'm not sure how I'd implement it. 

If what you're talking about involves modifying a_ba (or anything down the supermodel chain), I'm trying to avoid that. 

If what you're talking about involves something like changing the animroot on the neck and plugging that into the supermodel chain first (before a_ba), I'm going to need help understanding how that works and maybe an example of exactly how it would work.

If what you're talking about is the actual vertices of the neck (which I'm using as the face), that part of the model is a standard mesh and not skin mesh so I'm not sure how I'd go about doing that.

Maybe I'm misunderstanding entirely?  MaxScript tends to jelly up my brain like a hangover.  Any ideas are very appreciated.
               
               

               
            

[Legacy_OldMansBeard]

               @OTR -

How about a skinesh neck, parented to rootdummy (or the model base - it shouldn't matter), with the bone weights shaded between torso_g at the bottom, neck_g half way up and head_g at the top ?
               
               

               
            

[Legacy_Lord Sullivan]

               

OldTimeRadio wrote...

Lord Sullivan wrote...
Can't you just adjust the neck part in the animations that create the seem? Like to get the vertices
of the bottom to stay in place while the rest moves?

Good idea but I'm not sure how I'd implement it. 

If what you're talking about involves modifying a_ba (or anything down the supermodel chain), I'm trying to avoid that. 

If what you're talking about involves something like changing the animroot on the neck and plugging that into the supermodel chain first (before a_ba), I'm going to need help understanding how that works and maybe an example of exactly how it would work.

If what you're talking about is the actual vertices of the neck (which I'm using as the face), that part of the model is a standard mesh and not skin mesh so I'm not sure how I'd go about doing that.

Maybe I'm misunderstanding entirely?  MaxScript tends to jelly up my brain like a hangover.  Any ideas are very appreciated.

The reason I was suggesting is, since you can modify objects shapes in animations that you could go that route,
but if you don't intend to do that then nevermind. THe only thing I can see now is to not seperate the neck geom
between the torso and the face as you're doing. Put the geom with either one completly.

The one we're less likely to notice which would be the neck geom part of the torso and enters the bottom of the head... well I believe it is already this way with the current models.
               
               

               

                     Modifié par Lord Sullivan, 14 janvier 2012 - 01:53 .
                     
                  

            

[Legacy_Sylrae]

               .. Why are you avoiding changing the animation?