Jump to content

[Unofficial] BodyGen - docs


Recommended Posts

I hope topic is still alive as I got some problems that didn't even let me start working with this mod.

I've created templates.ini and morphs.ini in data/meshes/actors/character/BodyGenData/Skyrim.esm folder

 

morphs file: All|Female=Preset

templates: Preset=<some stuff with correct syntax>

 

It actually worked, but definitely not all females were affected. And further question is if it is possible to change or reset already creates bodies for NPCs or the only way is to use savegame where I hadn't used BodyGen yet?

Link to comment

It actually worked, but definitely not all females were affected. And further question is if it is possible to change or reset already creates bodies for NPCs or the only way is to use savegame where I hadn't used BodyGen yet?

 

Sometimes morphs tend not to apply immediately, at least for me, try using the console to disable then enable the actor that didn't morph.

 

For resetting, you could use NetImmerse Override Cleaner on your .skse co-save file. This will clear the morph data of all actors in your save.

Link to comment

 

 

It actually worked, but definitely not all females were affected. And further question is if it is possible to change or reset already creates bodies for NPCs or the only way is to use savegame where I hadn't used BodyGen yet?

 

Sometimes morphs tend not to apply immediately, at least for me, try using the console to disable then enable the actor that didn't morph.

 

For resetting, you could use NetImmerse Override Cleaner on your .skse co-save file. This will clear the morph data of all actors in your save.

 

 

Thank you, these 2 advices seem to fix all my problems with bodygen!

Link to comment

shoka's BodySlide to BodyGen converter didn't run on my 32-bit machine so I was forced to write my own simple converter with java

using some of the pointers from shoka's thread.

 

Updated (March 26, 2017)

- Fixed a bug where undefined sliders with default values are incorrectly inverted. Sheesh! You're gonna have to re-add your affected xmls to fix them.

- Adding an already existing xml will now override the existing xml instead of ignoring the action.

- Fixed slider values not being rounded to 2 decimals.

Not sure if intended, but this app does not generate ranges. It takes "big" values from .xml preset but ignores "small", for me at least.

 

Range:

Breast@0.1:1.0

 

Link to comment

Not sure if intended, but this app does not generate ranges. It takes "big" values from .xml preset but ignores "small", for me at least.

 

Oh, you're gonna have to use the "Edit Sliders" function to set the range. Added templates will initially use the big values.

 

Thing is, if you have all sliders set to use a range from say, 0% to 100% weight, you'll most likely get weird body proportions because you're randomizing all sliders "individually", specially if the range gap between the small and big is too far.

 

If you want to randomize between the body weights of a preset, like say, you want to randomize between a template called CBBECurvy at 100% weight and the same CBBECurvy but at 50% weight instead. A way to do that is: Add your template "CBBECurvy", by default it will use 100%, then "duplicate" it, rename the duplicate to "CBBECurvy-50" just so you know, then while selected, click "Edit Sliders", then set all of its sliders to 50%.

And you now have "CBBECurvy" which uses the 100% weight and "CBBECurvy-50" which uses the 50% weight.

Of course you're gonna have to add both "CBBECurvy" and "CBBECurvy-50" templates to your target morphs.

 

If you just want to randomize the range of a single slider like say, the Hips, you just go to "Edit Sliders" then set the Hips' "Min" to 0% and its "Max" to 100%, whatever your desire range is. This means actors that gets this template in-game will use the same body type, but will appear to have different hip sizes.

 

Of course, manually editing the templates by hand will give you more flexibility since you can use the "|" (OR) operator but that's not the point of converting a BodySlide template to BodyGen.

Link to comment

Thing is, if you have all sliders set to use a range from say, 0% to 100% weight, you'll most likely get weird body proportions because you're randomizing all sliders "individually", specially if the range gap between the small and big is too far.

Yes, but leave that responsibility to presets author, not the app. I have preset with min and max values and I really want to randomize all sliders individually. Manually setting "min" to zero isn't the answer either, because my preset might not be using 0's as min for most sliders.

 

Stacking morphs (another example mentioned by yourself) on top of each other would also apply full morph from first template then full morph from second template, giving the result that has nothing to do with original preset.

 

Perhaps there could be options to select "import only max" and "import only min", but by default, in my opinion, it should import complete preset.

Link to comment

Yes, but leave that responsibility to presets author, not the app. I have preset with min and max values and I really want to randomize all sliders individually. Manually setting "min" to zero isn't the answer either, because my preset might not be using 0's as min for most sliders.

 

