21 réponses à ce sujet

[dusty.lane]

Something's been stirring about in my head, knocking about inside of there. It's that I've been wondering, if individual PC body parts (like feet, shoulders, hands) can have individual animations that perhaps fire off during the main animation of the PC's body. Or even better, can you make a specific body part, skinmeshed?

It'd be neat to know, if anyone has ever tried such.

[NWN_baba yaga]

Not really sure how you mean that with the animations because if you walk you walk or do you want to walk and have flying feets at the same time??? Weird!

As far as I know you can only have one "skinmesh/ robe" at a time as a phenotype but OTR is the real scientist about that

[OldTimeRadio]

To answer the animation question, yes, individual parts can be animated and are animated and Baba's example is a good one.  Though it might seem like you have some wiggle room with 16 body parts, if you double any of them up except for the neck+head (unless it's a yawn idle animation, for instance), things will not look right.  I know RabbitHail from many years ago tried to add new bones.  I tried it too- this is a fiddling with caparts.2da kind of thing.  But no luck.  IIRC, there is an implied hierarchy in caparts.2da anyway which the engine sniffs for, too.  So, seems fairly fixed.

Thank you for the props, Baba!  I'd also recommend Merrick's Dad's thoughts on this topic (if he's around) because I know he definitely explored some of the same areas I did on this topic.  Before that (AFAIK) the exact same results were reported by, I dunno, PaperMonk or someone who later wound up being in CODI back in 2002-3.  What happens is it seems like one can skin mesh a body part in theory, but in practice with very few exceptions (something like only the left arm from the forearm down or some craziness like that) the skin doesn't work right, getting influenced by the wrong bones, IIRC.  Very difficult to test but that's three people at least who've tried it and not been able to get it to work.  It doesn't always play out like this but if, for instance, you find all your skin balled up around the right or left fist (I forget), you're looking at the beginning of the (seemingly) barren territory we explored.

[Rolo Kipp]

<depending on...>

You can have multiple skinmesh parts. But the problem is that the animations for player models are inherited from certain base models (a_ba, etc) and any skinmesh will need its own set of those anims.

A perfect example is the wemic found in the CC Guide. The lower body was replaced with a custom skinmesh. The upper body remained empty nodes so that various body parts could be swapped in or out. Because the anims on a model override the anims on the supermodel(s), the model had to carry *all* the anim keys, even the ones for the body part nodes.

Body parts themselves do not have anims (except wings and tails).
Edit: body parts can carry anims, OTR? I know items (weapons & shield) can, and assume tails & wings were finagled off of that sub-system, but body parts?

<...dependencies>

Modifié par Rolo Kipp, 15 mai 2013 - 10:00 .

[OldTimeRadio]

Rolo Kipp wrote...
Edit: body parts can carry anims, OTR? I know items (weapons & shield) can, and assume tails & wings were finagled off of that sub-system, but body parts?

Sorry, I meant it in the context of regular animations like a_ba, etc.  You can have anims on individual body parts but they won't play kind of like how you can have creature anims on a placeable but the engine will ignore/skip/whatever them.  I should have realized that's what he was talking about!

Modifié par OldTimeRadio, 15 mai 2013 - 10:12 .

[MerricksDad]

I had unknowingly been working on the exact same things older teams had tried, and I'd been at it offline since 2006 with very little success in adding any new bones.

The list of "parts" which can be successfully animated includes only the cloak, a robe, and the weapon models. Adding animations to any other body part does exactly as OTR mentioned, and curls the animation around an odd point, usually the left forearm, and for no apparent reason. This is completely independent upon where you base the animation from. My own testing seems to point to the engine assuming a specific heirarchy for its animations, which is instantly broken if you modify the structure or add another skin mesh. The only thing I have actually had success with is changing the object to which the animated part attaches, and while it does make the animation play successfully on the body part, it displaces the body part in a direction not dependent upon anything I modified. So I have no idea why what or how I did anything.

How it really works, or why they did this is anybody's guess.

I'm currently, and very slowly, working on a system where the main part of the body is a combination of the robe and the cloak. Body parts go OVER or UNDER the skins, and are slightly modified in position from where bioware put them. I've found that, for me, this system has a lot of potential, including additional non-dynamic body parts, but will take an exceptional quantity of work to complete. I've asked for some help on the topic, and given that my own time is limited, I am not surprised at all that nobody except two of my local friends have offered any modeling or texture help. And it seems they no longer have interest in NWN as a whole.

I've modeled some Drow for last month's Custom Content challenge, which you may have already seen here. These models are based on some of the stuff I had been working on for the Robe as Base Model project. Of which the only photos I have shared so far are already months old by now. You can view them on the old vault here.

