April 2024

General

…

Grab System

Back in March, I explained that the game had two grab systems.

One specific to VR
And one for Talas when he grabs a micro.

I also explained that I'd created a new, more general grab system with many more controls to replace them and allow the game to evolve.

This month I did the migrations for the two grabs systems stated above.

First for Talas:

It was complicated because I had to completely rewrite the grab management in the Talas-linked animation scripts.

Now, in the animation scripts, I have a generic system that manages the contextual poses and plays the grab animations.
And I have a modular overlay that allows Talas to grab an object at a precise position as before.

Generic Grab with Cobble.

And then for VR:

The most complicated part was reworking the VR-specific attachment point management system.

Different objects have different attachment points.

Some objects can be grabbed anywhere from any direction.
Other objects have one or more specific attachment points, such as the cup, which is always grabbed by its handle.

Funnily enough, it's now possible for Cobble to catch micros smaller than himself.

Refactoring With IK System

As I said, I had to update a lot of the animation system with the new grab system, but I also had to update the IK management.

Inverse Kinematics (IK) is used to move bones from child to parent.

This is what is used in a game, for example, to place the feet with the correct rotations according to the ground when you are not standing on a flat surface.

To control this, I used to have a general script to define the values according to the context, but now the animation script will ask all animation sub-scripts via an interface which parameters to use.

The Talas Grab animation script will then calculate the parameters itself and pass them to the main animation script.

The same goes for the animation script for stomping, or Cobble's script for stretching out his arms when he rubs Tala's paws.

VR

After a technical problem with my current headset, I switched to a Steam index that someone lent me.

I corrected the eye distance again, this time using OpenXR when a character changes scale.

I had already made this fix in a previous version of the game with Steam VR, but I had to modify the Unreal Engine source code.

The fix was skipped with the v0.4.2 update due to the engine switch to Unreal Engine 5.

For accessibility purposes, I've added an option to change the scale of the VR hands.

It's only local, so other players won't see the change.

VR Fullbody Animations

I've fixed a lot of hand related bugs and greatly improved the VR animation with hand head tracking.

I've also updated the test level to make debugging Fullbody VR easier.

VR Hand and Fingers Tracking

After several bugs tied to the hands, I had to rework the finger tracking management.

That is, all the data retrieved via OpenXR, how it is processed, replicated in multiplayer, and used in animation scripts.

Specifically, I've streamlined the system, improved performance, and greatly optimized multiplayer data transfer.

In the video, blue is the local data, red is on the server side and what other players see.

Data from each finger is sent every 0.4 seconds.

At the moment it's not possible to have a better frequency without destroying multiplayer performance.

I'm working on a small system that would allow the last 24 frames to be sent ultra-compressed every second, which would improve quality and make multiplayer replication even easier.

It's not planned for the next release, but I'll definitely talk about it again.

VR Offset

I've also reworked the hand offset, which no longer needs to be replicated in multiplayer with OpenXR.

With OpenVR, the hand position between two controllers could be quite large.

So the game had to replace the VR hand according to the controller used. It's an old system that I haven't cleaned up since v0.4.2 when I switched to Unreal Engine 5 and OpenXR.

Now I've created and use a reference model that I can easily position on the character.

I manage the offset according to this model and I'm sure everyone will have the same result if the Open XR integration is done correctly.

I can also preview the position of certain elements against the reference model, such as the grab attachment points and the VR interface.

For the VR interface and components, I've changed my method a bit. I previously used multiple components and actors with predefined positions directly on the hand.

Now I spawn the actor at the root and leave the position management directly to the actor. Here I've done the placement according to the reference model.

It's also something I won't have to do again when I make the VR menus for photo mode and Game Master.

Game Modules and ClangTidy

Here is an advice: don't use the ClangTidy plugin for Unreal Engine.

A few months ago I added the ClangTidy plugin, thinking that it would allow me to detect and improve certain problems or bad methods in my code.

I don't know exactly how it works, but during a build the plugin will check the code and add additional errors and warnings to correct.

The problem is that while it is checking, it locks certain files for writing and causes the build to fail or be corrupted depending on the number of modules.

MMVS includes 3 basic project modules.

TagGame for game code,
TagEditor for editor-related code that will not be included in the game.
TagServer for dedicated server integration.

(Tag stands for "Tiny Adventure Game", which is the name of the MMVS source code).

With just one module, I have a 99% chance of getting it to work on the first try.

With my three modules, I had a 20% chance of failure on the first compilation, but it always worked on the second try, since the compiled files didn't need to be recompiled.

And since I rarely change the code for the editor and server, the modules didn't need to be recompiled often.

With the VR finger tracking update, I had to create a 4th "TagAnimGraphRuntime" module to support custom nodes in BP animations.

And with the 4 modules, I have about a 90% chance of failure...

I didn't immediately understand what the problem was, so I wasted a lot of time just modifying my code, trying to figure out exactly what was causing the compilation to fail with an extra module.

The error report was inconsistent and different every time. As a result, when I found the 10% chance that the compilation was correct, I thought I was on the right track, when in fact I was simply breaking the integration of my modules.

Finally, I wrote a script to delete all temporary and compilation files to make sure it would compile from the beginning every time.

That's how I noticed that the compilation worked with a 10% chance when I restarted using brute force every time...

If I delete the ClangTidy plugin, it works with 100% chance.

Incidentally, I suspect that ClangTidy is also responsible for corruption errors in the game engine during engine compilations from the project compiler.

So don't use the ClangTidy plugin for Unreal Engine, it will save you a lot of time and preserve your sanity.

Render Pass

I reviewed a lot of code regarding the rendering methods and added more options to the graphics.

By default, the game uses static rendering for shadows and global illumination. This means that the rendering is calculated and saved as a texture applied to static objects, and for reflections, static 360 images. (Cubemaps)

This is the best for performance and quality.

Now, for users who can afford it, it's possible to use Screen Space Global Illumination (SSGI) as an overlay.

And replace static reflections with lumen reflections. It uses more resources, but you'll get better visual quality.

(At the moment, SSGI doesn't work well in VR).

Of course, I've kept the options to force the use of Lumen (Global Illumination and Reflections) and PathTracing.

Here are some test renderings:

I've also removed the button for changing the in-game rendering method, now you can do this directly in the debug menu.

New NAS

I bought a new used 16 slot NAS. The old one was maxed out at 4 disks in 6 Terra Raid 6.

Once the migration is complete, it will have 8 disks of 6 Terra in Raid 60.

I use the NAS to back up my game and project data, manage some of my tools, and post builds online.

Keep in mind that I use raid 60 to back up and duplicate data.

If a hard drive fails, all I have to do is replace it.

This is also why I can only use 10TB of the 24TB NAS.

Hungarian Translation

A big thank you to autumn_937 who worked on and completed the Hungarian translation for the next update!