Stacking morphs (another example mentioned by yourself) on top of each other would also apply full morph from first template then full morph from second template, giving the result that has nothing to do with original preset.

 

Perhaps there could be options to select "import only max" and "import only min", but by default, in my opinion, it should import complete preset.

 

It "does" import the complete preset.

The sliders uses "percentage" which refers to the weight in BodySlide, not the actual slider value.

So if your preset's small value (zero weight in BS) is 0.1, setting that slider with "Edit Sliders" to 0% will give you the value of 0.1 not zero.

 

Example, if in your BodySlide you have:

(Low Weight) AppleCheeks = 15%

(High Weight) AppleCheeks = 100%

 

Converting it to BodyGen and then setting its min slider to 0% and max slider to 100% will give you:

AppleCheeks@0.15:1.0 NOT AppleCheeks@0.0:1.0

Link to comment

It "does" import the complete preset.

The sliders uses "percentage" which refers to the weight in BodySlide, not the actual slider value.

So if your preset's small value (zero weight in BS) is 0.1, setting that slider with "Edit Sliders" to 0% will give you the value of 0.1 not zero.

 

Example, if in your BodySlide you have:

(Low Weight) AppleCheeks = 15%

(High Weight) AppleCheeks = 100%

 

Converting it to BodyGen and then setting its min slider to 0% and max slider to 100% will give you:

AppleCheeks@0.15:1.0 NOT AppleCheeks@0.0:1.0

My mistake, sorry, I meant export not import, because you do import it internally, yes. So the options could be "export only max" (current default) and "export only min".

 

About 0% giving the 0.1, yes I see it now, but its still non-intuitive.

 

In my opinion, the sliders should start at: min=0% and max=100% by default. Also current buttons (red, green, blue) and "all" slider could be separate for min/max.

Link to comment

Bug report: inverted sliders in default settings.json seem to be messed up:

"DoubleMelon": 1, - why multiply by one?
"Hips": 0.33,  - ??????

The correct settings are (all -1):

Breasts
BreastsSmall
NippleDistance
NippleSize
Arms
ShoulderWidth
ButtCrack
Butt
ButtSmall
Legs
Ankles

You can find them in (search for invert="true"): ..\CalienteTools\BodySlide\SliderSets\CalienteBody.xml

 

[EDIT]: Fixed settings.json

 

Removed 3 sliders from "Defaults" that aren't used by CBBE BaseShape (BreastGravity, Thighs, Belly) and sorted in same order as in CalienteBody.xml. Feel free to include as default:

 

 

 

{
  "Defaults": {
    "Breasts": {
      "valueSmall": 0.2,
      "valueBig": 1
    },
    "BreastsSmall": {
      "valueSmall": 1,
      "valueBig": 1
    },  
    "NippleDistance": {
      "valueSmall": 1,
      "valueBig": 1
    },
    "NippleSize": {
      "valueSmall": 1,
      "valueBig": 1
    },
    "Arms": {
      "valueSmall": 0,
      "valueBig": 1
    },
    "ShoulderWidth": {
      "valueSmall": 1,
      "valueBig": 1
    },
    "Waist": {
      "valueSmall": 0,
      "valueBig": 1
    },
    "ButtCrack": {
      "valueSmall": 1,
      "valueBig": 1
    }
    "Butt": {
      "valueSmall": 0,
      "valueBig": 1
    },
    "ButtSmall": {
      "valueSmall": 1,
      "valueBig": 1
    },		
    "Legs": {
      "valueSmall": 0,
      "valueBig": 1
    },
    "Ankles": {
      "valueSmall": 1,
      "valueBig": 1
    },
  },
  "Multipliers": {
	"Breasts": -1,
	"BreastsSmall": -1,
	"NippleDistance": -1,
	"NippleSize": -1,
	"Arms": -1,
	"ShoulderWidth": -1,
	"ButtCrack": -1,
	"Butt": -1,
	"ButtSmall": -1,
	"Legs": -1,
	"Ankles": -1,
  }
}

 

 

Link to comment

Bug report: inverted sliders in default settings.json seem to be messed up:

"DoubleMelon": 1, - why multiply by one?
"Hips": 0.33,  - ??????

 

Haha, I'm aware of both of these, well, the DoubleMelon one does nothing since it's multiplying by 1.

It sort of came from an earlier update where the DoubleMelon is inverted from what I read in shoka's documentation thread. I noticed something's off and that seems to be it.

It's just an explicit entry in the settings. You may delete it or don't, default values for undefined multipliers is 1 anyway.

 

