Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Categories
(Pateron) Can you guys please priorities oral?
I know there are countless post about oral already, but I don't understand why you guys don't bring oral to the forefront. If you can't make a oral version of every character than why not introduce reptiles and make a female and male snake person who sucks and uses there tongue accordingly, oral is such a awesome part of the sexual experience, but it doesn't seem like it's a focus here, why not?
Comments
If you want the TL;DR, here is: This project is big and complex; so they have to priorize features balancing implementation difficulty and what it adds to the project. Oral is something that will be implemented, but as it's something difficult to do the right way, it's a long way off.
About new characters, they are decided by voting. Next character is a fox femboy, then a pair of dragons (male & female). I guess that when the dragons are in production they will do the next poll.
Doing it hard-coded or with animations isn't hard, but creating behavior that can work with any mouth and any character in a dynamic fashion is another matter entirely. And that's how we do things - dynamic. Not hard-coded or with pre-made animations.
This is hard not only because the movement in itself is far more complicated than simply moving the pelvis around (here you'd have to take the whole spine into consideration), but also because the verts around the mouth area need to be controlled by more bones than 1, and that changes everything. In Unity you cannot access skinned vertex locations (after skinning). You either have to calculate those locations manually (which isn't hard, but would kill performance if you have to do it for thousands of verts), or bake the mesh (which is a horrible idea since that produces GC).
On top of that, we'd probably need more raycasting to create a believable result, but in Unity you can only raycast sequentially (despite there being explicit support by PhysX to batch raycast - Unity simply doesn't support it in their APIs), and that, too, would kill performance. Especially considering there is absolutely no way to get this to run in parallel due to Unity's single threaded nature (for our other algorithms, we have managed to thread a lot of it, but here it is impossible since raycast invocations are required to run in main thread).
So, for now, we have just put it aside in the hopes that either something here changes, or another solution emerges.
We were thinking of implementing our own triangle ray intersection that is able to run in parallel on the GPU, using the newest research available. But such a task is quite time consuming, and there's no guarantee we'd succeed. It's far safer to spend time working on simpler [but no less desired] features and content.