hdt pe Another HDT PE tutorial on collisions and movement physics

[Bazinga]

I guess at some point I'll do it anyway so no point in waiting, right?

 

 

This is a work in progress tutorial on how I set up an xml file using JFF v4,

 

I will try to explain this stuff using penis collisions and freely dangling testicles as an example.

 

What do we need if we want to add HDT PE physics/collisions to a Skyrim character/creature? Basically only 4 things, Nifscope 1.1.3 (newer versions will work too ... probably),  JFF 4.0 (both files!), the skeleton and the mesh using it.

 

Figuring out which skeleton the game uses is sometimes not trivial and you'd have to check the esp that includes the object the mesh belongs to (TES5Edit) and search the race entries for the subject in question.

In our case the skeleton is much easier to find though, since we all have the latest XPMSE installed. So just go inside the mod folder and under meshes\actors\character\character assets you find a file named skeleton.nif, that's the skeleton for human males (beast races use the skeletonbeast.nif but luckily for us that one has a very similar layout so we can ignore it for now).

The other thing we need is the penis mesh. You can get that from the schlong mod of your choice, let's use the VectorPlexus Regular one from SOS for this.

The mesh we need here is meshes\actors\character\character assets\SOS\VectorPlexus Regular\malegenitals_0.nif

Spoiler

Now that we have everything we need let's use Nifscope to take a look at the skeleton:

 

 

Whoa, that's a huge pile of bones right there, probably not much fewer than in the real human one.

When we zoom in a little and look at the penis bone chain (yeah, you read that right ^^) and then click on one of these bones it will look like this:

 

 

In the block list you see the bone hierarchy with parent bones and their children, and in the block details you can see translation and rotation values for the selected bone.

We will need that information later.

While we're at it let's also open the VectorPlexus Regular penis mesh:

 

 

I already highlighted the same bone that I selected in the skeleton before. You see these translation and rotation values there? They are different and there's a reason for that.

We might need these values too.

 

Okay, now comes the hard part, writing that xml.

So I'll just open JFF and start a new one from scratch, makes it easier to explain stuff.

Doubleclicking on the hdtHavokModifier.exe opens a simple grey window, clicking the Add button gives us this:

 

 

Now we need to name that bone that we just created out of nothing (yes, we are gods), or rather we have to choose a bone from the skeleton that we want to use.

Since I want to add the penis collisions first (easier) let's use one of the bones from the penis chain, like that NPC Genitals02 [Gen02] bone from before.

 

The motion type is preselected as MOTION_SPHERE_INERTIA, which would be the right choice if we wanted more than just collisions for that bone but since we don't want the bone itself to move we will pick MOTION_KEYFRAMED instead. That way the bone won't move an inch from its position in the skeleton no matter what (if it still moves then because of skeleton animation files, not HDT PE).

 

Friction is what it says on the box. It's a property of the surface of our collision box (that we still have to set up properly) and every time this collision box and another one slide past each other both their friction values are used to determine the opposing force.

I usually just set it to a low value like 0.1, HDT PE is a bit too crude to simulate that stuff properly so expect meshes getting stuck and then moving very abruptly if you set this too high.

 

Restitution is something like a force opposing deformation. The higher you set this the more elastic the deformation will be. I also set this low by default. It's completely pointless for rigid bones like this here (remember, MOTION_KEYFRAMED).

 

Of course Linear and Angular Damping are just as useless for rigid bones. They might even be useless for the MOTION_SPHERE_INERTIA ones, because HDT PE only uses both parameters if you didn't set up damping in the constraints tab (more on that later).

 

The gravity factor should influence the effect that gravity has on HDT movement ingame (more or less pull downward), in my experience it doesn't do that though, or anything at all. This settings seems to be broken.

 

The time factor on the other hand works and is a nice way to finetune how fast you want the bones that are moving with HDT PE (the MOTION_TYPE_INERTIA ones) to bounce around. But be careful with that, there are interactive effects with some constraints settings.

 

