Devious Devices LE 5.2

[Roggvir]

28 minutes ago, Lupine00 said:

Ah, there's a clunky command-line tool for doing those conversions. Also lets you get at the tag stream.

I have three tools. I think maybe they came from LL.

hkdump-develop.zip

hkxcmd_1_4-1797.rar

hkxPoser-develop.zip

And a UI called ConverterUi.exe that is definitely from Nexus.

The UI tool is sufficient for most things.

https://www.nexusmods.com/skyrim/mods/17109?tab=description

 

You obviously found some tool, but there are several. Maybe one works better than another?

Or, maybe they are all built off the same library?

 

The hkxcmd tools are all based on the same source, even the 1.5 version here on LL and while that one claims it does fix some problem when converting to HKX (the opposite of what i need), i wasn't able to make it even run at all (though that could be some problem on my VM box).

[Roggvir]

4 minutes ago, audhol said:

theres a clunky way of doing it which I used to make alternate armbinder anims. You can export both the armbinder and reference body as an .obj from os then load these into blender. Here the body obj can be aligned to the armbinder re-exported then used as a template in os to realign the reference body. The reference could be used to realign both the cbbe and unp bodys. you do have to be reasonably proficient with both blender and os to get the alignment right without distorting the body.

 

Yeah, or you can also align the body to the Armbinder directly in OS, using the bones posing feature.
But both approaches have the same problem - you are eyeballing it, and i want to work with solid data based on the actual animation, because otherwise i end up with a pose that just looks like in the game and seems to fit the armbinder, but the hands are "folded" differently than they really are in the animation, and then i spend dozen of hours just by trying to fix clipping that seems to come out of nowhere, and the worst part? if that happens, you still end up solving the clipping by trial and error, closing/restarting game and adjusting/rebuilding the sliders in OS.
I want to avoid that.

[audhol]

20 minutes ago, Roggvir said:

eah, or you can also align the body to the Armbinder directly in OS, using the bones posing feature.
But both approaches have the same problem - you are eyeballing it, and i want to work with solid data based on the actual animation, because otherwise i end up with a pose that just looks like in the game and seems to fit the armbinder, but the hands are "folded" differently than they really are in the animation, and then i spend dozen of hours just by trying to fix clipping that seems to come out of nowhere, and the worst part? if that happens, you still end up solving the clipping by trial and error, closing/restarting game and adjusting/rebuilding the sliders in OS.
I want to avoid that.

I thought armbinder covered slot 33 too? couldnt you just include a transparent texture to the hands nif so you dont care what the hands are doing in the animation?

 

[Roggvir]

26 minutes ago, audhol said:

I thought armbinder covered slot 33 too? couldnt you just include a transparent texture to the hands nif so you dont care what the hands are doing in the animation?

 

I appreciate the idea, but that isn't really applicable in this situation.
Beside the fact that the cleanest solution is to do a proper correct BodySlide, and just like that, all problems will be solved....
- it isn't just about fixing some clipping, but also about the shape of the arm/elbowbinder changing depending on the preset and NPC weight, so some sort of BodySlide is needed anyway.
- then there is the fact that with some *binders you can still see some parts of the hands, so that adds another complication.

- then there are the rope or the transparent *binders where the hands are in plain sight, so you cannot make them disappear.

[audhol]

20 minutes ago, Roggvir said:

it isn't just about fixing some clipping, but also about the shape of the arm/elbowbinder changing depending on the preset and NPC weight, so some sort of BodySlide is needed anyway.

the issue with the armbinder is its quite a low vertice model and all the detail is in the texture so its always going to struggle to keep up with movement in animation regardless of how good the weighting and bodyslide is, I believe its free permision now so doubling the vertices and remapping that to the old textures might be worth investigating.

curent model

 

 

1 subdivision of just the sleeve gives you a much easier model to work with.

[Roggvir]

1 hour ago, audhol said:

the issue with the armbinder is its quite a low vertice model and all the detail is in the texture so its always going to struggle to keep up with movement in animation regardless of how good the weighting and bodyslide is, I believe its free permision now so doubling the vertices and remapping that to the old textures might be worth investigating.

