A Guide to HDT-SMP Users/Modders

treota · February 14, 2016

Disclaimer: Some of these links are to LoversLab, I apologize if this offends anyone but most of the resources for SMP are only available there.

What is HDT-Skinned Mesh Physics?, essentially it's a better version of HDT-Physics Extension originally developed by the lovely HydrogensaysHDT (open source now).
SMP solves a lot of the issues that PE had, spazzing mesh, inaccurate collisions etc. SMP is based on Bullet and can handle much higher force without breaking. Simulates physics better to boot.

The one stop drop 'n' shop

Legendary Edition - Just install BHUNP, this should get body and clothing physics for most mods

https://www.nexusmods.com/skyrim/mods/100306

Special Edition - Install either of CBBE or BHUNP they should be all you need to get clothing and body physics for most mods.

CBBE 3BBB https://www.nexusmods.com/skyrimspecialedition/mods/30174

BHNUP https://www.nexusmods.com/skyrimspecialedition/mods/31126

If everything works as desired after installing any of the SMP bodies then there is no need to read any further.

First time user recommendations:

If this is the first time you are trying SMP I would highly recommend doing the following benchmark first before going any further.

Use a mod organizing tool (Mod Organizer is my recommendation)
Create a fresh install of Skyrim
Install SKSE manually, i.e not with your mod organizing tool
Install HDT SMP manually, i.e not with your mod organizing tool
Install XP32 Maximum Skeleton (might not be required if your mod comes with a physics skeleton)
Install one mod that uses SMP to test with (bodies are good for this, e.g. CBBE SMP)
-- Install Bodyslide if you are testing with a body mod, make sure to build the Physics or SMP version of the body

If the above configuration works and you have physics enabled, you are good to continue; if not then you may need to check if your hardware is compatible with SMP's requirements.

Basic Setup:

OpenCL 2.0:

If you are on Windows 10 and have an Intel CPU/GPU you probably can ignore this
Nvidia, try these https://software.intel.com/en-us/articles/opencl-drivers these will only work if you have compatable Intel CPU
AMD, drivers here http://support.amd.com/en-us/kb-articles/Pages/OpenCL2-Driver.aspx
OpenCL 2.0 was a requirement for HDT-SMP, while there is an option to turn off OpenCL simulation in the configs.xml the engine will crash without it, this option actually just sets SMP to use CPU rather than GPU calculation
OpenCL 1.2 seems to be workable with newer versions of SMP, have tested with NVIDIA 1080ti with encouraging results

HDT-SMP:

Special Edition

SMP has moved to open source, you can find a fork here that intends to continue work on the plugin https://www.nexusmods.com/skyrimspecialedition/mods/30872?tab=description
CBBE has support for SMP, the description also contains a link to the DLL files required https://www.nexusmods.com/skyrimspecialedition/mods/29023
SE version source, have used it with relatively few issues so far https://github.com/HydrogensaysHDT/hdt-skyrimse-mods

Legendary Edition (oldrim)

BHUNP is your friend, this is all you will need to get body & clothing physics for most mods https://www.nexusmods.com/skyrim/mods/100306
You can get the packaged files here http://www.loverslab.com/files/file/1817-hdt-skinned-mesh-physics-tutorial/ HDT-SMP.7z, this is recommended as it comes with useful xmls and the current SMP files as well as some further reading/watching tutorials and test mods.
This post explains the file structure very well http://www.loverslab.com/topic/45034-prepacked-hdt-sm-hdt-skinned-mesh-physics-with-modding-guide/page-1?hl=hdt-smp and tells you how to navigate the thread on 3dmgame
Source, you can get the files directly from Hydrogensays here at the first link http://bbs.3dmgame.com/thread-4497700-1-1.html

Requirements:

