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

[Legacy_Jenna WSI]

               Where are these bodies from? Never seen these.

OldTimeRadio wrote...

               
               

               
            

[Legacy_OldTimeRadio]

               They're both based off of the Titan Quest player models, from the TQ modding community.  I know at least the female is from a modder named Psych0phobiA.
               
               

               
            

[Legacy_Failed.Bard]

               The thought I had for it, was breaking the PC up into less parts, and meshing those segments together.  The theory being, that the now unused part slot could be used for adding accessory appearances to, since the part appearance was already added up the chain.
 I'd only tried it out with normal combined parts, not skinmeshed ones, so I don't know how what would affect bones, but it did allow me to add flame emitters in the hand slots that overlapped the hand added along with the forearm.
               
               

               
            

[Legacy_MerricksDad]

               I stopped in to check if you had made any progress. I see we're at about the same place in our quest...

I went through some of the model nodes the other day to see what I could get to work at each node. Here's a rundown of what I was working on:

p_ geometry nodes: can't get skins to work, does use plt, alterable by wearing items, can't use backward nodes in the model heirarchy, nor can it use forward nodes. Could be a mistake on my part. I may need to pass alternate model hierarchy. Its as if geometry is placed upon the existing structure, while robes are placed as an overlay to the existing structure.

p_ robes: skins work perfectly, does use plt, alterable by wearing items, but cannot be applied without a robe actually on (unless I can make a monster skin and apply that to the player in game), uses any model hierarchy its told to use

p_ cloaks: skins work perfectly, does use plt but uses special cases in 2da, alterable only by wearing cloak item, uses any model hierarchy

p_tail/wings: skins work well as long as model hierarchy is altered to be based upon the tail/wings node. I can programatically do this pretty easily. Does not seem to be able to use plt (is that right?), cannot be changed by wearing items, but does affect the base character appearance. Script could be used to modify tail upon wearing certain items.

w_weapons: main and offhand weapons can accept skinned models with custom hierarchy, which opens up the ability to create mirrored hierarchy so a gauntlet might send lightning vfx up the arm properly. Additionally, an offhand weapon could be constructed which could alter the appearance of the entire model much like a robe. Can't seem to use plt, and cannot affect base character appearance.

So why did I do this? Well I wanted to see from which nodes I can make new robe parts. I am stuck at this part right now: I can't get robed parts on every p_geometry node. I may be mistaken, because it appears that you have done just that. I have to assume that if you have, then its just me not getting the bones in the proper output order as listed on previous page.

Bookmarking this thread...
               
               

               
            

[Legacy_OldTimeRadio]

               Very good info there, though it can be difficult to nail down the difference between whether something works and how it works, when it does. 

For instance, putting skin mesh on player body part geometry (aka "p_ geometry nodes").  This is possible, and so technically it works.  But it's the way it works which makes it very difficult to achieve anything with, at least in my testing so far.  That's not to say that there aren't tantalizing results which seem to imply otherwise.  I had problems doing the same thing in the past, likely from the node I chose to try to add skin mesh to and how my skin mesh was set up.

Try using my Big Idea Tester as a left bicep and maybe you'll see what I mean.  Play around with dynamic creature's body parts in the toolset and note how the skin mesh shifts around.  Now, do the same thing with the BIT with the model set up as the right bicep.

I mentioned how the skin mesh was set up could yield different results.  To explain that a bit: IIRC, the elements of my BIT skin mesh are each weighted to the geometry they came from and that geometry has 100% influence on them.  So the left bicep subobject element in the BIT skin mesh is 100% weighted to lbicep_g, for instance.  Instead of a tangled mess when experimenting with things like how skin mesh works when applied directly to body parts, you can get a slightly clearer idea why the skin mesh is doing what it's doing.

To answer your question/clarify, what I did in the previous screenshots are both, essentially, robes.  Just plain, run-of-the-mill robes. 

Another example is the skin mesh body on the tail.  Works, just doesn't play all the human animations and can go out of sync.  That kind of thing.
               
               

               

                     Modifié par OldTimeRadio, 09 février 2013 - 08:31 .
                     
                  

            

