HDT variables altered by PC/NPC weight value

[skymod551]

I hesitated posting this before understanding more about how Havok/HDT/Papyrus/ etc. works, but since that is going to take awhile I figured I would ask how someone would go about doing this, if it has not already been done.  

 

Basically, I was thinking having the hdtPhysicsExtensionsDefaultBBP .xml file be able to have variables be modified by the playable or non-playable character's actor weight value (0-100).  So for example if you have an actor of weight 0 with A cups, and an actor of weight 100 with F cups, then you may want the Z direction linear constraints for breast movement to vary so breasts that are much larger will be able to move within a larger constrained area than breasts that are much smaller : i.e. "Max Z = (27.0 * (0.01*(Weight+1)))+2.73 ; so at weight 100 you allow a movement up to 30.0 and weight 0 you allow a movement up to 3.0 (just a quick thought to illustrate my point, not sure if it is erroneous or not).  Likewise other values such as the mass and inertial tensor/rotation matrix would be weight dependent as well.

 

Not sure if this is easy, hard, unnecessary or what, let me know what you think. Thanks.

 

[blabba]

I had a somewhat similar idea, but instead you use BodySlide to slide a pre-made Convex Hull shape with the same presets as your body.

 

Then you'd have to load up the hull shape into 3dsMax, and export the XML data thus creating your very own custom made collision ragdoll tailored to your specific body.

 

Honestly speaking, your idea would be pretty cool as well because then you could use the bodyslide to make the custom collision shapes and then as weight gets affected (or node scaling) you could have some sort of magical formula to dynamically change the collision detection.

 

The only problem is I have no idea how your going to get papyrus to edit the xml data

[skymod551]

Yeah this is where my limited knowledge of how this all works is, I didn't intend the xml file to actually be edited, but read in terms of a formula that requires the weight value inputs, so that thinking may be wrong.

 

I haven't messed with the 3d modelling yet so I'm not too sure about your suggestion and the effects, but I will keep the concept you are referring to in mind.

[RomeoZero]

Its already a team of people i see that can help Hydro to develop fast new Prog   Write her your ideas and concepts.

[blabba]

Yeah this is where my limited knowledge of how this all works is, I didn't intend the xml file to actually be edited, but read in terms of a formula that requires the weight value inputs, so that thinking may be wrong.

 

I haven't messed with the 3d modelling yet so I'm not too sure about your suggestion and the effects, but I will keep the concept you are referring to in mind.

 

That would be an even better/brilliant idea and could potentially get rid of some bugs with just editing the xml.

 

Some new problems/ideas about it:

 

1. You'd need to create a hook into the HDT.dll file provided by Hydrogen (I believe it was built with SKSE, so should be doable, but would require source code)

2. Then you would take the values that the file loads and right before it starts building the havok collision world, apply your formula to the vertices for the collisions based off the weights.

 

As for my 3-D BodySlide model tie-in, I was thinking, user makes the BodySlide ConvexHull collision shapes to match their body, and then your program reads the .nif vertex stuff from that instead of the normal femalebody.nifs (There's a reason for this, explained later) and applies the same standard transform formula based on that.

 

As for my reasoning behind why you'd want to read convex hull shape instead of normal femalebody.nifs is because less vertex data = faster procedure. Especially where Havok physics is concerned you really don't want to take up more CPU time :/.

Also because now instead of coming up with individual formula's for each body part, you just need to come up with 'transform' data similar to what the weight slider in-game does. (I'm sure someone knows how to do that trick already) better yet, you could potentially just read a .bsd (BodySlide slider transform data) which will give you the vertex positions needed. Added benefit is that .bsd files are really small (like 120kb are the biggest I've come upon)

[Yoo]

 

Yeah this is where my limited knowledge of how this all works is, I didn't intend the xml file to actually be edited, but read in terms of a formula that requires the weight value inputs, so that thinking may be wrong.

 

I haven't messed with the 3d modelling yet so I'm not too sure about your suggestion and the effects, but I will keep the concept you are referring to in mind.

 

That would be an even better/brilliant idea and could potentially get rid of some bugs with just editing the xml.

 

Some new problems/ideas about it:

 

1. You'd need to create a hook into the HDT.dll file provided by Hydrogen (I believe it was built with SKSE, so should be doable, but would require source code)

2. Then you would take the values that the file loads and right before it starts building the havok collision world, apply your formula to the vertices for the collisions based off the weights.

 

As for my 3-D BodySlide model tie-in, I was thinking, user makes the BodySlide ConvexHull collision shapes to match their body, and then your program reads the .nif vertex stuff from that instead of the normal femalebody.nifs (There's a reason for this, explained later) and applies the same standard transform formula based on that.

 

As for my reasoning behind why you'd want to read convex hull shape instead of normal femalebody.nifs is because less vertex data = faster procedure. Especially where Havok physics is concerned you really don't want to take up more CPU time :/.

Also because now instead of coming up with individual formula's for each body part, you just need to come up with 'transform' data similar to what the weight slider in-game does. (I'm sure someone knows how to do that trick already) better yet, you could potentially just read a .bsd (BodySlide slider transform data) which will give you the vertex positions needed. Added benefit is that .bsd files are really small (like 120kb are the biggest I've come upon)

 

 

Yeh, the pre-process wouldnt be that heavy but since this physics "engine" depends on framerate it could prove to be quite ureliable at low FPS

 

 

I had a somewhat similar idea, but instead you use BodySlide to slide a pre-made Convex Hull shape with the same presets as your body.

 

Then you'd have to load up the hull shape into 3dsMax, and export the XML data thus creating your very own custom made collision ragdoll tailored to your specific body.

 

Honestly speaking, your idea would be pretty cool as well because then you could use the bodyslide to make the custom collision shapes and then as weight gets affected (or node scaling) you could have some sort of magical formula to dynamically change the collision detection.

 

The only problem is I have no idea how your going to get papyrus to edit the xml data 

 

Maybe creating a rigged version of the convex hulls, then you could export the vertex data of those meshes. But I dont really know how bodyslide works... xD

 

 

Its already a team of people i see that can help Hydro to develop fast new Prog    Write her your ideas and concepts.

 

 

Meh, I dont want a program, I want Mesh Shapes for collisions... u.u

[skymod551]

 

 

 

1. You'd need to create a hook into the HDT.dll file provided by Hydrogen (I believe it was built with SKSE, so should be doable, but would require source code)

2. Then you would take the values that the file loads and right before it starts building the havok collision world, apply your formula to the vertices for the collisions based off the weights.

 

 

 

Where I stand right now, this sounds tough, but I'm thinking it's a good place to start.  I'll read up more on how I would even go about doing this - but if you can elaborate -as well as anyone else knowledgeable, that would be great, thanks.