Devblog January 2026

General

The January, February, and March 2026 devblogs were written at the same time due to delays.
This devblog focuses heavily on audio systems, with major progress on Wwise integration, spatialization, and interaction systems.

Audio - Wwise Approval

Let’s start with the good news.
If you remember in the last devblog in December 2025, I talked about the Wwise integration in MMVS and that I was waiting for the project approval.
I started to get worried because it was taking a long time, and in mid-January I got the approval to use Wwise middleware for the audio in MMVS!

So I was able to go further in the integration and remove old codes and assets related to the old audio system in Unreal Engine.
During my tests and integration I was careful to keep the old audio assets and code.
Many “@TODO Remove when Wwise approved” comments were added in the BP and C++ scripts for every change, This made it possible to revert to the old system without too many issues.

I was finally able to clean old code and comments.
Of course this is related to MMVS audio but for my tools and techs I keep everything compatible with both audio systems for the other uses.

The code will always prioritize Wwise assets when they exist.
For my plugins, I can build variations with or without Wwise support.

Audio - Audio Bus and Effect Design

In January I focused a lot on the audio tech with the Wwise integration and the paradigm changes.

A big update along the month was the main audio bus redesign to manage the sound in Wwise and Unreal Engine.
I spoke a bit about it in the devblog of December 2025 with the redo in Wwise, but I made many changes to have a better control on the effects, not just volume.

Example: I have a Music Bus -> Diegetic Music -> In Game Music

In the “Music Bus” I will control all non-diegetic music. (non-diegetic sounds are heard by the player but do not exist in the game world) In the “In Game Music” I will control all the music that the character can hear, like the music from a radio, a TV, etc.
Each sound controls its own effects, such as attenuation and stereo/3D spatialization.
I also use buses for specific zones. Example a radio music in the bathroom will send the sound to the “Bathroom Room Reverb” that will produce a reverb sound effect.

For user control in the ‘Music Bus’, I have a volume control that will also impact the “Diegetic Music” and “In Game Music” volume.

In Use:

It’s similar for many other type of sounds like the voice, footsteps, etc.
For global effects, I send “Diegetic Music”, “Diegetic SFX”, etc. to a “Player Root” auxiliary bus.

It’s like a global bus that allow me to control the effects of several bus types.
Example if the player get pinned under Talas paw I can add a low pass filter on the “Player Root” to give a muffled effect on all the sound that the player can hear, except the non-diegetic music or UI sound that will not be affected by this effect.

I briefly showed these effects in the December 2025 devblog, but the system is now much more advanced and structured.

Design philosophy:

I always keep in mind the context of the sound and add variation and effects depending on it.

Design philosophy context:

Diegetic vs non-diegetic
Subjective vs objective
Player vs world

Example: when the player walk his own foot steps will be a bit stronger than the others player foot steps.
About subjective if you get crushed and muffled in Talas sole, the objective sounds like the ambiances and other SFX will be muffled, but your own sounds like the bones cracking will be way less impacted by the effects.

Still about the bones cracks, if you get crushed in first person view you will hear the sound all aroud your ears with a headset.
But in third person view the sound will be spatialized in the 3D space and come from the character position.

For the player that give I think a good immersion about gettting shrunk and crushed.

Audio - Doppler Effect

About the effects, Wwise doesn’t support Doppler effect so I need to calculate it and set the pitch value in code, but at end this give me more control depending on the environment scale or the player scale.
With MMVS I set the speed of sound depending on the environment scale and for some specific objects I set the speed of sound on the player scale. Example:

In the Cozy House you can hear moving cars outside, the doppler effect use the environment scale to set the speed of sound.
But for the ToyCar the doppler effect directly use the ToyCar scale, so you will continue to hear a doppler effect at any scale when the ToyCar passes quickly by you.
I also have object that will use the player scale, it can give nice effect for object that the player can handle and throw in VR.

It’s not physically accurate but it give more control to the designs. I think in most cases I will use the environment scale.

During my tests I notice that my calculation was not working in some cases, it was because some sound with the size difference become supersonic (The object move faster than the sound speed) and the object calculation become wrong with negative value or infinite value.

I fixed that with pitch limits and volume modifications and it give some results. Not sure that physically correct and I have no idea on what I can use that but it fun.
In the video the object have a doppler effect that use the player scale to set the speed of sound, at smaller scales the sound become supersonic.

