You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The spacial audio blending is currently using all three values of the transform, which makes sense in 3D but not so much in 2D. It's not a problem if for small z values, but once you start to have values above 10.0 it starts to screw with the distance blending. Was just wondering if there is any intention to address this.
I also noticed that you could potentially implement the following optimization change in here. Not 100% sure if that is producing the exact same result, but it at least sounds similar and it reduces the need to compute a square root calculation for every spacial sound every frame, so that is a decent optimization for bigger games.
let volume = (1. - sound_path.length_squared() / self.max_distance.powi(2)).clamp(0.,1.).powi(2);
The text was updated successfully, but these errors were encountered:
The API of bevy_kira_audio is likely to change drastically over the next few months (see #114). In that, spacial audio might also change and become more configurable.
For now, you could increase max-distance for your special audio taking the probably constant z values into account.
Oh awesome. Yeah I just implemented a simple 2D spacial audio on my own. If this crate gets upstreamed into Bevy then there are most likely going to be a lot of changes, in which case this might get reworked too. Will close this and see where we are after a few updates. For anyone in the meantime, this my 2D spacial audio implementation: https://github.com/PraxTube/magus-parvus/blob/master/src/audio/spacial.rs
The spacial audio blending is currently using all three values of the transform, which makes sense in 3D but not so much in 2D. It's not a problem if for small z values, but once you start to have values above
10.0
it starts to screw with the distance blending. Was just wondering if there is any intention to address this.I also noticed that you could potentially implement the following optimization change in here. Not 100% sure if that is producing the exact same result, but it at least sounds similar and it reduces the need to compute a square root calculation for every spacial sound every frame, so that is a decent optimization for bigger games.
The text was updated successfully, but these errors were encountered: