Jump to content

UUNP Special Vagina for Hdt SMP?


Mister X

Recommended Posts

Heyho,

I just wanted to ask: did already someone build a HDT SMP preset with colliding vagina for UUNP Special?

I know SMP still in Dev state, though it already works better and more stable on my system than PE ever did, so I don't want to switch back :/

 

And I don't really have the time for learning all those values and build up a file for myself from scratch. Would be very nice if someone could provide me with a working file, especially epic would be working collision of vagina with SOS schlongs and breasts with hands. So I could tweak and test on a working bootstrap :)

Link to comment

Heyho,

I just wanted to ask: did already someone build a HDT SMP preset with colliding vagina for UUNP Special?

I know SMP still in Dev state, though it already works better and more stable on my system than PE ever did, so I don't want to switch back :/

 

And I don't really have the time for learning all those values and build up a file for myself from scratch. Would be very nice if someone could provide me with a working file, especially epic would be working collision of vagina with SOS schlongs and breasts with hands. So I could tweak and test on a working bootstrap :)

 

Actually,How did you set up a HDT SMP build,As user,not a modder/developer?

Link to comment

There is no such thing as "SMP compatible preset".

 

You either have PE or SMP on separate parts or not at all. While you can mix and match the two that's incredibly stupid for memory management and CPU overhead purposes and in addition to lowering your framerate unless you own an i5 or i7, you're probably thrashing the shit out of your cpu and L1 cache for no reason, which is one of the reasons SMP uses OpenCL, but i guess if you want swishy hair to go with your fiddly bits that would be about the only reason to combine the two.

 

To have collisions with SMP you need a compatible set of weighted meshes with a defined attendant xml. SMP uses either per-mesh or per-polygon collisions. PE uses predefined objects that approximate meshes which is why an xml made for small bouncy parts looks completely retarded on big jiggly parts and vice versa. That also means male mesh and female mesh for collisions. Renaming the baseshape to "UUNP" does exactly nothing for per-mesh collisions.

 

http://www.loverslab.com/topic/45034-prepacked-hdt-sm-hdt-skinned-mesh-physics-with-modding-guide/

 

Though I'm fairly certain you actually posted in this thread already, so you already have your answer.

Link to comment

I think you misunderstood what I wanted:
I don't want to mix HDT PE and SMP, I want to use purely HDT SMP for jiggling and body part collision. As meshes UUNP Special as generated by BodySlide for females, MNC for creatures and SOS for males. And my question was if there already exist .xml files for HDT SMP that do this.
I don't know what you mean with "defined attendant xml", I just gave UUNP as baseshape name because the main node of the body is called like this. And it works fine, my body jiggles like a charm.
 
So sth similar to the All-In-One Pussy, just purely for HDT SMP. I don't want to use any HDT PE stuff anymore, I already use NiO Highheels and now want to get rid of the always buggy HDT PE, because SMP is much more reliable and stable for me, even though it's only dev build.

 

And yes, I posted in that thread, but some time ago and I got no real answer there, also it wasn't for this exact topic but much more general.

Link to comment

The one who misunderstood is you.

 

There's a reason you didn't get a reply:

 

There is no such animal.

 

No such thing.

 

You need to create or find an SMP compatible -->>>> MESH <<<<-- and then make a correctly linked and data'd xml for it, and attach the nistring data that points to it. You as in specifically you the poster, not "you" in general.

 

SMP is a mesh based collision system.

 

Complex full body SMP mesh:

opLBR.jpg

 

Simple SMP naughty bits mesh:

opLIY.jpg

 

mesh.

 

A mesh, not an xml file with some bracketed words in it, though you also need that too.

 

 

I suggest you reread the thread because you'll find ALL the information you need.

 

Link to comment

That's exactly what I'm telling you because I only did 50% of the work putting it together in a nif-agnostic package and writing the xml, and the authors and originators of the other 50%, the 50% needed to have anything workable in the first place have not given anyone permission to load their shit all over the internet, and unlike most on LL, I have no intention of going against their wishes just because muh fetishes and faps. Since both of those authors are no longer in in the community, contacting them would be rather problematic.

 