OTR has since pointed me to the NWN Omnibus to a few articles, which you can start reading by searching for "facelifting nwn". It seems that while we were working on the same things, we came to the same conclusions, even if I didn't understand those conclusions for 4 more years

[OldTimeRadio]

Thanks for taking the time to type all that up, MD!  I'm out of action for modding till September at least...but if you still need another hand around then I might be able to help in some way.  On the system you're working with/on now, do you have a way to derive/construct the "fat" body shape for humans and the normal/fat for other races?

Modifié par OldTimeRadio, 16 mai 2013 - 12:22 .

[MerricksDad]

Not fat no, I was going dextrous, strong and healthy for DEX, CON, and STR based characters. I have a ratios system for deriving other standard races from the human forms of those three. If I did fat, I might think also about scrawny crones too.

[dusty.lane]

I suppose I should have been more specific; when I said animations on body parts, I suppose I mean, let's say you have a gear on your forearm for no reason other than to have it there spinning. Would it spin? Would it freak out? Would you be able to make it only spin when you fire certain animations like sit or fall back?

Over all, aside from that, thanks for all the response on the matter. =P

[MerricksDad]

I have just attempted to place a rotating gear on a bicep. I added the walk animation sequence to the gear, from frame 10 to 40, over which the gear should rotate 360 degrees in six 60-degree increments. After attempting this using the animroot value of rootdummy, the model name, and of the parent node name, the gear simply does not respond to any attempt to animate it. (I have this bicep in mdl format if you would like to see it)

You could probably somewhat accomplish the animated gear via an emitter on the arm, however, again that will not give you animation cycle control over it spinning or not spinning. (Are we able to put emitters on armor bits? I thought they fixed that...)

Another method might be to use OTR's texture replacement methods and rotate just the texture applied to the gear. This would require a fake texture file and a similar named TXI which pointed to the real texture you wanted to use. I have also found that you can stack textures and TXI files in this method and supply a TXI for the second texture (and on and on and on). You could then tell that texture to use animated frames, giving the texture file a 8x8 grid of slightly rotating images. This is still imperfect as you cannot alter its on/off state since you have no access to the animation cycles from the body part.

I am currently thinking of another two ways to accomplish what you want, and not use a robe slot, but both are adding an entire new model with animation, and might get out of sync with the bit you are trying to make appear to move. I think they would work, but you would need one of these models for every part you wanted animated this way. They would also potentially clog your emitter stack.

In my "skin as base model" method, if you had multiple needs for that rotating part, you would simply add it to maybe a cloned a_ba series and add that rotating bit to your base skin. Say for instance you have a bunch of clockwork people with gears, their base model would already include a variety of gear bones in the a_ba series. You'd just use whichever ones you needed for that skinned appearance. Copy off the bone you wanted to show and parent it to the original gear-bone, then set its render=1 and shadow=1.

In the same way, you could potentially append your gear and animation to the original a_ba cycle which the base races point to. Then create a new robe which you can have your character wear which displays that gear as part of the robe.

If you'd like an example, show me an example of something you want this animation to be on and I'll try to append it for you. I'd rather do it on your project than give you a scratch one you can't use.

[dusty.lane]

Wow.. Thanks Merricks.. That does answer basically all the questions I had, in that case. As for the gear, it was merely a simple geometric rotating object I thought of that would make my explanation work well. My idea is far more complex, but if it can't even handle a gear, then it surely can't handle what I was planning.

I think I will have to go the wing route for one of the things I was planning, and the other just flat out isn't possible it sounds like. No biggy though!

Also I really need to find out how to operate TXI files.. Doing a search on that right now, unsure what I'll unearth really.

EDIT: Scratch that, think I found out some stuff on TXI. Woo..

FURTHER EDIT: Scratch that scratch! I figured the NWN Omnibus would have all the information I'd want. I can't even run it and find things. >_<

Modifié par dusty.lane, 16 mai 2013 - 04:10 .

[MerricksDad]

TXI is both fantastic, and a pain in the ass

[dusty.lane]

"FURTHER EDIT: Scratch that scratch! I figured the NWN Omnibus would have all the information I'd want. I can't even run it and find things. >_<"

I think I need help on that, or a guide on TXI. Sure it's a pain in the ass, but as is, I don't understand it one bit. lol!

[MerricksDad]