The mass properties could be straight from a physics textbook. The definitions are basically the same. You have your mass and your center of mass (which you shouldn't change here, but in the shape setting a little further down). The inertia tensor is a matrix that tells you how fast the collision box that you set up changes its rotational speed if another object slides by and causes a torque on it. Higher values mean slower speed changes but also mean that as soon as the collision box is rotating it's harder to bring to a halt again.

And by rotating I don't just mean the mesh in itself, I also mean the center of mass relative to the bone location in the skeleton. But that's too much detail right now, we'll come back to it later.

In our case we don't need to set these mass properties up though, because we don't want the collision box to move at all.

 

The last but most important part are the fields summarized under collisions. Let's save 'Shape' setting for last and go to the GroupID field instead.

This is nothing but a simple way to decide which collision boxes should see each other (and therefore collide) and which shouldn't. One notorious example of modders frequently ignoring the importance of this group ID feature are hair mods that conflict with body physics because the hair modder thought it would be a good idea to let these hairs collide with everything and the kitchen sink. Then that overlong ponytail gets stuck at the boobs and everyone is sad. So please don't be like them, don't ignore group IDs.

Setting this to -1 makes the collision box disappear btw (well, not entirely, the inertia values that result from the collision box parameters are still used for the movement), which could come in handy if you want to have HDT PE movement but no collisions for your bone.

Here we want collisions though so we leave this at '0 - Default'. We could also use another group but in this case 0 is fine, penis collision boxes in group 0 is something like an inofficial standard anyway.

 

Now we should check all these 'No Collide With' boxes except for the ones with the same number as the group ID of the vagina or ass or boobs or whatever that penis is supposed to collide with ingame. We'd have to look up these numbers in the xml from the female body physics mod that we are using, if you're using mine (Naturalistic HDT) then you have to keep the boxes 2,3 and 7 unchecked. Why exclude everything else? Because we don't want to be like these hair modders, remember. We want full control over the things colliding with each other and we don't want weird side effects like interactions with HDT hair, clothing or weapon mods. The more we do from this end to prevent that the better.

 

Btw, you can make live easier for you if you first select group ID -1 and click Ok. Then everything in the no collide with field is checked, so now switch back to group 0 ...

I should have told you before the last paragraph? Sorry. ^^

 

Now click on the field right next to 'Shape'. There you can choose from a variety of basic shape types, each with its own parameters to set it up properly.

We want hkpCapsuleShape, that's the best approximation for an erect penis that we can find here.

The screen now looks like this:

 

 

Now what to do with these vertex parameters?

For that we have to first open the penis mesh again.

Now we'll screw with the mesh so we can obtain the measurements that we need. Sadly Nifscope 1.1.3 doesn't allow us to simply click on a mesh surface and take the coordinates from there, so we have to create our own device to do that. Click on the penis mesh in the render window. Now an entry in the block list is highlighted, 'NiTriShape MaleGenitals'.

Expand the block list for that and click on the BSDismemberSkinInstance node. Change the number of bones ('Num Bones' in the Block Details window) to 0 and click on the little circle made out of green arrows directly below that.

 

 

Now select one of the bones, not the NPC Genitals02 one though. Adjust the Y coordinate in the Block Details window next to Translation until you get to the tip of the penis and then write down that coordinate. Afterwards do the same with the back end (somewhere behind and above the balls).

 

 

So now we know the length of our collision box, it's 10 arbitrary meaningless units (AMU from now on).

We still don't know where we want to place the center of it though. I suggest we keep that at (0,0,0) - which is the location of the NPC Genitals02 bone, we named the rigidbody like that and HDT PE knows where that bone is at - and take another look at the mesh to find out how far in +Y direction and how far in -Y direction our collision box needs to be extended.

The translation y value for our bone is 7.8874, but we will just round it up to 8. The back end was at 5 AMU, the tip at 15.

So the y value for vertex 1 in that popup window in JFF (the one with the shape details) can be set to 5-8=-3, the y value for vertex 2 would be 15-8=7.

5 minus 8 instead of 8-5 because I didn't ignore that our bone is right inbetween both ends of the penis.

Also all this is basically vector algebra so what we are really calculating here is (0,15,0) - (0,8,0) to get the vector from the Genitals02 bone to the tip and (0,5,0) - (0,8,0) to get the vector from the Genitals02 bone to the rear end. These vertex coordinates represent vectors originating at the location of the NPC Genitals02 bone.

 

1 AMU for the radius is ridiculous, even for a Bosmer. We could have taken that measurement too when we had the chance but I forgot about it. Let's just set it to 5 AMU, which sounds about right in my experience. This is much more girth than what we would have gotten with measurements btw, but we need that extra radius to get proper collisions, HDT PE needs a little bit of collision box overlap before these bones are even starting to react.

Now we have a small problem though. If we enter 7 for the y value of the front end of the collision box then most of that radius of 5 gets added to that.

 

 

So we have to subtract 4 from these 7 AMU (not 5, remember the overlap needed) which makes 3 for the front end. And -3+4=1 for the back end.

Summarized:

 

 

Now keep clicking these OK checkboxes until only the main window remains and then save the xml.

 

 

That's it for now. This was simple stuff mostly, I'll try to explain some of the more complicated things next time.

 

to be continued ...

[Bazinga]

So to answer the question some of you might have:

No, starting this thread wasn't an elaborate april fools joke. Meaning I'll continue it now.

 

Last time we set up a single collision box for the entire length of the VectorPlexus Regular penis from SOS.

Which was quite easy to do because we could simply take the Y coordinate differences from the penis mesh to get the length ... and some prior knowledge about the overlap needed for collision boxes in HDT PE for the girth.

 

One thing I ignored on purpose in my first post are local and global coordinates. So let's take a look at these now, because we'll need that knowledge to set up the balls.

 

When I'm refering to global coordinates I mean the ones relative to the root node of the skeleton. When you open any random mesh you will find many of the same bones (which are NiNode entries in the Block List, the NiTrishapes are the meshes that are weighted for these bones) as in the corresponding skeleton, but instead of their local translation coordinates the only thing you will find in the mesh are their global coordinates relative to the skeleton root.

 

In the skeleton on the other hand you have both informations, the global position of each bone relative to the root, and their local translation or in other words their position relative to their parent bone as seen from their parent bone's coordinate system. Yep, that's right, every single bone in these skeletons comes with its own coordinate system or rather its own rotational basis (this is where the rotational matrix comes from). But don't worry, you don't have to do complicated math, you only need a little bit of spatial thinking. We just have to be aware of the fact that we can't just take some coordinates or rotation values and add or substract them all willy-nilly. In some cases we can but that can go wrong easily so we should make sure that what we're calculating actually makes sense. 

 

Some more in depth tldr stuff on local and global coordinates and how they are connected:

 

Spoiler

 

The next screenshot shows a human male skeleton stripped of everything except for the complete penis bone chain from the NPC root to the penis tip and the balls. I selected the NPC GenitalsScrotum bone and highlighted the global coordinates (position relative to the NPC root) in the upper right and the local translation relative to the parent bone in the Block Details in the lower left corner, for NPC GenitalsScrotum that would be GenitalsScrotumLag. Below that translation vector we can find the rotation matrix.

 

 

So how do we get from the local coordinate system of the GenitalsScrotumLag bone to the one of the NPC GenitalsScrotum bone, or from parent bone to child bone?

The local translation vector for NPC GenitalsScrotum is X=-0.0194 / Y=3.0329 / Z=3.2560  or simply (-0.0194/3.0329/3.2560)

That translation takes place in the local coordinate system of the parent bone, with GenitalsScrotumLag (the parent bone) being at the origin of coordinates.

Normally the x coordinate axis in Nifscope goes from the left to the right (if looking throught the eyes ... okay, through the eye sockets of the skeleton), the y arrow points from behind the skeleton towards the front and the z axis from below to above. Not so in local coordinates though, there the orientation can be completely off, just because of the rotation matrices of the parent bone and its parent bone and the rest of the bone chain up to the root combined.

In our case a local translation vector of (0/0/-10) wouldn't make the scrotum bone point downwards for example, instead it would point up and forward. We have to be aware of how our local coordinate system is oriented.

We arrived at that coordinate system by following the chain of bones from the root down to the GenitalsScrotum bone, moving our origin of coordinates with each step and then changing the rotation/orientation afterwards to get to the next child space which then is the parent space for the next bone in the chain etc.

 

Anyway, now we have the right position, but as mentioned above going from parent to child bone in a skeleton also means that the rotational basis might change. Meaning that if the rotation matrix isn't zero then we'd have to multiply that matrix to the product of all the rotation matrices of our chain of bones, from the NPC root down to GenitalsScrotumLag. To get back to global coordinate orientation (or global space) we'd have to take the inverse of the resulting matrix and enter it as our new rotation matrix.

Luckily we don't need to do that, we simply take notice if the rotation matrix is not zero so we know that vector orientations change when switching from the parent to the child space (parent space = local coordinate system of parent bone with said bone in the center).

 

 

Let's set up the HDT PE parameters for the balls now.

As I mentioned placing the collision box isn't as simple as for the shaft this time and we need both the translation vector (local coordinates) and the rotation matrix for the GenitalScrotum bone in the skeleton. We can just take the translation values from the Block Details in the screenshot inside the spoiler above, but the rotation matrix needs to be in Axis-angle format and not in Euler angles.

Because Euler angles aka 'Yaw, Pitch and Roll' (some might know that  convention from airplanes) are sensitive to the order they are applied in and as it happens that order is different in Just For Fun and in Nifscope. Meaning yaw(JFF) =/= yaw(Nifscope), instead yaw translates to pitch or roll. So doubleclick on these rotation matrix coordinates in Nifscope and change the text field from Euler to Axis.

 

Now we got the rotation matrix in axis angle representation. Together with the local translation vector:

 

translation -> X=-0.0194 / Y=3.0329 / Z=3.2560

rotation -> A=50.68 / X=0.98722 / Y=-0.14630 / Z=-0.06326

 

Now back to JFF.

 

 

RIGIDBODY SETUP

 

First we need to set up two more rigidbodies, one for the scrotum bone and one for its parent.

Again we get both their names from the male skeleton in XPMSE, NPC GenitalsScrotum [GenScrot] for the testicles themselves and GenitalsScrotumLag for the parent bone. We need a parent bone this time because this won't be a passive collision box with fixed position, it will move according to the constraints that we still have to set up in JFF. And for active HDT PE movement you always need a parent bone as an anchor or else the mesh will stretch to infinity, in this case the balls would sink into the ground (because that's the direction of the simulated force - gravity).