A HDT weighted/skinned body (PE or SMP) such as UN7B or SE CBBE should you wish to have jiggles and wiggles, you can safely remove any xml files that come with the HDT-PE bodies
Mods using SMP, there are a few around http://bbs.3dmgame.com/thread-4874470-1-6.html, seems to be a list of SMP related mods, it's in Chinese though
Any BBP / TBBP / HDT armor (Note that for these to work you will need to add whichever body shape name in your defaultBBPs.xml), e.g. Dwarven Bikini armor UN7B conversion uses UUNP as its name for the body's shape so just add an entry to defaultBBPs.xml pointing UUNP to your definitions file
Groovtama's skeleton XPMSE, make sure nothing overwrites this unless you really know what its doing (use ModOrganiser for sanity's sake) (not strictly necessary but it's the most usable skeleton)

Incompatibilities:

HDT-PE if using it for the same thing as SMP (notably KS hair HDT, applies PE to the body in order to have the hair work)
Floating damage text, this mod seems to break the SMP dll somehow

Troubleshooting:

If your physics log contains this error: xml parse error - not a float value then your os is probably trying to use comma notation for decimal numbers. Easiest solution is to change your os language to a dot notation equivalent (ENG_US is the simplest one).
In configs.xml change <opencl> -> <enabled> to false to use CPU calculation if your card does not support the appropriate OpenCL version
Blue textures - open hdtSkyrimMemPatch.ini, change fasterLoading = true to fasterLoading = false
Odd physics issues, try limiting your frame rate to 60 or 30 with enb settings/vsync or other such frame limiters
Try disabling other mods that use dll files, they might be conflicting with SMP
If you are using an operating system language that uses ',' for decimal notation you will have to either convert all xml files to comma notation or change your system language to dot notation (e.g. en_us)
User DartRevan has some troubleshooting tips here: https://forums.nexusmods.com/index.php?/topic/7504581-skyrim-le-se-strange-bugs/
You may need to install vc++ runtimes if you do not have them already. https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads

Body mods:

Special Edition

CBBE SMP, Demoniac (SMP supported skin texture)
CBBE 3BBB (different skeleton configuration)
BHUNP SSE

Legendary Edition (oldrim)

Further Reading:

Converting HDT-PE armor to SMP: https://www.loverslab.com/topic/89576-10-minutes-or-less-guide-to-making-your-entire-hdt-pe-armor-library-jiggle-with-smp/

If you have followed the above correctly... Nothing will happen :hurr: (probably, for the body at least. Clothing mods will work now and CBBE SMP is good to go out of the box).

Advanced Setup:

Here we tell SMP what to work on, for Mod Organizer users: do not try to modify files directly in the Mod Organizer directory if you installed it in Program Files, this will seem to work but it really wont (running NifSkope as administrator might fix this).

Linking Files:

NifSkope
Open your body mod (femalebody_1 or _0, the two files are for skyrims weight slider, both should contain the same data) in NifSkope
Click on the body mesh, this should highlight the node associated with the mesh, take note of the Value (Txt value) or change it if you wish by clicking the (Txt), this is your mesh name and is case sensitive (name != Name)
Also take note of the name of any alternate mesh/NiTriShape's that you may wish to apply physics/collisions to

There are two ways to do this:
Insert a NiStringExtraData block with the name: HDT Skinned Mesh Physics Object and the string value of the path to your xml file (-Data) e.g. SKSE\plugins\hdtSkinnedMeshConfigs\foo.xml, this is usually what you would use for clothing/jewelry etc as you don't want to be constantly overriding the defaultBBPs.xml
or
Open SKSE\plugins\hdtSkinnedMeshConfigs\defaultBBPs.xml add a line (or change one)

<map shape="your mesh name" file="path to your xml (-Data)"/>

if you want absolute default physics for body meshes change this:

<map shape="BaseShape" file="SKSE\Plugins\hdtSkinnedMeshConfigs\default-cbbe.xml"/> 
<!-- to -->
<map shape="your mesh name" file="SKSE\Plugins\hdtSkinnedMeshConfigs\default-cbbe.xml"/>

If you use one of the other default supported bodies then link your body to the appropriate default xml.

A somewhat incomplete list of body shape names: https://docs.zoho.com/file/1tnhp1fc8e67ed2a04e349b3568ce1b90cf7a

You can have multiple meshes/NiTriShapes point to the same xml file and define their individual characteristics in said file, could be useful for grouping common physics objects together such as two different sets of earrings pointing to a single jewelry.xml, however I have found it easier to just name common NiTriShapes the same thing and then just define the physics calculations once e.g. name both pave and bezel "earring" then define physics in earring.xml (assuming both earrings have the same physics properties of course).
At this stage everything should be working, although you could probably calculate orbital mechanics with the bounce :laugh:, and collisions will not be working with hands or other such extremities.

Collisions for the explorative learners:

ledo4ek provides his own xmls and a fairly easy tutorial on getting collisions working here http://www.loverslab.com/topic/45034-prepacked-hdt-sm-hdt-skinned-mesh-physics-with-modding-guide/page-15?do=findComment&comment=1335127 (Warning, there is some graphic content in the posts).

If you wish to skip ahead a bit and get collisions working with various body parts, use the knowledge you have gleaned so far and check out ledo4ek's fantastic xml files, pay attention to the hands_1.xml and labia.xml (this ones a bit more in depth as it has bone definitions).

Edited April 30, 2020 by treota

treota · February 14, 2016

Reference:

This is described from the point of view of the camera behind the player character, e.g. z+ would be moving in the direction the character is facing.

Translation:

X: Left <> Right

Y: Up <> Down

Z: Forward <> Back

Rotation:

X: Pitch

Y: Yaw

Z: Roll

Arrows indicate positive direction, e.g. <angularUpperLimit x="1.57" /> would allow your constraint to rotate 'down' by ~90 degrees.

Units:
Translation: ??? (these seem to be reasonably small, e.g. you will be working in values under 10 usually).
Rotation: These are in Radians

Proxy Objects (a very brief overview):

Proxy objects are a piece of geometry (mesh) that can be defined as a collision body (can collide with other things), this mesh is attached (weighted) to a specific bone or set of bones on the skeleton.

Proxy objects let you provide lightweight and targeted collision areas that give you reasonable collision simulation without destroying your processor, they also let you isolate specific objects that you want to collide with others.

There are two major versions of these (based on the attributes bone they are attached to):

Static Object:

These could be pictured as 'walls', objects that move along with the skeleton and bash into other things causing the other objects to move around.

Movable Object:

These could be pictured like a 'computer mouse', move the mouse around and the cursor on your screen also moves. When these objects collide they also move the attached bone around with them.

Example (static):

Let's say you wanted to have your characters skirt collide with your upper legs but not your characters waist / lower legs / chest etc, we could create a simple tube with minimal geometry that covers the upper part of our characters legs and moves

with the upper leg bones (static), this tube would then be our collision object that the skirt collides with on behalf of the body. (thus a 'collision proxy' or 'proxy object')

This skirt happens to not be long enough that it would ever collide with our characters lower legs so we have no need to model the collisions that far down, should we need to then we could just add another set of proxy objects to the lower legs as well.

Defining your Physics:

Here we get to the meat and potatoes of SMP, telling your mesh/bones what to do within the physics simulation. For the sake of this section lets assume we are working on the hands mesh and we have linked said mesh to handsOfArbritraryNamingConventions.xml

Collisions

These are the "easy" ones, all we need to do here is define to SMP what mesh we want to be a collision object, what type of object we want to use, and what we DON'T want it to collide with.

For starters, the simpler of the two, note that all xml files need to have the <?xml > tag and the <system></system> tag, place your declarations inside the system tags.

<per-vertex-shape>:

<margin> (float): how much padding is added to your mesh when calculating collision, this will cause your mesh to act on physics objects "before" it intersects with them

<shared>:

public [default] - can collide with another object if not otherwise prevented, e.g. via tags

internal - can collide with an object from the same skeleton only

external - can collide with an object from a different skeleton only

private - can only collide with the same mesh

<tag> (string): an itentifier for this mesh collision object for use with no/can collide tags

<no-collide-with-tag> (string): prevents this collision object from colliding with the specified tag, note that this will not prevent the specified object from colliding with this unless also defined on the other colliding object, no colliding with itself is fairly common and is a good standard unless your mesh does in fact collide with itself (multipart earring perhaps).

<no-collide-with-bone> (string): will prevent collisions with mesh skinned to bones, could be useful if you wanted the hands to collide with the body but not the belly although in that particular case the proxy objects give better results.

<can-collide-with-tag> (string): inverse of no-collide-with-tag

<?xml version="1.0" encoding="UTF-8"?>

<system xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="description.xsd">

<per-vertex-shape name="hands_1">
<!-- name here refers to the name of your NiTriShape, find this in your body mods femalehands_0/_1 or malehands etc -->

    <margin>0.8</margin>
    
    <shared>public</shared>

<!-- <priority>1</priority>
     Priority is deprecated and no longer used
     how much resource is allocated to this collision object in a multi-collision scenario -->

    <tag>hand</tag>

    <can-collide-with-tag>feet</can-collide-with-tag>

    <no-collide-with-tag>hand</no-collide-with-tag>

    <no-collide-with-bone>HDT Belly</no-collide-with-bone>

</per-vertex-shape>
<!-- per-vertex-shapes are the simpler and faster collision objects. Obviously that comes with the drawback of less accuracy -->
<!-- vertex is good to use for "dumb collider" type objects, like a bat or a hand, things that don't really need physics calculated on themselves -->
</system>

On to the second type, let's use the body as an example in body.xml or default-cbbe.xml etc.

Note: 27X points out that "prenetration" here was probably meant to be bullets "penetration" property.

https://www.loverslab.com/topic/86382-hdtskinnedmeshphysics-explainedlatest-binarys/ - Though this list appears to suggest that both are valid :smile:

<per-triangle-shape>:

<tag>

<no-collide-with-tag>

<no-collide-with-bone>

<can-collide-with-tag>

see per-vertex-shape

<penetration> (float): how far your mesh can be inside another while still applying collisions.

<weight-threshold bone="(string)"> (float): weight threshold lets you restrict which verticies/points deform and collide in the specified area only points with a weight value higher than this threshold will act on collisions.

<per-triangle-shape name="BodyName">
    <margin>0</margin>

    <penetration>0.05</penetration>

    <shared>public</shared>

    <tag>Body</tag>
    <no-collide-with-tag>MaleBody</no-collide-with-tag>
    <no-collide-with-tag>Malehands</no-collide-with-tag>
    <no-collide-with-tag>hand</no-collide-with-tag> 
    <no-collide-with-tag>Body</no-collide-with-tag> 
    <no-collide-with-tag>Belly</no-collide-with-tag>
 
    <weight-threshold bone="HDT Belly">1</weight-threshold> 
    <weight-threshold bone="NPC Belly">1</weight-threshold> 

</per-triangle-shape>
<!-- triangle-shapes are best for mesh that needs highly accurate simulation, such as the body -->

It should be noted that traingle->triangle collisions are very demanding and somewhat inefficient, its always best to have vertex->vertex or vertex->triangle, it should also be noted that the more collisions you have the more performance hungry the system will be.

Collisions with the ground:

<per-triangle-shape name="VirtualGround">
    <margin>0.5</margin>
    <penetration>10</penetration>
    <tag>ground</tag>
</per-triangle-shape>
<!-- This is in the xml tutorial that comes with the packaged files, this is usually added as a flat plane attached to your skeleton that acts as as the 'ground' -->

By default collision objects collide with all other collision objects, it is highly advisable to restrict your collisions, especially on per-triangle-shapes, to what you really need it to collide with for both performance and visual reasons.
You can have the hands collide directly with the body without the use of proxy objects, however, this essentially requires custom animations made specifically for your body mesh/weight value to get desirable results.

Bones

I'm not going to focus on rigging or weight mapping here as there are many guides and tutorials and many different methods, here I will just tell you how to declare bones to SMP.

Known properties:

<bone>
    <mass>1.000</mass> (float)
    <inertia x="50" y="50" z="50" /> (vector3)
    <centerOfMassTransform>...</centerOfMassTransform>
    <linearDamping>0.000</linearDamping> (float)
    <angularDamping>0.000</angularDamping> (float)
    <friction>0.00</friction> (float)
    <rollingFriction>0.000</rollingFriction> (float)
    <restitution>0.000</restitution> (float)
    <margin-multiplier>0.000</margin-multiplier> (float)
    <shape>...</shape>
    <collision-filter>1</collision-filter> (integer)
    <can-collide-with-bone>name</can-collide-with-bone> (string)
    <no-collide-with-bone>name</no-collide-with-bone> (string)
    <gravity-factor>1.000</gravity-factor> (float)(0-1)
</bone>

<centerOfMassTransform>
    <basis x="0.000" y="0.000" z="0.000" w="0.000" /> (quat) <!-- or --> <basis-axis-angle x="0.000" y="0.000" z="0.000" angle="0.000" />
    <origin x="0.000" y="0.000" z="0.000" /> (vector3)
</centerOfMassTransform>

<shape type="ref" name="name" />

<shape type="box">
    <halfExtend x="0.000" y="0.000" z="0.000" />
    <margin>0.000</margin>
</shape>

<shape type="sphere">
    <radius>0.000</radius>
</shape>

<shape type="capsule">
    <radius>0.000</radius>
    <height>0.000</height>
</shape>

<shape type="hull">
    <point x="0.000" y="0.000" z="0.000"></point>...
    <margin>0.000</margin>
</shape>

<shape type="cylinder">
    <height>0.000</height>
    <radius>0.000</radius>
    <margin>0.000</margin>
</shape>

<shape type="compound">
    <child>
        <basis .../> <!-- or --> <basis-axis-angle .../>
        <shape>...</shape>
    </child>
</shape>

<bone name="bonename" /> <!-- name refers to the name of the bone exactly as displayed in NifSkope -->

Technically this is all you need to declare a bone, although the default values are only really useful for declaring a bunch of Kinematic/Static bones.

Defaults:

<bone-default>
    <mass>0</mass>
    <inertia x="0" y="0" z="0"/>
    <centerOfMassTransform>
        <basis x="0" y="0" z="0" w="1"/> or <basis-axis-angle x="0" y="0" z="0" angle="0" /> <!-- translate/rotate your center of mass, only use one of these -->
        <origin x="0" y="0" z="0"/> <!-- center of rotation/translation -->
    </centerOfMassTransform>
    <linearDamping>0</linearDamping>
    <angularDamping>0</angularDamping>
    <friction>0.5</friction>
    <rollingFriction>0</rollingFriction>
    <restitution>0</restitution>
    <margin-multiplier>1</margin-multiplier>
    <gravity-factor>1</gravity-factor>
</bone-default>

These are the default values for bones, you can override these values and change the defaults however this will not "hoist" the deceleration, basically that means if you define a bone then change the default values afterwards those new values will only apply to bones declared after <bone-default>, you can use bone defaults to apply common properties to multiple bones without having to declare the properties on every bone.

As of update 20180113 we have the ability to define and extend templates for 'default' objects, we can now set up groups of common physics properties to be used later on.

e.g.

<bone-default name="dress">
  <mass>0.5</mass>
  <linearDamping>0.1</linearDamping>
  <angularDamping>0.3</angularDamping>
  <friction>0.5</friction>
</bone-default>

<bone-default name="dress_heavy" extends="dress">
  <mass>3</mass> (overrides mass to 3 instead of 0.5)
  (inherits liner/angular damping and friction)
</bone-default>

<bone name="dress_01" template="dress" />
<bone name="dress_02" template="dress" />
<bone name="dress_03" template="dress_heavy" />

<bone name="foo" /> <!-- this bone will have the standard default values -->

<!-- 
for the sake of space I have only declared mass, while this is a legitimate block you probably want to 
do more than alter the mass of a bone
-->
<bone-default>
    <mass>1</mass>
</bone-default>

<bone name="bar" /> <!-- this bone will have a mass of 1 -->

<bone-default>
    <mass>0</mass>
</bone-default>
<!-- Set default back to kinematic just in case, leave undeclared bones as non physics bones -->

You can also define custom properties for bones by turning them into explicit closing blocks/tags.

Be careful with bone defaults, if you set a default physics enabled bone and leave some bones undeclared they will automatically have the defaults applied to them, this is probably not a desirable result.

Custom bone properties:

<bone name="myBoneName">
    <mass>0</mass>
    <inertia x="0" y="0" z="0"/>
    <centerOfMassTransform>
        <basis x="0" y="0" z="0" w="1"/>
        <origin x="0" y="0" z="0"/> <!-- center of rotation/translation -->
    </centerOfMassTransform>

    <!-- the majority of the way your bone physics behaves is in these next values -->
    <linearDamping>0</linearDamping>
    <angularDamping>0</angularDamping>
    <friction>0.5</friction>
    <rollingFriction>0</rollingFriction>
    <restitution>0</restitution>
    <margin-multiplier>1</margin-multiplier>

    <!-- Skyrim Special Edition ONLY (20180519) -->
    <gravity-factor>1</gravity-factor>
</bone> 
<!-- as far as I can tell this will override any declared properties and use defaults for any non-declared properties -->

Let's look at the properties of bones:

<mass>: (float, reasonable starting value 1) This tells SMP how "heavy" the bone is, mostly used as a multiplier in other calculations, 0 is a special property though as a mass of 0 will change your bone to Kinematic/Static (will only be affected by animations targeting it, no physics). Use a mass of 0 for your anchor/root bone so that your bones don't "fall off your character".

<inertia>: (float, reasonable starting value 100 * mass) How much energy is applied to your bone, if your bone is Dynamic (affected by physics) then none of these values can be 0, setting one or more of these to 0 will give you undesired results. This also affects how much energy your constraints have, low energy will make your constraints basically worthless.

<linearDamping>: (float, valid range any) This will remove a percentage of your translational (X, Y, Z) energy per calculated second, a value of 1 will remove 100% of your energy, 0.3 will remove 30% etc.

<angularDamping>: (float, valid range any) This will remove a percentage of your rotational (Y, P, R) energy per calculated second.

<friction/rollingFriction>: (float, valid range unknown) These are not terribly well explained, needs more investigation.

<restitution>: (float, valid range any]) Restitution is how bouncy your object is, higher values being more bouncy.

