Mod Unity Monster Black Market - Tits Mod V2P

[Krongorka]

At this point I'm pretty sure most skeleton 'bloat'/performance loss in MBM comes from character faces (all facial features).

I started to rebuild Woman slave skeleton (third time's the charm, right? /s), but this time I can tell it's done right because of accumulated experience/using methods which are fast and accurate.

In V2p I didn't touch head/face mesh which is related to eyes-blinking feature while other parts of the body were 'stripped' from overall mesh complexity.
For new version facial mesh was reworked from scratch pretty much, so that difference in metrics for V2p and a new skeleton for base female is not 4x-5x in complexity but around 2x times, which is definitely not that much considering this time non of mesh/texture data is cut down.



- Facial mesh use minimal resources, while it stays accurate.
- Thigh/Hips are connected to each other properly with weights and not by mesh deformation (I really messed this aspect for girl's skeleton before, this needs to be fixed there too).
- Shoulders are connected to body properly with weights.

Rebuilding base skeletons with new methods in mind without adding new functionality is a faster process than I thought it would be. Current female's skeleton shown here is "lowest" possible complexity game can render, so I prepared these parts first. Other features adds lots of veritces/triangle data, but these can have V2p complexity pretty much and not bloat metrics too much.

So yeah, the work continues.

Default -> V3 (rework) WIP Woman Stand. Difference is minimal, as it should be (difference in height is a result of Spine outputting different GIFs resolutions) :




I also have one concept with possible implementation in mind, but I can't say for sure if it's fully stable. I'll just post a single screenshot with it for now:

Quick explanation: It's possible to control Slave's height with exploiting scale of a root bone and a separate "animation mix" function I showcased in Amilia's NPC breakdown before. Here "Height" is dictated by 'Eye Type' which overrides main "Root Bone" scale factor on X/Y adjusting all bone positions along with it and not requiring additional assets (which would have blown the skeleton's budget through the roof overwise). All of characters in screenshot use one default "Woman" skeleton type. Yeah, left one is just a downsized "Woman" type, not a "Girl".

 

[jonnijimbo]

At this point I'm pretty sure most skeleton 'bloat'/performance loss in MBM comes from character faces (all facial features).

I started to rebuild Woman slave skeleton (third time's the charm, right? /s), but this time I can tell it's done right because of accumulated experience/using methods which are fast and accurate.

In V2p I didn't touch head/face mesh which is related to eyes-blinking feature while other parts of the body were 'stripped' from overall mesh complexity.
For new version facial mesh was reworked from scratch pretty much, so that difference in metrics for V2p and a new skeleton for base female is not 4x-5x in complexity but around 2x times, which is definitely not that much considering this time non of mesh/texture data is cut down.

View attachment 5457572

- Facial mesh use minimal resources, while it stays accurate.
- Thigh/Hips are connected to each other properly with weights and not by mesh deformation (I really messed this aspect for girl's skeleton before, this needs to be fixed there too).
- Shoulders are connected to body properly with weights.

Rebuilding base skeletons with new methods in mind without adding new functionality is a faster process than I thought it would be. Current female's skeleton shown here is "lowest" possible complexity game can render, so I prepared these parts first. Other features adds lots of veritces/triangle data, but these can have V2p complexity pretty much and not bloat metrics too much.

So yeah, the work continues.

Default -> V3 (rework) WIP Woman Stand. Difference is minimal, as it should be (difference in height is a result of Spine outputting different GIFs resolutions) :

View attachment 5457615 View attachment 5457618


I also have one concept with possible implementation in mind, but I can't say for sure if it's fully stable. I'll just post a single screenshot with it for now:

Quick explanation: It's possible to control Slave's height with exploiting scale of a root bone and a separate "animation mix" function I showcased in Amilia's NPC breakdown before. Here "Height" is dictated by 'Eye Type' which overrides main "Root Bone" scale factor on X/Y adjusting all bone positions along with it and not requiring additional assets (which would have blown the skeleton's budget through the roof overwise). All of characters in screenshot use one default "Woman" skeleton type. Yeah, left one is just a downsized "Woman" type, not a "Girl".

View attachment 5457967

question of clarification here. how much of this optimization of the textures, motion bones, etc is from you- and how much is from the primary dev? and how closely are you working in conjunction with one another? secondly- because between this, and how the new potential version of this game is looking. im wondering what you might do next assuming all this optimization goes through, the cool stuff like freed up jiggle bones for NPC's is pretty cool, but i really want to know how far we take this game as far as modding is concerned, so what's your end goal?

 

[Krongorka]

question of clarification here. how much of this optimization of the textures, motion bones, etc is from you- and how much is from the primary dev? and how closely are you working in conjunction with one another? secondly- because between this, and how the new potential version of this game is looking. im wondering what you might do next assuming all this optimization goes through, the cool stuff like freed up jiggle bones for NPC's is pretty cool, but i really want to know how far we take this game as far as modding is concerned, so what's your end goal?

Lots to answer here. I can tell that one of devs is here on forums, monitoring both MBM and ProjectR topics.

Things changed a lot at the february-march 2025 since I got a first PM from the dev about my inputs/will to bug test 'potential Steam' build. Unfortunately Steam release is "postponed indefinitely until politics situation improves" (HA, YOU WISH /s) At that point we talked a lot and fixed most of visual bugs and I also got an uncompressed texture data for MBM.

At that time 2.0.16.0 used DXT5Crunched compression on lots of characters and it bothered me a lot because I had to come up with upscaling/editing of the extracted texture to try and remove compression artifacts. So I asked for uncompressed texture data and, to my surprise, I got it.
I suggested to change the way character outlines were rendered with texture copies, so they managed to implement it in other way which doesn't use texture copies. And then they also adopted BC7 compression for textures (except for rooms, it consumes a lot of memory for 4096x4096 atlases so it stays with an old compression).

Spine 4.2 update suggestion was the latest and most daring one, because it DID break some things in game, but I guess most of issues are ironed out at the moment.

So here's a list of things which weren't really possible for me to do:

- Entirely new data structure which don't involve repacking character skeleton and texture data (for the most part, lots of things are still hardcoded)
- Providing the original non-compressed and non "ai-upscaled" texture data (I can't stress this point enough)
- New character outline shading
- Fixing old half-censored ending CG
- Implementing Spine 4.2 support on Runtime level and fixing all sorts of nasty bugs which comes with it

Now, my current goal is to take skeleton data and remake it with a new mesh data which is responsible for both character movement and 'how much resources system spends on it'. It's something I learned for the past year and I'm confident with it.
I'm able to pack textures into a new sprite sheets with tighter packing and producing my own .skel files.

It's very time-consuming and actual dev can't spend time on it. They had to ship MBM before, now they have to ship ProjectR.

"How much of this optimization of the textures, motion bones, etc is from you- and how much is from the primary dev?"
Everything related to texture packing method, every change in skeleton files including adapting/making a new visual function is from me. Lots of ideas were implemented and lots were scrapped because I couldn't implement it in optimal way.

The optimization I'm doing is like a "micro-level", let's be real. It's just that MBM gameplay can amplify issues very quickly at late stages. Even more so if you're using ComplexBreeding which used the code itself to re-mix character graphics so it's more demanding.

Goal for the mod was always to put more stuff in the game right before V2p version dropped. It stays the same, but we're back at fixing "basics" and building a strong (performance) base.