Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

YL2 - Balls & body proportions

odesodes Administrator
Hi all!

We hope you're doing great!

We've managed to take some great strides this month. Let's just jump right into it!

Blending tech deferred renderer adaptation

In our post detailing our struggles with achieving mesh blending, we explained that we had to abandon the deferred renderer in favor of the forward renderer in order to make the tech work as desired. This was however never something that sat well with me, as a deferred renderer is simply just more efficient than a forward renderer (especially if you have multiple dynamic lights), and if there's something I value in games and apps, it's performance.

For the initial release, Pegashis has been working on a new environment that has yet to be shown to our fans. (It will be somewhat of a surprise.) This environment is quite intense, and so it pushes hardware a bit. When I finally got my hands on this map and started making tests, I discovered to my dismay that the forward renderer simply wouldn't be a viable option for us. When using the forward renderer, we were essentially cutting the framerate in half compared to the deferred one. Clearly this was unacceptable. And so, it was back to the drawing board for me, trying to figure out a way to make mesh blending work in the deferred renderer.

After lots of testing and frustration, I'm happy to say that we finally have a mesh blending tech that works with the deferred renderer. Below, you can see proof of this:

(Our new mesh blending tech now works in the deferred renderer. The framerate is capped and the scene is nearly empty, so in this case it doesn't make a huge difference. But for bigger environments, it does make a big difference in performance.)

This is great on so many aspects. Not only are we gaining frames from using the deferred renderer in itself, but we also no longer have to render character normals in a custom pass, as this is essentially given to us for free by the deferred renderer. So with that, we have additional frames saved. And as if that wasn't enough, we were also able to eliminate the grab pass from the mesh blending tech, making it even more efficient and saving even more frames.

I don't think I can adequately express the joy and relief of achieving these things!

Kickass bone scaling

Revamping bone scaling was always something I intended to do before initial release, but it wasn't something I had originally intended to do this month. However, one day I didn't wake up quite as well rested as one needs to be in order to work on new and difficult things, so instead I chose to revisit bone scaling, which seemed like a simpler task. And then work sort of just continued on that path. It turned out to be a slightly more complex task that I first anticipated!

Originally, bones were only possible to scale uniformly, i.e. you couldn't make a leg shorter without also making it thinner. This severely limited the amount of things you could do with it, and actually making any meaningful use of it at all for limbs was difficult if not flat out impossible, as demonstrated below:

(Our old scaling method. Since it's uniform, it's hard to use it in a meaningful way.)

So for starters, what we wanted to do was make it possible to scale bones on each individual axis (X, Y and Z). This would not only require us to rewrite the bone scaling tech itself, but also implement visual elements for the display of these types of properties as well as implement their behavior.

(A new cell view for Vector3 properties.)

It wouldn't be enough to do just that however. Since bones reside in a hierarchy, it means if you scale a bone that is the parent of another bone, then both bones will be affected. When using uniform scaling, this may not even be that big of a problem (albeit a bit annoying, since it would force you to go back and re-tweak bones at the end of the hierarchy if bones higher up in it were changed), but as soon as you introduce non-uniform scaling, the parents' scaling may affect lower hierarchy bones in an undesired way:

(When scaling the leg, the feet are affected too since they're part of the same hierarchy. This is undesirable.)

This isn't necessarily a huge issue, since you could just scale the bones at the end of the hierarchy (in the case above - the foot) to "undo" the parents' scaling. Again, it would be a bit annoying, but still doable:

(By scaling the foot after scaling the leg, we could undo the parents' undesired scale. It is however a bit annoying having to do this.)

Our solution to this is quite simple - we move all bones outside of the hierarchy and scale each one separately. Only when all bones have been scaled do we move them back into the hierarchy again. Then we won't have to scale any bones manually to undo the parents' scaling:

(By scaling bones outside of hierarchy, we can undo the children being affected by their parents scale. In this case, the feet remain unaffected even though the legs are scaled.)

HOWEVER, this only works for hierarchies where bones have semi-aligned axis. Look what happens if we scale bones non-uniformly in this fashion in a hierarchy where bones aren't aligned (axis wise):

(Since the bones aren't aligned, the children are distorted in a way that is impossible to correct using solely the children's own scaling.)

(The whole body is distorted when scaling the pelvis bone.)

As you can see, the results are horrific. The parents' coordinate systems distort the child bones in ways that becomes impossible to rectify in the child bones, since the axis aren't aligned. And this is what I meant when I mentioned that this turned out to be a slightly more complicated task than I first anticipated.

I'm happy to say we've been able to work out a solution to fix this problem. So now we're able to not only scale each bone individually without affecting the child bones' scale, but we can do so without causing any distortion. Let's see this in action!

(We're scaling the legs. As you can see, the feet are unaffected and undistorted. Then we can scale the feet along their own axis.)

(You can also scale the upper/lower legs separately, if you'd like.)

(Naturally, since you've got access to each component in the scaling vector, you can scale bones on other axis as well.)

(We're scaling the arms to match the legs.)

(Scaling pelvis and spine to make the body more proportional.)

(The neck felt a little long. No biggie!)

(Scaling the head. You can shift-drag a component to affect all components at the same time, making uniform scaling much more convenient.)

(Naturally, fingers are also possible to scale in any way you like.)

(Making the fingers thicker.)

(Shoulder spacing.)

(Ass is possible to scale too.)

(Final result of the bone scaling.)

This bone scaling functionality combined with our body type system will open up for great versatility in user customization. We can't wait to see what you'll create using these tools!

Revamped shaft options

Once we had this scaling tech implemented, we wanted to revamp our shaft customization options to make use of it. Originally, we were using two blend shapes (one "short" shape and one "long") and a single uniform scaling slider to affect the whole model. Together, these could be used to create both thick, long and in-between shapes for the shaft. However, we weren't happy with this solution, for several reasons:

  • Having to combine length and scaling to affect thickness was counter-intuitive.
  • The user was limited to our pre-authored "long" and "short" shapes. There are a lot of ways a penis could be short, for example. In the case of a knotted penis - when shortening it - should it shorten the knot too or only the shaft part? There was no way to configure this in our old implementation.
  • If you wanted to increase the size of a certain part of the model, let's say the knot, there was no way to do that.
  • Having to author these "short" and "long" shapes costs us extra time. If we can avoid them entirely while at the same time increase user options, obviously that would be preferable.

So using the same scaling tech demonstrated above, we reimplemented the shaft options to use it. Our new implementation has far more options, while at the same time being more intuitive (at least I think so). It also doesn't require us to author any special shapes for the shaft - it's simply just a model - which means we save precious time.

Let's see it in action!

To configure the length of the penis, there are multiple sliders you can use:

(Configure the length.)

(Configure the thickness.)

(You can configure the length of the tip of the penis individually from the rest. After increasing thickness, the glans looked a bit flat, so here we're making it longer.)

The glans distribution curve simply decides which length slider to use along the length of the penis. It's a convenience mechanic to split adjustment of length vs length of glans, which may come in handy when reducing length or when increasing thickness (as above). Let's see how this works in more detail.

(By making the glans distribution only have a value of 1, we're effectively removing the length property and only using the glans length slider for the whole penis.)

(Likewise, when reducing glans distrubtion curve to 0, we're canceling out the glans length slider entirely. Again, the whole idea with separating these sliders is for convenience. You probably don't want to change the glans distribution curve as much as this, but I felt like I needed to explain what it does and how it works.)

(Here we can see having the glans length separated from the base length is useful. When making the penis short, we don't want to distort the glans too much, and having a separate glans slider makes this easier to configure.)

(Another example of what the glans distribution curve does. Here we're moving the point at which the glans length slider starts to "take".)

Let's see how we could use these sliders and the length slider to affect a canine penis:

(When reducing the length of the canine penis, we're also making the knot smaller. In this case, that's not what we want.)

(We can start fixing this by tweaking the glans distribution curve.)

(Lastly, we tweak the length distribution to affect the length in areas in the fashion we want.)

(Thickness also has a curve slider. Here, we're increasing the size of the knot only.)

(You also have access to individual X and Z axis in the advanced section, if you for whatever reason would like to change the size of the penis on those axis.)

With this implementation, we have vastly increased user options while at the same time reducing our own work load. Everybody wins!

Balls authoring

Shafts aren't the only thing to receive some love this month. We've also been hard at work implementing customization for balls.

Originally, balls and inflation for balls were supposed to be pre-authored (just like in Yiffalicious). However, feeling inspired by our progress regarding our newly implemented bone and shaft options, we wanted to see how we could enable our fans to author their own shapes for the balls as well. This is great for many reasons - again, not only increasing user options, but also reducing our work load. It would be a win-win for everyone!

Now when configuring the character to use a balls/sheath model, not only is a specific shaft instance created in the outliner, but also a "BallsSheath" object. The object itself doesn't have any publicly viewable properties. However, when selecting it, 3 node points become visible that you can tweak in any way you like. Move, rotate and scale these nodes to author the ball shape you want!

(When using balls/sheath, a new object is instanced which you can tweak to affect the balls.)

(Tweak the balls to your needs.)

(More tweaking.)

You may already have noticed that the BallsSheath object has a "+" sign next to it, indicating it has child objects. Let's see what that's all about!

(The balls have an inflated state that is tweaked separately from its base state.)

As you can see, the balls has an "inflated" object. By selecting and tweaking this object, you can configure the appearance of the balls in their inflated state.

(You can copy the settings from the base state.)

(Tweak the inflated state as you like.)

(Previewing the balls in their base and inflated state.)

Interpolation between the default state and the inflated one (i.e. inflation slider) isn't implemented yet, but it will be. :)

With all of these options, we believe we are offering our fans a great deal of customization while at the same time reducing our work load. Again, everybody wins!

Areola mask

As you may have seen from our earlier updates, we have a rather unique and advanced areola/nipple tech implemented, that allows you to configure areola/nipples in very custom ways through projection and vector displacement technology. However, there wasn't any convenient way to color areola/nipples in our texture building system. Since the shape of the areola/nipple isn't really present in the model (it's calculated in the shader during rendering using vector maps), it would be very challenging to author maps for them. Clearly, this wasn't good enough. That's why we this month have invested time into creating a special procedural mask for our texture building system made specifically for areolas/nipples.

The character is the only object whose texture builder has access to this special mask. To create such a mask, navigate to the masks of the character's texture builder and click the plus sign. Then, select "Areola":

(Creating a procedural areola mask.)

The mask is connected to the options of the Areola/Nipple object, meaning if you change the size of the areola in the areola/nipple options, it means the mask will be affected as well:

(The areola mask is connected to the areola/nipple options. If areola size is affected in areola/nipple options, then mask is affected too.)

You can still affected the size inside the actual mask itself though. This is implemented as a radius multiplier of the areola size:

(Affect the size of the areola mask, as a multiplier of the areola size in areola/nipple options.)

You can also affect how "soft" the mask is, i.e. how far into the mask the fading from black to white should go, expressed as a multiplier of the mask size:

(Affect the fading gradient of the mask.)

As per usual - a mask by itself doesn't actually do anything. It needs to be referenced in a layer to actually affect the texture output. Here, we're simply using a LayerFillMask to fill the texture output with a pink color:

(Filling the areola mask with color.)

Just to see what it looks like, let's add in a nipple to this!

(Adding a nipple to the setup.)

Hopefully this mask should make coloring areolas/nipples much more convenient!

YL2 Batch Tools

A significant amount of time was spent refactoring the way YL2 Batch Tools work. Previously, we were required to issue the "export" command for each model we wanted to bake before baking, so that the newest of these low poly models would be exported from blender into a format that the baker understands. However, we discovered that this easily became quite difficult to remember to do each time you'd change the low or high poly model, so a lot of times we ended up baking maps for outdated models, which caused problems and cost us time.

I realized that this whole export process could essentially be entirely hidden from the user (in this case dogson) and done in the background instead. So now, we don't even have an export command anymore (for baking that is - we still have one for moving assets to Unity). Rather, when a baking command is issued, then the latest low poly model will be exported automatically (if needed), and all the asset management will happen in the background. This way, there's no room for human errors anymore.

This required quite a significant refactoring, because the system wasn't made for this originally, but I'm happy we did this change because it makes us more efficient in the long run and reduces weight on the mind (fewer things required to be remembered).

We've also upgraded YL2 Batch Tools with other quality-of-life improvements, such as head and teeth maps (which are baked separately) being automatically combined when exported to Unity. In addition to that, we've also added more tests such as checking that parts and body fit with eachother in bone weighting.


In our last update, I mentioned we'd spend time working on dev-builds, pose, simulation and tit dynamics. But, as you see, instead time was spent on the things we've been writing about above. So we got a little bit side-tracked. Not by things that weren't needed to be done, but just in the order which we originally had intended to do them. All of the things above are things that were necessary and that we'd do regardless.

But that means we still have those other things needing to be done, and I suppose now is a good time to do them. Especially content for dev-builds is something we want to get going with ASAP.

An issue we ran into when we started testing content built with our asset bundle project was that since some models are missing skeletons, it means the app would fail to merge the skeletons and would halt. So dogson hasn't been able to test his content inside the app yet, and since I've been busy coding I haven't had the time to add those skeletons to fix it. So at the moment, we're quite bottle-necked by the fact I'm both the coder and the rigger. In the future, when dogson has grown more proficient at rigging, hopefully he'll be able to take over the responsibility of these things.

Luckily, dogson has had a ton of other things to do though, so it's not like we've been losing any time - just that dogson hasn't been able to test his content inside the app yet.

But anyway, fixing those things and starting to test content in our internal dev-build is definitely something that's high up on the todo list.

Release plan

We have a special date in mind when it comes to a release, and we're prepared to make sacrifices to make it happen. For the initial release, we have chosen to cut out the cloud component entirely. That means no internal character browser or sharing. Instead, we will focus on finishing up the last bits and polishing the app as much as we can.

In the meantime, we have created a new section in our forum where you'll be able to share and discuss characters made with the character creator.

The built-in cloud browser and sharing system will arrive in a later release.


The character creator now has tools for great customization of the balls - both in default and inflated state. We've also implemented a new, much more intricate body proportion/bone-scaling system. We have used this new bone scaling system to revamp how shaft customization works. We've also added a new procedural mask to make coloring of areolas and nipples much more convenient. Work has also been spent on improving our internal dev-tools.

We are starting to feel confident about a release and have a special date in mind. We're willing to cut corners to make it happen, and so we have decided to cut out all cloud components from the initial release. Instead, we refer to our forum for sharing characters initially. Cloud features will be added in later.

We will continue to work with getting an internal dev-build up and running so we can start testing and polishing.



  • Bone scaling definitely opens up the body shape space, so that's a HUGE huge plus. I was worried about you abandoning the layered system of body shapes you had originally envisioned, but this more than makes up for the loss in flexibility. In fact, I think that you could get away with very few base shapes now. These few gifs alone feel like several different characters. 

    While 'cutting corners' traditionally means sacrificing quality, I strongly feel it's the right move, and I think whatever sacrifice happens will be worth it and made up for later.  :emoji of encouragement:
     Just to be clear, I'm not saying this so I can get my hands on an alpha sooner, I really do think limiting the amount of features (at least initially) will make for a better result. 


  • A special date... could this mean we get a special christmas present this year? :o

    Anyway, great work, as always. I'm already excited about the possibilities bone scaling opens (and the abominations one could create :D). That first gif reminds me of something... "Babylegs, you're a good detective. But not good enough, because of your baby legs."
  • This game just keeps getting better and better! We already have a lot of customization options for body, nipples, dicks, and balls, but what about vaginas? We have canine dick and horse dick but how about canine or horse pussies? Or other customization like innie pussy, more open pussy or puffy pussy. Maybe even erect clitoris?
    I don´t know, these are just one man's dreams, but adding these features to the character creator is a lot of hard work and takes time.

    Anyway keep being awesome!  
  • Add a meme that if you mess with penis sliders for too long, character will have an orgasm. Solid progress.
  • And will there be an option to get current version with one time payment or something? Like Fek does with Rack 2? Latest build is buyable on
  • This is gonna be awesome. The scaling demonstration is giving me some ideas for shortstack characters :)

    Great to see you guys still trucking along, can't wait to see what you'll show us next!
  • odesodes Administrator
    edited October 2019
    what about vaginas?
    Originally we hadn't intended to offer any customization of vagina in the first build, simply because we don't have the time and vaginas are a bit more intricate than shafts. However, we've started to take a different approach to the challenge of vagina customization, and I think we may now have a solution that is within our reach to implement for the first build. I can't guarantee it though.

    Animal like vaginas are currently not planned in any way.

    And will there be an option to get current version with one time payment or something?
    We used to offer Yiffalicious builds on for a short time. However, after trouble receiving payment and very unprofessional behavior on their part, I don't want to have anything to do with them anymore.

    If you want a build but not become a subscriber, you could just pledge, download the build and then cancel pledge.

    Thanks for your words of encouragement!
  • Very handy and versatile system you've come up with, here. I wonder if it could be adapted and used for facial customization, too. I recall you had some trouble coming up with an easy way to allow for that, so this could be a remedy there as well. Not something you should drop everything to implement, obviously, but worth considering.
  • While small, cute shortstack characters would be great (kobolds anyone?), I'm really hoping to go the opposite direction and made some truly BIG girls, like 8-9 foot busty muscular amazon warrior "death by snu-snu" big women.
  • Wow, looks like things are really coming together! I hope I can make just one tiny suggestion for a new feature, that I hope would be trivial to implement: something built in that estimates the character's height, weight, penis length, and anything else you can think of along those lines. I think Unity natively supports metric, right?

    I figure people will probably be using YL2 to design new fursonas and characters and things, so having that kind of information right there could be really useful for a ref sheet. It'd also help re-create existing characters exactly the size they should be.

    Having a weight based on volume might also help people keep their character sheets realistic; I really commonly see things like "3 meters tall, 200 kilos" and other crazy numbers from people who don't understand the square-cube law (3m and 200kg is the equivalent of a 1.7 meter person weighing 36 kilos, or 5'7" and 80lbs).

    Weight could hopefully just be abstracted from total volume (not including erect penis I guess?) and a density of 0.985 g/cm^3, with a note that muscular characters might weigh slightly more, and fat characters should ironically weigh a bit less than the estimate. I thiiiiiiink total character volume shouldn't be that hard to calculate?
  • That's really sweet. Exactly what I want in YL2 and everyone here. Thank you!

    @odes Would be scaling available during scene in future, like inflation currently? This will give us a lot of space to make new types of scenarios in our scenes.
  • odesodes Administrator

    Can't say that measuring lengths and weight is something that we had planned to include, and it certainly won't be included in the first release. Perhaps just some iconic objects to use as reference (like a soda can or basketball or something). Maybe measurements will be added later, but tons of other things have priority atm.

    Be sure to bring this up once we have our suggestion and voting system in place on the YL2 platform.


    Unfortunately, scaling will not be available during interaction authoring. Inflation will be though.
  • Finally, were gonna get a release. Im really tired with YL1.

    Btw, what will be in the release? Just the character creator? Or...
  • odesodes Administrator
    edited November 2019

    Yes, only the character creator (a very early version of it). The first release is only targeted to enthusiasts and 3D artists.
  • Dang. Wished there would be some sorta interaction system going. Oh well
  • Great job!!! I have a question: in future, add we some humanoid fantasy feature, for example elves face?

  • YL2 is a game only Furry/Anthro/. No humans, elves, draenei and others.

    @odes has already stated in other post ;)

  • How does scaling affect alignment?  I know this is just the character creator, but I have seen many samples of difficulty getting propper interactions working, when there is a bit of height/size difference. 
  • odesodes Administrator
    I'm sorry, I don't quite understand your question. :(
  • I think what he means is, will there be any issues with interactions when the characters are vastly different in size?
  • odesodes Administrator
    edited November 2019
    We haven't gotten to implementing the interaction systems yet. There will most likely be some challenges as regards to difference in size. However, since we're making a tool that lends a lot of artistic freedom to the author, there will always be ways for the author to mitigate it.

    (For example, the authored posing will probably be set up in a way that makes sense for the big x small interaction, rather than treating both as the same size.)
  • edited November 2019
    Three questions if you feel up to answering :]
    1. How do you plan to set up the interaction system?
    2. Will it be similar to YL1 where once two characters are attached they can't be deleted separately?
    3: Will it be possible to set up interactions with oral without having to add multiple transparent character?
  • odesodes Administrator
    The idea is to decouple sex systems from characters, so you can pose characters as you like and then add a sex behavior on top of it. That means you could remove the "connection" while retaining the characters, or delete a character but keep the other one(s).

    And yeah, the idea is to implement a "native" oral sex solver eventually.
  • @odes Thank God, Oral is a pain in YL1
  • Will there be a first person view in YL2 (just like YL1)?
  • odesodes Administrator
    Yes, for the interaction system we will implement a pov mode.
  • YL2 will be perfect then :D
  • @odes Sorry if i'm annoying, but will there be a camera system similar to Blender or will we have to continue to place static characters and using their POv
  • odesodes Administrator
    You mean placing certain camera angles in the scene? And having to use hidden characters for that currently? This could easily be added so you don't need to place characters for that.
  • @odes I bet you must get this a lot but I wanted to ask anyway, when can we expect a public release of YL2?
Sign In or Register to comment.