I've put 0.33 for the Hips because when I was testing the morphs in my game, 1.0 seems to go further than it should in-game.

My template with a Hip slider value of -300% in BodySlide seems to collapse inwards in-game when it does not seem to do so in BodySlide preview. So I've conjured up the 0.33 value and it seemed fine, okay... not sure if accurate, but okay.

Yeah, if you think it seems off in your game, feel free to set it back to 1.

 

The default value of Belly, Thighs and BreastGravity for both valueSmall and valueBig is zero, so it won't really do anything on your imports if you don't use those sliders. Another explicit definitions in the settings.

 

I'm under the assumption that people mostly uses 100% weight when they design their template since most templates I've scoured upon doesn't seem to put much thought into the Low Weight sliders, sometimes none at all.

I think 0% for min and 100% for max shouldn't be the default. I mean, the point of a conversion is that so you can easily see what your morphs will look like in-game from the BodySlide preview. So randomizing values in between Low and High will yield "different" results.

 

The separate All sliders for min and max has crossed my mind but I thought it's not something I would use most of the time.

Because well, using ranges could have undesirable results if not calculated carefully on sliders.

And if I were to use ranges, it'll just be on a few sliders and I wouldn't have touched the All slider.

But I agree, it could be convenient to some.

Link to comment

I'm under the assumption that people mostly uses 100% weight when they design their template since most templates I've scoured upon doesn't seem to put much thought into the Low Weight sliders, sometimes none at all.

 

I think 0% for min and 100% for max shouldn't be the default. I mean, the point of a conversion is that so you can easily see what your morphs will look like in-game from the BodySlide preview. So randomizing values in between Low and High will yield "different" results.

Yes, I know that most presets are made for player and for max weight only, but the sole purpose of BodyGen is to assign randomly selected body parts among NPCs. You can't do it RANDOMLY by setting 100% weight preset (the same body) to everyone.

 

Assigning some specific preset to specific NPC is feasible, but its not the core feature of BodyGen (we could always do that by editing them in CK).

 

Anyway, I've noticed that "ranges" where min and max values are same are getting replaced with single value (by this app). So even if it was generating 0-100% range by default (my suggestion), when loaded with "max weight only" preset, it would still end up generating single value template!

 

BTW, I like the app and found it useful, so I'm throwing ideas out of my ass, don't take it as criticism by any chance (just saying)!

Link to comment

None taken! I did put a disclaimer on the description.

 

 

It was written on a whim and I haven't tested it much, so feel free to give it a run and tell me if there's something wrong.

 

I'll just try to explain on why I made things the way they are.

 

Though I prefer assigning specific presets or assigning random presets from a list.

I don't think you can do that with the CK, plus CK is a pain.

Ranges are great for that extra "surprise me!" factor. A good example is using the same preset but only using a range for say, the butt, with that you'll have a variety of butt sizes. But it can be somewhat disappointing at times, like say, the randomization ended up unsatisfactory to your tastes, what are you gonna do?

Another scenario is if the randomization worked too well on a certain actor but not for others, this means if you want to change the others, you're gonna have to reset or clear your .skse co-save file with something like "NetImmerse Override Cleaner", this means you'll also be clearing that "perfect" result of randomization and you'll be having a hard time doing that because there's no way for you to know the exact values that came from the randomization!

Well, you could wait for a new version of skse cleaner and hope it has a new option to clear only specific actors but even that will require you to skim through a bunch of Form IDs and that would be tedious.

 

With specific presets, it's easy to determine what preset an actor is assigned with:

"Hey! Preset#1 kinda suits Lydia! But Preset#2 doesn't look good on Ysolda... Maybe I'll just clear my skse save file and assign Lydia Preset#1 and give Ysolda Preset#3!"

This is a common scenario that I encounter in my latest play-through.

It may not be ideal for everyone, but it works for me.

 

The reason for that single value might be because the small and big values in that preset have the same value!

Something like "Slider@0.5:0.5" is not necessary and "Slider@0.5" would suffice.

Link to comment

no way for you to know the exact values that came from the randomization!

I do it with my debug script:

Event OnKeyDown(Int KeyCode)
	If KeyCode == 2
		DumpMorphs(Game.GetCurrentCrosshairRef())
	ElseIf KeyCode == 3	
		DumpMorphs(PlayerRef)
	EndIf
EndEvent