I will set up both with the same parameters as before except for the collision box and the Group ID, and the motion type in the case of the scrotum child bone (NPC GenitalsScrotum [GenScrot]).

For the sake of simplicity we will go without collisions for the balls, so the group ID has to be set to -1 for both rigidbodies (if you want collisions with thighs, butt, penis shaft etc then I won't stop you, I just don't think that the payoff is big enough for all the finetuning that's necessary). And for the collision boxes we will keep the default values, a sphere with radius 1 and no offset to the bone location.

The motion type for the parent bone has to be MOTION_KEYFRAMED again, and for the child bone it's MOTION_TYPE_INERTIA this time, the standard choice for all things that you want to see bouncing, jiggling, swinging or moving in whatever type of Havok-supported way.

Also set the mass for the GenitalsScrotum bone to 1. This parameter has a lot of influence on the constraints settings, our next item of business.

 

 

CONSTRAINTS

 

Now we are done with the rigidbody settings, let's proceed to the constraints for the scrotum bone, the thing that keeps it in check and near its parent bone (so the mesh doesn't disappear in the ground below your ingame character) and also provides all the necessary parameters for mesh position, basic rotation angles and movement behavior.

Open the constraints tab at the bottom of your JFF main window and click 'Add'. Now we could use Ragdoll constraints but that would constrain us too much (hehe), we don't just want the balls to rotate around axes, we also want them to bounce around a little. So we should change the type to hkpGenericConstraintData which gives us all the degrees of freedom that we need to create realistic movement.