<margin-multiplier>: (float, valid range any/standard float range) Has something to do with skeletal related collisions, higher values will increase impact of collisions on the bone.

<gravity-factor>: (float, valid range [0-1]) Add gravity as a force that affects this bone.

Formula for damping: v = v * (1-damping), damping is applied when there is no external force/movement, to somewhat remove movement on a single axis set your linear/angular damping to 1 on that axis.

As a note, it is best to use a combination of linear and angular movement in most cases, relying only on one will give you somewhat poor simulation. In particular relying only on angular movement can give you frustratingly difficult movement to work with, e.g. If you have an earring attached to a chain, add at least one anchor bone, at least one bone for the chain using both angular and linear movement and at least one bone using angular/linear movement for the earring itself.

With some dedication you could get very nice physics simulations by combining animated (Kinematic/static) bones with Dynamic bones constrained to them.

Constraints

Links:

https://github.com/bulletphysics/bullet3/blob/master/docs/Bullet_User_Manual.pdf

https://download.autodesk.com/global/docs/maya2014/en_us/index.html?url=files/GUID-CDB3638D-23AF-49EF-8EF6-53081EE4D39D.htm,topicNumber=d30e571077 (linking the maya manual as it has some nicer descriptions)

This is where we tell our bones what to "stick" to and how far they are allowed to deviate/move from their parent's position. Known constraint tags:

