Jump to content

Photo

A Guide to HDT-SMP Users/Modders

hdt smp hdt-smp physics guide

  • Please log in to reply
19 replies to this topic

#1
treota

treota

    Journeyman

  • Members
  • Pip
  • 20 posts

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 being developed by the lovely HydrogensaysHDT.
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.
 
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.int.../opencl-drivers these will only work if you have compatable Intel CPU
  • AMD, drivers here http://support.amd.c...CL2-Driver.aspx
  • OpenCL 2.0 is 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:

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.c...874470-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:

  • 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 have followed the above correctly... Nothing will happen   :hurr: (probably, for the body at least. Clothing mods will work now).

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.co...b3568ce1b90cf7a
                                                   
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:

ledo4ek provides his own xmls and a fairly easy tutorial on getting collisions working here http://www.loverslab...15#entry1335127 (Warning, there is some graphic content in the posts), he is essentially using proxy objects to drive collisions so that you can have more fine tuned control over what collides with what.
Should this prove to be beyond your abilities I have attached the body I use which requires 
UN7B with collision objects. (mesh name is Material.001) Body with proxy objects.
Replace UN7B femalebody_1/0 with these (testing body has a texture applied to the objects for visual feedback should you need it).

You may, and probably will need to also copy the HDT Belly node from his 0.nif, to get the belly object working on your own mesh.

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).

After applying the collision proxy objects your body is set up and ready to go, now we just need to define what it collides with. And so concludes the super easy part of SMP.
This has mostly been for the benefit of Users so far, however some information may be useful to modders as well.


Edited by treota, 21 February 2018 - 05:26 AM.


#2
treota

treota

    Journeyman

  • Members
  • Pip
  • 20 posts

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
 
Forum_Title_Object_Collisions.gif
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>:

<?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>
<!-- margin is 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 -->

<!-- <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>
<!-- an identifier for this mesh collision object for use with no collide tags -->

    <no-collide-with-tag>hand</no-collide-with-tag>
<!-- 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>HDT Belly</no-collide-with-bone>
<!-- this ones pretty apparent, 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 -->

</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, lets 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.
 
<per-triangle-shape>:

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

    <prenetration>0.05</prenetration>
<!-- this ones new, something to do with prison sex?, translation error perhaps. This value is only for traingle-shapes -->
<!-- Have not fully grasped exactly what prenetration does at this time -->

    <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>Lbreast</no-collide-with-tag>    
    <no-collide-with-tag>Rbreast</no-collide-with-tag>
<!-- here we have our proxy objects coming in handy, letting us separately define collisions with the left and right breast  -->

    <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> 
<!-- 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>
<!-- 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>
    <prenetration>10</prenetration>
    <tag>ground</tag>
</per-triangle-shape>
<!-- This is in the xml tutorial that comes with the packaged files, I have not personally tested it yet -->

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 mesh without the use of proxy objects, however this essentially requires custom animations made specifically for your body mesh/weight value to get desirable results.
 
 

Forum_Title_Object_Bones.gif
I'm not going to focus too much 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.


<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.
 
Speaking of 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>
</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 -->

You can also define custom properties for bones by turning them into explicit closing blocks/tags.
 
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>
</bone> 
<!-- as far as I can tell this will override any declared properties and use defaults for any non-declared properties -->

Lets look at the properties of bones:

  • <mass>: (float) 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) 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
  • <linearDamping>: (float, valid range [0-1]) This will remove a percentage of your translational (X=sideways, Y=forward/backward, Z=up/down) energy per calculated second, a value of 1 will remove 100% of your energy, 0.3 will remove 30% etc
  • <angularDamping>: (float, valid range [0-1]) This will remove a percentage of your rotational (X=twist, Y=left/right, Z=forward/backward) energy per calculated second.
  • <friction/rollingFriction>: (float, valid range unknown) These are not terribly well explained, as damping is only applied when there is no external force then friction is most likely applied regardless, this would make your object seem "heavier" as it would be less affected by changes in velocity
  • <restitution>: (float, valid range unknown) Restitution is the energy lost through heat/friction etc when your object collides with something, in this case when your bone collides with it's boundaries or collision objects
  • <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.

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.
 

Forum_Title_Object.gif
This is where we tell our bones what to "stick" to and how far they are allowed to deviate/move from their parents position. There are two constraints so far:

  • <generic-constraint>
  • <stiffspring-constraint>

At the moment I have not been able to get stiffspring to work so I will focus on the more expansive generic-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, I don't know what unit is being used but a value of 1 seems to be 90° on angular movement -->

    <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" />

Shall look into some more use cases and examples...

 

So how do I use this:

 

Using mod assets as collision objects (easy):

 

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

  1. Open up the gloves mesh in NifSkope and add the NiStringExtraData block, point it to your desired xml file
  2. 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 exists you could either assign both as collision objects or pick the dominant mesh (the one that is more likely to collide) if appropriate.
  3. 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.

 
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...ng-guide/page-1 - Basically everyone in this thread for persistence and testing

Edited by treota, Yesterday, 08:27 AM.


#3
Shivala

Shivala

    Old hand

  • Members
  • PipPipPip
  • 637 posts

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.



#4
treota

treota

    Journeyman

  • Members
  • Pip
  • 20 posts

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 by treota, 18 February 2016 - 03:52 AM.


#5
Asterra

Asterra

    Old hand

  • Members
  • PipPipPip
  • 523 posts

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.



#6
Shivala

Shivala

    Old hand

  • Members
  • PipPipPip
  • 637 posts

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.



#7
treota

treota

    Journeyman

  • Members
  • Pip
  • 20 posts

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 by treota, 06 April 2016 - 02:20 AM.


#8
Asterra

Asterra

    Old hand

  • Members
  • PipPipPip
  • 523 posts

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 by Asterra, 06 April 2016 - 09:25 PM.


#9
FiftyTifty

FiftyTifty

    Faithful poster

  • Members
  • PipPipPipPip
  • 2,031 posts

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.



#10
treota

treota

    Journeyman

  • Members
  • Pip
  • 20 posts

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

 

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.

 

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 by treota, 07 April 2016 - 07:26 AM.






Also tagged with one or more of these keywords: hdt, smp, hdt-smp, physics, guide

Page loaded in: 0.820 seconds