Function DumpMorphs(ObjectReference akTarget)

	string[] morphNames = NiOverride.GetMorphNames(akTarget)
	string[] morphKeys
	
	Debug.Trace("========================================")
	Debug.Trace("	Morphs for " + akTarget.GetBaseObject().GetName())
	Debug.Trace("========================================")
	
	int j = morphNames.Length
	int i = 0

	While i < j
	
		morphKeys = NiOverride.GetMorphKeys(akTarget, morphNames[i])		
		Debug.Trace(morphNames[i] + ": ")	
	
		int g = morphKeys.Length
		int h = 0
		
		While h < g
			Debug.Trace("	" + morphKeys[h] + ": " + NiOverride.GetBodyMorph(akTarget, morphNames[i], morphKeys[h]))
			h += 1
		EndWhile
		
		i += 1
	EndWhile

	Debug.Trace("========================================")	
EndFunction

and ClearBodyMorphKeys(ObjectReference ref, string keyName) to clean stuff.

 

The reason for that single value might be because the small and big values in that preset have the same value!

Something like "Slider@0.5:0.5" is not necessary and "Slider@0.5" would suffice.

I know its intended, but what I meant is that would allow you to generate 0-100 by default and still get single values for "max-weight-only" presets just as you like. :)

Link to comment

I do it with my debug script:

 

and ClearBodyMorphKeys(ObjectReference ref, string keyName) to clean stuff.

 

I know its intended, but what I meant is that would allow you to generate 0-100 by default and still get single values for "max-weight-only" presets just as you like. :)

 

Well, writing a script mod specifically for it is one way of doing it.

 

So you'll dump the morphs, recreate it in BodySlide slider by slider, then reassign it?

And if you happen to not like the result on an actor, you'll call upon ClearBodyMorphKeys function in-game?

 

By the way, if you managed to clear an actor, would new morphs reapply immediately or would you have to restart the game? Because the latter would be a bit tedious but could still be convenient in a lot of situations. But if it does reapply immediately, that would be awesome.

 

I didn't catch that last one, what do you mean generate 0-100? What were you expecting?

And what is "max-weight-only" preset? Is it a preset created in BodySlide that doesn't have low weights? Or an imported preset in the converter that has all sliders set to 100%?

Link to comment

Well, writing a script mod specifically for it is one way of doing it.

 

So you'll dump the morphs, recreate it in BodySlide slider by slider, then reassign it?

And if you happen to not like the result on an actor, you'll call upon ClearBodyMorphKeys function in-game?

No, that was just an example of checking their morphs. I don't change their morphs usually because morphs of the actors I care about (the player and followers) are controlled by RM and EFF anyway.

 

I didn't catch that last one, what do you mean generate 0-100? What were you expecting?

And what is "max-weight-only" preset? Is it a preset created in BodySlide that doesn't have low weights? Or an imported preset in the converter that has all sliders set to 100%?

"max-weight-only" or "single-weight" is the type of BodySlide presets you mentioned earlier, where the preset has one weight only (min is copied from max).

 

I meant that if the app was generating BodyGen templates for 0-100% weight range BY DEFAULT (which was my original suggestion), it would still keep its current functionality of generating only ONE/SINGLE/MAX value morphs for "single-weight" BodySlide presets, without changing any additional options.

 

So if you are using these "single-weight" BodySlide presets usually (as you mentioned earlier), you would still end up with single values BodyGen template instead of ranges. WIN=WIN

Link to comment

"max-weight-only" or "single-weight" is the type of BodySlide presets you mentioned earlier, where the preset has one weight only (min is copied from max).

I meant that if the app was generating BodyGen templates for 0-100% weight range BY DEFAULT (which was my original suggestion), it would still keep its current functionality of generating only ONE/SINGLE/MAX value morphs for "single-weight" BodySlide presets, without changing any additional options.

 

So if you are using these "single-weight" BodySlide presets usually (as you mentioned earlier), you would still end up with single values BodyGen template instead of ranges. WIN=WIN

 

Ah, I get it. You mean those left and right arrows in BodySlide that copies the low weight to high weight and vice-versa so there would be no changes between low and high.

 

I still think that setting it to use ranges as the default is against the "What You See Is What You Get" point of the converter.

Also, most can't be bothered to fire up BS just to click copy, well, they could just use Edit SetSliders and click 100 All, but that's another thing to worry about.

 

So what I think is, just add convenience buttons and sliders for those who wanted to set the ranges,

hence this update:

 

Updated converter tool.

 

Updated (May 3, 2017)

Added convenient buttons and sliders for setting all min and all max.

Link to comment

I still think that setting it to use ranges as the default is against the "What You See Is What You Get" point of the converter.