<constraint-group>

<generic-constraint>

<stiffspring-constraint> (not sure if this one is implemented, code exists to read it)

<conetwist-constraint> (not sure if this one is implemented, code exists to read it)

<generic-constraint bodyA="name" bodyB="name" template="named generic constraint default"> (Generic 6DOF constraint)
  <useLinearReferenceFrameA>false</useLinearReferenceFrameA> (boolean)
  <linearLowerLimit x="0" y="0" z="0" /> (vector3)
  <linearUpperLimit x="0" y="0" z="0" /> (vector3)
  <angularLowerLimit x="0" y="0" z="0" /> (vector3)
  <angularUpperLimit x="0" y="0" z="0" /> (vector3)
  <linearStiffness x="0" y="0" z="0" /> (vector3)
  <angularStiffness x="0" y="0" z="0" /> (vector3)
  <linearDamping x="0" y="0" z="0" /> (vector3)
  <angularDamping x="0" y="0" z="0" /> (vector3)
  <linearEquilibrium x="0" y="0" z="0" /> (vector3)
  <angularEquilibrium x="0" y="0" z="0" /> (vector3)
  <linearBounce x="0" y="0" z="0" /> (vector3)
  <angularBounce x="0" y="0" z="0" /> (vector3)
</generic-constraint>