curent model

 

 

1 subdivision of just the sleeve gives you a much easier model to work with.

Well, that would be very nice too - but are you really sure about the permissions?
From what is written on the mod page:

Quote

- You can NOT post this mod or any of its parts (including any derived works) without explicit permission.
- You can NOT post or share any patches against this mod without my express permission, unless their sole purpose is fixing bugs.

but also this:

Quote

For all art assets used by this mod, all conditions set by their original creators apply instead. Please contact the respective author for further information on permissions etc.

...but even then i still don't know who made it (Zadil, Koffii, Coopervane, Pincopallino, Feuertin, El Duderino, Heretical, and Colycon), and even then i wouldn't know what they permit or not ?

So i think it would be best to wait for @Kimy

 

EDIT: just one small thing - there is definitely no need to subdivide the area covering the rest of hands down from the wrists (palms and fingers), because there are no sliders affecting those parts anyway.
But it would be truly beneficial to subdivide the rest of the mesh (except the metal parts and laces), and especially the straps that go around the body - that is another place where it often suffers from clipping (which then needed to be solved by inflating the mesh, which in turn greatly accentuates the lowpolyness of the straps).

[audhol]

20 minutes ago, Roggvir said:

Well, that would be very nice too - but are you really sure about the permissions?

My understanding is that anything from DDA was made by Zadil and has free use permissions but for sure it cant hurt to check with kimy.

21 minutes ago, Roggvir said:

just one small thing - there is definitely no need to subdivide the area covering the rest of hands down from the wrists (palms and fingers), because there are no sliders affecting those parts anyway.

My thinking was if you weighted that part of the mesh to the hands and fingers it would be a bit more flexible during an animation.

 

[Roggvir]

1 minute ago, audhol said:

24 minutes ago, Roggvir said:

just one small thing - there is definitely no need to subdivide the area covering the rest of hands down from the wrists (palms and fingers), because there are no sliders affecting those parts anyway.

My thinking was if you weighted that part of the mesh to the hands and fingers it would be a bit more flexible during an animation.

Oh yes, definitely, i agree, i just didn't think the lower part would need to be subdivided to fit the hands.
But i just looked at the hands mesh (from CBBE) and they are pretty detailed in comparison, so i think you are right - it may be best not to be stingy and subdivide that lower part too.
(it comes from me trying to remain conservative when it comes to increasing number of plygons, but in this case being too conservative is probably not worth it)

[audhol]

11 minutes ago, Roggvir said:

Oh yes, definitely, i agree, i just didn't think the lower part would need to be subdivided to fit the hands.
But i just looked at the hands mesh (from CBBE) and they are pretty detailed in comparison, so i think you are right - it may be best not to be stingy and subdivide that lower part too.
(it comes from me trying to remain conservative when it comes to increasing number of plygons, but in this case being too conservative is probably not worth it)

yeah even subdived its not a huge vertice count for the size of the model. If you wanted to claw back any loss due to higher face count you could remove the emissive map from the texture and just run the default shader. 

 

Good luck with doing it.

[DonQuiWho]

2 hours ago, Roggvir said:

Well, that would be very nice too - but are you really sure about the permissions?
From what is written on the mod page:

but also this:

...but even then i still don't know who made it (Zadil, Koffii, Coopervane, Pincopallino, Feuertin, El Duderino, Heretical, and Colycon), and even then i wouldn't know what they permit or not ?

So i think it would be best to wait for @Kimy

 

EDIT: just one small thing - there is definitely no need to subdivide the area covering the rest of hands down from the wrists (palms and fingers), because there are no sliders affecting those parts anyway.
But it would be truly beneficial to subdivide the rest of the mesh (except the metal parts and laces), and especially the straps that go around the body - that is another place where it often suffers from clipping (which then needed to be solved by inflating the mesh, which in turn greatly accentuates the lowpolyness of the straps).

 

@Kimy

 

Any chance that you might be able to pop in for 5 min and maybe put Roggvir out of his misery?  TIA if you can ?

