86 réponses à ce sujet

[WebShaman]

Impressive! Keep it up.

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

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

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

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

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

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

[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

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

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

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

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

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

[Kalindor]

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

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

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

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

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

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

[Sylrae]

.. Why are you avoiding changing the animation?

[OldTimeRadio]

@OldMansBeard & Lord Sullivan - Thank you both for the good ideas!  Sorry for the lack of response to your suggestions but I don't have one yet.  If I do it this way, I have this problem.  If I do it that way I have that problem.  I'm starting to think I've clevered myself into a corner.  I will likely turn the tables and start doing full-body NPC conversions and then work from there to see what customizability I can eek out from there.  It doesn't address all the issues but maybe someone will make progress using monster nodes for player customizability.  That would at least help.  Again, thank you both for the suggestions- esp. about the neck skinning, OMB.

@Sylrae -Two things: Modifying the animations to get them to work with my modeling (in this case, anyway) is one of the "red lines" I didn't want to cross from the beginning.  The other thing is that I don't know if an issue like that could be addressed with creative animrooting.  I don't have the skills and experience in that yet to know if I can do it right.  I'll eventually wind up trying something like that (the animrooting) again in the future, I'm sure.

Modifié par OldTimeRadio, 18 janvier 2012 - 08:57 .

[Sylrae]

"is one of the "red lines" I didn't want to cross from the beginning."

I gathered that. I was wondering why you were drawing that line at all; as opposed to making a new skin mesh and either editing the animation or making a new animation to suit your purposes.

Creative animrooting might solve your problem, but changing the animation sounds a lot more straightforward.

I guess I dont understand why you're imposing what seem to be arbitrary limits on yourself to force yourself into doing it in what seems to be a more complex, convoluted way.

Modifié par Sylrae, 23 janvier 2012 - 03:51 .

[OldTimeRadio]

I was wondering why you were drawing that line at all; as opposed to making a new skin mesh...

It might come to that.  I thought I would do some experiments doing full body conversions but I haven't gotten around to it yet, still seeing if I can conjure up a solution for multipart models that works well.

...and either editing the animation or making a new animation to suit your purposes.

The animations we're talking about here are a_ba, a_ba_non_combat, a_ba_med_weap, etc. Those are the player animations.  Megabytes of them.  A lot of models supermodel into them.  The time it would take aside, modifying that supermodel chain would impact all the other models which use them, so that's out.  Duplicating the supermodel animation chain and modifying it would still burden users with all those megabytes of new animations..an entire duplication of the supermodel chain...just for tiny changes.

I just think there's a better solution out there.  And hey, maybe there isn't.  Sort of in the vein of OldMansBeard's idea, I'm trying to structure my sample pmh0_neck001.mdl into something like how a cloak is done, where a skin and proxy bones are supermodeled into (something) and the proxy bones take on the animation that they're supermodeled into.  It actually works...sort of.  More of a party mask + flying fez combo at the moment.

I guess I dont understand why you're imposing what seem to be arbitrary limits on yourself to force yourself into doing it in what seems to be a more complex, convoluted way.

Just seems like a waste of resources.  I'd rather change what I'm doing than change big chunks of NWN to get it to work.  Plus it would be a heck of a lot more work just to move forward on one point in an already complex process:

I have 3 skin meshes: Body, Face & Hair.  Give me some explicit instructions about exactly how those could be implemented and still retain their PLT's and I guarantee I'll listen.  The problem is most of the "easy" answers I've come across aren't so easy when you actually implement them, causing a problem that has to be worked around.

Modifié par OldTimeRadio, 23 janvier 2012 - 08:34 .

[Sylrae]

Hmm. Alright.

I would think if you're going to change how "humanoid" graphics work, you'd be changing all of them, not just some of them, so the fact that other models would be affected by your animation changes would be okay.

I guess if you want to do a small change as opposed to having an overhaul of all the players and NPCs that use the same animations as the players, you have different design goals.

I'd suggest making the hair a separate mesh, so that would cover that PLT.

I suppose the tricky part would be having different faces.

The customizable Kobolds I mentioned might provide ideas.

[OldTimeRadio]

Sylrae wrote...
I would think if you're going to change how "humanoid" graphics work, you'd be changing all of them, not just some of them, so the fact that other models would be affected by your animation changes would be okay.

Oh!  Just to be abundantly clear, none of this would affect current models, content or anything like that at all.  I only keep referring to pmh0.mdl , pmh0_neck001.mdl, etc. because I'm too lazy in my experiments to use a different phenotype.  When I talk about compatibility, I'm merely talking about this system taking advantage of existing systems, not overwriting them.

If this comes to fruition it would wind up as one or more new phenotypes.

Modifié par OldTimeRadio, 23 janvier 2012 - 11:07 .