Everything you need is in the last 5 pages of the SMP thread.

Link to comment

That's exactly what I'm telling you because I only did 50% of the work putting it together in a nif-agnostic package and writing the xml, and the authors and originators of the other 50%, the 50% needed to have anything workable in the first place have not given anyone permission to load their shit all over the internet, and unlike most on LL, I have no intention of going against their wishes just because muh fetishes and faps. Since both of those authors are no longer in in the community, contacting them would be rather problematic.

 

Everything you need is in the last 5 pages of the SMP thread.

 

That's everything I've wanted to know ...

Link to comment

 

That's exactly what I'm telling you because I only did 50% of the work putting it together in a nif-agnostic package and writing the xml, and the authors and originators of the other 50%, the 50% needed to have anything workable in the first place have not given anyone permission to load their shit all over the internet, and unlike most on LL, I have no intention of going against their wishes just because muh fetishes and faps. Since both of those authors are no longer in in the community, contacting them would be rather problematic.

 

Everything you need is in the last 5 pages of the SMP thread.

 

That's everything I've wanted to know ...

 

 

If you succeed in getting a full SMP Body someday,(Breasts,Butt,And even hands,feet,etc collision for the female body,PLEASE share! :3)

Link to comment

Hmm, I just lurked into the meshes of SOS and a generic UUNP Special body, and theoratically it should be possible, just not with such a detailed collision definition.

So there are meshes/sections for the body, private parts, hands and feet. So these areas could be individually set as collision areas if I got that correctly.

 

The biggest problem seems to be the belly, as its no separate section in any generic body. As a result, if you want to have hand-breast collision, you will have hand-belly and hand-butt collision, too as belly, butt and breasts all share the same mesh section.

 

Now I only need to find an explanation of all those parameters and I could try if I get sth to work :)

Link to comment

[...]

You need to create or find an SMP compatible -->>>> MESH <<<<-- and then make a correctly linked and data'd xml for it, and attach the nistring data that points to it. You as in specifically you the poster, not "you" in general.

[...]

Btw, something that came up my mind now: I already got a HDT compatible mesh with UUNP Special, and I got physics and fhand-fbody collision applied by the hdtSkinnedMeshConfigs\defaultBBPs.xml file. In other words, a normal, generic BodySlide UUNP Special mesh jiggles like a charm.

 

Do I really need to alter the meshes then for other collision? Or is there another reason to directly write the file into the mesh data? Shouldn't it be possible to apply a collision enabling file for schlongs the same way I did with the two files for female hands and body?

Link to comment
possible

 

Yes, it's entirely possible.

 

 

 

ENB

 

As stated, ENB and SMP do not get along AT ALL, and the memory allocation scheme in .305 does not help. Before you 86 the ENB, try 2 and 3 instead of 1 and 0, if that doesn't work try 1 and 1.

 

 

First of all, make sure your collisions aren't actually disrupting something through the console. Second of all, if you have an asston of SL mods running and other scripted sutff, PE may be your only choice, even though it's not as efficient or smooth as SMP, it's more stable under duress.

 

Thirdly, if you're just copy-pasta'ing xmls, then I have to question why you're bothering to use it in the first place, and if the reason is better framerates on potato hardware, then you're actually not helping yourself at all because SMP is unstable as fuck. Did I mention it's unstable as fuck? Because it's unstable as fuck.The Bullet runtimes hydro used are like two years deprecated, and I think the reason they're that old is Bullet recently got rid of all their pre-made runtime collision stuff for whatever reason and she didn't or couldn't write her own, or simply moved on. Who knows.

 

The reason I use SMP is absolute control and because I was able to make realistic  instead of anime instantly ultra bouncebouncebounce collisions, and because I have a system that can handle it. That's not bragging, that's factual engagement. I can run Skyrim at 4K with a personal ENB that makes NLA look like Seasons of Skyrim Low based on Cook-Torrance lighting at 60 frames, and it doesn't matter what's onscreen, and that's why SMP works... and even then it still occasionally CTDs, and it's SMP shitting the bed every time. Every time.

 