[Lupine00]

1 hour ago, audhol said:

If you wanted to claw back any loss due to higher face count you could remove the emissive map from the texture and just run the default shader.

That's a kind of apples and oranges trade.

If the emissive map isn't used, it should just be removed anyway, but there's probably some DDe re-texture that has glowing polka dots or something.

 

Would be a nice chance to smooth out some of the sharp corners if it's subdivided. I imagine the mesh in the picture was just to show the subdivision, not how it could ultimately be polished up.

 

Now you just need to put "Special Edition" on the end and charge four times the price of the LE version.

[darkfender666]

16 hours ago, Zaflis said:

Current XPMSE skeleton version is 4.8.. which is surprising as it's newer than mine too.

https://www.nexusmods.com/skyrim/mods/68000?tab=files

 

XP32 skeleton does not work with HDT. XP32-Extended is required.

updated but didn't change anything.

 

it was already XPMSE

I have to say i use enhanced character edit could that be the issue?

[audhol]

44 minutes ago, Lupine00 said:

Would be a nice chance to smooth out some of the sharp corners if it's subdivided. I imagine the mesh in the picture was just to show the subdivision, not how it could ultimately be polished up.

Yeah was just to show roggvir that subdividing the mesh doesn't make it huge, if I was going to do it I would use the multresolution modifier to smooth at the same time as doubling the face count but that's down to roggvir and kimy. As for the textures I don't claim to be the world's leading expert but for me emmisive maps are mainly used for metallic objects, however the quality of the diffuse is very good considering how little vertices there are to work with. The restrictive boots are a masterpiece of hand painting textures as the mesh is even lower and its only when you zoom right in you see everything is flat. 

[Roggvir]

Just a small update regarding my struggle of getting the "snapshot" frames from the animations (mentioned here)...

Who would have thought, but Havok Preview Tool comes to the rescue

As i stated before, i can't convert most animations back to KF, and even if i can, i can't import them into Max again.
But i can use hkxcmd to convert the anims to the HKX XML format and get the data i need using several easy, not convoluted steps at all:
(stick to Oldrim source files - skeletons, animations, etc.)

1. Use hkxcmd to convert the HKX animation to HKX XML format.
2. Start the Havok Preview Tool, and load (File->Open) a XML skeleton (found for example in XP32MSE modders resource).
3. Add the HKX XML file (File->Add).
4. Export all of that back into XML again (File->Save).
5. Open the exported XML and find a "referencepose" frame, that looks like this:
   Spoiler

   <hkparam name="referencePose" numelements="126">
       (0.000000 0.000000 0.000000)(0.000000 0.000000 0.000000 1.000000)(1.000000 1.000000 1.000000)
       (-0.215923 0.411461 0.000000)(0.000000 0.000000 0.000000 1.000000)(1.000000 1.000000 1.000000)
       (-0.215923 0.411461 0.000000)(0.000000 0.000000 0.000000 1.000000)(1.000000 1.000000 1.000000)
       ...

   ...each of the lines with the numbers sets the position, rotation, and scale of corresponding bone in a "bones" block that you can find just before this "referencePose" block.

   The "bones" block looks like this:

   Spoiler

   <hkparam name="bones" numelements="126">
       <hkobject>
           <hkparam name="name">NPC Root [Root]</hkparam>
           <hkparam name="lockTranslation">false</hkparam>
       </hkobject>
       <hkobject>
           <hkparam name="name">x_NPC LookNode [Look]</hkparam>
           <hkparam name="lockTranslation">false</hkparam>
       </hkobject>
       <hkobject>
           <hkparam name="name">x_NPC Translate [Pos ]</hkparam>
           <hkparam name="lockTranslation">false</hkparam>
       </hkobject>
       ...

   ...every Nth line in the "referencepose" corresponds to Nth bone in this block, so you can pair the values with the appropriate bone.

6. Now we can use the data to pose the bones in OS
   ...or, we can make a skeleton where we put the bones in the appropriate pose, that we can then load into OS instead of its original skeleton - that will save us the annoying editing of the pos/rot values in OS (which afaik cannot be saved, so if you close OS and want to do it again, you needto pose the bones again).
   So, right now i am using NifSkope to make the "posed skeleton".

 

