raytraced-audio: procedural occlusion and reverb for Godot

What the plugin actually adds

raytraced-audio is described as adding procedural audio effects to Godot like echo, ambient outdoor sounds and muffle. The word procedural is the important one, because it says the effects are computed from the scene at runtime rather than authored as assets or zones. The plugin removes a class of manual work that a level designer would otherwise face. You no longer need to create and maintain zones while creating levels, since putting the RaytracedAudioListener node in your scene makes most of the features available. That single node is the entry point and the only structural requirement, which is a strong statement about the ergonomics. A demo video is linked, and the README also points to a video by Vercidium for insights into how the implementation works, which is a useful pointer for anyone who wants to understand the approach rather than just use it. The project is MIT licensed, the primary language is GDScript, the default branch is main, and the last push to the repository was on 2026-06-09 with no GitHub releases, so the repository itself is the distribution channel rather than a tagged artefact.

Two audio buses and what each one controls

The plugin creates two new audio buses right off the bat, one named Reverb and one named Ambient, and both names can be changed under Project Settings, Raytraced Audio. The fact that the names are configurable is a small but telling detail, because a hard-coded bus name is a collision waiting to happen in a project that already has a bus called Reverb. The reverb bus controls echo and reverb, and the README gives the behaviour that makes it more than a named effect. There will be a much bigger reverb in large enclosed rooms compared to small ones, or outside in the open, which is the opposite of a fixed reverb preset and the reason the plugin exists. The ambient bus controls the strength and pan of sounds coming from outside. In a room with a single opening leading outside, sounds on this bus appear to come from that opening, and they fade based on the player's distance to it. So the ambient bus is doing something subtle and quite specific, since the pan is not a fixed value but is derived from where the opening is relative to the listener, and the level is a function of distance. That combination is what produces the impression of an opening to the outside rather than a stereo sound effect.

Muffling without authoring occlusion volumes

The second headline feature is that by using RaytracedAudioPlayer3D nodes instead of regular AudioPlayer3D nodes, sounds get automatically muffled behind walls. This is the part that a conventional Godot project handles by hand, either with an AudioListener area shape or with an occlusion mask, and both approaches require the designer to keep a shape in step with the level geometry. The plugin derives the obstruction from the scene itself, which means the muffling follows the walls whether or not anyone remembers to update a volume. The reason the muffling works for a particular player is that the plugin casts a ray from the listener towards the player, and if the ray is interrupted by geometry, the sound is treated as occluded. That is the same ray that produces the echo information, which is why the plugin can offer both effects without a second, separate query for each one. The distinction between the two node types is what makes this opt-in per sound, since a regular AudioPlayer3D is left entirely alone and plays as Godot normally plays it.

The cost model, stated as a formula

The performance section is the most useful thing in the README for planning a scene, and it is stated as a count rather than as a vague warning. Because the rays need to gather different information about the environment, the actual number of processed rays can go up to rays_count times (2 + n), where n is the number of enabled RaytracedAudioPlayer3D nodes in the scene. The breakdown in the README spells out the terms, being one ray that bounces around, one echo ray, and one muffle ray per enabled RaytracedAudioPlayer3D. So rays_count is configurable and it is the base multiplier, and the per-player term is what makes the cost scale with the scene. A scene with two enabled players and a rays_count of, say, four is already processing a noticeable number of rays per tick, and the cost grows linearly with the number of players. The practical implication is that the plugin's cost is a function of content, not just of settings, and a dense scene with many audio sources needs a lower rays_count than a sparse one if the frame budget is fixed. The plugin also adds two performance monitors to the engine's own monitoring tooling, raytraced_audio/raycast_updates for how many raycast updates happened in the update tick, and raytraced_audio/enabled_players_count for how many RaytracedAudioPlayer3D nodes are currently enabled in the scene. Having the enabled player count as a visible monitor is the detail that makes the cost model actionable, since it tells you when a scene is drifting towards more rays than you planned for.

Installing it

The installation is a manual copy, and the steps are short enough that there is no room for a package manager entry here.

- Download or clone this repository
- Copy the `addons/raytraced_audio` folder into your project's `addons/` folder
- Enable the plugin in `Project Settings > Plugins > Raytraced Audio`

The third step is the one that matters and the one that is easy to forget, since copying files into a project does not enable anything in Godot. The plugin has to be switched on in the project settings before the RaytracedAudioListener node appears in the scene tree. The repository layout is that of a Godot addon project, with an addons/ directory holding the plugin itself, a default_bus_layout.tres resource at the top level, an icon.png with its .import file and an icon.svg with its .import file, a project.godot for the plugin's own project settings, and the usual .editorconfig, .gitattributes, .github and .gitignore. The presence of default_bus_layout.tres at the root is worth noticing, since it means the two buses the plugin creates are defined as a Godot resource, which is the mechanism Godot uses to lay out buses and their routing, and it explains how the plugin arranges to have its buses present in a project that opens with the plugin enabled.

Where raytraced-audio is the wrong choice

The first limit is the per-frame cost, which the plugin itself documents and which will decide the outcome for a large scene. The number of processed rays scales with the number of enabled RaytracedAudioPlayer3D nodes, so a level with many sound sources pays for every one of them, and on a platform with a tight frame budget that is a real constraint rather than a theoretical one. The second is that the effects are procedural, which means they are computed rather than authored, and a computed reverb is an approximation of a room rather than a convolution of an actual room. For a game where the audio is a feature rather than a detail, that approximation may not be the one you want, and a hand-tuned convolution reverb on a zone trigger is still the higher quality option. The third is that the plugin only understands what it can see in the scene graph. Occlusion comes from geometry, so an opening in a wall that is not modelled as geometry with a gap will not produce an opening in the ambience, and a room whose bounds are implied by a bounding box rather than by walls will not give the enclosed reverb that the README describes. The fourth is the single entry point. One RaytracedAudioListener node is what makes the features work, and a project with several local player characters, or a camera that moves independently of the listener, has to decide which one drives the effect, since the plugin's model is a listener-centric one. And the fifth is the delivery, since there are no GitHub releases and the installation is a copy of a folder, so a project pins the plugin by copying a specific commit and nobody is distributing a version for you.

Editorial conclusion

Adopt raytraced-audio if you build a Godot project where the player moves through connected spaces and you want audio that reacts to the geometry rather than to hand-authored zones. Skip it if your project is a linear set of scenes with fixed audio needs, since a zone based setup is simpler there. Verify first how many RaytracedAudioPlayer3D nodes your scenes contain, because the number of processed rays grows with each one, and that the plugin's bus names do not clash with buses you already have.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. WhoStoleMyCoffee/raytraced-audio on GitHub