Next choose 'NPC GenitalsScrotum [GenScrot]' for 'Body A' and 'GenitalsScrotumLag' for 'Body B'.

'NPC GenitalsBase [GenBase]' for B works too btw, because that's the parent of our parent bone and GenitalsScrotumLag doesn't add anything to that parent regarding translation and rotation.

Now under joint settings, we adjust the pivot that corresponds to the parent bone, which we assigned to body B.

There are other methods to set this up but I prefer to move the parent bone exactly on top of the child because that makes it easier for me to calculate the linear limits in the second constraints tab. Now that translation vector that we wrote down before comes in handy. In order to move the GenitalsScrotumLag bone on top of the GenitalsScrotum one we just enter the aforementioned local translation vector from parent to child as the joint coordinates for 'Pivot B'.

 

Next switch to the linear limits tab. The rotational basis of our parent bone is very badly aligned but this time we don't need to worry about that, because we'll just use the same settings for all three axes, X, Y and Z. Meaning we will ignore the 'Linear Basis B' setting and move on to the linear limits settings.

 

What we are setting up in this window is basically this:

 

Now the bone (inner cube) is supposed to stay inside of the linear constraints box, the walls of said box are the linear min and max limits, as measured from the bone location.

The bone in this case would be our child bone, GenitalsScrotum. We chose a sphere for the collision box so the child bone shape is not really a cube but this is just for illustration anyway. Then we have the springs that are attached to that bone. There are two springs on both ends of a linear motion axis, and there are three axes, meaning 6 springs in total.

The other ends of the springs are connected to the boundaries of our linear motion box.

Be advised that the bone won't necessary be in the middle of the box. It all depends on the limits I choose. If they are symmetrical for positive and negative values then the springs on both sides of the bone have the same length. If not then one of the springs will be shorter and the movement will probably look forced too.

As mentioned I used the joint settings to place the parent bone right on top of the child bone (at least as far as HDT PE is concerned). Now the mesh doesn't look distorted ingame and we can still use symmetrical linear constraints so the two springs per axis have the same length and strength and the movement pattern will be nice and symmetrical too.

If I did it differently then the springs will have different lengths and the child bone will very likely be under constant high spring tension so the movement will look forced and unnatural.

Also gravity comes into play here, and with our chosen joint values (the translation vector that we copied from the skeleton) the child bone won't be in the middle of the box if the character is standing still, meaning the mesh will look a bit stretched downwards (gravity pull applies constant force on the springs).

To counter this we should reduce the joint values a little, so our new Pivot B settings are X=0 / Y=2 / Z=2.1

The translation vector in this case is parallel to the grvitational pull so it makes sense to just reduce it to two thirds of its length to offset that effect on the springs and get the scrotum mesh back to the intended shape.

 

Now with this in place we can simply use the same symmetrical linear limits and spring settings for all three axes:

 

The springs are simulated through the hkpSpringDamperConstraintMotor option for the 'Linear Motor' settings. Enter the same values for the spring constant and the spring damping of all three motors as in the screenshot.

Spring constant is self-explanatory -> F(x)=k(x)*X, F(y)=k(y)*Y, F(z)=k(z)*Z

Damping isn't that mysterious either, just remember that normally you need a number that's one or 2 magnitudes below the spring constant setting. Finding the best value is a matter of extensive testing, and of taste I guess.

 

Now the only thing left is the angular limits tab. This is where we finally have to enter the rotation matrix from the skeleton, and in axis angle notation.

Again it's the parent bone we have to adjust here, because in contrast to its function in the skeleton it's just the pivot or anchor here, the thing that our actively moving child bone needs as a reference for its idle state. So we take the orientation (rotation) of said child bone from the skeleton and enter it as the angular basis for the parent bone. The parent bone's own rotation matrix in the skeleton is irrelevant, HDT PE already got that orientation from the Havok engine or doesn't need it for its calculations (beats me tbh). After this is set up the mesh shouldn't be doing anymore what it did if you were curious and used the xml in its current state, bend forward. Instead it should look like it does in Nifscope or when you open the ingame console (which deactivates HDT PE).

Enough talk, let's enter that rotation matrix:

 

Now 'Ok' everything and save the xml.

If you want to earn bonus points (and maybe get a little better movement patterns) copy the values from the angular rotation matrix to the linear basis that we ignored earlier (in the linear limits section of this post). This way the linear limits axes there won't point in weird directions but actually up, down and to the left/right. Don't expect the linear Z axis to be the vertical one ingame though, I think it's in global coordinate y direction instead. Also don't expect this to always work for every skeleton/mesh. Often the rotational matrix for the child bone doesn't send us to a coordinate system that has axes parallel to the global ones. In those cases if you want to use different linear constraint settings for the different axes you either have to guess the linear limits basis or might want to use another little Nifscope trick. Open the skeleton in Nifscope and copy the child bone in the Block List in Nifscope (Ctrl+C) and paste it (Ctrl+V) directly onto itself, so the copy now is the child of the original child bone... let's call it grandchild.

 