There is just a small hickup, that the bone rotations in the XML are Quaternions, while the NifSkope is using Euler Angles by default, so you may need to convert that (if you don't know how, same as me, wikipedia comes to rescue).

NifSkope also annoys the hell out of me by not allowing me to paste in numbers with more than 5 decimals so i have to round them up first, but omg, at least we are FINALLY GETTIN SOMEWHERE!

EDIT: THIS IS ALL WRONG!
That damn "referencePose" frame is no representation of the pose at all. It is a completely unrelated pose.
It's USELESS!

[Rafuc]

23 hours ago, hungvipbcsok said:

You can tried to overwrite the animation with a new one like pet suit.

It worked,Thanks !

[zarantha]

11 minutes ago, Roggvir said:

hat will save us the annoying editing of the pos/rot values in OS (which afaik cannot be saved, so if you close OS and want to do it again, you needto pose the bones again)

 

Actually, they can be saved. Just set the pose as the base shape and save it as a project. Or at least that's what I did. From there I can add the project to the outfit project and use it as a reference shape.

[Roggvir]

12 minutes ago, zarantha said:

 

Actually, they can be saved. Just set the pose as the base shape and save it as a project. Or at least that's what I did. From there I can add the project to the outfit project and use it as a reference shape.

But that will "bake" the pose into the saved mesh, no?
It won't save the values you put in the bone posing input fields, it won't even save the values in the actual bones in the resulting NIF - i mean not in the same way, right?
It will save the mesh morphed into the pose, and the values will be lost so you are screwed IF for any reason you need those values again.
Or am i wrong?
 

[zarantha]

26 minutes ago, Roggvir said:

But that will "bake" the pose into the saved mesh, no?
It won't save the values you put in the bone posing input fields, it won't even save the values in the actual bones in the resulting NIF - i mean not in the same way, right?
It will save the mesh morphed into the pose, and the values will be lost so you are screwed IF for any reason you need those values again.
Or am i wrong?
 

 

Yes, it's baked into the pose at that point. But before I figured how to save the pose, I was entering it manually every time so I have the values written down anyway. You can still adjust the bones after saving, it just doesn't show the original offsets.

[VirginMarie]

6 hours ago, donkeywho said:

permissions

donkeywho    #5 on in the FAQs

 

[Roggvir]

8 hours ago, Roggvir said:

Just a small update regarding my struggle of getting the "snapshot" frames from the animations (mentioned here)...

Who would have thought, but Havok Preview Tool comes to the rescue

As i stated before, i can't convert most animations back to KF, and even if i can, i can't import them into Max again.
But i can use hkxcmd to convert the anims to the HKX XML format and get the data i need using several easy, not convoluted steps at all:
(stick to Oldrim source files - skeletons, animations, etc.)

1. Use hkxcmd to convert the HKX animation to HKX XML format.
2. Start the Havok Preview Tool, and load (File->Open) a XML skeleton (found for example in XP32MSE modders resource).
3. Add the HKX XML file (File->Add).
4. Export all of that back into XML again (File->Save).
5. Open the exported XML and find a "referencepose" frame, that looks like this:
     Reveal hidden contents

   <hkparam name="referencePose" numelements="126">
       (0.000000 0.000000 0.000000)(0.000000 0.000000 0.000000 1.000000)(1.000000 1.000000 1.000000)
       (-0.215923 0.411461 0.000000)(0.000000 0.000000 0.000000 1.000000)(1.000000 1.000000 1.000000)
       (-0.215923 0.411461 0.000000)(0.000000 0.000000 0.000000 1.000000)(1.000000 1.000000 1.000000)
       ...

   ...each of the lines with the numbers sets the position, rotation, and scale of corresponding bone in a "bones" block that you can find just before this "referencePose" block.

   The "bones" block looks like this:

     Reveal hidden contents

   <hkparam name="bones" numelements="126">
       <hkobject>
           <hkparam name="name">NPC Root [Root]</hkparam>
           <hkparam name="lockTranslation">false</hkparam>
       </hkobject>
       <hkobject>
           <hkparam name="name">x_NPC LookNode [Look]</hkparam>
           <hkparam name="lockTranslation">false</hkparam>
       </hkobject>
       <hkobject>
           <hkparam name="name">x_NPC Translate [Pos ]</hkparam>
           <hkparam name="lockTranslation">false</hkparam>
       </hkobject>
       ...

   ...every Nth line in the "referencepose" corresponds to Nth bone in this block, so you can pair the values with the appropriate bone.

6. Now we can use the data to pose the bones in OS
   ...or, we can make a skeleton where we put the bones in the appropriate pose, that we can then load into OS instead of its original skeleton - that will save us the annoying editing of the pos/rot values in OS (which afaik cannot be saved, so if you close OS and want to do it again, you needto pose the bones again).
   So, right now i am using NifSkope to make the "posed skeleton".

 

There is just a small hickup, that the bone rotations in the XML are Quaternions, while the NifSkope is using Euler Angles by default, so you may need to convert that (if you don't know how, same as me, wikipedia comes to rescue).

NifSkope also annoys the hell out of me by not allowing me to paste in numbers with more than 5 decimals so i have to round them up first, but omg, at least we are FINALLY GETTIN SOMEWHERE!

 

LOL, this is embarassing...
After poking into this a bit further, i found that the "referencePose" frame is completely unrelated to the animation pose.
I mean... does this look like an elbowbinder pose to you? ?

Yeah, i didn't think so.

So, back to square one. I need to think...

[Roggvir]

I managed to convert the animation into KF and import it into Max.
I had to find the skeleton that worked for the HKX to KF conversion, which was the uber ancient XP32 Maximum Skeleton v1.96 (i was googling for skeletons and trying them one by one until this one worked - which doesn't mean its the best choice for this anim file, but it seem to work).
The hkxcmd spits out some warnings about non-uniform scaling, but does create a KF file.

Now to import the KF into Max 2012, i tried various rigs i could find (same trial and error like with the skeleton) and what seem to work best is "3DS2009 XPMS 1-6 T-POSE_Controller Rig_F_v0.13.max" from https://www.loverslab.com/topic/36314-3ds-max-skeleton-controller-rigs-draugr-v0132-2015-09-22/.

Problem is, the animation in Max is just plain wrong.
The hands are NOT in a elbowbinder pose, and well... see for yourself:

Spoiler

EDIT: i forgot to mention, when i preview the anim (converted into XML) in Havok Preview Tool, it shows exactly as it should.
No glitches, hands in the correct pose, everything 100% perfect, so i gues it must be the subsequent conversion to KF that breaks it, or importing into Max, but ...does it? and why?

Any ideas?

[Roggvir]

5 hours ago, Roggvir said:

I managed to convert the animation into KF and import it into Max.
I had to find the skeleton that worked for the HKX to KF conversion, which was the uber ancient XP32 Maximum Skeleton v1.96 (i was googling for skeletons and trying them one by one until this one worked - which doesn't mean its the best choice for this anim file, but it seem to work).
The hkxcmd spits out some warnings about non-uniform scaling, but does create a KF file.

Now to import the KF into Max 2012, i tried various rigs i could find (same trial and error like with the skeleton) and what seem to work best is "3DS2009 XPMS 1-6 T-POSE_Controller Rig_F_v0.13.max" from https://www.loverslab.com/topic/36314-3ds-max-skeleton-controller-rigs-draugr-v0132-2015-09-22/.

Problem is, the animation in Max is just plain wrong.
The hands are NOT in a elbowbinder pose, and well... see for yourself:

  Reveal hidden contents

 

EDIT: i forgot to mention, when i preview the anim (converted into XML) in Havok Preview Tool, it shows exactly as it should.
No glitches, hands in the correct pose, everything 100% perfect, so i gues it must be the subsequent conversion to KF that breaks it, or importing into Max, but ...does it? and why?

Any ideas?

Problem SOLVED.

First, use the old XP32MS v1.96 skeleton rig (from the main file, not from the modders resource) with hkcmd to convert the animation to KF.
Then make copy (call it "anim.nif") of the skeleton NIF from BodySlide resource folder, open it in NifSkope and attach the KF animation to it (ignore any errors).
Go to first frame, or whichever frame you want to make snapshot of.
Open the "Inspect" tab on the right side, and make sure the "Show Local Transform" is checked.
Save the "anim.nif" file, and keep it open in NifSkope.
Create another copy (call it "pose.nif") of the skeleton NIF from BodySlide resource folder and open it in NifSkope.
Now copy transforms from the bones of interest in "anim.nif" to the same bones in the "pose.nif" (select node/bone in the "anim.nif" and click on "Copy Transform to Clipboard" button in the "Inspect" tab, then switch to the "pose.nif", find the same node, right click on it and choose "Transform" -> "Paste").
Do this for every bone you need (since i am doing this for the Elbowbinder, i am interested in every bone from L/R Clavicle down to the fingers).
When done, save "pose.nif" and you can discard the "anim.nif".
Now make the "pose.nif" into a BodySlide reference by copying into it some shapes - in my case that means the CBBE bodyand CBBE hands (use Copy/Paste Branch to copy the whole ...branch with the mesh, including all the DismemberSkinInstance and BSLightingShaderProperty and whatever else the mesh may needing).
EDIT: actually, you don't need to make it into a reference, you just need to set the "pose.nif" as the reference skeleton for Outfit Studio.

When done, you can start Outfit Studio, load any outfit you want, go to "Bones", unfold the "Posing" rollout, check "Show Pose", and voila the real work can start...



EDIT: I forgot one more step - set the "pose.nif" also as the reference skeleton for Outfit Studio.
Without that the bone "posing" based on the skeleton won't work.

[Lupine00]

31 minutes ago, Roggvir said:

you can start Outfit Studio

Outfit Studio is so useful. It's an awesome tool.

I do wish there were ways to use numerical values when setting the "reference" - the origin about which rotate and scale work - maybe there is?

 

For me, OS is the easiest way in and out of other programs, as well as doing all the things its made for, and many others besides.

 

 

But thanks to Roggvir for working on this, for the benefit of all, because it does mean - ultimately - better Bodyslides for all those animation poses.

 

 

On another topic ... Havok Preview ... 

 

I went digging on my machine and found the latest version of the Havok SDK I have is from ... 2004.

It's a little old.

 

Does anyone have a newer version that they definitely wouldn't ever distribute by uploading to Mega/Google Drive, that they can not give me?

[Zaflis]

I'm curious btw, how does HDT chains work currently? Are they really simulated from torus polygon collision shapes or are they what i'm hoping for, just rope-like joints together? It would really make no sense at all to actually have each chain link collide with eath other, it would explain much of its buggy behavior though.

[Lupine00]

27 minutes ago, Zaflis said:

I'm curious btw, how does HDT chains work currently? Are they really simulated from torus polygon collision shapes or are they what i'm hoping for, just rope-like joints together?

AFAIK they are simply a set of points with distance constraints. Some may be a 'chain' of boxes. YMMV depending on the source of the config file and who made it... and whether they cared about collision. In most cases collision is pointless and there isn't going to be any.

 

To be candid, I can't even remember how these are made, but you can see just by looking in the config file.

 

They are definitely not torus collisions. Notice how you can stretch them out almost infinitely, like elastic?

 

They go nuts all the time because PE seems to have some systemic problem with damping, and has the ability to "produce energy from nowhere".

Also, gravity is a weak force, because ... see above ... strong forces generate more mystical Havok zero-point energy than weak ones.

The result is it's easy for stuff to jump in the air at the slightest disturbance.

I think a lot of this comes from the Havok version and configurations in Skyrim, that use the absolute cheapest resolvers configured in the cheapest mode, also the frame-rate variance issues.

It was possible to get nice results with Havok on the PS3, and extreme numbers of objects were quite feasible.