August 2024

General

The July and August devblogs were produced at the same time.

Digestive System Dynamic Mesh

Following new CPU optimizations in July, I've been working on new methods for animating the geometry of the digestive system.

By default, I use a Static Mesh with a Dynamic Shader animated via the GPU.

First I added the possibility of animating the geometry via a Dynamic Mesh on the CPU side, as I do for dynamic collisions, but without the physics engine recalculation of course.

It works well, but the optimization is not as good.

I lose some optimizations specific to Static Mesh that are not available on a Dynamic Mesh.

In addition, the Distance Field used to calculate the dynamic lights of a volume doesn't work with Dynamic Mesh.

Digestive System GPU Optimization

I continued to work on GPU optimization and data processing in textures.

One problem with the GPU and shaders is that I can't cache data like I can with the CPU.

It's much more raw.

To explain, here's an example with 12 modifiers.

The CPU will filter out useless modifiers, such as those outside the zone, and then encode the data for the 6 remaining modifiers in the form of a texture. 2 pixels per modifier.

Now, in the Vertex Shader, each vertex will read the position of the 6 modifiers and load 6 pixels to obtain the location and attenuation data.

The top will determine if it needs to calculate the modifier and if so, it will read a second pixel per modifier to get the remaining data.

The calculation cost quickly becomes exponential as I add modifiers or geometry.

I've made several optimizations to make data processing as fast as possible, but reading the pixel still takes the most resources.

I did a stress test with 8192 modifiers (128x128), with the RTX 4090 in an empty scene, I'm running at around 70 frames per second.

As the plane mesh contains 8192 vertices, the Vertex Shader will read 8192 vertices times 8192 modifiers, i.e. at least 67117056 pixels per frame.

That's why I say the calculation is gross of force.

If I increase to 159411 modifiers (512x512), I'm down to 8 fps.

Here's what it looks like with the Complexity Shader.

Of course, in the game, shaders will never have to calculate so many modifiers at the same time.

My current maximum is 32 modifiers per texture.

Maintenant que l'optimisation CPU est meilleur je peux plus facilement couper un model en plusieurs sections et donc réduire le nombre de sommer à calculer dans un Shader.

Now that CPU optimization is better, I can more easily cut a model into several sections and therefore reduce the number of vertices to be calculated in a Shader.

Here's what it looks like in game with the debugger.

Optimization is much better, but still doesn't work on smaller machines.

Digestive System New GPU Method

My main problem is the time-consuming reading of pixels. Each vertex will read several pixels from an encoded texture as explained above, and the accumulation is extremely heavy for the graphics card.

From there I moved on to a new paradigm. Since my CPU optimization is much better, I can make it calculate more things without affecting performance and gameplay, such as calculating vertex positions instead of the GPU.

Operation remains very similar. The CPU will calculate and filter the modifiers as before, but it will also calculate the new positions of the mesh vertices.

Then, instead of sending the modifier data encoded in a texture, it will directly send the position of each vertex.

Each pixel will be equal to the position of a vertex, so on the GPU side the Shader will only read one pixel per vertex.

I have a mesh that I use to do stress tests with 1050625 vertices.

With the old method, it was impossible to calculate the animation. Now I can run it at 15 frames per second.

Every frame, the CPU will encode a 1025 x 1025px texture with the new data.

This consumes a lot of RAM, but works much better and is much more scalable according to the performance of each PC.

In addition, I can continue to use my previous optimization with multi-sections.

Voilà ce que ça donne pour le moment avec la configuration minimum.

System: Windows 10

GPU: Radeon RX Vega-64 (Close to a 1080 GTX)

CPU: AMD Ryzen 7 2700 X Eight Core Processor

Average previous method:

Low -> 29 fps

Med -> 29 fps

High -> 26 fps

Ultra -> 6 fps

Average new method:

Low -> 75 fps

Med -> 55 fps

High -> 42 fps

Ultra -> 30 fps

Game Master UI

I've updated the player interface and added the game master speed.

As before, you can change the speed mode and specify the speed with the mouse wheel.

But this time it's clearly presented in the user interface.

Small in-game test:

Character Scale UI

Add a new layout to the user interface to display its current size.

As with other layouts, you can show/hide it in the game settings.

The icons were all made by MagPi! Thanks for her great work and feel free to check out her gallery.

Game Unit Scales

I've reworked the way the game handles units such as weights, lengths or speeds.

The aim is to optimize calculations to maintain good performance and accuracy, especially with extreme sizes.

For example, it's much easier for the computer to calculate 1nm times 2 than 0.0000001cm times 2.

I took the opportunity to update the libraries and codes to manage localization.

MMVS Support extreme scale differences with characters.

From 0.001 scale to 10000000 (Ten million) is the range to keep good unit calculation.
From 0.05 scale to 100000 (One hundred thousand) is the range to keep an stable gameplay.

