Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
YL2 Update Jan/Feb 2019 - Body type demonstration!
odes
Administrator
First and foremost, thank you so much for your patience. We know we are late with this update, for reasons we will get into soon.
These past weeks have been a huge trial for both me (odes) and dogson. The body type system and the content authoring for it have been immensely challenging for us, to the point that we were close to giving up on eachother. There were times when we were seriously considering to part ways. But despite the hardships, we endured. If anything, I think this whole experience has made us stronger. In moments like these where uncertainty and setbacks loom, all you really need to know is that if you just keep trying and keep making an effort, it's inevitable that success will eventually be granted. It's with great joy that we can say we're still kicking and still able to provide an update like this for you.
So with all that said, lets have a look at our latest developments and why things are taking the time they do.
Body types
Before we being, let's just summarize what body types are and our thought processes behind their realization.
In Yiffalicious (1), we always felt that the diversity of our characters and their differences in shape was one if not the biggest selling point of the app. Having this diversity just made things so much more interesting, and opened up so many more opportunities for fun and sexy interactions.
When we started working on YL2, we knew we wanted to try and preserve this diversity. At the same time, we also wanted to offer a character editor, but making a character editor that allow for the same amount of diversity as in Yiffalicious is very challenging. An obvious way to circumvent this problem could have been to simply offer two different types of characters - user generated ones made with the editor, and unique "special" characters made by us (similar to how Yiffalicious worked). This way, we could create vastly different characters without having to worry about integrating them into any editor. But we didn't like this approach. We found something profoundly appealing with the idea of all characters being made in the character editor, because this would force us to make all the content we create compatible with it and thus accessible to our fans. So we abandoned the idea of "special" characters to focus entirely on the editor.
Our original idea was to simply use sliders for the shape authoring of the characters in the editor, just like so many other games/applications do. However, we quickly discovered that this approach meant we would either have to limit just how far these sliders could affect the shapes, or limit the amount of sliders, in order for things to work and be manageable. Indeed, even for professional character editors you find in high budget video games, you don't see them able to create characters with the difference in shape and size as between let's say "Fraenir" (male dragon) and "Cat" characters in Yiffalicious. With these editors, it's usually quite easy to see that every character is based on the same model - any differences between them are just slight modifications of that said model. For example, In Skyrim it's easy to see that all the characters are essentially the same. Furthermore, each character that is, let's say, fat, would always look like the same kind of fat even though fatness can look in so many different ways. With our character creator, we wanted to get away from all of these limitations. Being the small team that we are, we knew this would be a huge challenge, but a challenge worth exploring none the less.
In order to achieve our vision of a diverse set of shapes for our characters, we had to abandon the slider based system and instead pursue something different. In search of ideas and inspiration as to what this new system could be, we browsed though content generated by the furry fandom, and came to the realization that most characters are actually based off stereotypical body types. Of course there are differences between all characters, but there definitely are archetypal shapes that can be abstracted and categorized, such as huge muscular dudes, thicc females, short stacks, slender beauties, and so on... So we began working towards this idea - the definition and implementation of body types as a selectable and configurable concept in YL2.
We liked this idea a lot, because it meant we gained full artistic freedom and control of the shape authoring process, allowing us to sculpt these body types individually and in great detail. It also meant we could implement several different versions of the same kind of archetype - for example different kinds of chubby where the fat has accumulated differently across the belly. However, this body type system came with many different challenges:
1. How do we create a generic low poly mesh that is robust enough to encapsulate the diversity of body types that we want to implement?
2. How do we migrate high poly body types to the generic low poly mesh?
3. How do we author different body parts (heads/hands/feet) that fit with each body type?
4. How do we handle parts that greatly affect the body type, such as digitigrade feet?
5. How do we eliminate seams between body and parts so they don't appear as being separate?
In short, it is these questions and our attempts at solving them that has taken us such a long time to tackle.
Generic low poly mesh (1)
This has definitely been one of the bigger challenges of the ones listed above, and also one of the scarier ones. Because when we started with it we didn't really know what this mesh should look like, so we were pretty much reaching in the dark. Each time we encountered a problem, we went back to the drawing board, adapted the mesh to handle the problem, and tried again. There were many times where we thought we had gotten it right, only to be proven wrong later down that path, forcing us to go back and fix the issues. The problem with this is that the longer we had worked on an iteration without any problems emerging, the more invested we would get into it, so when we eventually did run into a problem, any additional content made for this now obsolete model would have to be remade and adapted as well. As you might imagine, this iterative process has cost us a tremendous amount of time, and without really having much to show for it other than simply new variations. This has been frustrating for us - partly because doing the same thing over and over is annoying - but also because we have been working so hard each month, without being able to explain or show the full extent of our efforts. I'm still proud of the progress we've been able to show off in each update, but know that there's usually a lot more going on than we're able to show...
High poly -> low poly migration (2)
Creating a low poly mesh from a high poly model is simple enough, but this is not what we're doing here. Instead, what we're trying to do is adapting an already authored low poly mesh against a high poly model with a completely different shape. Luckily, there are software tools to help with this adaptation process, but learning them and incorporating them into our workflows has taken time. Furthermore, we've had to develop our own methods in addition to mentioned tools in order to get things to where we wanted them to be.
Part authoring & adaptation (3)
Creating and adapting separate body parts that are supposed to fit with a base body model can be quite tricky already as it is, but here we're making the processes even more difficult by having to do it for every body type that we implement. Each part needs variations that fit with every body type. This has been extremely difficult, and has forced us to develop our own plugins for our authoring software in order to author these shapes as well as manage the complexity. Even with these plugins, this work has been immensely difficult and complex, to the point where we've had to do a lot of internal documentation and training sessions in order to remember how to do everything properly. We believe we now have a working method for this task that we're starting to get the hang of. For every new part and body type that we implement, we get a little better at it.
Digitigrade (4)
In addition to having to adapt each part to each body type, we also have to do the reverse for parts that are in digitigrade form. I.e., each body type also needs a digitigrade shape that fits with the digitigrade feet. This isn't necessarily a problem, but it does mean there's more to keep track of, and any adjustments made to one thing will create a rippling effect, requiring changes in others as well, extending the amount of time required to get everything right.
Seamless (5)
The appearance of seams between models can be attributed to two things - 1) the mesh normals and 2) the different texture spaces. So we've had to handle these two.
For the first one, we implemented our own mesh normal calculator that runs on the GPU, making normals across seams point in the averaged direction of the connecting vertices, and thus making them appear as one model. Now, I bet most devs would have been happy with this solution, but of course we were not. Why? Because when importing a model into Unity, its source information of quads is translated into a more GPU friendly triangle representation. Why is this a problem? Well, this can be explained with these images.
Here, the highlighted vertex has 4 adjacent quad faces. The normal of a vertex is the average of its adjacent faces:
However, look what happens if the mesh is triangulated. Suddenly, the very same vertex has 6 adjacent faces! This skews the normals in the wrong direction, as some (formerly quad) faces are counted "twice"!
(When importing a mesh into Unity, it actually uses the original quad normals, but if you then "manually" calculate normals on the triangle mesh, they will be skewed. We need to calculate the normals manually to fix the seams.)
To solve this issue, we store each mesh not only as a regular Unity 3D model, but also as a quad mesh (using our own format), where all the original mesh data is preserved. We created a module that is able to translate between the triangle and quad mesh representations, which we use to calculate the quad normals, which are then injected into the triangle model. Such a seemingly simple problem required all of this work...
Ok, so that was for the mesh normals. Next was textures.
Blending textures is simple enough, all we need to know is what coordinates to use (the UVs). For this, we actually store a part of the body's UVs in each part, making it able to look up textures from the body. Then we simply blend the body and part textures according to a mask.
But here's when we ran into a problem... Blending normal maps across different tangent spaces (derived from UVs) is not possible. You need two sets of tangents in order to do that. Unfortunately, this simply isn't possible to do with Unity's SkinnedMeshRenderer, which required us to write our own skinned mesh renderer. This is something we experimented with months ago, but the custom renderer we made was only a proof-of-concept - not something we could actually use in a final build. So this month, we've made a release-ready version of this that is not only handling the tangent issue, but is also able to handle blend shapes (vertex offsets forming a shape) in a much more efficient manner than Unity's native skinned mesh renderer. This is because we're baking blend shapes we know to be static for a certain character configuration, and further more only perform the blend shape offsets if they have changed from last frame rather than every frame, meaning we save a lot of processing. (Blend shapes are processed prior to rendering in a compute shader, rather than during rendering as Unity's Skinned Mesh Renderer does.)
(Unity's skinned mesh renderer lack luster blend shape performance is especially noticeable if you use a shader with many passes, such as a fur shader which has dozens of passes, since each pass will essentially perform the blend shape processing. In Yiffalicious (1), we had to move the blend shape processing from Unity into our own module in order to get good frame rates. Here we're doing that too, but this time entirely on the GPU. There is a setting in Unity to move the blend shape processing from GPU to CPU which "fixes" this issue, but naturally increases load on CPU.)
Body type refactoring
In our original body type implementation, we had attempted a layering system, where each layer referenced a body type that could be blended in according to a slider and a referenced mask. The idea behind this system was that you could cherry pick and mix different body types according to your own liking. Of course this would cause issues, so we also invested a lot of time into something we called shape correction, which was a procedural correction technique used to apply a shape as an offset to the current skeleton rather than as a global offset.
Once we had enough content to start testing this system, we quickly discovered that the layering and shape correction weren't enough to make this look good in all cases. You could create general shapes that looked OK, but there usually were artefacts and iffy areas. Furthermore, the layering and mask authoring simply weren't any fun to use. It felt cumbersome and results were often unpredictable. We still think this system could work in theory given the right amount tools and correction techniques. However, in the form that it was, it simply wasn't enough. This is where we started to have second thoughts about this system, because if we were to make it work, we would have to implement even more systems to make up for its flaws, but there was no guarantee this would actually succeed (and we were already behind schedule). Furthermore, we also felt that regardless of what tools we'd implement to try and make this work, it would all feel so technical and boring to use as a user. That's not what we wanted.
So we went back to the drawing board. Keep it simple, keep it stupid. Results should be easy, instant and fun, not require a ton of work. Our new idea was to focus entirely on the individual body types and introduce "tweakables" - body type specific blend shapes that alter the character in different ways. Examples of such tweakables could be the abs of a muscular character - should they be clearly visible or more like that of Rhino in Yiffalicious? So instead of having to achieve that by authoring a mask and blending in another body type, it would simply be a slider. Also, since these tweakables are compartmentalized to each body type, it means we circumvent a lot of complexity that otherwise would become unmanageable. So we can implement tweakables at will without worrying how they interfere with other body types.
(I might add that inflation is something we tailor for each body type and that's always accessible for all body types regardless of what tweakables are present. Tweakables are a per body type addition to inflation.)
Body type & part demonstration
So with all that said, lets finally demonstrate how body types and parts currently work in YL2!
Here we have our new universal (generic low poly) model integrated into the editor. Apart from a different topology and higher triangle density, this one also stands in a hybrid T-X pose rather than a A-X pose. (We discovered that having a T-pose gave us more room to work on the arms, which is handy for big shapes like those on beefy muscle guys.)
With the character builder object selected, simply browse down to the "Shape" section and "Body type" sub category, and click "Body type". A window appears showing what body types are currently present in the app. As of right now, we don't have any preview images, so they all appear in white, but naturally the idea is to actually show what the body types look like during the browsing.
To apply a body type on your character, simply drag and drop it in the view (or select and press OK, or double click it):
https://gyazo.com/8ea5bece354656a4a854a26ff0e6e6df
As you can see, the character is significantly changed from its original shape.
You can still apply the body type according to a slider:
https://gyazo.com/a8d2785f3caf2e3dfceacb54548f307d
Parts are also affected by body types being applied, changing not only location and size but also shape:
https://gyazo.com/6e5c24977bb1e25acd6b826332fc02e2
https://gyazo.com/9f1529a54aa1048869a808f0e02a52ad
This means we are not limited to having areas of the body that may not change. Necks, wrists and ankles are allowed to alter their shape between body types, giving us more freedom during body type authoring.
Also, notice that the areas connecting parts with the body are seamless.
As the body type is applied, maps are altered as well:
https://gyazo.com/d0f73486e595a06005409e18996c5590
Here's what it would look like without maps:
https://gyazo.com/ef213995a780eb958299a08b5abedf11
To try another body type, simply drag and drop it in the same fashion:
https://gyazo.com/99d1a99a31116c90a1832e846aac0ba3
https://gyazo.com/38cbe9beef4ea4217f7ee60746aa0e5c
Despite these two shapes being vastly different, they both work on the same universal mesh topology. This is at the core of our vision!
Naturally, like any body type, this one is also possible to affect with a slider:
https://gyazo.com/4751f53b7fe7cb059988201b605e26f2
https://gyazo.com/3b98b224589782f15dc04454e489e867
If you want to switch a part (head/hands/feet) on the model, simply browse down to the "Species" category and click what part you want to change. Here, we're switching the feet from being plantigrade to being digitigrade:
https://gyazo.com/63486b7bfffa38b2e03083d1c78f9f69
https://gyazo.com/dab33c9620d3eb3d6c7c65ea984a02bc
Notice that the feet and body are adapted to fit with eachother! This goes for any shape, so if you were to apply the muscular body type, the feet adapt to fit its shape:
https://gyazo.com/fdca0db14f669467cee1aebfe4ac2f97
Of course, the digitigrade feet also work without any body type applied:
https://gyazo.com/94f5e2225200d496526bbbb4a7d5894d
In addition to body types themselves, each body type can also have additional body type specific shapes that we call "tweakables". Since we have applied the bt_m_muscular body type, tweakables for this body type have been loaded in and are accessible in the "Tweakables" sub category:
(A "daddy" belly for bt_m_muscular, inspired by Rhino's belly in Yiffalicious.)
https://gyazo.com/fe479001551607ce3cd532ac11931c70
(A beer belly tweakable for bt_m_muscular.)
https://gyazo.com/a3f696e328ec280bcd8d110c41c5d32d
In the pictures above, notice that the maps are altered as the tweakables are blended in.
(Neck muscles. Despite the neck being vastly altered, the body and head still connect seamlessly.)
https://gyazo.com/f3cc846701b29c644c0f0bf8c6c52fbd
The cool thing about tweakables is that we can just keep on adding more and more over time. So if fans have requests for tweakables that they'd like to see on a certain body type, we would be able to add that. I was thinking maybe we could start providing polls for such things!
It has taken us a long time to reach this point. While the technology is for the most part fully implemented, we're still missing content in the form of body types, tweakables, inflation and parts. This is what we will continue working on in the future.
Other things
While the body type refactoring was a major task, it didn't take more than a few weeks to complete. So while dogson has been working on content for the body type system, I've been busy implementing other features in the meantime.
Skinned mesh import support
Previously, only static models were possible to import into YL2, but now we have a method of importing skinned meshes using the collada (.dae) format. This is a major feature that will enable you to import things like tails and have them bend during interaction authoring. The idea is to enable automatic physical behavior of things like tails, but that's something we haven't gotten to implementing yet. Still, this would not be possible without skinned mesh import support.
(We took Charlotte's tail and separated it into its own mesh. Then we exported it and imported into YL2.)
https://gyazo.com/11c2119b0850b5e1a557938720ea4507
Just to prove it's actually a skinned mesh... (Affecting joints is not yet possible in the character editor.)
https://gyazo.com/2a201d7596a752d69b78c430a199e219
JPG import
YL2 now also supports import of JPG textures in addition to PNG.
I was always under the impression that JPG was a big no-no when it comes to textures in games - that the lossy compression would be too apparent for them to be acceptable. However, in our testing, we've discovered that they actually work pretty well, even for things like normal maps! While all textures shipped with the app itself naturally will be stored in a higher quality format, JPGs may come to play a huge role in user authoring because of their small size, which brings us to our next topic...
PBR & normal occlusion layers
The acceptable quality of JPGs and their small size has giving us the confidence to add two new types of layers that are entirely user texture based - PBR layer and normal occlusion layer.
The PBR layer simply references imported textures for the albedo, emission, metalness and smoothness (inverted roughness) channels. Likewise, the normal occlusion layer is able to reference imported normal and occlusion maps, and blend them in on top of the body type normal-occlusion stack according to a mask and blend mode (either combines channels or replaces them, according to mask).
This way, you're essentially free to author maps in any software you like, and then simply import them into the app. The reason this wasn't viable before was because PNGs are simply too heavy. But with JPGs this is possible to do while maintaining relatively small file sizes.
These layers will open up for literally any type of texture customization you can think off, since you've got access to all texture channels used by the character shader.
(Example of authoring a texture in Substance Painter and then importing it into the app. Naturally, you would have to do this for the other channels as well to get the same look. In this instance, I think the smoothness was a bit higher in Substance Painter which made it look a bit shinier.)
https://gyazo.com/e3d1e2e982729a062c85a668b518059d
(Local assets will listen for changes to files and update them automatically if the "Reload" option is checked in the local asset object, as demonstrated here. It's just a demonstration, not an artistic expression. I'm a programmer, what do you expect lol.)
https://gyazo.com/79b12828402d261a23c868ce4d102bce
Detail textures
Detail textures are patterns that tile multiple times over an object, defining its "feel". For example, a typical detail texture in the context of anthropomorphic characters could be a snake scale pattern, to make it appear more reptilian. Now, we have full support for these textures in YL2.
To assign a detail texture, simply import a repeating normal map you want to use. Make sure to use the "Map" mode when importing:
https://gyazo.com/9afa84006781d276d816a73e793c1127
Then, in the "Detail texture" object inside "Character builder", simply click "Detail texture" and select your imported map:
https://gyazo.com/bdc09118d683ff89ed7f2d1c25310af1
In the sub objects of the detail texture object, you can customize the detail texture tiling and offset for each submesh index.
https://gyazo.com/37ea0ea6ef6806bf63e59aa471a46a4b
You can also assign a mask to use with the detail texture, so it only appears in certain areas. Here, we're simply demonstrating the technique using a radial gradient mask (procedural):
(Detail texture only applied where mask is authored. You'll probably want to author your own textures and use a mask texture instead rather than a radial gradient, but just as an example...)
https://gyazo.com/3121547d4d638974c1650d88a26f435c
(By enabling the "Final" view mode in the mask, we can see the changes in real time as you alter the mask. This is just an example.)
https://gyazo.com/311fabc513f8f93459d2fd3d2b1e2b62
Bone scaling
This is a minor change, but thought I'd mention regardless.
You are now able to scale spine and neck bones in addition to head, arms, hands, legs and feet. Also, the allowed slider ranges have been increased from 20% to 50%. This means you could theoretically alter your character regardless of body type to be more top-heavy, for example.
https://gyazo.com/3d3b7218721602b215a0024605db456a
I think in the future, we will replace the float sliders with vector sliders, so you're able to scale on each individual axis rather than uniformly.
Quad triangle GPU raycaster
Mostly a side note, but figured I'd share...
As you may know from earlier updates, we have implemented our own GPU raycaster that is able to raycast against skinned meshes in real time. Now, we have improved this raycaster according to state of the art research, speeding it up by around 50% (1.5x). This is done by exploiting the wide vector width of GPUs and their SIMD functionality (Single Instruction Multiple Data), essentially testing four triangle-ray intersections at a time per thread rather than one, meaning we only need a quarter of the threads required previously. The instructions that benefit from SIMD will essentially perform 4 operations at the cost of 1. (This method requires a bit more setup and not all instructions can utilize SIMD, which is why we "only" get 1.5x and not 4x boost.)
Summary
The body type system has been challenging for us to implement and create content for, requiring refactoring and a lot of iterations on the content. We're happy to say we finally have a proof-of-concept for the entire process - from authoring and integration to being able to browse and apply these body types in the editor. From the app's point of view, the body type system is essentially fully implemented - all that's left to do is create content.
The body type refactoring was finished before the content was complete, so while dogson has been busy iterating on the content, I've been implementing other features in the meantime. Among those is support for the importing of skinned meshes and JPG textures. As it turns out, JPG textures actually look totally OK, which has made us more confident in implementing purely texture based layer types, offering you even more opportunities as a user. (Size would otherwise be an issue for other image formats.)
Detail textures is another feature that is now fully implemented, allowing you to define the "feel" of the surface for your characters. This will be super handy for things like snake scales.
Bone-scaling and GPU raycaster optimization are two other things that have received our attention.
These past months have felt like a huge crunch and we're quite exhausted. Especially this last week has been absolutely insane. We're happy that we finally seem to have figured out all the steps involving body types - from creation to integration and implementation. But there's still much left to do. In the coming weeks, we will continue working on making the universal mesh as adaptable as possible, as well as creating and integrating new body types and parts. It's all shaping up and we're getting very close to a first release! As far as features are concerned, there's only a handful left to implement.
We hope you have enjoyed this somewhat lengthy update. Props to you if you read through the whole thing!
With all that said, we wish you all a nice weekend!
All the best.
- Yiffalicious crew
Comments
Yeah, this would take at least a year more before we'll be seeing an alpha, isnt it?
Sounds to me like we're pretty close to a demo of the character creator, given that this was the last major component of it left to implement. Should only need a few more smaller things before it's ready for prime time. After that, though, the time-frame for implementing the actual character interaction mechanisms is anybody's guess.
@odes
Too bad you decided to scrap the original mix-and-match concept, would have been fun to create distorted abominations with it, heh. Still, I can understand the technical reasons behind it and as long as there's enough variety in the body types and "tweakables" available to compensate, it'll be fine.
Regarding the universal mesh, though, are you planning on making it more androgynous? As it stands, it seems to me every male body type is going to end up having a bit of a bosom unless the "body type influence" slider is maxed out. That'd be great for some purposes, but I'd say those purposes would be better served by a separate breast size tweakable, since I'm guessing most users won't be all that interested in such a niche concept.
The texture system upgrades are looking quite spiffy, should make an already robust system even more useful. Good to see the range of bone size variability increased, too.
Well, I suppose that depends on what you count as major, but there definitely are several things left to implement that are not trivial, like anuses, ball+socket meshes, shafts and areola/nipples. The body type system is however for the most part fully implemented, yes.
Breast inflation will also be able to handle negative values similarly to how the most recent female characters worked in Yiffalicious, meaning half applied male body types don't need to end up with a bossom (unless desired).
Well, obviously I don't see those as trivial, but they should be considerably simpler than the ordeal you just went through to implement the body types, yeah?
Hang on a minute, didn't you already have a system for generating nipples based on an editable vector line? Did you decide to scrap that in favour of something else, or have you simply not integrated it into the actual editor yet?
will it be possible to import user-created body types?
If yes, what is the workflow on these? Is it similar to a normal map?
First of all, only a single body type per character is limiting right off the bat. As far as I understand from your post, it will not be possible to mix two or more body types together, is this correct?
Second, if custom masks and difficulty making/assigning them was an issue, why not either hide the option behind an 'advanced' interface, and/or use a selection of premade masks, for common body regions, such as shoulders, upper/lower arms, u/l legs, upper/lower torso, etc. It is extremely likely most use cases would be completely covered by such premade masks anyway. I believe that some artifacts and inconsistencies at seams would be very acceptable.
As for tweakables per body type, this is a terrible idea, I think. Unless there is a way to create generic tweakables that work on all body types (which I understand is not what's described) this system will quickly become too large to be maintained, and at the same time too limited to be useful.
You will end up with a number of tweakables that you'll have to reimplement for each body type you make. What happens when you create a new body type that's a variation of a previous one? A different muscular shape for example. More work redoing all previous tweakables that would be useful for this type as well. Or, worse yet, some body types will lag behind, and have significantly less options than others. It will become a mess of inconsistencies very quickly, while still not being very useful in creating the level of variety you say you want. Not to mention it will enforce a linear editing workflow, where it will be impossible to swap a body shape for another, as it would be with the mask/region approach.
At least bone scaling is there, that is a huuuuuge positive.
My suggestions are first, to revisit the old plan of body types and masks, maybe hiding advanced mask creation. It will be really worth it in the long run. It _can_ work, it works for stuff like daz and poser. ( at least for some morphs it does ) Maybe there will be some wonkiness at the edges, but that is ultimately acceptable, expected, and a small price to pay.
Second, to hire or commission at least one additional artist once the pipeline is more stable. The work that you're putting out is pleasing and consistent, but it is very obvious that it is from a single artist with a single style. A second or third eye will help with variety, especially when it comes to heads and faces. From what I've seen so far, faces seem to be very lacking. From a user perspective, faces will be of equal if not greater significance to the overall variety of possible characters, and generally something you cannot do with a base shape + sliders. Again, look at daz/poser. There's at least three times the amount of parameters for the face area as there are for the entire rest of the body, and that's only concerning human faces. And still, the results are same-y. This is an area where the multiple bases + tweakables approach would actually work, provided that the bases are as different as possible (hence, more artists).
Third, please decide on a small set of features and release something with those features. More and more you seem to get lost in features that while nice, are not immediately necessary. Detail textures, for example, are nice and all, but as a feature of a later alpha, not with so much stuff still left to do. You're getting a significant amount of support even with zero tangible releases, I really don't think a series of limited but solid and focused alphas would harm that, in fact the opposite. Plus, you'll get actual informed feedback and not just speculation.
Anyway these are my thoughts.
Love
As I've already stated, I simply don't know.
It's not entirely ruled out, but if ever implemented it will be far down the road when editor and tech is very mature.
That's exactly what we're trying to do with this solution. There were simply too many issues with the layering for us to be able to solve them in a timely manner. Maybe we'll revisit the layering idea in the future, but for now, this is what will have to do.
The level of customization is still far beyond what Yiffalicious offered (which only had inflation and external skins), while at the same time supporting the same diversity in body shapes. Even though other editors may have more options, it's evident that their characters are based off the same model, and any difference between them (despite all the options) are not as interesting as archetypal differences (in our opinion). We truly believe that vast archetypal differences between characters is what defined Yiffalicious, which is why it is so important to us. We had to make a choice - either reduce difference in shape or somehow manage the complexity of options to allow for great body shape differences. We chose the latter.
You ask for more yet want something out sooner.
And the neck tweakable for example, that would make sense in most body types, will have to be reimplemented for all body types, including future ones. Or there'll be functionality in some body types and not in others, that would make sense in all. I suspect this will be the case for most tweakables instead of only a few.
I'm not talking about sliders over a base body type, I'm talking about the system with several body morphs over a base body, applied through masks. I don't remember on which exact post you mentioned it.
I'm asking for less
Don't release at all if you must, just set a small set of features and focus on those. Each of these feature posts could have been accompanied with a prototype*, if that was the case. (well, not these, the hypothetical ones describing each one of that small set of features). And you'd have solid, actually useful feedback instead of just speculation, like this one and my other post. If something required reimplementation in order to add new features later, then so be it. It doesn't seem like you avoided reimplementing things now, anyway.
These updates are showing a wider and wider scope, and while this is commendable, it does feel like you're both getting spread out too thin so to speak. Case in point, this compromise from an elegant but more difficult plan to a considerably less elegant one. Feature creep, etc.
* to clarify, I dont want a prototype as a proxy for an early release. I imagine it as useless from an entertainment point of view, only actually useful from a technical point of view.
Which is still not ruled out - it just won't make it into the app as of right now since this approach had too many problems associated with it.
You're asking us to implement body type layering, which will require more time and more systems in order to make it work properly. We don't have that time.
What's keeping you?
Oh, I already know how to do that, I'd rather be able to just import models after modding them at this point. or to YL1 to give something for people to do while they wait, the harder part is making the animations, worse at those.
Sigh.. That's what I'm saying. You're being obtuse on purpose. Maybe you would have the time if you would set aside unnecessary features for much later.
The underlying problem here is that an approach like this will be unmaintainable and ultimately give poor results. No matter what the alternative may be. The end result will have functionally just as much variety as the number of base shapes you create, and that will be that. It will be YL1+ in effect.
Maybe generic sliders are not gonna cut it, though I'm saying that with reservation. They do work for other software, over an extremely wide selection of morphs. Not all combinations give meaningful results, but not all combinations are expected to. Several morph combinations give correct results at full 100%, but they're not expected to.
Again, look at daz and poser, and specifically how extreme third party morphs (including extreme shapes like digitigrade feet or cartoony out of proportion characters) interact with all other morphs that exist.
Done arguing, prove me wrong with actions. Or don't.
Maybe they would have more time if they won't have to answer to disrespectful whinny bitches like you being choosing beggars.
Do you want your dream porn game? With all your favorite features? Do it yourself; you look very knowledgeable pushing Odes around on the reasons for doing something one way or another.
These so called "unnecessary" features you are referring to were mostly things I chose to implement to make the most use of my time while I was waiting for dogson to complete his tasks. I.e., they're things I was confident I could implement, and that do increase versatility of the app.
A million dollar company with 20 years in the business was able to pull off more customization than 1 dev and 1 modeller hobbyists? Shocking.
(FYI, DAZ works very differently and has the benefit of acting on high rez models. We don't have that luxury, since this is a realtime app that needs to work with animation and physics, not to mention the rendering cost. All our shapes are very low poly in comparison, which means we have to store high poly data in textures, and blending different shape textures together on a surface is not guaranteed to look anything what you expect it to, especially not if multiple shapes are acting on the same areas. Working solely on high poly is a huge advantage in this context.)
you know my problem with the head already...
'Oh no, the game is settling for a simpler implementation that still gives great results but isn't exactly the way I want it! I don't care that you're limited in manpower and resources, I want top-tier features coming out yesterday! '
It's almost as if a project like yiffalicious has time and money constraints, you ignorant wankstain.
Thanks to you odes and dogson, I hope you guys are still able to find your work enjoyable.
Anyway, well done all of you. Here's to the future of diverse, technically sophisticated 3D erotica!
Once we get to implementing interactions, the idea is definitely to add automatic oral behavior eventually.
honestly I couldn't read anything but the summary from the announcement because I'm too burned out atm to try and follow all that xD but I'm seeing that you have had some difficulties.
all the best!
There won't be more release estimates, as the last time they gave one it was for before the end of last year...
Anyway, it doesn't look that the first release is very far off, but i won't hold my breath.
The first release will consist of the character creator only, and it will be for patrons on the "Enthusiast" tier only (currently costs $12/month).
I'll pitch in the contribution sometime along the line! ^^
All the best to you guys!