If you're having to choose between ENB's stability and SMP's reduced framerate jigglies, then I strongly suggest you get PE and bazinga's Naturalistic XMLs and save your self and your Skyrim build a lot of bullshit.

Link to comment

I use SMP, because I want to try new stuff. I know PE and I know it's way more stable, I just want to try out SMP because I'm kind of a modern techniques fetishist :P. Additionally I also do not just copy & paste xmls (well, atm I do to build up a base), I wanted to build up the collision to a point where it works and then start to try out new values for jiggling and stuff. BTW, what's that prenetration/penetration parameter? First, how should it get written, I've seen both, and what is is supposed to do, because I didn't see any changes when I removed it.

 

My problem just is, that the collision already shits up my game ^^. One funny thing I've found out: If I only take the files for female bodyparts, it works fine, also in an outside area. It only freezes, when I add any combination of male files, and only when I go outside of the tavern where the game loads up.

 

And I do this, because I like it. I do know it's unstable, I also have a HDT PE setup there, that works, it's just deactivated atm (MO ftw ^^) because I want to build the same thing with SMP, for the building aspect, not for framerate. I like to tinker with Skyrim mods, to get things to work where others said it couldn't be, or just to build up a complex mod base to a (mostly) stable setup. Same thing here.

Link to comment

http://www.loverslab.com/topic/45034-prepacked-hdt-sm-hdt-skinned-mesh-physics-with-modding-guide/?p=1421765

 

I've been absent on the SMP front for almost a year; but I believe this is as far as hacking the SMP mesh collision has gotten. @Farass may be using CBBE though, but has been the most active in that thread, in pursuit of mesh collision. That entire thread has been helpful and friendly. I'm now trying a few of the PE all-in-ones. And as mentioned above, mixing SMP and PE is a bad idea. MemoryPatch logs are a mess.

 

Way I understand SMP is the collision happens at the Mesh Weight (paint per skeletal bone), so you really need to be mindful of weight paints that "Overlap". If you overlap collision weight paint : things go wrong. You have to actively disable "all" collisions in xml on the same mesh where overlap is likely. This is a fps killer, if you haven't disabled a few overlaps. It's actually a lot simpler than PE, once you get your head wrapped around the basics; and the very simple xml variables/values. Also, you just need to point the base xml at mesh you want to use, to get the mesh to work (@Grovtama pointed that out early in the thread). So basically collision/physics happens per bone (via weight paint for that bone). Xmls just target the specified bone weights (or target mesh). 

 

Also, be mindful that there are "two" HDT memory patches floating around, one seems to be packaged with SMP (~300kb) the other with PE (~50kb), they may be mutually exclusive respective to the physics method. Though I've tested both, using both methods. Oddly, one mem-patch works much better with ENBs (50kb version). 

Link to comment

[...] You have to actively disable "all" collisions in xml on the same mesh where overlap is likely. [...]

So, the thingy with adding a tag to the body mesh and prevent the body to collide with such tag? This one?

[...]
<per-triangle-shape name="MaleHands">
    <margin>0</margin>
    <tag>MaleHands</tag>
    <no-collide-with-tag>MaleHands</no-collide-with-tag>
[...]

Hmpf. So breast/breast collision of the same body won't work well then, did I understand that correctly?

 

[...] Also, you just need to point the base xml at mesh you want to use, to get the mesh to work (@Grovtama pointed that out early in the thread)[...]

That's this defaultBBPs.xml file, right? No mesh editing needed for SMP then, said here ...

 

Also, be mindful that there are "two" HDT memory patches floating around, one seems to be packaged with SMP (~300kb) the other with PE (~50kb), they may be mutually exclusive respective to the physics method. Though I've tested both, using both methods. Oddly, one mem-patch works much better with ENBs (50kb version).