WARNING: "It exports only half of your preset by default, to export second part fill CAPTHA". ;)

 

Link to comment

[EDIT]: Fixed settings.json

 

 

 

{
  "Defaults": {
    "Breasts": {
      "valueSmall": 0.2,
      "valueBig": 1
    },
    "BreastsSmall": {
      "valueSmall": 1,
      "valueBig": 1
    },  
    "NippleDistance": {
      "valueSmall": 1,
      "valueBig": 1
    },
    "NippleSize": {
      "valueSmall": 1,
      "valueBig": 1
    },
    "Arms": {
      "valueSmall": 0,
      "valueBig": 1
    },
    "ShoulderWidth": {
      "valueSmall": 1,
      "valueBig": 1
    },
    "Waist": {
      "valueSmall": 0,
      "valueBig": 1
    },
    "ButtCrack": {
      "valueSmall": 1,
      "valueBig": 1
    }
    "Butt": {
      "valueSmall": 0,
      "valueBig": 1
    },
    "ButtSmall": {
      "valueSmall": 1,
      "valueBig": 1
    },		
    "Legs": {
      "valueSmall": 0,
      "valueBig": 1
    },
    "Ankles": {
      "valueSmall": 1,
      "valueBig": 1
    },
  },
  "Multipliers": {
	"Breasts": -1,
	"BreastsSmall": -1,
	"NippleDistance": -1,
	"NippleSize": -1,
	"Arms": -1,
	"ShoulderWidth": -1,
	"ButtCrack": -1,
	"Butt": -1,
	"ButtSmall": -1,
	"Legs": -1,
	"Ankles": -1,
  }
}

 

 

 

By the way, I forgot to mention, if you're using this exact same setting you posted, there's some slight error in the json format that might cause problems:

 

...

    "Ankles": {

        "valueSmall": 1,

        "valueBig": 1

    },                                   <--- Excessive comma

},

 

"Multipliers": {

    "Breasts": -1,

    "BreastsSmall": -1,

    "NippleDistance": -1,

    "NippleSize": -1,

    "Arms": -1,

    "ShoulderWidth": -1,

    "ButtCrack": -1,

    "Butt": -1,

    "ButtSmall": -1,

    "Legs": -1,

    "Ankles": -1,                  <--- Excessive comma

}

Link to comment

Yeah, noticed that the app wouldn't even start with these settings, just after I posted them. Didn't report when I saw you couldn't even be bothered to include it in new version.

 

[EDIT]: Eh, app still doesn't start even with these two commas removed?

Link to comment

Yeah, noticed that the app wouldn't even start with these settings, just after I posted them. Didn't report when I saw you couldn't even be bothered to include it in new version.

 

[EDIT]: Eh, app still doesn't start even with these two commas removed?

 

Well, those aren't really bugs, those were deliberate changes and would really make no difference on the results either way.

But the Hips multiplier, of course, is still open for further inspection.

 

Really? Can you try deleting the settings.json file and running the app? This should recreate the settings file.

Link to comment

Well, those aren't really bugs, those were deliberate changes and would really make no difference on the results either way.

Its all to make inexperienced users less confused.

 

Really? Can you try deleting the settings.json file and running the app? This should recreate the settings file.

Recreating works, but after modyfing their order the app doesn't start.

 

settings.json

 

 

Link to comment

Wow, things have happened since I last uploaded this.

 

First of all, I'm sorry for not responding and not giving any support. The sad truth is that I just cannot - I have no time or energy to support at this point.

 

However, I did write a version of this with GUI support. I am now planning to read the comments above to correct any bugs. I will then post the code here. The code is not the best, but perhaps people will find it useful. I might even be able to convert it to an exe.

 

The problem is that as with everything that involves BodyGen, this requires a level of knowledge to use and operate. Hopefully the GUI will be explanatory enough.

Link to comment

i don't understand why BodyGen receives so little attention. I actually almost got it to work the way I want which feels so good, really.

Is here anyone who knows how morph.ini filters work?

The most interesting thing is the plugin.esp filter. Leaving it alone like "xxx.esp=body" seems to crash the game, adding "All", "Female" in any combination doesn't crash, but doesn't do anything neither. The only thing that works with it is "xxx.esp | id=". So if I want all npcs only from an esp have the morph I have to put them all as ceparate lines? That would be terryfying since esp has over 200 npcs. Is there a workaround?

 

It really is a pity if such cool feature only has 3 filters: ".esp | id", "all | female", "all | female | race"

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • 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