[Legacy_MerricksDad]

               Very amusing how the skinmesh wraps itself around the left forearm in both test cases for biceps.

I went as far as to install a reversed tree structure from right hand all the way back to torso so that I could create a hand object that created an entire sleeve. I figured it should work perfectly, but it also wraps itself randomly around various nodes, and/or shoots off into space. I tried with and without local animations so that I could make the skin conform to the whole tree, but alas no-go.

In a few places ( and I think one is right in this thread) I had read that part geometry doesn't properly take skins because of named node order. Something about how custom skin nodes have to come before any nodes the engine relies on for part geometry. I find that even if I do include the entire tree structure in my hand model (similarly named or otherwise), due to how part geometry is attached to the model, I can't bypass that issue.

Unfortunately, various nodes seem to be hard-coded very differently in how they work. For instance, wings, tails, and robes are essentially the same format. They can take ANY skin and any animation set. The only difference is that robes are applied almost like a second model based at the same aurorabase, while tails and wings are based at those nodes respectively. Like robes, cloaks are based at the aurorabase, but unlike robes, cloaks follow a slightly different plt and model handling method using that odd cloakmodel 2da. However, if you ignore that fact, you can actually make the cloak and robe do the exact same stuff.

In testing the weapon model as a base for more skins, I studied bioware's whip and original other skinned weapons such as flails. Like with other skinned models, if you rename them to fit into part geometry, they behave very differently. Otherwise, weapon models could behave exactly like wing or tail models when used as skins based at their respective nodes. The main trouble then with weapon skins that affect other model structure would be that weapons could go in either hand and you could not build a model that worked for both sides of the body. However, that leaves off-hand-only stuff a potential hotspot in my project.

The best news I have found so far is that you can provide alternate node tree structures for every odd-node skin (wing,tail,weapon). This is the only reason I am still working on this project. But, you have to supply the entire modified pmh0 tree structure for all those off-nodes (wing, tail, etc). That's definitely something we don't have to do with robes or cloaks, because they base at the aurorabase. Its also something that could make my project not as useful to people, due to file sizes. I mean we are talking a separate a_ba and a_fa series for wing and tail nodes (and offhand items if I go nuts). With scripts, those are not hard to create. But they may be hard for users to swallow if they are packaged into online-play modules.

I suppose you don't have to include ALL the body tree structure. I mean its very unlikely that an off-hand item skin would affect the opposite foot. But if I intend to create a wing model that works exactly like a robe, then yes, I need basically the entire body's tree.

In any case, its very fun to poke around with this stuff, and I am very interested to see what you make of it all, especially since we seem to have been working side by side on this and I didn't even know, for years '>
               
               

               
            

[Legacy_Rolo Kipp]

               <digging in the linen closet...>

Dude! Just finished playing with your robes.. OMG! They work!
*does snoopy dance*
Wanted to put one on my trusty assistant, but she refused to wear it ;-P And what's with all the ladies named "Human Male NPC 1"? ;-)

Now, for a complete set of disassociated armor to try that on in layers, right?

<...for lots of drool towels>
               
               

               
            

[Legacy_OldTimeRadio]

               @MerricksDad - Very cool that you took the time to reproduce what I was saying with the bicep test and that BIT model, and excellent post overall.  This kind of skin work can kind of get to be a boondoggle and that little exercise with the bicep shows how you can be thinkiing everything works out one way only to find out it doesn't...quite.  I think there are lots of interesting things you mentioned especially, for instance,  the unconventional use of skin meshed weapons.  But sticking to just robes and cloaks for a moment...as "the safest ones": I don't have a definitive answer on this but where you're going/are, if you run into a snag with how your skin mesh is playing back animations on a robe/cloak, try moving the skin to the top fo the node hierarchy AND supermodeling into whatever the appropriate coat supermodel is.  I.e. for my human male, I'd be supermodeling my robe into a_ba_coat.  The little tweaky stuff such as you saw with the bicep test with the BIT does not appear to stop there and there's similar issues with robes, though they're more subtle.  So, again, if you have problems with desync, try moving that skin node up to the top of the hierarchy and try the coat supermodel.  For this full body stuff, it's about reducing the "noise" as much as possible and those two things, today, seem to be working to reduce the noise (i.e. the animation sync problems) the best, even with all body parts hidden (except for head, which doesn't appear to produce an effect, anyway) in parts_robe.2da.  Conventional CCG wisdom says center the pivot on your skin mesh and not, say, moving it to 0,0,0 and from what I've seen this advice is of dubious value but in this case, conventional wisdom probably can't hurt.