I use the omnibus without the java package. Instead open your windows (you use windows right?) explorer to the location you installed the omnibus files. There should be a folder in there called data. In your explorer's search bar, just type in TXI to get all the txi hits as a windows file search starting in that folder on down. Windows can do text-from-files searches just as the java application provided with omnibus is doing. Additionally, the omnibus data folder has a subfolder entitled TXI which contains a list of the TXI files used in the original content. You can look through those to get an idea of what is going on here and there. The best document, although far from complete, is a document I believe bioware released which contained a lot of commentary about what each part was doing. I seem to have lost its exact location, but I bet its in the omnibus package.

[MerricksDad]

Here you go, I found my copy and posted on the new vault since these forums are no longer accepting any of my known zip formats for some reason...

http://neverwinterva...are-txi-example

[dusty.lane]

Okay! And thanks a lot for that link! =)

[Pstemarie]

That's a handy chunk of information. I'm going to snag it for my NWN Miscellany document.

[MerricksDad]

Yes please do. Anything we may not have gotten into the omnibus or anything we forget to transfer to the new vault might be lost otherwise. Too much stuff has been lost already.

[Rolo Kipp]

<searching for...>

@Dusty: The Omnibus uses DocFetcher for searching and I was having a great deal of difficulty with it on my Win 8 machine. But DocFetcher has been rewritten from scratch and the new version works great. In fact, I have my entire NwN reference directory indexed :-P

Please look for the link in the stickies Omnibus thread (copying links on the phone is a pain :-P ).

Note: you may have to tell windows where to find the javaw engine... It's wherever you installed java.

@ MD: Thank you! Now we just need some cool screenies showing the different setting and procedures... ;-)

<...links>

Modifié par Rolo Kipp, 16 mai 2013 - 01:47 .

[MerricksDad]

You mean the TXI? Yeah I know what you mean. I would personally like more information on the non-arturo procedures. Some of those, if you supply them certain variables, bog the engine down in the extreme, but for at least a few seconds, the magic they do on the texture is exactly what I want. I've looked all over the web trying to figure out exactly the mechanics behind them, but I've got nothing but poking and prodding.

[OldTimeRadio]

MerricksDad wrote...
You mean the TXI? Yeah I know what you mean. I would personally like more information on the non-arturo procedures. Some of those, if you supply them certain variables, bog the engine down in the extreme, but for at least a few seconds, the magic they do on the texture is exactly what I want. I've looked all over the web trying to figure out exactly the mechanics behind them, but I've got nothing but poking and prodding.

A note about the proceduretypes and why I never got around to writing the Big Book of TXI's.  The second of the two reasons might be a novel viewpoint but my testing bore it out:

First, it was very, very difficult to get a handle on how things worked and even what things actually worked.  I found I was flying blind, even with a debugger.  A testing session involved starting the toolset up 50+ times with different settings just to see if you could happen on something interesting or find the right combo.

The second reason was that after being able to reproduce all the proceduretypes with the possible exception of wave (?), I took a breather and thought about all the stuff I'd seen (water, live, perlin, arturo, cycle)...and came to the conclusion that in most cases it was easier and far more efficient to simply prebake the distortion (or whatever) I wanted into an animated sprite sheet and then use a plain old proceduretype cycle to display the pre-baked frames.  Yes, you eat it on the file size of the image but if your animated texture is part of a static placeable you eat the extra loading time only on level load and they're never unloaded until the level changes.  The upside is if you have a good effect generator or even a passable one, you can generate some nice looking sprite sheets to use with the method.

I had six variations on this (each variation with a different colored dot in the center so I could be sure they were all different) all loaded up at the same time on a 512 meg NVidia 7300 with no problems.  Same for similar creations from the caustics generator (the second link, above).

The intense level of GPU work required to do some of these distortion proceduretypes made the ones that did work only good for special cases, whereas a proceduretype cycle was much more flexible and a hell of a lot faster.

Not saying proceduretype cycle is always better but my interest in the other types dropped considerably when I saw how their performance compared to cycle, especially when the fps on the cycle was tuned down to something reasonable.

EDIT: BTW, that "bigfire" sprite sheet has an alpha channel but it doesn't necessarily 'need' to have it.  That was just to pad the image date to make each instance as 'fat' as possible.  I was doing tests about how much gfx data NWN could seemingly push into an otherwise-capable (memory-wise) graphics card.  Never hit a wall on that.

Modifié par OldTimeRadio, 17 mai 2013 - 09:34 .

[MerricksDad]

OTR:

and came to the conclusion that in most cases it was easier and far more efficient to simply prebake the distortion (or whatever) I wanted into an animated sprite sheet and then use a plain old proceduretype cycle to display the pre-baked frames

exactly