A couple of HDT SMP questions

[Monsto Brukes]

I've read completely thru the other most notable threads, and need some clarifications. Who knows . . . if I can get it working as expected I may even write an actually readable doc.

 

• Bodyslide: What source body should I use? Where do I get it?
  I've seen a bunch of different references to different specific names body types, none of which are even close to what I have in my very recently updated bodyslide app.
   
• Based on this download here, which xml would I edit to make visible changes to the effects on the above bodyslide generated mesh?
  Again with the different references, but nothing seems to change.
   
• what's the method for actually changing the file and seeing the changes in game?
  with HDTPE it was running skyrim in windowed mode with the .xml open in the editor. Save the .xml, then initiate a cell change in game (coc studioblack), even if it was the same cell, and the changes were loaded. Either that doesn't work now or i'm changing the wrong file.
   
• Is there a description of the effective ranges of the entries in the xml?

 

[27X]

You're asking for an objective consensus on Loverslab? rofl.

 

No such animal.

 

You're gonna shit on someone's fetish and then you shall receive the sternly worded anguish.

 

Any body made for specifically for PE is compatible.

 

HOWEVER. SMPs constraints are based directly on the mesh, so depending on what you vaguely mean by "changes" (i'm assuming ranges or velocities?),  the type of changes in PE and SMP aren't even kind apple to apple in regards to deformation and motion.

 

Hydro has provided exactly jack shit for documentation, and half the supplied files are not even needed or actively interfere with with other loading processes.

 

Also, any ENB with color correction or active dynamic memory reallocation aren't even kind of compatible with SMP, so make you aren't running anything other than ENBoost... (even then you're going to get re-allocation issues between the two), that might be why you can't effect changes per cell.

 

- no ranges are documented.

 

That said, you're probably changing the wrong file, but SMP isn't loaded into memory the same way as PE was, and a cell change may not help.

[blabba]

You're asking for an objective consensus on Loverslab? rofl.

 

No such animal.

 

You're gonna shit on someone's fetish and then you shall receive the sternly worded anguish.

 

Any body made for specifically for PE is compatible.

 

HOWEVER. SMPs constraints are based directly on the mesh, so depending on what you vaguely mean by "changes" (i'm assuming ranges or velocities?),  the type of changes in PE and SMP aren't even kind apple to apple in regards to deformation and motion.

 

Hydro has provided exactly jack shit for documentation, and half the supplied files are not even needed or actively interfere with with other loading processes.

 

Also, any ENB with color correction or active dynamic memory reallocation aren't even kind of compatible with SMP, so make you aren't running anything other than ENBoost... (even then you're going to get re-allocation issues between the two), that might be why you can't effect changes per cell.

 

- no ranges are documented.

 

That said, you're probably changing the wrong file, but SMP isn't loaded into memory the same way as PE was, and a cell change may not help.

 

SMP is mesh based. It is still rigid body dynamics (same core physics formula's as PE, except now deformations are now approximated automatically by the mesh. However for actual motions it's still the same as PE in that your controlling how a bone in the skeleton moves and reacts. It's also in the same exact parent axis viewpoint for constraints, same constraint types etc...)

 

I have no current knowledge of SMP's memory handling. But it's probably safe to say that it will interfere/conflict with high memory usage enb's (normal enb's should be fine, also depends on how much memory your system has and it's configuration etc...)

 

SMP's major difference with PE (other than mesh based approximation for deformations) is that it now has a secondary xml file that will allow you to define .nif file shapenames and match them with a corresponding SMP physics file (also .xml). This means you no longer need to manually attach the physics presets into the nif file.

 

SMP is loaded almost exactly the same as PE preset files were loaded. Simply make sure that there are no mesh instances in the area of the game you are currently in that match a shapename that has a physics file loaded to it. (So if your in a room with npc's that use the same body as you, reloading the cell isn't gonna force a re-load of the physics preset since npc's forcing preset already loaded into memory)

 

In short. except for 2 things, SMP and PE are exactly the same beast (well 3, it doesn't use Havok physics solvers but Bullet physics solvers, which are more open source and arguably better documented again not really a huge difference since the math is more or less the same, you just have less parameters you can change in SMP because hydro used the simplified bullet solvers)

[27X]

 

 

SMP is loaded almost exactly the same as PE

 

Used a mem checker, and this isn't really the case.

 

The solvers are better documented, but that's not even hydro's doing. I'm talking about her specific implementation.

 

Are you certain the constraints are the same, cause I'm not even getting the same KIND of results with "identical" xmls between the two (and yes I'm accounting for more linear parameters)

 

A collision that causes instant perpetual jitter in PE along the y axis, causes probably a third of same motions in SMP with fairly rapid rest. (+/- about second and half even with a completely cross-intersecting collision)

 

Granted the shapes have to be manually tweaked in PE to get the same types of interaction, but I don't think I'm that far off. (Admittedly, because of the myriad injection issues, I haven't put in as much research into SMP as I could have)

 

[blabba]

 

SMP is loaded almost exactly the same as PE

 

Used a mem checker, and this isn't really the case.

 

The solvers are better documented, but that's not even hydro's doing. I'm talking about her specific implementation.

 

Are you certain the constraints are the same, cause I'm not even getting the same KIND of results with "identical" xmls between the two (and yes I'm accounting for more linear parameters)

 

A collision that causes instant perpetual jitter in PE along the y axis, causes probably a third of same motions in SMP with fairly rapid rest. (+/- about second and half even with a completely cross-intersecting collision)

 

Granted the shapes have to be manually tweaked in PE to get the same types of interaction, but I don't think I'm that far off. (Admittedly, because of the myriad injection issues, I haven't put in as much research into SMP as I could have)

 

 

Hydro uses the same hooks as the PE code, the only difference is the secondary xml to abstract physics load for multiple shapes. The hook just loads a new function to handle this (the location of the hook is exactly the same, I'm like 90% sure on this). I imagine a mem checker will be useless for this as it only analyzes what is in the memory which ofc will be vastly different since this is new code (new vars, new internal memory hanlding setup so that your not double loading a physics file etc..)

 

The math is exactly the same. The constraints still use parent space on the bones to define motion. Deformations are auto-approximated if you define mesh-type. As mentioned before, collision motions are a lot more simplified and do not give you as much choice in your parameters. Also, the mesh approximation may or may not be decent depending on what algorithms they used.

 

edit: fun fact you can easily test the same hooks are used since if you go back to a TBBP style rig map in SMP and pause the screen or have the VM at anytime pause itself, you will see that the physics gets cleared and go back to stiff animations. This was because the hook is less than ideal. (or there needs to be extra hooks in place to maintain the consistency of the physics throughout the game whenever rig maps are reloaded etc...)

[Monsto Brukes]

Hey guys, thanks for the help. o_O