@Rolo - LOL!  Indeed.  Yeah, I think I may have some trouble coughing up that armor.  And also the deal with the toolset not letting me visually edit the armor combos unless the parts replace the human base phenotype.  From what I've read, I believe changing this functionality was in the cards for 1.69 but the toolset programmer(s) who would have been tasked with it were unavailable.  Maybe someone like Virusman might take it on, the pmh0 references seem to appear pretty frequently in the toolset exe's string dumps.  Perhaps a toolset extender modification which allowed you to change what p-model was loaded for editing armor via an INI?  What I may do is make a model very similar to the Big Idea Tester with a few little changes which should reduce the animation desync problems down to (if my testing this morning, with the skin node hierarchy change, et al. that I mentioned above to MD) almost nothing and then say "Here's a sample robe for the full body dynamic armor.  All you need to do is figure out/create the rest."  Like the toolset issue, using scripting to deal with unclothed player being invisible, creation of appropriate armor parts, etc.

Though, now that I think about it, I'm not sure how much different that would be than WhatBrick's female elf full body robe on the Vault.

It kind of gets to be like a full-fledged VFX PC Personalization system: One looks at Ippensheir's and (at least my mind, probably yours too!) practically explodes with ideas about how it could be used.  Yet, "curiously", nobody seems to have gotten past a certain level of exploitation with it.  I'm starting to get wary and think that when I see situations like this, it's because everyone walked down the same path, fell down the same bottomless hole- and over the years it's just been a procession of people doing the same thing.  As in, the original concept in this thread, of doing the robes as the now-known(?)-to-be-accursed tails.
               
               

               
            

[Legacy_Rolo Kipp]

               <trying on the glove...>

Hmmm, what if you don't hide the body parts and ignore the clipping while you adjust the armor. Then cut away the non-armor parts of the body parts and save them as a "skinned" pheno.

That might also be cool to create invisible people who's armor isn't invisible... or animated armor, etc. But primarily, wouldn't the armor then be visible and aligned with the robe-skin?

<...for fit>
               
               

               
            

[Legacy_OldTimeRadio]

               @Rolo - Do you mean for part-based?  In theory, you could do that.  In practice I went through the body parts some time ago and there weren't all that many that I liked.  There are some good bits, though.  There are also things like Gnolls which have great armor.  There was a project by RunnerDuck on the Vault (IIRC) for NWN2 which seemed to have promising armor parts, too.  If you haven't used the FFD cage modifier, play around with it sometime.  If you're willing to deal with the temporary brain trauma of conceptualizing the deformation matrix, you can use it to wrap objects onto each other in ways that are insanely difficult using regular vertex selection and (say) scaling or moving.

@MerricksDad - I wanted to update my suggestions to you a bit:  The two suggestions I made to you in hopes of making sure your or anyone else's robes are as snug-fitting animation-wise as possible may very well be spurious.  Worse, I can't say they are or not, definitively, because my own testing with robes is yielding varied results.  One promising thing I noticed is that the rootdummy in all the Bioware robes I looked at was actually geometry with a trimesh modifier as opposed ot a helper dummy.  This kind of makes sense based on two different problems I ran into too long ago to recall with much detail, TBH, except that dummy nodes in a supermodeled situation might act as a firewall for animations down the chain.  The other, also from a smattering of Bioware robes, was that the pivot point is at an arbitrary spot on the mesh.  These "tips" are more like Arne Saknussemm's trail of rocks in Journey to the Center of the Earth.  Don't know how much ultimate truth they contain.

Oh, and you know that bicep stuff with the Big Idea Tester?  I chanced on a similar observation from Papermonk of CODI 10 1/2 years ago.  You can find it in the Omnibus searching for "PC Robes and You" and it's an interesting thread if you havent't seen it yet.
               
               

               
            

