Jump to content

Designating positions in animations


PaulGreen

Recommended Posts

On 10/29/2018 at 2:32 AM, MadMansGun said:

 

 

  I don't have 3DS max unfortunately. Does 3DS have an .fbx export format?  That's a compatible exchange format.

 

  I got annoyed that the blender nif tools can't import animations into the newer versions.. I spent some time the lat couple days looking at it, I think I got it in at least..  I haven't looked at the exporter at all. I want to add the ability to import a .nif and have the meshes auto-track the imported skeleton and animation, too..  I think I can see how to hack that together. My motivation for it is a little low, tho, heh.  Maybe not.

 

Link to comment
1 hour ago, PaulGreen said:

 

  I don't have 3DS max unfortunately. Does 3DS have an .fbx export format?  That's a compatible exchange format.

 

  I got annoyed that the blender nif tools can't import animations into the newer versions.. I spent some time the lat couple days looking at it, I think I got it in at least..  I haven't looked at the exporter at all. I want to add the ability to import a .nif and have the meshes auto-track the imported skeleton and animation, too..  I think I can see how to hack that together. My motivation for it is a little low, tho, heh.  Maybe not.

 

wrathtest.FBX

Link to comment
15 hours ago, MadMansGun said:

 

 

   Animation seems to be okay. Either the fbx conversion is covering up some subtle problem in 3DSMax, or the export / hkx conversion is doing something wrong. It might be that the skeleton hkx I created is wrong. I can look at hkx and see if I did it wrong, which is the most likely explanation, since I am taking guesses in te creation of some of these things. It worked for me at first with just import / export already existing animations, but those didn't use the new IWA bones, so not a 'real' test.

 

   When exporting from 3DS max, is there any mention of skeleton.hkx as the export, or is that only when using hkxcmd after export from 3DS ?

 

   The other way it could be 3DS max is if it saves the "original" reference pose position as extended data (non-standard data nodes trhat wouldn't be exported with fbx). Are there "notes" or other node types on each, individual bone? Is there a note or custom data on the skeleton node that contains reference pose data for the skeleton bones?

 

 

   In the skeleton.hkx,  I presume most likely is the reference pose position data for the IWA bones is wrong. If it is, it's a more difficult problem that might require a different way of doing this.

 

 

EDIT:  I manually looked through the MAX file scene data. Is the testing skeleton file you're using called "icetest.hkx"? Is this correct skeleton file, the non-xml one? It looks like the 3DS scene might be referencing some parts of the havok data like the .hkx files, which means it's possible that the exporter does something, which means that I can't analyze since I don't have 3DS >.>

   All I can do is hand you a bunch of trials and see if anything works, heh

 

 

Link to comment
3 hours ago, PaulGreen said:

 

   Animation seems to be okay. Either the fbx conversion is covering up some subtle problem in 3DSMax, or the export / hkx conversion is doing something wrong. It might be that the skeleton hkx I created is wrong. I can look at hkx and see if I did it wrong, which is the most likely explanation, since I am taking guesses in te creation of some of these things. It worked for me at first with just import / export already existing animations, but those didn't use the new IWA bones, so not a 'real' test.

 

   When exporting from 3DS max, is there any mention of skeleton.hkx as the export, or is that only when using hkxcmd after export from 3DS ?

 

   The other way it could be 3DS max is if it saves the "original" reference pose position as extended data (non-standard data nodes trhat wouldn't be exported with fbx). Are there "notes" or other node types on each, individual bone? Is there a note or custom data on the skeleton node that contains reference pose data for the skeleton bones?

 

 

   In the skeleton.hkx,  I presume most likely is the reference pose position data for the IWA bones is wrong. If it is, it's a more difficult problem that might require a different way of doing this.

 

 

EDIT:  I manually looked through the MAX file scene data. Is the testing skeleton file you're using called "icetest.hkx"? Is this correct skeleton file, the non-xml one? It looks like the 3DS scene might be referencing some parts of the havok data like the .hkx files, which means it's possible that the exporter does something, which means that I can't analyze since I don't have 3DS >.>

   All I can do is hand you a bunch of trials and see if anything works, heh

 

 

i don't use hkxcmd at all, Havoc for Max2010 exports hkx animations directly.

Eg: standard export settings (human).7z

so the skeleton.hkx is not used by max at all, it just uses a list of node names from a txt file.

 

icetest.hkx is just what i named the animation when i exported it.

 

 

Link to comment
9 hours ago, MadMansGun said:

i don't use hkxcmd at all, Havoc for Max2010 exports hkx animations directly.

 

 

   I see, I didn't know.  For sure, then, this is the problem. All 3DS knows about via the bone list is IWA nodes. You'll notice that that .txt file has no IW nodes since these were just a series of "non-animated" nodes.

 

   So 3DS Max HKX exporter probably sees:

head -> IWA Seg01 -> IWA Seg02 -> IWA Seg03 -> ...    and applies the Location to these IWA bones on export, like  (5,0,0) ->  (12,0,0) -> (18,0,0) along it's 'spine' nodes.

 

  However, the actual skeleton, the order is:

head -> IWA Seg01 -> IW Seg01 -> IWA Seg02 -> IW Seg02 -> IWA Seg03 -> IW Seg03 -> ...

 

   and the location data is on  IW  bones,  not IWA bones,  with the IWA bones just having location of  (0,0,0). It is the IW bones that are supposed to have the X value increasing further down the spine,  not the IWA bones.

 

 

   So, since the animation export from 3DS accidentally gives increasing X-location values to the IWA bones in the animation .HKX, but the IW bones in the actual skeleton already have this increasing X-location as well, the spine doubles in length when the animation plays.

 

    I have to think about it awhile...

 

 

   Separately, do you know if charus or dragon priest have animation problems?

 

Link to comment
2 hours ago, PaulGreen said:

 I see, I didn't know.  For sure, then, this is the problem. All 3DS knows about via the bone list is IWA nodes. You'll notice that that .txt file has no IW nodes since these were just a series of "non-animated" nodes.

 

 Separately, do you know if charus or dragon priest have animation problems?

i tried adding them to the list but it made no difference....are you able to add a second full skeleton into your skeleton.hkx?

one of my past failed ideas was to swap out the meshes using CF with ones rigged to a different skeleton inside the same skeleton.nif: failed double skeleton.nif

but of course one of the problems with that idea is that they would lose there animations if they "got aroused" outside of a sexlab event (if it even worked that is, i never got that far)

 

i'm not aware of any chaurus or dragon priest problems at this time.

Link to comment
10 minutes ago, PaulGreen said:

 

   Just taking guesses. From your picture of settings on export, it looks like the order in the nodes file matters. Did you try the node file like this? If not, maybe try it in this order

 

nodes icewraith-Edit.txt

yes the order does matter, but that list made no difference.

hell i even tried deleting the IW nodes before export but even that failed to make a difference.

Link to comment
4 hours ago, MadMansGun said:

 

 

   Try it in combination with this skeleton.hkx

 

   If it does work, pay attention to the regular movements of the wraith, too. Make sure that it isn't wonky. If possible, also find one not summoned by Hentai Creatures or some such. I think the original wraith had a little bit of problem following the player as "follower" as well.

 

   So, use that bone list above to export the animations, and use this skeleton.hkx for the game.

 

skeleton-PosAndIW.hkx

Link to comment
1 hour ago, PaulGreen said:

everything looks good so far (still need a "IWA Seg00" somewhere) the tail is correctly moving dynamically in all stock animations, and in SL animations it looks exactly how i have it in Max.

 

...and now for some obligatory worshiping:

https://www.youtube.com/watch?v=c3sOuEv0E2I

?

 

Link to comment
3 hours ago, MadMansGun said:

 

 

   Wow, neat. I am surprised that it works, heh. The main point is that apparently,  it is okay to put havok-controlled bones, like the lag bones, in a skeleton to animate. The original animations that didn't use the lag bones in the animation still work fine.

   I think if one *did* have an animation where it was intended to have the lag bones only be controlled by havok instead of the animation,  you could do that by exporting from Max using Havok Content tools directly to .hkx,  using the bone-list that simply does not include that bone chain. So, use the original one here.  The skeleton .nif  and the .hkx would still be the new ones in the game,  but the animation would let the bones be havok controlled since it would not include animation-graph references for those bones.

   Basically, if one opens the .hkx in nifskope  (convert to .kf using the hkxcmd tool) and looks at the control graph bones,  if you see the lag bones exist in the .kf, it's animation controlled,  if you don't see those bones listed,  it will be havok controlled in game.

 

   As a note,  I think you can control the IW nodes in this setup. It may actually not be necessary to have the IWA nodes at all..  Maybe try it out (animating the IW nodes directly) and see what happens. Don't change the setup, just move the IW bones around.

 

   For the Seg00,  which part of the body is not controllable now? "Seg 01" should control the area just behind the head I think. It maybe that the IWA nodes should have gone on the part they control instead of in front of the part they control.

 

Link to comment
5 hours ago, PaulGreen said:

 As a note,  I think you can control the IW nodes in this setup. It may actually not be necessary to have the IWA nodes at all..  Maybe try it out (animating the IW nodes directly) and see what happens. Don't change the setup, just move the IW bones around.

 

   For the Seg00,  which part of the body is not controllable now? "Seg 01" should control the area just behind the head I think. It maybe that the IWA nodes should have gone on the part they control instead of in front of the part they control.

 

no i tried that, it sort of works but it glitches out, makes it looks like the icewrath is having a seizure.

 

 

this is what i'm talking about when i say that i need a "IWA 00" note:

iw vs iwa.jpg

left is "IW 01" and right is "IWA 01"

Link to comment
On 11/6/2018 at 1:57 PM, MadMansGun said:

 

 

   I spent a bunch of time trying to get the Blender .nif tools to import skeletons and animations. I actually got very close, but I'm stuck on how pyffi and the original algorithm, was trying to set up the local coordinate system of each armature bone. I could just force it to be correct, but I have not enough idea to know what is the actual 'correct' way intended.. whatever way is programmed now in the blender .nif plugins just flat out doesn't work, and I don't know what the intent was. It creates an independant coordinate system per-bone whereas the havok data inherited adjustments from the parent bones for each bone's coordinate system, and the way the plugin seems to be trying to accomplish the translation doesn't work, and I don't know what was intended.

   I got the animations and skeletons importing and know how to fix the exporter, but I gave up for now.. too much work and brain is fried, heh.

 

   in doing this, I do see that the current animations are not actually animating "IWA Seg01". That bone is fixed and does not have any movements, rotation nor translation. I think this may be what is going on. If you are moving Seg01 in 3DS, somehow the export isn't actually animating this bone. If this bone is animated, it moves the neck area just behind the head for me in Blender.

   This is true for all animations linked in this thread.

 

    Maybe double-check that "IWA Seg01" is actually being animated?


 

Spoiler

 

 

IWChannels.thumb.jpg.0afa3eee0a1ced89e558824829d43410.jpg

 

 

 

 

Link to comment
1 hour ago, PaulGreen said:

  in doing this, I do see that the current animations are not actually animating "IWA Seg01". That bone is fixed and does not have any movements, rotation nor translation. I think this may be what is going on. If you are moving Seg01 in 3DS, somehow the export isn't actually animating this bone. If this bone is animated, it moves the neck area just behind the head for me in Blender.

   This is true for all animations linked in this thread.

 

    Maybe double-check that "IWA Seg01" is actually being animated?

?‍♂️i'm an idiot....i was mistaking IWA Seg02 for IWA Seg01, your IWA Seg02 node is on top of IW Seg01, and IWA Seg01 is inside the head where i could not see it.

Link to comment

 

   Just as a reference if it's useful to link to here from somewhere.  Here is the fixed FNIS file to get spiders animations ending. Will have to place this in FNIS tool for users for creature pack,  then re-build the FNIS animations as a user.

   Modders will need to place this file, then also re-run the "modder" tool. Both have to be done, nost just modder tool or just user tool. This also means animation packs would have to be re-distributed with the FNIS files so that users' FNIS builds get the updated values.

 

 

   Getting chicken, rabbit, etc.. fixed will require the next Sexlab update (assuming Ashal includes the fix) or re-compiling the sslActorAlias file with the fix as in thie thread.

 

 

 

 

 

BehavioredObjects.txt

Link to comment

I got the blender NifTools in 2.78 to import a skeleton and animation.. oh boy

 

It was quite harrowing, I'm bad at keeping the matrix mulitplications and the implications of ordering, etc.. in mind.  I had to ask questions of a mathematician friend, heh.  I think there was both a few bugs in the original way matrix was calculated, need to update for new python 2->3 and for new blender style of data structures and data types..

 

I dunno if I want to try the exporter, but at least can view the animations in blender, heh.


 

Spoiler

 

.

BlenderNifTools.thumb.jpg.93bff2491bf497c7b010be4c31b55792.jpg

.

 

 

 

Link to comment
4 hours ago, PaulGreen said:

I think I got blender import sort of working. It's very hacky,  but next is seeing about export. Maybe can use blender for  simple  animation imports and exports.

 

 

Import of hcos thing, heh  >.>

as far as i know animations are made in newer blender versions but then exported with blender v2.49b.....at least that's what people use to do, i don't keep track of blender based animation work so things may have changed by now:

https://www.loverslab.com/topic/17279-so-you-want-to-make-animations-the-pose-animation-blender-and-nifskope-tutorial-compendium/

 

 

it's odd that the feet are sliding around in that Import, but i guess some errors are to be expected, usually you can't even import user made animations without major errors happening (but i use 2010 and export directly to HKX where as everyone else uses 2012 and exports to MXL or whatever the hell it is, so maybe that's a factor?).

Link to comment
  • 3 weeks later...
14 hours ago, MadMansGun said:

 

 

   I just used text editor and xml converter. I guessed at what data structures were meaning and tried it, then convert it back to .hkx. For the ice wraith, was adding new bones to the non-rag-doll skeleton with the right position offsets and order.

 

Link to comment

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use