New Update 2014/2/28

[lordofthedread]

Sadly can't access pan.baidu.com no matter what.

 

I am in SEA so I should be able to access it easily (well easier than if I was in the US for example).

 

Can we get a mirror somewhere pretty please ?

[TnTTnT]

Here you are.

 

hdtPhysicsExtensions 24-02-14.zip

[lordofthedread]

Thanks

[TnTTnT]

Nice.

I will use this new update in non-collision play.  Too bad that all collision xml are only for 10-25 and don't work well with newer version of HDT.

multiply all xyz value in inertiaAndMassInv by 0.01425

 

Thanks for advice.

Since I never modify the xml myself, may I ask which which value in this context that need to be multiplied?  All four or which three are x,y,z?

 

<hkparam name="inertiaAndMassInv">(0.000000 0.000000 0.000000 1.500000)</hkparam>

 

[HydrogensaysHDT]

 

Nice.

I will use this new update in non-collision play.  Too bad that all collision xml are only for 10-25 and don't work well with newer version of HDT.

multiply all xyz value in inertiaAndMassInv by 0.01425

 

Thanks for advice.

Since I never modify the xml myself, may I ask which which value in this context that need to be multiplied?  All four or which three are x,y,z?

 

<hkparam name="inertiaAndMassInv">(0.000000 0.000000 0.000000 1.500000)</hkparam>

 

 

 

the 1st, 2nd and 3rd numbers.

don't modify them if they are zero.

 

[TnTTnT]

Thanks HydrogensaysHDT. 

[HydrogensaysHDT]

All the hair stretching problems are gone now. Hydrogen do you think you could add mesh quality type support? It just crashes when trying to load mesh type instead of convex/box/capsule/sphere. I don't mind using convex if that's all that works, but I'm just curious as to why it crashes.

 

I don't know either, but after I checkedd the havok sdk I found that hkpMeshShape is marked "deprecated". it use hkpExtendedMeshShape which is not in HCT. I think that may be one of the reason.

I'll do some more check for it

[blabba]

Hey Hydrogen, just took a look through the source (thanks fr that by the way)

 

I just stumbled upon the World.cpp file and saw that the way you check for collision is by checking whether or not the nif contains the extra_data string path to a collision xml.

 

I was wondering/hoping there might be an alternative way to do this?

Like adding a check to see if another file like 'collision.xml' was in the same directory, and then applying it to all actors in the cell, basically a system more similar to how the defaultBBP.xml gets loaded up.

 

I'm a huge novice to the SKSE sdk as well as the Havok sdk, so I don't know if this is even possible (though I would think it is) and I'll try tinkering around to see if I can get somewhere with it, but hopefully I could entice you to look at it as well

 

I apologize in advance if any of this gets lost in translation (I understand your first language is probably not English xD)

[HydrogensaysHDT]

Hey Hydrogen, just took a look through the source (thanks fr that by the way)

 

I just stumbled upon the World.cpp file and saw that the way you check for collision is by checking whether or not the nif contains the extra_data string path to a collision xml.

 

I was wondering/hoping there might be an alternative way to do this?

Like adding a check to see if another file like 'collision.xml' was in the same directory, and then applying it to all actors in the cell, basically a system more similar to how the defaultBBP.xml gets loaded up.

 

I'm a huge novice to the SKSE sdk as well as the Havok sdk, so I don't know if this is even possible (though I would think it is) and I'll try tinkering around to see if I can get somewhere with it, but hopefully I could entice you to look at it as well

 

I apologize in advance if any of this gets lost in translation (I understand your first language is probably not English xD)

 

I considered this idea before but the default collision will collide with the attached one, so I just rejected it because it's very easy to make conflict(unsolvable constraints etc)

[jacques00]

 

 

Hey Hydrogen, just took a look through the source (thanks fr that by the way)

 

I just stumbled upon the World.cpp file and saw that the way you check for collision is by checking whether or not the nif contains the extra_data string path to a collision xml.

 

I was wondering/hoping there might be an alternative way to do this?

Like adding a check to see if another file like 'collision.xml' was in the same directory, and then applying it to all actors in the cell, basically a system more similar to how the defaultBBP.xml gets loaded up.

 

I'm a huge novice to the SKSE sdk as well as the Havok sdk, so I don't know if this is even possible (though I would think it is) and I'll try tinkering around to see if I can get somewhere with it, but hopefully I could entice you to look at it as well

 

I apologize in advance if any of this gets lost in translation (I understand your first language is probably not English xD)

 

 

 