<stiffspring-constraint bodyA="name" bodyB="name" template="named generic constraint default"> (Spring constraint presumably?)
  <minDistanceFactor>0.000</minDistanceFactor> (float)
  <maxDistanceFactor>0.000</maxDistanceFactor> (float)
  <stiffness>0.000</stiffness> (float)
  <damping>0.000</damping> (float)
  <equilibrium>0.000</equilibrium> (float)
</stiffspring-constraint>

<conetwist-constraint bodyA="name" bodyB="name" template="named generic constraint default">
  <angularOnly>false</angularOnly> (boolean)
  <limitZ>0.000</limitZ> (float)
  <limitY>0.000</limitY> (float)
  <limitX>0.000</limitX> (float)
  <limitSoftness>0.000</limitSoftness> (float)
  <biasFactor>0.000</biasFactor> (float)
  <relaxationFactor>0.000</relaxationFactor> (float)
</conetwist-constraint>

Much like bones we can either use/change the defaults or define the properties on the constraint itself, this follows the same hoisting rules as above.

Adding a constraint:

<generic-constraint bodyA="Bone-ear" bodyB="Bone-ear-anchor"/>
<!-- bodyA: the bone you want to constrain to something -->
<!-- bodyB: the parent bone you want to constrain it to -->
<!-- this constraint will use the default properties as defined before its decleration -->