The game also supports extreme environment scales.

From 1/1 000 000 scale to 10 000 000 000 (Ten billion.) is the range to keep good unit calculation.

This allows me to exploit many of these sizes in the game.

In the following example I use several environment scales to support all type of scale, from atom to Earth for the moment:

MegaNano: Enviroment scale: 5000000000.0 From Atom to Bacterium
AltNano: Enviroment scale: 1000000.0 From Bacterium to Dustparticle
Nano: Enviroment scale: 5000.0 From Dustparticle to Paperclip (Used for Talas Nano Sole)

Micro: Enviroment scale: 20.0 From Paperclip to Person (Used for Talas Cozy House)
Norm: Enviroment scale: 1.0

Macro: Enviroment scale: 1/20 From Person to Mountain
BigMacro: Enviroment scale: 1/1000 From Mountain to Planet

User Preferences

During this month I concentrated a lot on finalizing new features and fixing small bugs.

I've also added options to let players choose what they want to see according to their preferences.

Rendering options won't affect gameplay or local sound only.

Force volumes

I updated the force volume I made to push the player with the water flow in the Talas house.

I've made the script more general and optimized for more use.

It can now handle several types of conditioning and use a curve to animate force, as in the video.

I've also added a friendly mode to adapt the force to the player's movement.

This is what is used to move the player along the digestive system.

I've added several modes based on the different types of force that can be applied.

The previous videos work like a treadmill, while the next one shows a wind-like force that takes into consideration the volume and mass of the object to be pushed.

Volume forces will not just push players in one direction, but will also take into account the environment and impacts, to redirect the movement if necessary.

In this video, during the first test, the actor bounces like a ball.
In the second, he slides along surfaces.
The third shows how the character reacts when pushed against a wall.

In some cases, it will force the player to crouch.

This video shows a more organic use with splines and a test in the digestive system.

(Warning: may cause nausea).

Physical and Kinematics Interactions

During development, I had several problems due to the physical interactions between the player and the digestive system.

To make it simple, since the digestive system is totally dynamic when the player is pushed and crushed against walls, there's a good chance he'll fall under the map.

It's a problem I'd been able to correct for physical objects with a few cheats, but not for the player at the time.

So I did a bit of research and development to understand the physical versus character interactions.

The fact is, character actors are cinematic objects and are not managed directly by the physics engine.

As a result, certain basic interactions between characters and physical objects need to be developed, which is not the case with Unreal Engine.

This is not a technical problem; it works without a hitch on old games like Half-life 2, released in 2004.

But not on modern graphics engines like Unreal Engine, because that's not a priority, unfortunately,

because most studios avoid using physics in their gameplay.

During my research and development I tried to redo some basic physics interactions.

But since this is done as a patch after the main physics engine calculation, it's not stable and produces other problems.

To solve the digestive system problem, I have to modify the engine's source code to calculate the character as a dynamic object rather than a cinematic, which is far too laborious to do.

I could also manage the character's movement with a real physical object, but this would require more research and development, and I'd have to revise a lot of code that isn't at all suited to this use.

In the meantime, I've discovered the Mover plugin, currently under development and being presented at unreal Fest 2024.

It seems to be the solution to correct the problems linked to physical versus cinematic interactions, as well as revising the entire management of character movements.

Modular movement management will come in very handy in MMVS.

I'll be using this plugin in the future after the Vore update.

An Introduction to the Mover Plugin | Unreal Fest 2024

In the meantime, here's what I've done:

This fix allows the character and physical objects to react when hit. By default, physical objects bounce off the player as if it were a wall.

On impact, the physical object cancels the physical interactions of the previous image and recalculates an impulse according to its mass and the mass of the player.

This seems to work for impacts with small objects, but when a large object has to push the player continuously as the previous image is constantly cancelled, it becomes unstable.

This fix enables the character to react better to moving objects and dynamic collisions.

One use is when Talas pushes you with his hand or taps you with his foot while walking.

This is what I finally used in the digestive system when you're crushed between walls.

I'll tell you more about it below.

Its main objective is not to crush or injure the player, but to prevent him from falling under the level with dynamic collisions.

Here are some more tests:

Digestive Animations and Character Interactions

I've reused the technique developed to push the player into my R&D with physical interactions for dynamic collisions of the digestive system.

This time the code will use the point closest to the contact between the character and the collision, and will reposition the character each time the collision movement is updated.

This also works for physical objects.

Movement in the digestive system is much more stable and seems a little “sticky”, as the character's collision box will follow the most stable point.

Collisions will force the character to kneel or teleport if necessary.

More Bug Fix

I don't talk about it much in the development logs, but I do a lot of testing with testers to find and fix bugs.

I think this is one of the most common bugs since v0.4.

The fact that the character in FPS view has no head.