[Legacy_OldTimeRadio]

               I just wanted to toss out some information that apparently didn't make it into the general Omnibus.

When asked about differences between some of the cloaks in Tyrants of Moonsea premium module and cloaks in 1.68 (IIRC), Lisa and RTrifts had the following to say:
Tiamiat/Lisa:

Yes in moonsea the cloaks were all robes. They released the old versions. There I maded a couple that were tabard(skirt) portion combined with a cloak. Now you will be able too use any tabard in with any cloak...If you note in 1.68 we have cloaks with dragon, helm, torm, and cyric and certainly peeps are already adding their own gods and logos to more. In my 5 extra cloaks I put on the vault I have a unicorn for prince gilthanas and a hak with gilthanas chain tabard set which can be used with or without cloaks.

When Wyvern Crown is released you will get chain and plate tabard skirts (plus chain and plate mix and match torsos with various logos) Allowing you to make many combinations.

The animations for the tabards and long coats are in patch 1.68 and I expect the actual models will be in 1.69 (but since I don't work at bioware I cannot promise that for certain)

RTrifts:

Quote: Posted 09/03/06 12:13:30 (GMT) by Kjetil_Magne
I have not yet updated to 1.68 as my PW has yet to update as well, but i have played the Tyrants of the Moonsea module and I've seen the cool new cloaks there.  However, as far as I understand, the new "official" cloaks differ in some ways from how they were implemented in Tyrants of the Moonsea. Can someone confirm this if it is true?

Yes, it is true that the implementation is different, but the effect in game appearance wise is not substantially changed. For the most part, the geometry/animations that appear in Tyrants have not been changed, but the
underlying implementation of it has changed.

When the cloaks and tabards (and long coats for that matter) were first implemented, the geometry was all modeled as one "robe". The animations to control all of this geometry was all added in to the a_ba (etc.) supermodels and animated to work together as one large robe.

The animations were created so that you could have a loincloth/tabard and cloak at the same time and they would not clip with one another when you were wearing most standard armors.

At the time, as BioWare had not yet created the new "cloak layer" these various systems were still part of one single robe model - not a "cloak layer". Tyrants uses the all-in-one-robe implementation.  There are a number of problems with the all-in-one model combo approach. Principally, it stretches the texture too much. It also adds a lot of models to the game as you work out the combinations and permutations.  It's more restrictive, ultimately. Also, it is not backwards compatible with earlier mods.

By splitting cloaks off as a separate later, the permitted combinations increase while the number of models equired decreases. They are also more intuitive to use and with a few changes, are backwards compatible.

Note - as we created only a few robe+cloaks combination models originally - and because different robes animate differently - the cloaks when split off to their separate layer do not animate perfectly with robes they were not animated to work with originally. That's why you see the clipping that you do with some cloaks added to some robes.

You don't see that happen in the Tyrants version of the cloaks - because they aren't combined with a lot of robes in that version.

FWIW.
               
               

               

                     Modifié par OldTimeRadio, 23 février 2013 - 07:50 .
                     
                  

            

[Legacy_MerricksDad]

               See now, I don't personally have any issues anymore with out of sync models. I think the reason being that I use a custom a_ba tree all packed into a single file (which is smaller than the combined file size). It includes all the files from a_ba all the way up to p*h0 (er, well not so much the p model but stopping at the a_ba_casts). After I tweaked all the animations, due to the fact that left-blank nodes were pulling from a supermodel file, all the animation issues went away. I think, but don't quote me on this, that animation out-of sync is primarily caused by animations built like that, using supermodels to fill in missing node animations. When using vanilla bioware a_ba chains with a male model wielding two weapons, or two weapons and a torch, I often get out of sync torso to pelvis animations, giving really awkward run animation cycles. If you open the running sequences in Gmax, you can see that the torso leans forward, but the pelvis subtree is stationary, or otherwise tilted but inanimate. These cycles are just those that require file changes to get the rest of the animation sequence. All other one-file animations work perfect for me in every test. If I get a sec this week, I will merge the a_ba and a_fa chains into single files and post them on the vault so people can experiment. Again my personal copy is highly modified and not for general bioware parts use, which is why I just don't post that one.