<generic-constraint bodyA="Bone-ear" bodyB="Bone-ear-anchor">
    <!--Properties-->
</generic-constraint>
<!-- for custom properties -->

And the default values:

<generic-constraint-default>
    <frameInB>
      <basis x="0" y="0" z="0" w="1"/>
      <origin x="0" y="0" z="0"/>
    </frameInB>
<!-- This is a standard transform like above, it's where you want your constraint to start from, defaults to the center of the parent bone or bodyB -->

    <useLinearReferenceFrameA>false</useLinearReferenceFrameA>
<!-- looking into what this is -->

    <linearLowerLimit x="-1" y="-1" z="-1"/>
    <linearUpperLimit x="1" y="1" z="1"/>

    <angularLowerLimit x="-1" y="-1" z="-1"/>
    <angularUpperLimit x="1" y="1" z="1"/>
<!-- These limit how far the constraint can move/rotate away from its parent -->
<!-- For angular (rotation) the lower and upper limit define the range of motion available to the constraint -->
<!-- e.g. <linearLower x="-5" /> | <linearUpper x="5" />, would allow this constraint to move 5 units left or right -->

    <linearStiffness x="0" y="0" z="0"/>
    <angularStiffness x="0" y="0" z="0"/>
<!-- These will change how stiff your spring is, much like suspension on a car -->

    <linearDamping x="0" y="0" z="0"/>
    <angularDamping x="0" y="0" z="0"/>
<!-- same as other damping values, although here I am not sure if the valid range is [0-1], it is not specifically stated to be so but I would assume it is -->

    <linearEquilibrium x="0" y="0" z="0"/>
    <angularEquilibrium x="0" y="0" z="0"/>
<!-- Equilibrium is where the bone will naturally try to come to rest, in general this will be 0,0,0 as you probably want your bone to rest where it started from -->
<!-- In terms of a spring this is where it would rest if there was no force being exerted on it -->
</generic-constraint-default>

A fairly basic example:

<bone name="Spine05" />

<bone name="BreastCenter">
    <!--values...-->
</bone>
<bone name="BreastFore">
    <!--values...-->
</bone>

<generic-constraint bodyA="BreastCenter" bodyB="Spine05" />
<generic-constraint bodyA="BreastFore" bodyB="BreastCenter" />

configs.xml:

There are several options available to tweak the physics engine settings here.

<configs>
  <solver>
    <numIterations>16</numIterations>
    <groupIterations>4</groupIterations>
    <groupEnableMLCP>false</groupEnableMLCP>
    <erp>0.2</erp>
    <min-fps>60</min-fps>
  </solver>
</configs>

<numIterations>: (int, reasonable starting value 10 - 16) Could be simplified as 'simulation accuracy', lower values will gain performance at the cost of less quality. The default value will probably suffice for the most part.

<groupEnableMLCP>: (boolean) Turn on the higher quality constraint solver, better constraint simulation at the cost of performance.

<erp>: (float, valid range [0-1]) The error correction force applied per simulation step, constraints will drift apart naturally, this value will exert a force to move them back to where they are supposed to be. You probably won't need to change this from default, do not use a value of 1 http://www.ode.org/ode-latest-userguide.html#sec_3_7_0

So how do I use this:

Using mod assets as collision objects (easy):

So let's say you download a pair of fancy gloves and you want them to collide with your character.

Open up the gloves mesh in NifSkope and add the NiStringExtraData block, point it to your desired xml file
In your xml file create a collision object (probably per vertex) and assign it to the name of the mesh you want to collide, if multiple meshes exist you could either assign both as collision objects or pick the dominant mesh (the one that is more likely to collide) if appropriate.
Use an appropriate animation or idle to test and tweak the margin value until you have a desirable effect

What about armor?
To have armor collide is easy just do the same as above, likewise with any other type of mesh just make sure to note what the mesh's name is or change it to something standard like glove or armor. Note that your characters body will not collide with anything if you are wearing armor that has not been set up to simulate physics as there is nothing to collide with.

Jiggles and wiggles?

Jiggles is a bit more complicated as you will probably need to add extra bones to the mesh, in the case of armor most old HDT/BBP mesh has one bone for each breast located somewhere near the clavicle area and as you know SMP needs a parent child arrangement or your bones will fall off your character, also the location of the bone is less than ideal for collisions.
To get physics working you will need to load up Studio Max (or Blender) and shift/add the bones to a more ideal locations. Use the body mod as a reference for where to put your bones, this will of course require you to re-skin/weight map the new and old bones that you are modifying/creating.
Make sure that when creating bones you think about what they will be anchored to on the main skeleton.

I want to create waggling nose hairs!

Well much the same as above you would need to open up your 3D program, model some nose hair and add an appropriate number of bones depending on how detailed you want the waggling, weight map your mesh and the rest I would hope is fairly trivial when it comes to defining the physics of said bones.

Handy Techniques:

Create a bone default definition at the end of your physics file with a mass of: 0, this will cause any bones you have forgotten about or don't care about to be 'static' (have no physics applied)
Mostly relevant if you are using bone defaults to apply common values to several bones at once, probably more effective to use naming and templates with newer versions of SMP

<bone-default>
  <mass>1</mass>
  ...
</bone-default>

<bone ... />
<bone ... />
<bone ... />

<bone-default>
  <mass>0</mass>