I considered this idea before but the default collision will collide with the attached one, so I just rejected it because it's very easy to make conflict(unsolvable constraints etc)

 

I can confirm collisions clashing (was testing with giants some days ago and ran into this issue first-hand)--I advise to avoid inserting collision info into the hdtPhysicsExtensionsDefaultBBP.xml and link it separately, especially if you have multiple objects/NPCs running their own collision .xml's.

 

[samogen]

Is the collision .xml a new file that we need for this to work? If so where might I find the proper collision .xml for females and males?

[chajapa]

Please forgive my n00b question, but when I see the terms "default collisions" it leads me to believe that collisions are in the new dll by default. Or should we take this to mean the hdtPhysicsExtensionsDefaultBBP.xml is where the "default collisions" are?

 

And am I also reading this correctly that the hdtPhysicsExtensionsDefaultBBP.xml that I'm using in the 10-24 stable will not work with this new dll?

 

If that's the case, is there an updated version of THAT file as well? Did I miss it?

[imranlateef]

Here you are.

 

Thanks TnTTnT

 

Was having the same problem in EU.  Also BIG THANK YOU to Hydrogen for the continued development of UBER Skyrim goodness.

[jacques00]

Please forgive my n00b question, but when I see the terms "default collisions" it leads me to believe that collisions are in the new dll by default. Or should we take this to mean the hdtPhysicsExtensionsDefaultBBP.xml is where the "default collisions" are?

 

And am I also reading this correctly that the hdtPhysicsExtensionsDefaultBBP.xml that I'm using in the 10-24 stable will not work with this new dll?

 

If that's the case, is there an updated version of THAT file as well? Did I miss it?

 

Collisions are not enabled by default--only edited .xml will have them.

 

hdtPhysicsExtensionsDefaultBBP.xml, straight out of the box shouldn't have any collision information. If you pulled the hdt.xml and hdtm.xml from the HDT Object mod, that would have collision data. You can also add collisions yourself using the "Just For Fun" tool in this forum, though again, I do not recommend it for the default .xml. You can link it to a .nif mesh, however, and that should (mostly) be fine.

 

[chajapa]

OK. Now I feel like I'm just chasing my own tail. 

Talk to me about the basic mechanics here in terms of how this loads.

Does the dll actually DO the default HDT effects or does it load the hdtPhysicsExtensionsDefaultBBP.xml and from THERE we get the hdt.

 

I'm talking about basic weight, balance, dampening, etc.

 

IF we have an hdt.xml and an hdtm.xml, should those 2 files ONLY contain collision information?

 

MY BRAIN HURTS!

 

Right now I'm using a default xml that's about 200k in size and contains everything for the female. From basic bounce and jiggle all the way to collisions.

I'd have to go back into JFF and look but I don't understand how you'd set up a breast sphere in the default so that you could have the weight and stuff without defining the collisions for it as well. 

[canderes]

I think the dll only affects the breast/butt bones directly, but everything else is loaded from an xml-havok has some animation controls that can act on the skeleton only and don't require rigid bodies, but if you add an xml that does map to bones on the skeleton then it will use those rigid bodies and load in any unrecognized bones in place of what the dll does by itself.

[jacques00]

chajapa, the DefaultBBP.xml with only the physics movement and no collision info should be about 60-80 or so KB. If it's in the hundreds, you either have a lot of extra rigid bodies, or there are some collision parameters in there.

 

From what I've experienced, .dll will pull the info from the hdtPhysicsExtensionsDefaultBBP.xml. That means, if you have a "blank" .xml file in that place (with the proper headers--basically delete all the rigid body nodes in the .xml), you will get no physics. And if you have BBP/TBBP animations (and a BBP-compatible skeleton_female.hkx), they should play normally without the physics. At least for the last two or three builds of the plug-in--I'm not sure about earlier versions. The .dll, from what I understand, just scans for the proper nodes laid out in the .xml and applies it to the proper mesh's parent skeleton--though I could be wrong since I haven't looked at the source code to confirm. This auto-linking may be a problem since some meshes that I did not link HDT to had been affected because the names matched between a skeleton node and a DefaultBBP.xml rigid body node. And I just figured out that the clashes don't happen with only collision binding, but binding physics in general--if the nodes don't match, HDTPhysicsExtension will return errors.

 

