Right now, the entire simulation runs on its own thread, separate from the rendering and main threads. However, it should also launch each partition to run in their own threads.

After running the simulation, we need to determine what sort of output file we will have.

Notes:

• 7D function needs to be saved. There is a 3D function of source position, a 3D function of listener position, and of course time.
• Sample equally spaced points throughout the scene for both source and listener (and we can interpolate between them).
• Will we need to run multiple simulations for different frequencies?
• Compression? These files could be very large.
• Memory optimization? For such large files, we may need clever schemes to keep memory paged properly

Everything is 2D for now, as this allows for more rapid testing and debugging. In practice, we will need to upscale everything into 3D.

We need to be able to take some scene, perhaps an obj or fbx file, and partition any open areas into rectangular partitions. See the paper for details.

I'm very interested in using this (or https://github.com/jinnsjj/ARD-simulator) in my audio/video sequencer, perhaps we can cooperate.

We need to add code that modifies the forcing functions near the boundary conditions (interfaces), so that sound can propagate between partitions.

To simulate absorbing boundaries, we need to create a small pressure layer at the boundaries. On the boundary of this pressure layer, the forcing terms are multiplied by a reflectivity constant between 0 and 1. See paper for more details.

Probably a house with some walls/doors in it for one of the scenes. A cathedral or concert hall for another. Perhaps an indoor shooting range. We could also have a scene that contains outdoor portions.

After performing rectangular decomposition on a scene, we will have a set of partitions. When loading these into the simulation, we need to find any shared boundaries between them.

I tested ARD in 3D case using MATLAB, there are two partitions, but the interface didn't behave as expected. The wave can pass the interface, but large error arose either. The figure shows the pressure values at a horizon slice of 3D space.

Straight forward. Once we have a demo scene to work with, we need to use the game engine to build up a demo where the user can simply walk around the scene, and maybe look around a bit.

This will be tough, and probably split into smaller tasks later. We need to build an engine that can import our simulation files, and then given an audio source and a listener position, determine what the output sound should be over time.

Please consider adding a license to the project so that others are permited to use it. You can easily do so by clicking this link: https://github.com/thecodeboss/AcousticSimulator/community/license/new?branch=master

Thank you!

Once the project is in a working state, we need to test it on a few demo scenes and record some demos. We'll have to decide on some sounds or music to play in the scene that represent the power of our project.

The project files are called "AudioSimSDL", which was a super temporary name. I can rename these to AcousticSimulator.

This is likely harder than it seems. We have to evaluate various game engines, and figure out which would work best for a simple walking/listening demo. Unity or Unreal are probably overkill, but we could still consider them.