This was made mainly for slime girl penetration. I have not tested other cases where transparency would make sense.
+krea2:
The dataset is the same as v5 for Illustrious which honestly worked better than expected (since the captions are still all booru tags). Krea2 doesn't have a good understanding NSFW stuff so you might need other LoRAs to help with certain concepts and positions. You don't need any specific bypass nodes or LoRAs to "unlock" Krea2, the LoRA(s) just need(s) to be good enough (and this one does seem to be good enough for that). I also haven't had enough time to do a lot of testing with Krea2 yet so there could be other issues I'm not aware of. Euler + beta works well for 8 step turbo generations.
v5 update:
I went through and fixed most of the transparency & anatomy issues still present in the dataset. So now transparency should be better, make less patchy slime, and work for more things (like fisting, fingering, multiple penetrations). Note that there are still issues with high/from above angles, size differences for oral, and the orientation for some unique penetration types. Using a big stack of loras and/or a lot of high tag weights will also make proper transparency significantly harder to get.
Getting proper transparency to work with slime girl penetration is a pain. Most approaches either use x-ray (which looks weird for slime girls), do some complicated prompting workarounds, or just deal with low annoyingly low success rates.
The dataset is a mix of different resolutions, aspect ratios, slime colors, positions, and penetration types. It should be pretty responsive to color and transparency in most cases. You may need other loras to get concepts such as fisting, fingering, multiple penetration, etc. properly consistent though.
translucent penetration should be the only thing needed to trigger it, but you might get better results with additional tags/phrases such as slime girl, (object) in slime deep penetration, perspective, goo girl, monster girl, (color) skin (such as blue skin, green skin, multicolored skin, etc), (object) visible through body, etc. Some penetration types might work better with specific angles (especially the types that are still WIP). If you are getting mismatched internal penis sizes you can try adding (disconnected penis:1.2) to your negative prompt.
I recommend pairing this with a dedicated slime girl LoRA (such as DaSiWa-Illustrious-Slime-Girl, Realistic Slime Girls, or Slime Girls - Concept) and a checkpoint that is able to handle NSFW concepts well such as DaSiWa Illustrious | Anime. While a strength of 1.0 should be safe, it's possible the image could end up overcooked with other LoRAs. Try setting it to ~0.7-0.8 if you are getting distorted faces and/or patchy slime. That should be enough to guarantee the concept in most cases, but a good LoRA combination with some good prompting can get it to work with as low as ~0.25.
My typical generation args are either:
steps: 37
cfg: 4.0
sampler: euler ancestral
scheduler: simpleor:
steps: 40
cfg: 4.0
sampler: uni_pc
scheduler: ddim_uniformunless I have Config Skimming enabled then I set my cfg to 16 or 24 with the skimming cfg at 4 or 3 respectively.
If you are having issues with four or six fingers and you are still using v4 or earlier, try updating to v5 and reinforcing your negative prompt.
Description
Changes
Fixed a lot of the transparency & anatomy issues still present in the dataset. As a result there should be less finger/hand deformations, less patchy slime, less "penetrating through", and more consistent transparency overall
Transparency works for fisting and multiple penetrations. It also kinda works for fingers/fingering too.
Issues
It doesn't have a good grasp on the concept of fisting even though the transparency works. A helper lora at ~0.5-0.7 for the concept is needed for consistency
It doesn't quite understand which fingers to apply the transparency effect to for fingering
It won't necessarily respect the position/orientation for multiple penetrations yet. The most likely to work is spitroast (oral + vaginal or anal)
There are some size/orientation issues with oral still
A weight of ~1.0 should still work well
FAQ
Comments (5)
Hey, great job with this model!
Was deep fisting LoRAs helpfull? I'm thinking on improving "shoulder-deep-fisting" dataset, so there may be some merit in cooperation with datasets. Eg me taking some of the slime girls and you taking some of the better deep fisting pictures to make LoRAs work better together.
I haven't tried the Illustrious version of yours yet but the Anima version was definitely helpful. Idk how useful my dataset you be for you though since only 8/301 images in v5 are fisting and only 1 is more than wrist deep.
I'm generally down for cooperation but what I really need are images with transparent fingering and/or perspective from above on most penetration types. So if you have any pov from above fisting images that could be very helpful.
@DustyDrab I suppose by "from above" you mean just top-down with back of recieving person visible? I do have multiple pictures with this point of view for fisting, so if it helps, I will try to make bodyes transparrent (or to be more precise leave only contours of it).
For the amounts - even just a couple of images can help. After all idea is to just add knowledge to base, so that LoRAs won't conflict with each other.
And as I understand, 300 images is sort of too much for just a LoRA. Don't know, if you have experimented with smaller datasets or bigger Dim/Alpha values or different types of adapters (LyCORIs for example seem to have more strict effect in cases when concept is not present in base checkpoint), but it may be worth it in the future.
@WannaBeWoman Yeah from above would be like this for example.
For the dataset, the number of steps and quality of the images are a lot more important than strictly the number of images. The images just need to showcase the concept well enough, have enough variation, and not introduce issues like anatomy errors. I did 10 epochs for my 301 images which was more than enough especially with Prodigy as the optimizer. More images just means more variation in the dataset, errors in individual images (usually) matter less, and using a higher rank will work better (higher ranks also seem to be more sensitive to errors in images tho).
@DustyDrab thanks for usefull info. If I get good results with images - will post them on civitai. May be in this model gallery, but we'l see.
For dataset size and rank I usually have seen explanations, that rank is pretty much the amount of data, you can store. No matter how big the dataset is, past some point, defined by rank, nothing else fits and you are just wasting time.
Observation about errors in higher rank is definetly correct, but it is more about general amount of details. Errors are just more visible.