For instance, I added a new NPC PreBelly and NPC Belly node to the Default.xml and it works fine for the character and NPCs since they have all the nodes that are affected. But when I go to room with one of my custom female mannequins with an outdated skeleton, the log builds up with error messages of missing PreBelly Node. I updated the skeleton to have a PreBelly node and the errors of the missing node disappears. A similar incident happens with my giants mod when I tried testing a HDT Path links on those meshes. Because the skeleton is either missing a node or has a corresponding node misspelled, once HDT auto-latches onto that skeleton, the listed rigid bodies in the DefaultBBP.xml have to exist in the skeleton, otherwise it will return errors. This will make it hard for any custom NPC or object with it's own unique .xml and skeleton--so it's probably best to have the Default.xml blank to have HDTPhysicsExtension function properly.

 

I have noticed some anomalies when using both the DefaultBBP.xml and linked custom.xmls simultaneously, especially when collisions are added to one or both of them. The movement becomes more erratic and random for split seconds, possibly due to overlapping calculations, probably because of same-named rigid body nodes (and because it's calculated, the result will vary on different machines). Some movement will not move as they should and may jump out of place. I've found that optimal performance is when you have only one .xml affecting the mesh's skeleton--that is you either have everything stashed into the DefaultBBP.xml and hope that any other meshes/skeletons affected have the same nodes in them, or you have a blank DefaultBBP.xml and link all of your meshes either by way of an HDT Object or manually--either process has it's pros and cons unless there is an even better and more efficient way of enabling physics without clashes.

 

So in short, if you have 'NPC nodeA' in your DefaultBBP.xml, and 'NPC nodeA' in your linked Custom.xml, expect to see some weird physics due to calculation overlaps. If you have 'NPC nodeA' and 'NPC nodeB' in your DefaultBBP.xml, and a custom mesh is using a skeleton that has 'NPC nodeA' but no 'NPC nodeB', then expect the log to infinitely return errors about missing 'NPC nodeB' when that mesh appears in the cell. That particular mesh does not have to be linked with HDTPath nor does the .xml need to have collision information, the node name just plainly needs to be listed, and if it can't be found by the .dll, it will log errors.

 

If any of this is contrary to the actual function of the .dll, please correct me. I am only reporting what I've observed thus far.

 

Edit:

IF we have an hdt.xml and an hdtm.xml, should those 2 files ONLY contain collision information?

 

That may be ideal--though I would honestly keep the DefaultBBP.xml "blank", and have the custom .xmls on their own, with both movement and collision info in one .xml for each different mesh. This is so when any meshes' skeleton has one node matching any that's in that DefaultBBP, HDT will return an error for each node that doesn't match in the skeleton.

[blabba]

Hmm,

 

Just an after thought, but if we wanted collision on all characters even with armor and without linking the extra xml's...

 

Would it be possible to adjust the 'default' game collision on the skeletons?

From what I understand, all the skeletons I've seen so far have had zero collision object changes done to them. And I believe the reason why we cannot have the HDT.dll load up a seperate collision xml is because the game already has a set 'default' collision that is attached to the skeletons (hence why linking the extra data to skeleton .nifs don't work)

 

So then wouldn't it be possible to make new RB's parent them to the breast/butt/cape/hair whatever bones and produce a true 'HDT' skeleton?

 

I know canderes has a good ragdoll setup, so why not just use that parent it to skeletons?

 

Then I again I say all this in ignorance and do not know for sure if this method is even feasible or if it even works :/

Would be much obliged if an expert could weigh in on this!

[jacques00]

Hmm,

 

Just an after thought, but if we wanted collision on all characters even with armor and without linking the extra xml's...

 

Would it be possible to adjust the 'default' game collision on the skeletons?

From what I understand, all the skeletons I've seen so far have had zero collision object changes done to them. And I believe the reason why we cannot have the HDT.dll load up a seperate collision xml is because the game already has a set 'default' collision that is attached to the skeletons (hence why linking the extra data to skeleton .nifs don't work)

 

So then wouldn't it be possible to make new RB's parent them to the breast/butt/cape/hair whatever bones and produce a true 'HDT' skeleton?

 

I know canderes has a good ragdoll setup, so why not just use that parent it to skeletons?

 

Then I again I say all this in ignorance and do not know for sure if this method is even feasible or if it even works :/

Would be much obliged if an expert could weigh in on this!

 

Yes, I remember testing the links to a skeleton myself and have it not work, and I'm sure others have tried way before I have (thus the HDT Object and linking methods). We probably could tie the havok rigid bodies to the skeletons, but if possible, I would only imagine that method to be resource intensive in gameplay and highly un-customizable in terms of modding since the bones will all be affected, weather or not the meshes are bound to those bones--so everything will be calculated and not all of it would be shown in-game. And then, multiple characters, multiple physics calculations, so many resources used. This may also be one of the reasons why the devs never implemented real-time physics for their characters since it would require a lot of extra work and game engine resource budgeting to consider.

 