</bone-default>

Credits:

HydrogensaysHDT - Obvously :smile:
ledo4ek - Great work on everything, collisions in particular
ApoKryta - Packaging everything nicely
prZ - The monumentally useful all in one easy package & detailed guides
Uhuru N'Uru - Explaining the file structure and how to navigate
01023 - I believe for the xml tutorial in the packaged files
FiftyTifty - Testing OpenCL compatability
http://www.loverslab.com/topic/45034-prepacked-hdt-sm-hdt-skinned-mesh-physics-with-modding-guide/page-1 - Basically everyone in this thread for persistence and testing

Edited May 24, 2022 by treota

Shivala · February 16, 2016

Hey, thanks for this! I run HDT-SMP but a lot of people don't because documentation is scattered all over Tamr...the Internet. Maybe if you cannot link that one other website, you could put the links on a third party page, like maybe a wikia, wikihow or something like that?

I haven't worked out collisions yet, so thanks for that new info! Maybe Ill be back with a few questions.

treota · February 17, 2016

Maybe if you cannot link that one other website

You're welcome, I felt the same when I first picked up SMP and felt obliged to share something a bit more cohesive.

Links to loversLab, which website are you meaning?

Edited February 18, 2016 by treota

Asterra · April 5, 2016

I'd have to say the main reasons why HDT-SMP is not very high on the must-have list are the following:

1: No complete packages - specifically complete vanilla armor sets for multiple bodies, prioritizing skimpy variants since those are what people want.

2: Aforementioned incompatibility with other things such as HDT KS Hairdos.

3: Supposedly some incompatibilities / unpredictability when using an ENB and/or a less-than-superb framerate. Not an issue with standard HDT.

4: Practically no demonstrations of the effect in action; those which exist are low-quality, low-framerate and just not very useful.

In short, no all-in-one, more issues, and essentially nothing to prove that it's better in any event. I tried it out myself and found it to be more jello-y. While I recognize that it could probably be improved with tweaks, I have no way of knowing for sure because of the lack of video evidence.

Shivala · April 5, 2016

Asterra : I am here running HDT-SMP on a relatively low-medium end laptop, with ENB and I manage to get at least 25+ fps in most places, 18 under heavy load in some areas, but most intense battles still run smoothly.

1) You can use HDT-PE bodies/armor for HDT-SMP, but yes, there are relatively few dresses fully HDT-SMP. (which is awesome)

2) I am running HDT KS Hairdo in conjuction with the armor/bodies no problems. Even had HDT-PE and SMP mixed here for awhile.

3) HDT-PE is indeed lighter on the system, but not by much.

I just finished up a big tweak session, because the standard config file of HDT-SMP means that for instance breasts are balloons that just bounce up and down lighter than air. In my version I tweaked it to make sure HDT materials have actual feeling of weight (be it weapons or breasts or whatever), which much more realistic. In HDT-SMP the actual mesh can be deformed, which is not true for HDT-PE, which I believe uses the bone of the skeletons to shape the mesh.

I am thinking of releasing it here on the Nexus. But I don't know how to make a gif from my game to show the result.

treota · April 6, 2016

Asterra: Right on all counts, although 3. incompatability with ENB or framerate:

This is a problem with the way physics is implemented in skyrim as it was never designed to run at over 60fps, it does not cause drastic problems just some odd simulation and should be present in both PE and SMP as well as vanilla HAVOK physics.

As far as my testing has shown the only problem with ENBs is either framerate (not SMPs issue) or the blue texture bug which is easy to fix.

I have tested SMP and HAVOK at 30-100+fps before though and never ran into these physics issues so it may be one of those 1:100 problems that is caused by specific computer/driver setups.

You can in the mean time use the wig versions of KS Hair as they should not conflict with SMP, the body version has issues as it applies physics to the same bones that SMP is trying to use.

The lack of demonstration content is indeed a problem in the uptake of SMP, I did want to attach some demo content to this very guide but found that I neither had the time or the software to do so, also the TOS seem to suggest that you are in fact not supposed to have frontal nudity at all which makes it a bit harder to show anything.

A somewhat different problem is that any demonstration content would be based on the personal settings of whoever made it, as such the "betterness" of the simulation is very hard to put across in motion content, things like the mesh not spazzing out of control or flying off at insane velocity is hard to demonstrate as they aren't constantly occurring issues with PE.

Part of the reason I made this guide was to make SMP easier to get into for modders in the hope that we would get some of the aforementioned demonstration content and even perhaps some "all in one" packages, basically the more attention SMP gets the faster the development for it will be.

On a side note, which issues are you running into? Other than Nvidia being a bit odd about OpenCL there were very few issues I ran into, will be useful to add more troubleshooting to the guide.

Shivala: https://screentogif.codeplex.com/ haven't really used it but this thing claims to be able to capture screen content directly to gif format.

Should you manage to get some demo content I would love to have it here in the guide, make sure to check the forum rules or contact a moderator though as the TOS is somewhat hazy about sexual content.

Currently my TODO list contains:

- Side by side comparisons

- Demonstrating PE spazzing, flying mesh and how SMP handles the same situations

- Demonstration of the basic tweaking process to show how easy it is to customize the settings

- Demonstrating the more complex possibilities with SMP (this one is very unlikely atm as it would require buying 3DS Max and quite the time investment)