(Activate the sound on the video below)

Audio - Foot interactions

I also did a big refactoring pass on steps managements.
For every step I have a big data structure used to chooses which sound to use, the footprint texture, the damage type, the camera shake etc.
The code chooses which data to use based on strict parameters like the floor surface, the leg used, the step type (Light, Normal, Heavy, Lift) etc.
But now it’s more flexible and support blending space between the parameters and assets used.

For example I have a scalar parameter “Step Weight”:

0 = Ghost Step (Silent)
0.5 = Light Step
1 = Normal Step
2 = Heavy Step (Stomp)

Example at 1.2 the code will spawn the normal step dust particle effect but with a value of 1.2 and the FX can use this value to add more dust or change the speed, Then I can just use the same particle effect assets for all step weight and let the FX manage the difference.
I can also overdrive some parameters for specific use, example a footprint with crack with a Step Weight a 3.

Like that I can blend the sound, the particle effects, the footprint textures, the camera shake, etc. And every assets can manage the data on their side.
That’s what I do with the sound now. I can use the value 1.5 to have a perfect blend between a normal step and a stomp.

At this moment I was primarily doing the tests with the step sounds in Wwise.
I gradually moved all sounds to Wwise, and cleaning and refactoring old code related to sounds. (Since I finished moving all the sound in Wwise.)

I also moved all the code that manage that in C++ and in a modular system for better debugging/maintainability.
Before that was setup in the character code and mixed with other modules.

Audio - New Shoe Sounds

Following the new foot interaction blend, I finally did Talas shoes with a mix of new sounds and many variations.
Before the sound was exactly the same as Talas barefoot.

As I did with the door in the last devblog, I don’t have a single sound per step. I use several sounds that the engine mix, with several attenuation and localization and also depending on the step type, surface, weight etc.

(Activate the sound on the video below)

It’s not perfect yet, I will have to do a big pass and mastering, but I have a good base.

Audio - Wwise Engine Update

During January, I also moved from Wwise 2022.1.19 to 2024.1.8.
At the first installation I thought 2022.1.19 was the last compatible for Unreal Engine 5.4.
I misread the doc but thanks, the upgrade went smoothly, did not break many things and I was able to update everything without issue.

Because I work with Unreal Engine 5.4, I need to keep the Wwise version compatible with it.
for MMVS v0.4.8 I will move to the last version of Unreal Engine and Wwise.

Audio - Wwise Audio Reflect plugin

The Wwise upgrade also fixed some issues blocking the use of the Wwise Audio Reflect plugin.

In Wwise I use a plugin called “Audio Reflect” that give the possibility to have good sound reflection from obstacles in the environment.
It don’t replace the Reflection and Diffraction system with a good room spatialization but it give very good results for obstacles in the scene.

The idea will be to use the Reflection and Diffraction system for separate the rooms and playable areas, Plumbings, Rooms, In wall zones, etc.
And use the Audio Reflect plugin for the obstacles in the scene like furniture, shelves, shoes, etc.

Here an example only with the Audio Reflect.
When I turn the cameras you can notice that the sound in stereo have a good spatialisation and really come from the doors.
You can also see the preview in Wwise.

(Activate the sound on the video below)

Here I have a big room with several walls to test sound obstacles. But the correct use would be to have several rooms with portals between them. Here it’s just to test. Also the reflect plugin will be applied only on specific sounds when that relevant to keep a good optimization.

Audio - More tests with Wwise Spatialization.

Here I do more tests with the Wwise spatialization with the room zones and dynamic portal.
It’s not perfect yet, I still have some issue because I learn but that work well.

In the video we can see the sound of a room that propagate through the portals, the distance path will impact the attenuation and spatialization in the 3D space.
When the door is open the sound will propagate normally and when closed the sound will be more muffled but still spatialized and come from the door position.
It may not be obvious in the video but around the door I have like an invisible wall that fully block the sound so it only propagate through the door.

(Activate the sound on the video below)

Audio - Desert level and Cobble footsteps

I didn’t just work on tech this month.

I finished updating the Desert Level with the sound rooms, portals and blocking geometry.
The desert level is way more simple than the Talas Cozy House, before big spaces with big but few obstacles and rooms.

(Activate the sound on the video below)

In game it renders pretty well so now need just have to add more variation, sounds and more accurate reverb zones.