So it might be best to dictate which objects uses which physics, collisions or otherwise, and let the engine take care of the rest. Of course I think it would be more convenient for all skeletons to be unified so there wouldn't be a need for linking and worrying about clashes, but at least it's less resource intensive because it only uses what it needs and is highly customizable for anyone wanting to make a unique set of values for their physics.

 

[Redflyingmonkey]

Not sure I get it jacques, concerning the fact that DefaultBBP shouldn't have collisions on it. Wouldn't it be actually more stable to keep every content in a single xml ? I mean I've been tinkering with a xml I liked which didn't have collision, but added it manually through the JFF, I don't seem to have a lot of issues with it except the occasional spazzing and crash, would it be even more stable if I made a havok object specially for the collision ? 

[chajapa]

Getting clearer and more confusing at the same time.

 

If the dll is loading the xxxDefaultBBP.xml AND if I'm using a xxxDefaultBBP.xml that has all of the collision information in it, wouldn't ALL female characters have hdt with collisions enabled? I mean... wouldn't they have it WITHOUT me having to link a nif to the xxxDefaultBBP.xml? Wouldn't collisions be the default?

 

And in my case, because of the experimenting I'm doing to see who loads what, I've copied the xxxDefaultBBP.xml with several filenames.

I have vanillahands.xml, lwhands.xml (for Lunari Warriors), lrhead.xml (for Lunari race), and a few others..

If EVERY character is getting the effects of xxxDefaultBBP.xml and then a SPECIFIC character is linked to ... let's say... lrhead.xml, does the information in lrhead.xml OVER WRITE the xxxDefaultBBP.xml or am I loading the same information for that character TWICE somehow? And causing problems?

 

I'm getting the occasional boob or butt flutter, but otherwise seems to be running ok 90% of the time.

 

[jacques00]

Not sure I get it jacques, concerning the fact that DefaultBBP shouldn't have collisions on it. Wouldn't it be actually more stable to keep every content in a single xml ? I mean I've been tinkering with a xml I liked which didn't have collision, but added it manually through the JFF, I don't seem to have a lot of issues with it except the occasional spazzing and crash, would it be even more stable if I made a havok object specially for the collision ? 

Well, it's okay only if you have just one type of object/character using it (like human/beast race players and NPCs, since they all have matching skeletons), sure. But once you throw in linked (or non-linked) mesh with a skeleton that has at least one node that matches the one rigid body in the DefaultBBP.xml, the DefaultBBP.xml will apply the physics to that node and scan for the other nodes matching the listed rigid body nodes for that skeleton as well. If they do not exist in that particular parent skeleton, the plugin will record errors. It doesn't seem to happen for male and female skeletons for some reason, but I've so far noticed it happen with custom giant, werewolf, and mannequin skeletons that have the added Breast/Butt nodes in their skeletons (I've been experimenting with these).

 

Getting clearer and more confusing at the same time.

 

If the dll is loading the xxxDefaultBBP.xml AND if I'm using a xxxDefaultBBP.xml that has all of the collision information in it, wouldn't ALL female characters have hdt with collisions enabled? I mean... wouldn't they have it WITHOUT me having to link a nif to the xxxDefaultBBP.xml? Wouldn't collisions be the default?

 

And in my case, because of the experimenting I'm doing to see who loads what, I've copied the xxxDefaultBBP.xml with several filenames.

I have vanillahands.xml, lwhands.xml (for Lunari Warriors), lrhead.xml (for Lunari race), and a few others..

If EVERY character is getting the effects of xxxDefaultBBP.xml and then a SPECIFIC character is linked to ... let's say... lrhead.xml, does the information in lrhead.xml OVER WRITE the xxxDefaultBBP.xml or am I loading the same information for that character TWICE somehow? And causing problems?

 

I'm getting the occasional boob or butt flutter, but otherwise seems to be running ok 90% of the time.

They "should", but I am unsure if that is the case--I haven't tested collisions much to confirm or deny that, but I have tested linking collisions and looking for errors with the experimental skeletons and meshes I am using. Again, it doesn't seem to be constrained to just colliders, any added physics rigid body is prone to setting off the "missing bone, cannot bind" error reporting.

 