Edited April 6, 2016 by treota

Asterra · April 6, 2016

The lack of demonstration content is indeed a problem in the uptake of SMP, I did want to attach some demo content to this very guide but found that I neither had the time or the software to do so, also the TOS seem to suggest that you are in fact not supposed to have frontal nudity at all which makes it a bit harder to show anything.

The videos on Youtube do not have nudity; they show the physics in action. But, as I earlier intimated, those videos which do exist are of unusually poor quality, and when the breast physics are apparent at all, they are not promising. Essentially the same thing as what I experienced. Again, I am fully aware of the fact that the correct tweaks can make all the difference. For example, I am really quite happy with the xmls I ended up with in my HDT-PE setup, but the default was too unrealistic and had a springiness that I would liken to a cavernous reverb, just like HDT SMP's default.

On a side note, which issues are you running into?

I tested it for about five minutes. I can vaguely recall being comparatively impressed by something - perhaps the collision. The issues were the following: 1) The default settings are no good and, at least for HDT-PE, I have always relied on third-party submissions when seeking something more to my liking; HDT SMP really doesn't have much in the way of such options. 2) The mesh I had to use to get it to work included sphere elements hidden inside the breasts - something which I assume is essential to getting the intended physical reactions. The problem is that the only mesh in my chosen body's complete vanilla set which includes those spheres is the naked body; all of the vanilla armors are just meshes with breast bones. Perhaps I was hasty in assuming that this was a dealbreaker, but I have to wonder what the point of those spheres is.

A nice 60fps video showing the effect in action, with as many different tweaks as one can manage, is what's needed to push this forward. Everyone knows what HDT-PE can look like, from one end of the spectrum to the other. That's what HDT SMP is up against. While I would say it's a bit late to prop this up for Skyrim's sake, FO4 is just getting started, so now is the time to push for the new, if it truly can be superior.

Edited April 6, 2016 by Asterra

FiftyTifty · April 6, 2016

Another hindrance for adoption o' SMP, is that OpenCL 2.0 hardware ain't widespread. Only AMD's rx 200 series and later support it, whereas NVidia's latest and greatest...Don't.

That, and disabling OpenCL 2.0 in the .xml doesn't do squat, far as I've been able to tell; if your hardware doesn't support OpenCL 2.0, Skyrim crashes. Supposedly, OpenCL 2.0 will run on CPUs that have SSE2 and later instruction sets, but SMP just crashes on me Phenom II.

Maybe once the next roll of GPUs come out, there'll be more uproar o'er it, due to price depreciation.

treota · April 7, 2016

The spheres are proxy objects that are not necessary for collisions but do make collisions behave a lot better, you could if you so desired tell your hands mesh to collide directly with your body mesh but this would require very specific animations created for it otherwise your mesh will be compressed to pancakes whenever the hands move too close/through the collision area.

All the spheres are doing is detaching the collision from the rest of the body so that instead of being compressed they move and in doing so influence the bones they are attached to, you can see this in action if you so desire with the testing version of the body I provided which just puts a visible texture on the spheres.

They are in no way needed to get the physics to work, only if you want nicer looking collision simulation.

Very true though I could probably rig up/find an underwear version of one of the bodies to use SMP for some demos, shall look into it.

The problem for armor/clothing is that in order to use SMP to its potential you need a slightly different rig than what PE uses, PE has bones near the clavicle area which I assume act almost exclusively on the rotational plane, where SMP works better if you have your bones in a more standard rig format, central to the area you want to deform.

Essentially this means that if you wanted to get nice SMP simulation you would have to do a minor change and re skin of every PE armor/clothing set, so no easy rename a few objects conversions, what you could possibly do is write an interpreter which takes PE xml files and generates the equivalent as a SMP xml file (I may look into this too).

Left: Typical PE rig Right: Example of something more useful for SMP

http://s28.postimg.org/90k2kgr8d/demo_Rig_SMP.png

With enough bones in your rig you could get some really nice simulation going, you could emulate things like squash and stretch when changing velocity or have parts of your mesh deform asynchronously giving you a much more skin and fat deformation rather than a balloon bouncing around always maintaining the same shape. In theory this could result in some really nice simulations like the formation of cleavage or the mesh conforming to the shape of the hand/arm/appendage influencing it.

http://s23.postimg.org/lk6nmhg6f/demo_Rig_SMPfrontage.png

To clarify though you can add SMP physics to anything that has been weight mapped properly, so PE meshes will work you would just have to set up a SMP xml file for them and probably link the mesh to the new xml with NifSkope. The simulation will probably not be that nice though and I am unsure if you would be able to get collisions at all due to the placement of the bone.

(All this is speculation, it's entirely possible that someone will come up with a way to easily adapt existing PE rigs to the new SMP system)

FiftyTifty: You are quite right, Nvidia has some grievance with OpenCL last I checked which has been slowing down their adaptation of newer versions. Thank you very much for testing the option to disable OpenCL, I did not have a computer available to test it on, shall add it to the guide.

https://wiki.tiker.net/CudaVsOpenCL - If you are interested in the CUDA vs CL debate

Edited April 7, 2016 by treota

A Guide to HDT-SMP Users/Modders

Recommended Posts

Link to comment

Share on other sites

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Recently Browsing 0 members