It looks like you're new here. If you want to get involved, click one of these buttons!
We hope you're doing well!
We've managed to get a lot of stuff done this month. The light at the end of the tunnel is getting brighter each day, and we're very excited!
Let's just jump into it!
Audited by bank
Before we begin, I feel the need to tell you about a recent interaction we had with our bank, because it has affected us mentally as well as our ability to work.
Apparently, according to new regulations in the EU, banks are obligated to know their customers much more closely now than before in order to prevent money laundering. The way banks in our area seem to have interpreted this is to require customers running businesses to set up a special type of account that require significant questioning before being issued. Not only that, but regular customers also need to answer questions.
Recently, our bank created obligatory forms asking all their customers (private individuals as well as businesses) how exactly they are using their accounts and where money is coming from. During this auditing process, it was discovered that we've been using a regular bank account for business activity, which is not permitted anymore, even if it's just a sole proprietorship. For this, you need this special business type account.
In order to acquire such an account, you have to send in an application, fully detailing what it is you're doing, where the money is coming from, how much is being spent each month and so on. They look at this request, and then call you back within 10 banking days, where they will then ask you even more in depth questions. As you might imagine, knowing this is what we would have to go through to acquire a bank account we can use for our business put us in a bit of a distress, because we had no idea how they'd feel about our kind of work. I mean, there's nothing illegal in what we do, but we genuinely feared they might take offense to this type of content, or somehow think it isn't in line with their policies or something. We just didn't know what to expect. So as soon as we learned that this audit was going to happen, we immediately started working on a script, trying to anticipate what they might ask and what the best way to answer their questions might be.
Not knowing when exactly they'd call was very troublesome, because it was tough to put it out of our minds, which interfered with our ability work. The possibility of your income being stripped away from you was mentally really tough to deal with, and there was nothing we could do but wait for them to call to actually know what was going to happen. Eventually, after a few days of feeling almost sick of worry, it started feeling better and I was able to start working somewhat normally again.
The day when they called finally arrived 11 days after we sent in the application, and as it turns out, our fears were completely unnecessary. The call was a little bit awkward, naturally, but other than that they were super cool about it. We spoke for 27 minutes and I thoroughly explained what we're doing, how our work is financed, how Patreon operates and so on. We got our business account, so hopefully we should now be able to put this behind us and continue to work in peace!
In our last post, we mentioned some of the tasks left to do before we can have a release - saving and loading being one of them. This month, we're happy to say we've finally got this going! This was a rather big task that we didn't know just how much trouble it was going to give us. YL2 is a very complex application, so I feared this was going to give us many headaches. Some refactoring was necessary, but other than that, I must say things have worked out smoother than I thought they would. Sure, some problems here and there, but not anywhere near as bad as I thought it would be. It's almost as if it was a bit too smooth which has left me feeling a little bit paranoid. Surely, there must be a bug lurking somewhere in there! I'm sure there is, but it isn't showing itself atm. I'm certain we'll have to revisit this topic later on once we have an internal dev build that we can start testing with, but as far as saving and loading is concerned for all the components we've tested, it seems to work fine in Unity Editor!
I'm not sure if there's that much else to say really, so here are two pictures showing it in action:
(Silly example of saving a character that has been configured.)
(Loading said character. Here we can see texture builder, balls, shaft, nipple, eyes and custom parts (in this case ears) being loaded properly. Body types and work too, but we recently changed the UVs and our body type maps haven't been updated yet so they don't line up with them. That's why we chose not to show a body type.)
We've started working on a pose mode inside the app. The idea is to allow the user to try out different poses for the character being authored, and also save these poses (a bit like a pose library in Blender). We want to complement this with a "simulation mode", which would be something similar to the "test" mode in Yiffalicious, i.e. the character starts moving a bit and appears to be alive. In this case, that's when gravity would be applied, so you can see how exactly boobs would look when being affected by gravity.
(We've started working on a pose mode for the character creator.)
(Nodes automatically activate when you use them, so there's no need to press "C" like in Yiffalicious. You can still deactivate an activated node though.)
For YL2, we want to improve on every aspect of the app, and naturally tits are not an exception to this. That's why we've been researching how we could rig things a little bit differently this time around in order to achieve more jiggly, squishy and generally better behaving boobs.
Here you can see the results of our research:
(We're experimenting with a new a new tit rig that will offer more jiggly and squishy boobs. Her left side is rigged according to new method, while right side is rigged in the old way.)
Automatic corrective shape generation
This was another big task that we mentioned in our previous post.
Essentially, in Yiffalicious we noticed that with the boob sizes that we have, there would be ugly distortion if we modeled the characters' breasts in hanging fashion (with gravity) for other situations than that base pose (hanging). Not only mesh wise, but also map wise, because if maps were baked with the boobs hanging, then the crease beneath the boobs would look very strange for other situations, for example if they were hanging forward (the character bending over). Therefore, with later characters (after Maya I think), we started modelling our characters in "zero gravity", i.e. with boobs standing right out. This would also make the baking process produce maps that were less situational and more well-rounded.
When it comes to bone deformation, it's generally a good idea for the base pose of the character to be "in the middle" of that character's possible poses, simply because that will require the least amount of deformation to reach a desired pose. That's also the reason why we started modelling our characters in X-pose (with the legs spread), because then the legs will require less rotation to reach any of the poses those legs can be in than would otherwise be required if the character was modeled standing.
However, modelling tits in this zero gravity fashion has its own downsides, namely that the hanging pose (when gravity is applied) doesn't look as good as it would have if the boobs were modeled like that from the beginning (which isn't that surprising if you think about it). The way we solved this was by creating "corrective shapes" for the situation when the boobs are hanging (as well as some other situations) - essentially an adjustment that is applied to make it look good.
Someone might ask why we didn't just model boobs regularly with gravity and then create corrective shapes for non-hanging poses. The reason for this is simply that those correctives would require much more significant vertex offsets than if we simply created correctives for a more "in the middle" kind of pose. You can picture if as a joystick being calibrated for a middle position rather than for a special kind of tilt - naturally it's better to pick the middle position. Also, the issues with map baking was another contributing factor to why we started with zero-gravity, as we explained above.
Before, these corrective shapes were something we manually created on a per character basis inside our authoring tools. However, that's something that wouldn't work in YL2, for several reasons. In order to achieve the best quality corrective shape, it needs to be made for a specific shape. But the final shape of a user's character isn't really known prior to user authoring, so there's no way to pre-make these corrective shapes. Furthermore, even if we wanted to, we don't even have access to the shape of the skeleton for the different body types in our authoring software, as that's something that's computed during runtime in our systems in Unity. Therefore, we wanted to try and see if we could automate this shape generation inside Unity during runtime as well, because it's essentially just a modifier being applied ("corrective smooth" in Blender).
We're happy to say we have been successful in this endeavor, and now have a system that's essentially a 1 to 1 parity with its blender counterpart as far as results are concerned. Our implementation is far more performant than Blender's though. Generating 1 corrective shape in Blender takes many seconds to do, but in our implementation, we are able to create multiple correctives at the fraction of a second. This is thanks our computations being implemented on the GPU rather than the CPU, which speeds things up significantly. So now we can generate corrective shapes at runtime tailored specifically for any character shape that the user has configured. SUPER COOL!
(The difference correction shapes make on hanging tits.)
(The actual correction shape itself looks quite crazy and counter-intuitive. But here it is! The idea is to apply this shape gradually as the breast hangs down - just like in Yiffalicious. The difference now is that these shapes are automatically calculated, requiring zero authoring on our part!)
Some of you may remember that we mentioned SSS (surface scattering) in a post many months ago. SSS is a feature that HDRP - the new rendering pipeline for Unity - has native support for. However, as HDRP is still in development, we've found ourselves to be quite heavily invested into the current "built-in" rendering pipeline of Unity. Not only in terms of our custom made material shaders (which are becoming quite many), but also for techy stuff like hooking into the rendering setup for our mesh blending tech. Furthermore, HDRP seems to not really perform at the framerates we would hope, and considering just how much GPU compute YL2 will use, we feel uncomfortable moving over to HDRP at this point. Therefore, we have decided to continue using the built-in pipeline for YL2.
This poses a problem however, as we really want to get SSS into it but built-in doesn't support it natively. That's why we this month have been looking into options for achieving SSS in the built-in pipeline.
After some research, we're happy to say we think we have a viable method of achieving SSS in YL2 at very good framerates. We think our solution provides a very noticeable visual improvement:
(Toggling a custom SSS effect on an off in the built-in pipeline. It's a subtle effect but that really makes a big difference in the appearance and interpretation of the object.)
(Still image. For comparison, here's the same object w/o SSS.)
For comparison, here's what the HDRP SSS looks like:
(SSS in HDRP, for comparison with our solution for built-in pipeline.)
Considering how much better our solution performs compared to HDRP, I'd say we're quite pleased with the looks of it!
Our custom solutions uses the best parts of many different SSS assets, combined into a new tech that performs very well while producing OK results, and w/o requiring special materials (which is a huge bonus!). It operates exclusively as a post-rendering step. Thanks to shader trickery, the objects receiving the effect are not required to be rendered again (only the actual post-processing effect itself requires draw calls), which is seemingly unique for our solution. Other solutions would require many more draw calls, and sometimes even require the entire scene to be rendered twice, which is totally unacceptable! That's why we chose to invest time into this custom solution that performs far better.
Some work still remains to actually get this into YL2, but it is our hope that we'll be able to add this for the initial release of the character editor.
Content iteration efficiency improvements
Iteration is everything in game dev. So this month, as we're getting closer to an internal dev-build, we've put effort into improving iteration times. We have now split up our projects into two smaller ones - one for the code, and one for the content.
YL2 Batch Tools is now able to easily and quickly export assets to this second content Unity project with a simple button click. YL2 Batch Tools will export objects with the correct settings, name and put each one of them into the correct folder structure. Then, inside Unity, we have created a custom asset build pipeline where assets are processed and compiled into an AssetBundle. This asset bundle is then used by the YL2 build. This means dogson can work freely and try out new assets inside the build, without having to involve me or without having to create a new build, which speeds up iteration times significantly. This also means we in theory can keep adding content without changing the build.
(YL2 Batch Tools is able to quickly export our source files/baked textures from our source folder structure to the one inside our Unity project.)
(Inside Unity, we have set up a special project for building asset bundles separately from the actual code build itself.)
What lies closest ahead is getting an internal dev-build that we can start testing, and that dogson can start creating asset bundles for to test the content. We will most likely run into some problems during this process that need to be solved, but hopefully things should be working fluidly after some time.
We need to continue our work on the pose mode, and also start implementing the simulation mode - which will require us to rig and implement boob dynamics.
In general, I think as we're starting to test the dev-build, we will run into many unexpected issues that needs solving.
So these are the things we're going to work with until next update.
Despite distress caused by being audited by our bank, we've still managed to make some great strides this month. Saving and loading has been implemented as well as automatic corrective shape generation - two very big tasks we are proud to have accomplished. A pose mode for the character creator is also something we've started working on.
We've also been experimenting with a new tit rig that will offer higher quality boob behavior. Realtime sub surface scattering is another topic we've been looking into, and results are promising.
Finally, we've spent much time setting things up for faster content iteration times.