I think the information is loaded in twice for matching nodes. I am not sure about overwriting but I have seen anomalies with physics calculation when two .xmls overlap and their node names that match are the ones that wig out--namely the Breast and Butt nodes, there will be more flutter and turning 180 degrees with a character will produce a split second of geometry shooting out before returning to it's place. However,  when the DefaultBBP.xml is left blank, and the mesh is linked with the custom.xml instead (or if the mesh isn't linked and all the physics are using the DefaultBBP.xml), the physics will move normally as it should. Say if there are different variables for nodes of a matching name in two separate .xmls, one obviously being the DefaultBBP.xml, will one overwrite the other or will the numbers overlap and fluctuate on their given time intervals? It's worth a test if you want to know for sure. However, if you left the DefaultBBP.xml with no named nodes, and had two separate custom.xmls (like super jiggly for naked body, no jiggle for armored body) with matching-named nodes, they should all run fine in their own intervals, assuming that that particular skeleton is not grabbing more .xmls with matching-name nodes to run simultaneously on the same body (if that makes any sense).

 

So theoretically, you can give each part their own physics and collision .xmls, just as long as the nodes don't match any of the other nodes of the connected .xmls, you shouldn't experience any weird issues as they all run their calculations simultaneously. Say, if you have a HairPhysics.xml, make sure they don't contain any rigid body collider or physics information related to the breast or butt nodes if you have the .xml with those nodes linked elsewhere for the same skeleton.

 

Again, this is just based off my observation. If anyone would like to correct me with how the source actually functions, please do.

[Redflyingmonkey]

Still a little confused ! Like, I linked the hdtm to my male body and my defaultbbp to my femalehead. Would, say, the hand/spine/neck/head nodes from each xml conflict with each other ?

[jacques00]

Still a little confused ! Like, I linked the hdtm to my male body and my defaultbbp to my femalehead. Would, say, the hand/spine/neck/head nodes from each xml conflict with each other ?

 

Yes, if the DefaultBBP.xml, has the hand/spine/neck/head info in it, colliders or otherwise, there will be some abnormal behavior when it latches onto a mesh that has hdtm.xml linked to it. The errors will primarily be visual, like if you had matching rigid body colliders of different sizes, it will use both; and if you had physics of different values for the matching bones, they may jitter and fluctate. It won't give you an error in the log, unless you encounter another creature that uses at least one node with a matching name, and at least one missing from the DefaultBBP.xml's rigid body list (collider or otherwise)--like spawn a giant, werewolf, draugr, etc. and check your log to test, you'll see what I mean.

 

If you have the DefaultBBP.xml from out-of-the-box, you will not get these scanning errors because they only contained Breast and Butt nodes--bones that the vanilla skeletons do not have, thus the .dll will not pick them up and scan the rest of the skeleton. I (and Groovtama) only just stumbled upon these conflicts when I added the new bones to those skeletons and new rigid body nodes to the DefaultBBP.xml. I have confirmed that adding bones of matching names to a skeleton without taking all the rigid body bone names into consideration will cause missing bone errors because the devs of the vanilla assets were not consistent with their bone-naming process for all their rigs. Again, this is any rigid body information found in the DefaultBBP.xml. If you link it to your own .xml, there shouldn't be any conflicts.

 

By leaving the DefaultBPP.xml "blank", the .dll will auto-search for no nodes, so then you'll get no reports of missing nodes. You can link however many .xmls you want to whatever .nifs you like, just know that matching joint names will cause clashes in physics, and non-existing bones will cause error reports.

 

As a side note, I did test the physics on the DefaultBBP.xml and collisions will not work for it, so that's confirmed (though I'm sure many have confirmed this way before I have--thus the HDT Object and linking methods!). I did test collisions for separate linked .xmls and they seem to work, of course. I would not advise having DefaultBBP.xml to have any collision information (and to reduce skeleton clashes, to have no physics information at all) and just link everything together for what you want to have physics/collision. Even though the collisions will not work, the scanning will still look for those nodes by name, and if they can't find them, you will see log errors.

 

[chajapa]

So.... the suggestion here is to take a xxxDefaultBBP.xml, for example the one that came, by default, with the 10-24 hdt extensions download, REMOVE the ridgid bodies and constraints, and save it out as a blank file. THEN link your characters, npcs, whatever, to a custom xml?

 

I'll give it a whirl

 

I am noticing that if I UNlink my character I get better hdt movement, but obviously no collisions. When I link her back up I get collisions but it appears the "movement" is diminished AND I get the occasional spasm body parts. Usually a breast or butt cheek. So.... I'll give this a try and see if I either (A) Crash or ( get the best of both worlds.