Then just try and change the rotation matrix for the original child bone (which is now the parent of our test setup) until you get to an orientation that somewhat aligns with the global coordinate system. Also change the grandchild translation vector so it only has one non-zero entry.

Since the yaw, pitch and roll notation (Euler) is easier to visualize you might want to use that and see what changing one of these parameters does to the grandchild orientation.

 

...

Of course you can also set up angular movement limits and motors and the balls will swing even more realistic then. The basic principle is pretty much the same as for linear constraints (the graphic I drew up there doesn't apply for this of course). Just choose these angular X, Y and Z limits with caution, and don't pick values higher than -1 to 1. In fact start with values of +-0.1 and increase in steps of 0.1 if you are not satisfied with the amount of swing and twist.

The springs have to be adjusted too. A spring constant of 200 might still be good enough but the damping needs to be set a little higher, maybe to 10 or even 50.

To get a ballpark figure for the spring constant you can take a look at the values inside the inertia tensor (rigidbodies - GenitalScrotum bone). The lower these values are the easier it is for the spring to accelerate the bone or (with those six springs surrounding the bone) slow it down and get it back into its initial position if it wasn't there before. So the same torque will cause higher angular acceleration and the mesh will swing about faster, which means that the lower the inertia tensor values the lower you can set your spring constant. A lightweight bone doesn't need strong springs to keep it under control.

But there are other effects that complicate things. Like if the spring constant is set very low then the bone will just bounce back and forth between the angular limits really fast, like a pendulum possessed by a poltergeist.

The reason for that is the fact that these springs inside the angular and linear limits boxes are not the only thing moving the bone. The character also moves when going through an animation, be it an idle, running, jumping, combat, sex or whatever. And these animations also accelerate the bone relative to its parent. If the springs are set too weak then they won't be able to effectively counter these animation-induced accelerations and the bone will bounce around inside the constraint limits like crazy.

Now to counter that you can set the damping higher, but that can have the negative side effect of the mesh settling down in weird angles if the spring constant is very low. That's especially true when the inertia tensor also consists of smallish values.

So you need a spring constant that fits the inertia tensor values of your moving bone and a damping parameter that's high enough to bring your mesh to a halt after a few moments of bouncing, but not so high that the mesh hasn't enough time to swing back in its initial position.

To make matters even worse there are heavy interactions with the linear constraints, both types of springs also influence the other movement type (angular motor settings influence linear movement and vice versa), so in many cases your best bet when setting up these angular spring parameters is dumb trial and error.

But in the end using generic constraints is still the best option if you are aiming for realistic looking movement patterns.

 

Just remember that your xml setup for these bones isn't the same as in the skeleton. If you set it up like I did then the parent usually serves as the initial position marker, so its joint, linear and angular parameters put it where the child bone is in the skeleton and also give it the rotation matrix of the child bone space. In other words the parent bone sets up the position/orientation of the boundary box from my selfmade graphic up there. The child bone parameters then determine how the child bone behaves inside that box (initial position in the box - middle is best, neutral/initial orientation that the springs want to get it back to, spring constant, damping etc).

 

Good luck with this and you're welcome for the headache.

And if you find mistakes and other things I got wrong in this way too longwinded post then please keep them tell me.

 

[Bazinga]

Other things to keep in mind / random stuff that I just put here and maybe rearrange later:

 

The joint settings for pivot A and B inside the constraints don't apply to the same coordinate system. The joint vector for pivot B is written for the rotational basis of bone / coordinate system B and the one for A uses A's rotation matrix.

 

So if I wanted to use another approach and move the child bone on top of the parent one instead of the other way around then that would work too, but not with the joint vector (0 / -2 - / -2.1) but with (0 / -2 / 0). Because the child bone, GenitalScrotum, has a basis in which the Y axis points downwards, which is where the balls should be relative to the GenitalsScrotumLag bone (the parent).

Dunno why it isn't (0 / -2.9 / 0) though which would have the same absolute value as (0 / 2 / 2.1). Differences on how or when gravity is applied? Distance to mesh surface, changing the influence the bone has on the mesh? I honestly don't know.

...

Okay, I just tested this and for some reason the results are a little better than with the approach I took in post 2.

This is a SOS RegularPlexus xml where the joint is applied to the GenitalsScrotum bone.

hdtm_VPregular1.xml

And this is one where I entered that parent-child joint offset for the GenitalsScrotumLag bone like I suggested in post 2.

hdtm_VPregular2.xml

 

I see a small difference there, the bouncing and swinging looks very similar (imo slightly better for setup 1) but in the one from post 2 the mesh sometimes bends to the side a little. It doesn't do that in the other setup...

 

Too bad I can't look under the hood of this, all my knowledge is basically deduced from trial and error testing in the different programs I used (JFF, Nifscope, sometimes Outlook Studio, Skyrim itself)...

 

The penis shaft rigidbody is different from post 1 btw, I didn't bother to change it from my own xml set. Doesn't make much difference though.

[Bazinga]

I added the resulting xml and a few thoughts in post 3. There might be more to come. If someone has more insight into this stuff then please come forward and share your knowledge. The whole intention of this thread is to give some more useful and indepth explanations of how HDT PE works and how to write xmls so any additions are appreciated. 

I literally had to figure most of this stuff out on my own and wasted months of time until I had a grasp of it because I couldn't find much more than uneducated guesses and superficial bs about the inner workings of HDT PE.

And I think that lack of information is one of the reasons why havok physics modding isn't much of a thing outside of the Far East... I always wondered how they do it over there. Maybe their communication on this front is less superficial.

 

Anyway, would be cool if the mods could pin this btw, provided that people can actually follow my train of thought.

[Bazinga]

Okay, since there are no complaints so far (feedback is welcome btw, even if it's just "I don't get it" because then I might try to rephrase whatever you didn't get) I decided to complicate things even further.

Remember how I wrote this:

Quote

For the sake of simplicity we will go without collisions for the balls, so the group ID has to be set to -1 for both rigidbodies (if you want collisions with thighs, butt, penis shaft etc then I won't stop you, I just don't think that the payoff is big enough for all the finetuning that's necessary).

So I'll ignore my own advice and just add testicle collisions anyway. The following part of this tutorial should be especially interesting to all the people that asked me to add more collisions to my mods, like Riekling hands for Beast HDT.

 

So now let's see, which collisions would make sense here? First we will prevent the balls from clipping through the schlong when bouncing up and down. So far I achieved that by just setting the constraints limits narrow enough but why not use collisions instead.

 

We'll begin by choosing a group ID in the rigidbody settings of our GenitalsScrotum bone. You can bet that the balls will stretch in ugly ways with hands and dicks nearby if we just use something like 2,3 or 7 as group ID, like the other things in my mods that interact with the penis and hand collision boxes.

Or don't bet, have a look instead:

Here's how it looks with the GenitalsScrotum bone in group ID 7 and the "no collide with" checkbox for group 0 unchecked. I also extended the Genitals06 shaft collision box a little (-4 to -12 instead of -4 to -8).

 

benis.mp4

 

... and here without collisions:

willynilly.m4v

 

 

So we have to change something, either in how we set up the schlong collision box or the balls.

...

 

tbc

[Reesewow]

I don't really have much to say other than thanks very much for putting the work in for this.  It isn't something I need right now, but I guarantee that if in 6 months I want to manipulate an XML in JFF or make something new from scratch for a mod or personal use, I'll be coming back here. 

 

Great to see that it is pinned so that I should be easy to find without bookmarks - this topic can be really hard to get concrete good advice on through google searching.

 

 

 

 

[Bazinga]

Thanks, @Reesewow

 

I'm still not sure if it even makes sense to write this because without a working version of HDT PE for Skyrim SE in sight I expect everyone to switch to SMP sooner or later. So while I usually don't really care for moral support in this case it's appreciated.

 

 

Anyway, I tested a few things and this is probably my final result for this xml with collisions with the penis shaft and the thighs included:

hdtm_VPregular.xml

 

I started with setup 1 from my third post (the one where the joint is applied in a slightly different way than I explained before).

Like in the first post of this tutorial the Genitals02 bone is the one responsible for collisions with females now (can't also have collisions with the balls on that bone, see the videos in my last post), I added Genitals06 and both thigh bones to get the collisions with the balls. All three bones are in collision group 10, colliding with group 7. The balls themselves are now in group 7, but only colliding with group 10 so there is no interaction with the female collision boxes, the hands, arms and Genitals02 (because all of them are in collision groups that are checked in the 'no collide with' settings of the GenitalsScrotum bone.

I also changed the shape of the scrotum collision box from sphere to capsule because I expect to get a little more twist in the balls then (length 2 and radius 1 in X direction, meaning left and right - global X too in this case). And I changed some constraints settings, like the linear limits and spring damping (increased all of them I think).

I'll explain later how I set up the Genitals06 and the thigh rigidbodies and the collision shapes therein, don't have time for this atm.

[Bazinga]

Ok, now let's wrap this up before I leave for summer vacation and forget about it completely. ^^

 

First while testing the xml I just realized that for some reason the schlong collision boxes don't get applied properly when loading a savegame with a naked male character. You either have to equip and then unequip an armor or use the showracemenu console command.

Seems like a scaling issue because the collisions are still there, the collision boxes are just way too small. I suspect that it's a problem with different mods loading on the fly and SOS scaling getting applied after the xml is already loaded. Then you probably have collisions for a size 1 schlong instead of the actual size.

... Stupid freaking unstable overmodded POS mess of a game. 

 

Anyway, back to the additional collisions I added in the last iteration of this xml:

 

Now as I mentioned I moved the schlong - female body collisions back to bone 'NPC Genitals02 [Gen02]', the one I used in the first post. So everything there still applies.

What's changed is that I used a slightly different joint for the scrotum constraints than in post 2 (see post 3 for more details) and that I added 3 more static bones to the rigidbodies.

'NPC Genitals06 [Gen06]' gives us schlong scrotum collisions, while the two thigh bones add collisions between scrotum and thighs. Obviously.

 

Now while I could explain the NPCGenitals06 bone setup in the same simple way I used in the first post I won't, because in this case we also need a small Z axis offset and that's where the local and global coordinate systems differ.

The y axis orientation is still the same as in global coordinates, so I could simply enter -10 and 0 (0 is where the Genitals06 bone is on the y axis - in the local coordinate system of said bone) for Vertex1(Y) and Vertex2(Y).

But the Z axis (vertical axis) is backwards in local coordinates, meaning plus is down and minus is up. And that's why I entered a -2 offset there for both vertices, because as we saw in the above video placing the collision box at the same height as the bone brings us too close to the testicles.

 

On to the thighs:

Here's another "gutted" male skeleton, this time I only left the thigh bone hierarchy intact.

 

So your first instinct might be to use the NPC Calf bones because their vector is where we want the collisions at. Because mine certainly was, but that makes things overly complicated and you shouldn't do it.

Btw, the line we see in Nifscope is actually a vector connecting the parent bone, in this case 'NPC L Thigh [LThg]', with the child, 'NPC L Calf [LClf]'. The actual "bone" is the point at the end of that vector. Just in case you didn't already know.

The problem here is the rotation matrix (I highlighted it, together with the local translation coordinates), because if you use the NPC Calf bones then whatever you enter as vertex coordinates under Collisions -> Shape will get applied in the local coordinate system of that Calf bone. So you also get the orientation change from the rotational matrix. You can check for yourself by doing what I did in post 2, copy the bone onto itself and see where the new child points at.

Like this:

Doesn't look too bad but you can see that the orientation changed. So if we want to place our collision box using the original calf bone (parent in this picture) then a vertex Z coordinate of -35 wouldn't bring us close to the hip but somewhere behind it.

So we won't use the NPC Calf bones but the thigh bones instead.

See how I cut off the local translation vector and the rotational matrix this time? That's because they don't matter, we already know which coordinates we want to use. As I said we want to follow the path of the child bone vector, NPC L Calf. The local transformation that would get us there was (0, 0, 35.6).

So when we use the thigh instead of the calf bone we can simply enter 0 and 10 as vertex coordinates for the Z axis and leave X and Y at 0. We don't need to prolong the thigh collision box down to the calf bone location, so 10 instead of 35.6 is fine.

The resulting XML parameters for the thighs will look like this:

The radius is a result of simple trial and error, there's not much thought put into it beyond that.

 

Well, that's all for now.

If there are any questions then don't hesitate to ask. Maybe I can help, maybe I can't, but I promise I will try.

[Rygus]

Great explanation you confirmed quite a bit for me. Right now I'm having trouble getting my char's upper arm/biceps and forearms to collide with her breasts. Any help you can offer? I have the collision checkboxes right, I think the arm shapes are good. I have no problem with the hands colliding with breasts either.

[RomeoZero]

On 5/16/2018 at 11:44 PM, Bazinga said:

Ok, now let's wrap this up before I leave for summer vacation and forget about it completely. ^^

That is a nice tutorial Bazinga,but it lacks a lot of basic stuff also.There's a lot to cover just on the axis coordinate itself and its pivots. 

First thing that I noticed back in 2013, is the Skeleton itself is in wrong axis (-180 on rotation).Because of the object space map coordinate system they chose I assume. Of course no rigged object physics in the game is present with such coordinates (-x, -y, z ) ~ tis quite hard to write the data for xml.

 No wonder you got the same .."do not understand hows this shit's working"  issues with translate\rotate and pivots for the binded bones, and especially creating some new bones for JFF data, like I did back in the day creating hdt stuff ?

[Koalmex]

Thank you for your great work
I have a doubt
How can I see the XML modifications without closing the game?
The XML is updated without having to close the game because it is very annoying.

[Guest]

is there a way to make the collision points scale in line with the Sliders in bodyslide for breast

[Guest]

Hi Bazinga, first of all I want to thank you for your tutorials and files. I have been messing with those PE files myself and tried to fix some of the KS Hairdo files. The thing that doesn't work is that if I assign the spine bones to the collision group 2, with collision activated with group 16 and leave the tail of the hair at collision group 16, with collision set up to collide with group 2, no collision is happening. The tail goes through the body. When I assign the tail to the collision group 0 Default collision is working fine. I know that the 0 group collides with everything but I would rather like the spine bones to be at collision group 2 so that they aren't at the same group as the genitals for example. Is it so that some collision groups e.g. 2 are not working?

 

Thank you in advance!

[Bazinga]

Sorry, I didn't really follow this thread and missed the last few posts.

@SilverBlack

Group 0 doesn't automatically collide with everything. It's just set up like that in most xml files.

And the hair in your example should have collisions with the spine. Are you sure that you also placed and dimensioned the collision boxes correctly?

Maybe the orientation is off or if it isn't centered on the bone and shifted in the wrong direction.

 

edit:

Come to think of it you might be right, I can remember there being some issues with group 2. Probably one of these nasty JFF bugs where it doesn't translate your input to the xml correctly. Maybe try another group then if you didn't already.

[Guest]

Hi Bazinga, thanks for the input. I will try that. Is there a way to somehow see the collision boxes in 3dsmax? Because sometimes it is hard to find the right shape for those boxes by just using the skeleton and the mesh. Another question: I don't know anything about scripting but how would I add mods to your HDT Toys e.g. the psyche animation toys?

[Bazinga]

I don't know of any way to load these xml files into 3ds Max, sorry. Doesn't mean that there is none, I just don't know it.

 

You could probably visualize and edit the shapes with Havok Content Tools, but I never tried that myself.

I really just opened skeleton meshes in Nifscope, added bones and played around with them (read: changed their coordinates to find the x, y and z orientation of this particular parent bone space). After that it was a LOT of trial and error ingame, but with practice I also got faster and needed fewer tries.

 

For HDT Sextoys see here.

[Lux77]

Can this work for clothes?

[Bazinga]

13 hours ago, Lux77 said:

Can this work for clothes?

Of course.

But there's an extra step. You have to make sure that the clothes are weight painted for the bones that you set up collisions for... or rather for the bones that are set to motion_sphere_intertia or some other motion type setting for bones that are not static in the context of HDT PE.

Basically in the same way that the body meshes are weight painted for the non-static bones in my examples above.

 

But weight painting is a science of its own, and quite difficult to get right.

[Lux77]

16 minutes ago, Bazinga said:

Of course.

But there's an extra step. You have to make sure that the clothes are weight painted for the bones that you set up collisions for... or rather for the bones that are set to motion_sphere_intertia or some other motion type setting for bones that are not static in the context of HDT PE.

Basically in the same way that the body meshes are weight painted for the non-static bones in my examples above.

 

But weight painting is a science of its own, and quite difficult to get right.

yeah but boneweighting is no issue...the mesh isalready properly weighted to skirtbones and legbones...what i would love to achieve is a no clipping or streetching version,without the use of 3dsmax...(which unfortunately isnt free,and the right versions are no longer eligible for student version)

So you think it's possible to do from blender + these tools?

[Bazinga]

Sure, it might even be possible with just Outfit Studio.

But the interface for that program is terrible, especially camera adjustments, so Blender or 3Ds Max might be a better choice.

 

I never made any HDT clothes or armor though so I'm probably the wrong guy to ask for details about how to do it.

All I know are the basic steps.

Clothes might need more complicated HDT xml setups to look realistic when moving than what I dealt with above.

[Submaxie]

On 4/1/2018 at 4:02 AM, Bazinga said:

Now what to do with these vertex parameters?

For that we have to first open the penis mesh again.

Now we'll screw with the mesh so we can obtain the measurements that we need. Sadly Nifscope 1.1.3 doesn't allow us to simply click on a mesh surface and take the coordinates from there

This is possible in Outfit Studio. In outfit studio you can hover the cursor on the surface of the mesh and it will give you the coordinates of the vertex. In the image the green dot is the vertex. This is a faster and easier method of obtaining the coordinates. 

Spoiler

 

[Bazinga]

True. I simply didn't want to introduce another tool/program but you're right. When you measure it like this you still don't know where the bone is relative to the mesh surface though. And it seems like these vertex coordinates don't exactly align with the bone coordinates (one has the origin of coordinates above the mesh, the other below it) so you can't compare them without an extra step.

Also using global coordinate differences/offsets only worked in this case and will not in many others. Depends on the local coordinate system of the bone that you want to attach the collision box to. So in a lot of cases you will probably need Nifscope to get the correct vertex coordinates for the xml.

 

The xml vertex values have nothing to do with the mesh vertices btw ... except that the collision box should ideally have the right size to add collisions somewhere near the mesh surface.

 

Which brings me to another hint:

Nifscope 2 is better than 1.1.3 because it shows the local coordinate system for the selected bone. So no more need to copy bones on top of themselves and changing coordinates just to see how it's oriented.

You can also check mesh vertex coordinates in Nifscope 2 but it seems like you have to click directly on the vertex to select it and these things are small as fuck.

[bigglebojiggle]

I was wondering if anyone can tell me if this will work, so I have my character set up for hdt collisions, but, I didn't really like the way the breasts act so instead, I used JFF to create a separate hdt file for belly collisions, and left the breast data in the original hdtPhysicsExtensionsDefaultBBP.xml file. Basically, I removed the breast data when I loaded it into JFF, then saved the belly info as a separate file, then removed the belly info from the original. The femalebody_1.nif has 3 hdt files attached, I removed one that I didn't want, and replaced the hdtPhysicsExtensionsDefaultBBP.xml with my custom, hdtbELLY.xml (made a dumb capslock mistake typing, but whatever). Everything seems good so far, breasts are bouncy and seem to respond correctly to fingers, all good. Vagina works correctly. Stomach though, I can't tell. No bulge that I can see. Will it work by creating my own file like I did?

 

 

I'm uploading the file I created if anyone wants to look at it. As far as I can tell, all collision data for belly and penises ect, is set up correctly.

 

hdtbELLY.xml

 

Edit: Well, it was working, and then I made the mistake of letting MO reorganize my load order and now it doesn't, yay!

 

Edit2: Yeah, it was just the hdtfingers.xml giving it issues, works fine without it

Edited November 27, 2021 by bigglebojiggle