You can notice in the video that I have also fully redo the footsteps of the cobble.
Like for Talas and Macro characters I seperated the sound when the paw touch the ground and the sound of the paw lifting.

It’s not as detailed as the Talas shoes but it doesn’t need to be.

Audio - Cozy House Level

For the Cozy House level it way more complex than the desert.
It took a long time because I need to set up all the playable areas with the rooms and portals between them, and the cozy house have many rooms and areas. Then I need to set up the obstacles in the rooms with big objects like the sofa, the bed, the table, etc.

A bit sad it’s not possible to generate all this automatically from the level geometry and surface types like we do to bake the static lightmass.
So I needed to do all at hand.

To add context: Unreal Engine provides a Brush system (BSP) to setup 3D volumes in a level.
It’s what Wwise recommends for defining the room on fly, and it works well for simple setups.

However, in the case of the Cozy House, that was a very bad idea.
In the Cozy House I have many area which intertwine each other, the player is very small and can go in the walls, in the plumbing, under the floor, etc. So I need precise geometry with good modelling.

The Unreal brush is convenient for simple volumes, but it became really complicated to manage when we start to do complex shape and it’s not at all optimized for that.
It will create a lot of unnecessary polygons and dislocated or inverted faces that will cause many issues in the sound propagation.
I discovered that after and I will speak about it in the next devblog.

For the moment keep in mind that all the zone were made with the Unreal Brush.
I started to do the big zones and faces to specify the surface types, wood, concrete, marble, etc.

Following that I created many presets (Mini BP scripts) for the windows and doors to simplify the placement with the level design.
That way I can just update the preset and all windows using it will be updated automatically without having to update each window one by one.

Every preset contain all the necessary components.
Just the kitchen window contains the frame mesh, the glass mesh, a portal for the sounds propagation, a portal to help the light propagation, and two planar reflection for the dynamic reflection when Lumen is not used.
It’s better to manage all that directly in a script preset than in the level design.

All this took me several days of work, before the audio spatialization look like this:

The next big step was the plumbing, and working with the Brushs took a lot of time.

With that Wwise add texts on the face to specify the surface type.
It’s useful but it makes the editor very laggy when you have many faces.

At first, everything worked well, but I quickly notice more and more issues.
Many rooms were not calculated without reason producing sound leaks, the preview in Wwise was wrong removing rooms and Wwise was not giving any log about it.
I did a post about it but no answer was given. Wwise Forum Post

At this moment I used workarounds to re actualize the rooms in the preview but it did not fixed the sound leaking.

For the rest I will explain how I fixed the issue in the next devblog.

Collision Update and Sound Propagation

In the Talas Cozy House level some object was still using per poly collisions.
That is not good for performance and physics calculation because the engine will calculate a lot of faces and not the volume of the object.
It’s better to use a mix of simple colliders (Box, Sphere, Capsule, etc) to approximate the shape of the object.

In the past I already did big pass on all floors and walls to avoid the player to fall through the floor and the rest was planned for the Talas House General Update.
But Wwise also use the collision to calculate the sound propagation and occlusion so I updated all related objects.

Here I just show the shelf. 2848 triangles replaced by 12 box colliders.

Modular Interaction Conditions

During this month I worked on how I manage the interaction conditions to make it more modular.
Before to make an object interactable by the player I needed to create a child class of an interaction point, add the condition logic of the interaction (If the interaction is enabled, Who can interact, at what size, the title, etc) and add the new interaction point to the object.

Now I just add the interaction point to my object and I can directly plug modular condition modifiers.

The condition modifiers are mini scripts that I can reuse easily.
For for the door showed upper I have: - A condition that check if the door is not moving to enable or disable the interaction, - A condition that check the player size. - And a modifier that set the interaction title.

Since it did more change but I will spoke about in in the devblog or February 2026.

VR Mode

I removed the option “Show Body When Stuck to Sole” and added “Preferred VR Mode”, “Preferred Mode When Stuck” and “Preferred Mode In Vehicle”.
It more ergonomic, the user knows immediately what options control what context.

For that I had to update how the VR module that detects the player context and settings, then update the other modules that depend on it, the VR hand, the VR camera, etc.
I also did a big pass on the VR settings and naming.

Simple User Tip

Some people got issue to understand the weighted probabilities in the personality editor, So I added a small help section.

You can open and close the help section.