bugfix(audio): Fix range volume fade of 3D sounds and make it configurable in AudioSettings.ini

[xezon]

• Follow up for refactor(audio): Use MilesAudioManager::getEffectiveVolume consistently #2058
• Fixes 3D sounds are a bit quiet and behave differently from retail #2226

This change is a follow up for #2058 which accidentally and insufficiently changed the volume of 3D sounds depending on their distance to the camera pivot.

Originally the sounds did not correctly consider the 3D distance checks in MilesAudioManager::getEffectiveVolume. They were considered for some logic, but not for the actual volume. This meant that the volume never correctly faded between the min and max ranges of audio events, and left sharp audio cut offs instead.

Problems

1. The originally unused fade math in MilesAudioManager::getEffectiveVolume was incorrect. The commented linear fade math was actually correct.

2. The original 3D sounds were always loud all the way to the max range because they never faded correctly. Therefore an exponential fade is suitable to better preserve the original loudness of 3D sounds.

AudioSettings.ini

New configuration options were added to AudioSettings.ini to control the 3D sounds fade behavior:

• Use3DSoundRangeVolumeFade = Yes/No // Set No for original bugged behavior
• 3DSoundRangeVolumeFadeExponent = 1..N // Set 1 for linear fade, larger 1 for sharp fade near max range

Exponential Fade

I picked a exponent of 4 which creates a curve like this and sounded good.

x(0) is MinRange, x(1) is MaxRange
y(0) is MinVolume, y(1) is MaxVolume

[greptile-apps]

Greptile Summary

This PR fixes the 3D sound range volume fade in MilesAudioManager::getEffectiveVolume, replacing the previously broken reciprocal-distance formula with a correct configurable exponential fade, and exposes the new behavior through two new AudioSettings.ini keys (Use3DSoundRangeVolumeFade and 3DSoundRangeVolumeFadeExponent).

Key changes:

• Removes the erroneous 1 / (objDistance / objMinDistance) attenuation that was applied unconditionally, which caused volume spikes rather than fades.
• Implements a correct normalized linear-to-exponential fade: attenuation = pow((dist - minDist) / (maxDist - minDist), exponent), applied only when the new m_use3DSoundRangeVolumeFade flag is set.
• Adds m_use3DSoundRangeVolumeFade (Bool, default true) and m_3DSoundRangeVolumeFadeExponent (Real, default 4.0) to AudioSettings with proper constructor initialization and INI parse-table wiring.
• Caches the TheAudio->getAudioSettings() pointer locally in getEffectiveVolume to avoid repeated calls, a minor clean-up.
• The m_3DSoundRangeVolumeFadeExponent has no runtime clamping: a zero or negative value set via INI can produce a negative or zero volume for all sounds beyond objMinDistance, which may cause unexpected audio backend behavior.

Confidence Score: 4/5

• Safe to merge; the core fade math is correct and the only concern is a missing clamp on the user-configurable exponent.
• The fix correctly replaces broken attenuation logic with a well-understood exponential fade formula. All edge cases within the documented valid range (exponent ≥ 1) are handled correctly — distance equals max silences the sound, distance within range fades proportionally. The only gap is that an out-of-range exponent (≤ 0) set in the INI can produce a negative volume, which is not validated at parse time or at use time.
• Core/GameEngineDevice/Source/MilesAudioDevice/MilesAudioManager.cpp — the pow call at line 2715 should clamp or validate m_3DSoundRangeVolumeFadeExponent to prevent negative volume output from bad INI values.

Important Files Changed

Filename	Overview
Core/GameEngine/Include/Common/AudioSettings.h	Adds m_use3DSoundRangeVolumeFade and m_3DSoundRangeVolumeFadeExponent fields with correct constructor initialization; existing structure and pragma-once guard are intact.
Core/GameEngine/Source/Common/Audio/GameAudio.cpp	Two new INI parse-table entries wired up correctly to the new AudioSettings fields; no functional issues.
Core/GameEngineDevice/Source/MilesAudioDevice/MilesAudioManager.cpp	Replaces the broken reciprocal-distance attenuation with a correct configurable exponential fade; logic is sound for valid exponent values but lacks a guard against zero or negative exponents which can produce negative volume output.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[getEffectiveVolume called] --> B{isPositionalAudio?}
    B -- No --> C[volume *= m_soundVolume]
    B -- Yes --> D{getCurrentPosition != null?}
    D -- No --> E[return volume as-is]
    D -- Yes --> F[compute distance vector\ndistance = listenerPos - soundPos]
    F --> G{ST_GLOBAL flag?}
    G -- Yes --> H[objMin/Max = globalMinRange / globalMaxRange]
    G -- No --> I[objMin/Max = event minDistance / maxDistance]
    H & I --> J[objDistance = distance.length]
    J --> K{objDistance >= objMaxDistance?}
    K -- Yes --> L[volume = 0.0f]
    K -- No --> M{use3DSoundRangeVolumeFade\n&& objDistance > objMinDistance?}
    M -- No --> N[volume unchanged]
    M -- Yes --> O["attenuation = (objDist - minDist) / (maxDist - minDist)"]
    O --> P["attenuation = pow(attenuation, fadeExponent)"]
    P --> Q["volume *= 1.0f - attenuation"]
    L & N & Q --> R[return volume]

Loading

_{Last reviewed commit: 49616d2}

[greptile-apps]

_{3 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[Mauller]

sounds good to me

[Skyaero42]

when objMaxDistance and objMinDistance are set by m_globalMaxRange and m_globalMinRange, they are set through ini. Theoretically, a user could (incorrectly) edit the ini such that the values are the same, causing a division by zero.

Looking at it, this could also be the case if objMax/MinDistance is set by m_minDistance and m_maxDistance.

[xezon]

If objMaxDistance == objMinDistance, then it never gets here, because if( objDistance >= objMaxDistance ) above.