You don't have per chance a copy of this at hand? Or a link to it?

Link to comment

Yeah, that's the tag, however if the declared hand bones (weight paints) and the breast bones are not usually coming in contact, it shouldn't be a problem when collision is enabled on same mesh -- only when something constantly overlaps, such as left butt bone and right butt bone, or left breast and right breast; basically adjacent bones will stress the system if colliding -- it may not be apparent in a small cell, but when you load into a cell with multiple instances of the condition, fps will tank. Any bone using collision has to be disable versus any bone's weight paint that may ovelap it. You can load your nif in BodySlide and view the bone paints there, to see what is overlapping what. You'd be surprised, there is a lot of sloppy painting on these body mesh, but you can clean it up in BodySlide while you're there. An example might be using a female mesh with a very large butt, where the hands are constantly clipping into the bone weights -- if these are constantly in contact when hands swing while walking/running, you're stressing the physics; hands and butt should probably not collide if this condition exists.

 

Yes, for CBBE, you open up your mesh in NifScope and look for the name of the mesh "inside" the nif file: CBBE = "BaseShape"; so you need to have any shape you want to target declared in the DefaultBBPs.xml, same goes for male genital mesh "inside" the nif file etc. Then each declared mesh gets it's own xml targeted in the DefaultBBPs.xml. Example: 

 

<map shape="Labia" file="SKSE\Plugins\hdtSkinnedMeshConfigs\Labia.xml"/>
<map shape="MaleGenitals Regular" file="SKSE\Plugins\hdtSkinnedMeshConfigs\MaleGenitals.xml"/>
<map shape="MaleBody" file="SKSE\Plugins\hdtSkinnedMeshConfigs\MaleBody.xml"/>
 
this obviously differs depending on which mesh you use, and how you have it set up with the various mesh within a nif file (I used SoS Light, Regular Mesh). 
 
Unfortunately you'll also have to consider using BodySlide to Weight Paint various bones -- I'm convinced this is one of the most critical factors in setting up good collision. 
 
Good Collision = Good Weight Paint transitions. 
 
The two different MemoryPatches can be found packaged in SMP downloads and PE downloads here on LL, the mem-patch I'm currently using is packaged for PE and found in:
 
 
This is not the same MemoryPatch packaged with HDT-SMP

 

edit; and I agree with 27x, PE is so much easier to get going, just not as realistic as SMP, PE you get infinity tits, alien butt attacks, invisibility bugs. If you spend time tweaking settings in JFF app, you can really improve the jello floppiness of typical PE xmls. It's just the infinity tits and invisible bug that ruins the view. 

 

.. this page shows SMP working with collisions: http://www.loverslab.com/topic/45034-prepacked-hdt-sm-hdt-skinned-mesh-physics-with-modding-guide/page-15

Link to comment
Unfortunately you'll also have to consider using BodySlide to Weight Paint various bones -- I'm convinced this is one of the most critical factors in setting up good collision. 
 
Good Collision = Good Weight Paint transitions.

 

 

This and rewriting xmls are pretty much mandatory, if you don't want time out/broken thread crashes.

 

 

 

Hdt mempatches.zip

Link to comment

Ok, so I tried some different setup with vertex/triangle changing of several parts together with changing the no-collide-with-... thingies, and it works fairly well, all hands collide with breasts, female masturbation has a visible effect down there and it will be given space for schlongs when they cum ... erm, come.

 

Now, I think it interferes with NiOverride. I have enabled the DCUR feature that bloats up the belly a little bit when "a huge load is pumped" into the girl, but then soon after the event I have the effect as seen in the picture. Can I do something to avoid it?

post-441196-0-04490200-1461866205_thumb.png

Link to comment

Link the bones used in the effect in the xml, unless you're using the Ledo proxy belly plane, in which case the answer is no.

 

Hmm, there are already links to "Belly", "HDT Belly" and "NPC Belly", do I have to add "PregnancyBelly" then? I don't believe this is a bone, as it's just a slider in Bodyslide, is it?

Link to comment

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use