No acoustic simulation available after baking process is done

[joachimpoutaraud]

Hi everyone, here i am asking again for a little help :

I did a new scene on Unity 2019.3.7f1 with a basic wood house (1floor, 1 ceiling, 3 walls (Mesh Filter+Mesh Renderer+Box Collider+AcousticsGeometry Script) put an audio source inside of it (with some acoustic adjust & adjust experimental scripts).

I did a NavMesh for my scene, went to the Acoustic Window, enable the house in Acoustic Geometry and apply some wood varnished acoustic on the materials. Finally, i made a probe calculate process (everything was fine and i could see probes and voxels on play mode) and baked my scene locally.

After that i reopened Unity, drag the acoustic manager with my .ace file baked (that i renamed .ace.bytes), activate play mode but still nothing is working and the audio source now no longer takes FPSCharacter distance into account (i mean that the audio source sounds like it's everywhere).

One thing i noticed is that the probes are now appearing in a red color, is that normal? Other than that the Console shows nothing and here is a part of my AcousticsLog.txt file :

----------------------CREATE TASK IMAGE---------------------- Successfully set working directory to: working Writing to file: Acoustics_SampleScene_TaskImage_0.dat Setting simulation region for probe 0. Floor depth: 5. Ceiling height: 10 Filling Rectangles...

----------------------RECTANGLE FILL---------------------- Creating simulation voxel map of size (367,367,73) from scene voxel map. Applying simulation region around source...Ensuring load-balancing for up to [10] runtime threads: Limited max rectangle size to [0.938206M] cells Setting up rectangular decomposition.Fill rectangles: [0/9,382,051 voxels][-------------------------------------------------] Fill rectangles: [939,369/9,382,051 voxels][--------------------------------------------] Fill rectangles: [1,885,113/9,382,051 voxels][*---------------------------------------] Fill rectangles: [2,829,413/9,382,051 voxels][**----------------------------------] Fill rectangles: [3,772,046/9,382,051 voxels][***-----------------------------] Fill rectangles: [4,715,352/9,382,051 voxels][****------------------------] Fill rectangles: [5,656,602/9,382,051 voxels][*-------------------] Fill rectangles: [6,280,410/9,382,051 voxels][****----------------] Fill rectangles: [7,104,010/9,382,051 voxels][****------------] Fill rectangles: [7,296,727/9,382,051 voxels][*****-----------] Fill rectangles: [8,007,437/9,382,051 voxels][*-------] Fill rectangles: [8,102,157/9,382,051 voxels][**------] Fill rectangles: [8,334,157/9,382,051 voxels][***-----] Fill rectangles: [8,596,813/9,382,051 voxels][****----] Fill rectangles: [8,774,293/9,382,051 voxels][*---] Fill rectangles: [8,874,682/9,382,051 voxels][**--] Fill rectangles: [9,006,985/9,382,051 voxels][***-] Fill rectangles: [9,142,695/9,382,051 voxels][***-] Fill rectangles: [9,272,385/9,382,051 voxels][****] Switching away from random sampling to HashSet for managing unassigned voxels. Fill rectangles: [9,371,507/9,382,051 voxels][****] Fill rectangles: [9,382,051/9,382,051]: Done.
Interface area: 999,998.00. Average volume: 177,019.00. Average (nlgn/area): 75.19 Filled rectangles: 53. Total simulation cells: 9382051 Elapsed time: 1 s. Successfully wrote task image file: Acoustics_SampleScene_TaskImage_0.dat

----------------------CreateTaskImage Finished----------------------

RunTritonTask launching with parameters -- TaskImageFile: Acoustics_SampleScene_TaskImage_0.dat NumThreads: -1 WorkingDir: working SharedInputDataDir: . Encoder Mode: parametric Encode from file: No TelemetryId: f0673203-8b72-412e-86ec-5d2232a26566 NodeSize: Local

Setting working directory to: working Setting working directory failed. Defaulting to current directory. RunTritonTask: Auto-detected [10] threads. RunTritonTask: Loading task image file from: Acoustics_SampleScene_TaskImage_0.dat... Task will output file(s) with common prefix: [Acoustics_SampleScene_task0] and extension: [.enc]

=====================INITIALIZING SIMULATOR====================== MaxFreq: 500.000000, CellSize : 0.255000, Timestep : 0.000340, #Rectangles : 60, Air cells : 11272165 Creating rectangle map of size: [367 367 87], from global voxel map. PML Cells: 5.84M Tracking interfaces...Done. Creating simulator instance: 0 Added monopole probe with volume type: [Point] Creating simulator instance: 1 Added dipole probe with direction: +X Creating simulator instance: 2 Added dipole probe with direction: +Y Creating simulator instance: 3 Added dipole probe with direction: +Z SIMULATOR INITIALIZED.

========================== ENCODER ========================== Receiver grid spacing: 1.500000 Outdoorness: 0.944321

----------------------COLLATE---------------------- Successfully set working directory to: working Reading config data. Collating now. Done adding acoustic data. -----VOXEL MAP COMPRESSION----- Runtime voxel map coarse cell refinement: 16x. Cell sizes: Coarse / Fine: 1.02 / 0.06375 meter. Filling runtime voxel map... Compressing runtime voxel map... Voxel compression progress: 1% Voxel compression progress: 2% Voxel compression progress: 3% Voxel compression progress: 4% Voxel compression progress: 5% Voxel compression progress: 6% Voxel compression progress: 7% Voxel compression progress: 8% Voxel compression progress: 9% Voxel compression progress: 10% Voxel compression progress: 11% Voxel compression progress: 12% Voxel compression progress: 13% Voxel compression progress: 14% Voxel compression progress: 15% Voxel compression progress: 16% Voxel compression progress: 17% Voxel compression progress: 18% Voxel compression progress: 19% Voxel compression progress: 20% Voxel compression progress: 21% Voxel compression progress: 22% Voxel compression progress: 23% Voxel compression progress: 24% Voxel compression progress: 25% Voxel compression progress: 26% Voxel compression progress: 27% Voxel compression progress: 28% Voxel compression progress: 29% Voxel compression progress: 30% Voxel compression progress: 31% Voxel compression progress: 32% Voxel compression progress: 33% Voxel compression progress: 34% Voxel compression progress: 35% Voxel compression progress: 36% Voxel compression progress: 37% Voxel compression progress: 38% Voxel compression progress: 39% Voxel compression progress: 40% Voxel compression progress: 41% Voxel compression progress: 42% Voxel compression progress: 43% Voxel compression progress: 44% Voxel compression progress: 45% Voxel compression progress: 46% Voxel compression progress: 47% Voxel compression progress: 48% Voxel compression progress: 49% Voxel compression progress: 50% Voxel compression progress: 51% Voxel compression progress: 52% Voxel compression progress: 53% Voxel compression progress: 54% Voxel compression progress: 55% Voxel compression progress: 56% Voxel compression progress: 57% Voxel compression progress: 58% Voxel compression progress: 59% Voxel compression progress: 60% Voxel compression progress: 61% Voxel compression progress: 62% Voxel compression progress: 63% Voxel compression progress: 64% Voxel compression progress: 65% Voxel compression progress: 66% Voxel compression progress: 67% Voxel compression progress: 68% Voxel compression progress: 69% Voxel compression progress: 70% Voxel compression progress: 71% Voxel compression progress: 72% Voxel compression progress: 73% Voxel compression progress: 74% Voxel compression progress: 75% Voxel compression progress: 76% Voxel compression progress: 77% Voxel compression progress: 78% Voxel compression progress: 79% Voxel compression progress: 80% Voxel compression progress: 81% Voxel compression progress: 82% Voxel compression progress: 83% Voxel compression progress: 84% Voxel compression progress: 85% Voxel compression progress: 86% Voxel compression progress: 87% Voxel compression progress: 88% Voxel compression progress: 89% Voxel compression progress: 90% Voxel compression progress: 91% Voxel compression progress: 92% Voxel compression progress: 93% Voxel compression progress: 94% Voxel compression progress: 95% Voxel compression progress: 96% Voxel compression progress: 97% Voxel compression progress: 98% Voxel compression progress: 99% Compression done. Compressed 2.26 MB raw voxel data to 0.51 MB. Checking precompute and runtime voxel map consistency... Check progress: 0% Check progress: 1% Check progress: 2% Check progress: 3% Check progress: 4% Check progress: 5% Check progress: 6% Check progress: 7% Check progress: 8% Check progress: 9% Check progress: 10% Check progress: 11% Check progress: 12% Check progress: 13% Check progress: 14% Check progress: 15% Check progress: 16% Check progress: 17% Check progress: 18% Check progress: 19% Check progress: 20% Check progress: 21% Check progress: 22% Check progress: 23% Check progress: 24% Check progress: 25% Check progress: 26% Check progress: 27% Check progress: 28% Check progress: 29% Check progress: 30% Check progresData was not found for some probes. Output contains data for 0 / 123 probes Done. Output written to: Acoustics_SampleScene.ace s: 31% Check progress: 32% Check progress: 33% Check progress: 34% Check progress: 35% Check progress: 36% Check progress: 37% Check progress: 38% Check progress: 39% Check progress: 40% Check progress: 41% Check progress: 42% Check progress: 43% Check progress: 44% Check progress: 45% Check progress: 46% Check progress: 47% Check progress: 48% Check progress: 49% Check progress: 50% Check progress: 51% Check progress: 52% Check progress: 53% Check progress: 54% Check progress: 55% Check progress: 56% Check progress: 57% Check progress: 58% Check progress: 59% Check progress: 60% Check progress: 61% Check progress: 62% Check progress: 63% Check progress: 64% Check progress: 65% Check progress: 66% Check progress: 67% Check progress: 68% Check progress: 69% Check progress: 70% Check progress: 71% Check progress: 72% Check progress: 73% Check progress: 74% Check progress: 75% Check progress: 76% Check progress: 77% Check progress: 78% Check progress: 79% Check progress: 80% Check progress: 81% Check progress: 82% Check progress: 83% Check progress: 84% Check progress: 85% Check progress: 86% Check progress: 87% Check progress: 88% Check progress: 89% Check progress: 90% Check progress: 91% Check progress: 92% Check progress: 93% Check progress: 94% Check progress: 95% Check progress: 96% Check progress: 97% Check progress: 98% Check progress: 99% Check progress: 100% Checks passed.

[jaegrover]

Hi there, I'm not an official PA team member but have been working with it in Unity recently. Please take my comments with a grain of salt.

Can you confirm you've tried the following: -After baking, search for the MicrosoftAcoustics prefab in your project explorer window -Drag and drop that into your scene somewhere -Reference your baked data with that file (I believe you said you did all this, just checking) -Make sure the Transform/Coordinates on your MicrosoftAcoustics object are set to 0,0,0 otherwise the probe location may be offset and it might not work -Make sure that you add a Mixer with the Project Acoustics effect on it in your Windows --> Audio --> Audio Mixer view -Make sure the Audio Source's Positioning is set to full 3D, not 2D -Make sure the Audio Source has the Spatialize checkbox checked ON -Make sure that Project Acoustics is set as your Spatializer plugin in your project settings -While the game is in Play mode, click on the Scene tab. Do you see green voxels drawn over the level geometry where your camera is pointing? If not, the probe data may not have been loaded / positioned correctly

Let me know if any of that helps :)

[joachimpoutaraud]

Hi and thanks for your help ! Yes i confirm all the following informations that you send, especially when it comes to set the 0,0,0 on the Transform/Coordinates of the MicrosoftAcoustics object.

(I've also noticed that the audio source is making a short crack when i enter play mode)
Anyway maybe a screenshot of my scene will be more easy to analyse :

[jaegrover]

Ah, I'm sorry that didn't help. It may be best to just wait for an official answer from the PA team.

What I can say at the moment: -My project looks similar to yours, with the voxels and probes appearing, except the voxels render as blue in my project, rather than red in yours, as you have pointed out. -I am not using the Acoustics Adjust Experimental script -I did a bake in the Azure cloud, rather than a local bake

Perhaps you could try removing the Experimental script, and if that doesn't work, doing an Azure bake? I notice you mentioned that you had to rename the baked data file - that's also something I didn't do. The Azure bake should only take about 5-10 minutes. Setting up an account is a little tricky, but it comes with $200 of free credit, and the bake should only cost a few dollars, if that, as long as you select Use Low Priority Nodes from the Bake tab of the Acoustics window. I've set up a couple of Azure accounts now, for personal and professional use, so if you have any questions, please let me know, the process of setting up can be a little intimidating, but it's great once you have it up and running

[joachimpoutaraud]

Alright then, i tried to remove the experimental script and rename the .ace.bytes file with only .ace but it is still not working. Concerning the Azure bake, i will take your advice in consideration and create a virtual machine and see if there are any notable changes thanks!

[kegodin]

Hi @joachimcnrs , the red colored probes implies a bake failure. As @jaegrover mentioned (thanks!), probes from a successful bake are colored blue-green. The log file you shared in your original post shows a failure message ('Data was not found for some probes. Output contains data for 0 / 123 probes').

How long did the local bake take? For 123 probes I would have expected it to take a few hours. This will tell us whether the bake failed during initialization or if it completed some computations and failed mid-bake.

You mentioned this is only part of the AcousticsLog.txt, can you share the rest?

[joachimpoutaraud]

Alright thanks that is good to know ! The bake did take only 10 minutes so i guess this explain that.

But then i dont understand why the local bake didnt work here is the AcousticsLog.txt file AcousticsLog.txt

[kegodin]

Thanks for sharing the full file. The log file shows the simulator-encoder crashed on initialization.

How much RAM is on your workstation? If less than 8GB, or if there were other significant RAM users running, it could be an out-of-memory problem. This specific error is one that we know our tools currently lack diagnostics on.

[joachimpoutaraud]

Ok thanks, here are the caracteristics of my workstation :

Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2208 Mhz, 6 Core(s), 12 Logical Processor(s) Installed Physical Memory (RAM) 32.0 GB

I did install Docker on my machine and configured the advanced settings with resources for 10 GB of RAM for the local bake. I also tried to bake my scene using the Azure Batch and create a vCPU (Standard D13 v2 (8 virtuals processeurs, 56 Gio memory) but the Azure bake status indicate "Waiting for the nodes to initialize".

I precise that i did put the number 2 for the Node count in the bake tab.

[jaegrover]

Ah ok, you'll need to request more nodes.

In your Azure portal, click on your Batch Account, then on the bottom left (scroll down), click Support (or Open Support Ticket / Request Assistance, I forget the exact wording and unfortunately can't sign into my account atm. The phrases / things to select that I've written below are probably not word for word accurate either, but it'll at least give you a clue as to what to look for)

Select Open a New Issue Under Issue Type, select Quotas or Account Limits Select Request a Quota Increase It will ask you what type of core you want to increase your quota for There is a drop down menu where you can select what type of cores you're requesting an increase for Click on this drop down menu and scroll down far until you find "Low-priority nodes / cores," then click on that Type in the number of Low-Priority Cores that you want. I typed in 1,000, which corresponds to 125 active nodes, so far this has been perfectly adequate for my needs Click OK / Submit By the end of the day, you should receive an email letting you know that your quota increase request has been approved Now, in Unity, open the Acoustics tab, click Bake Under Node Count, put in 1000 Click on USE LOW PRIORITY. Make sure this is ON Then submit your bake

This is what has worked for me so far.

To clarify - there are two main types of nodes you can use, dedicated or low priority. Dedicated nodes are reserved exclusively for your use. They are quite expensive to use. Low-priority nodes are not assigned exclusively to you. When you submit a bake, Azure will attempt to assign you as many available nodes as you have specified in your Node Count field in the Acoustics Bake window - this number is limited by your Account Quota Low Priority Nodes are MUCH cheaper, and you can easily get access to enough of them to bake even large maps in a few hours. The only disadvantage of Low Priority Nodes is that they can be co-opted for other tasks by other users with higher priviledges. So far, however, this hasn't affected me negatively - I've had a steady 125 node (1000 core) Low Priority allocation for all of our level bakes over the past weeks with no interruptions. I think the longest bake was a fine bake of a level with 4800 probes, which maybe took 4 hours? Probably less. By default, when creating a free account with Azure, for some reason you're not assigned any Low Priority Nodes, i.e. your Quota is Zero, so you have to go through the process of requesting that quota increase. If you request a huge number of nodes, you'll likely be contacted by MS Tech Support for a credit check, basically they don't want people accidentally running up massive charges they can't cover, or abusing their free accounts etc. I'm sure there's more to it, but that's what I know at the moment.

I hope that all helps / makes sense. I'll have access to my account later today, if you're still stuck I can make a quick video tutorial.

[joachimpoutaraud]

Thanks for your answer ! I guess my problem is also that i don't really understand the exact meaning of nodes. Can you explain it to me ?

Concerning the Azure Batch, i did ask for a request with a number of 500 low priority nodes. But like you said the Azure Batch Account seems a bit tricky and I think i'll definitly prefer to understand the process with a local bake first to be sure that i am not doing some tricky mistakes.

[jaegrover]

Sure thing :)

Honestly it's a little confusing for me as well. I've been learning Azure, and all of this terminology, for the first time as I've been figuring out Project Acoustics as well.

If I understand correctly, Azure works by sending tasks to Virtual Machines (VMs). Each Virtual Machine is similar to an actual PC, in that it has a certain amount of RAM and CPU speed available. They can be assigned operating systems like Linux or Windows - you can even select to have certain software installed, e.g. Maya to do 3D rendering tasks.

A "Core" just refers to one of those CPU cores, similarly to how your desktop PC might have an 8-core processor. A Node is a group of cores. In Unity if you go to Window-->Acoustics-->Bake tab, check out the VM Node Type drop-down menu.

By default, the VM (Virtual Machine) Node Type is listed as Standard_F8s_v2. This means that when your data is sent off to Azure for processing, it's going to try to allocate "Standard F Series, Version 2" nodes, which each have 8 cores. Think of this like saying, "We're going to give you one Intel i7 Processor, which has 8 cores in it." So, for each node you are assigned via Azure, you'll be using 8 cores to process the tasks that are sent in.

If you selected 500 Low Priority Nodes, and selected Standard_F8s_v2 as your Node Type, Then Azure is going to try to look for up to 500 Low Priority, Standard_F8s_v2 nodes to use for your task. If it manages to assign all of them, you'll be using 500 nodes * 8 cores, for a total of 4,000 cores. Once again, think of that as using 500 Intel i7 processors, each with all 8 cores running to compute your bake task.

Now, everyone's Azure account has what's called a quota. This is a limit of the maximum number of cores you can use. By default, there's a big group of low-priority nodes that are available on a first come, first serve basis. Think of this like going to a public swimming pool that you and your friends want to go to. If you pay a small fee, you can get in during Open Swim time. Each of you will try to find a lane that's not full of people. As more people come in, lanes may fill up, and they might start going to other lanes. If everything fills up, no more people can come into the pool until someone leaves.

Now, let's say someone is a professional swimmer, so they paid a lot of money to reserve an entire lane for the afternoon. When they show up, they're going to kick everyone else out of that lane. Then they're going swim there for as long as they want. Once they leave, the lane opens up again, and the other folks can come back in. That's similar to how Dedicated Nodes work. You pay a much higher fee, but you guarantee that no one else can interrupt your task.

You could think of a quota as how many people you're allowed to bring to the pool with you. If you've just joined the swim club, they might not want you to show up on the first day with 20 of your friends, especially if they don't know you or your friends very well, or don't know how long you're going to stay there. But if you check in and ask for permission, they'll give you a higher max number of people you can bring with you to the pool at once. You start off with a very low quota of low priority nodes (actually, I think it's zero!) and a very low quality of Dedicated Nodes as well. Once you've spent some time in the pool and have decided which one works best for you, you can submit a request to the staff to either let you bring more friends with you into the open swim area for a lower price (increasing your low priority node quota) or reserve lanes exclusively for you and your team for a very high price (increasing your dedicated node quota).

Since I'm a solo sound designer working as a contractor for an indie team at the moment, I got a quota of 125 Low-Priority Nodes, which corresponds to 1,000 cores. This week, I submitted bakes for 6 of our levels, which had anywhere from 800 to 4000 probes. The average time it took to bake each map was around 3 hours, and the cost for doing all of those was around $200 (it might have been less, we tried an experimental very high probe count - 12,000 - build at the end which increased our charges). By comparison, using 25 dedicated nodes for a bake of a level with 4000 probes took about 3 days and cost us $500. The support staff here at Project Acoustics were super helpful (love you guys <3) in helping me out and saving me from spending tons of money I didn't need - check out the other Issues in this forum, I have a post from a couple of weeks ago that goes into more details.

I hope that helps! If you're still struggling with Azure at all, don't get frustrated. It's pretty weird to get into without having a background in this stuff. I'd be happy to throw together a little video overview for you later on if you think that would be helpful.

Have a great weekend :)

[nikunjragh]

Great answer @jaegrover - love the swimming pool analogy for low-pri vs dedicated nodes, quotas etc. Thanks for taking the time to help others.

@joachimcnrs: like jaegrover said, a "node" is a PC sitting somewhere far away with a CPU and RAM, and "cores" are all the CPU cores in it just like your laptop. Our tools are such that each listener probe needs a full PC to do the simulation fast - it will use up all the cores and a lot of RAM on the PC/node (off the top of my head, 16GB to be on the safe side although like @kegodin said, 8GB should be good, but for the local bake you could try upping to 16GB and if it still fails, share logs with us).

[joachimpoutaraud]

Hi again and thanks for your answers, they are very clear and helpful !

Because my actual computer has only 6 cores with 32 GB of RAM, i guess it won't be possible to do a local bake. Anyway, i think i'll just wait and see if my low-pri request is accepted and then see if i can manage to do a bake with Azure correctly.

Have a nice day

[nikunjragh]

@joachimcnrs 6 cores will work, it will just go slower than with 8 cores :). The hard limit is on RAM. You should be able to do a local bake. I was suggesting increase your Docker allocation to 16GB and try doing a local bake again. And if it still fails, share those logs with us, because with 16GB we know a 100% that it can't really be running out of RAM.

[joachimpoutaraud]

Finally it worked !! Thanks again for your help

[kegodin]

Great to hear! So to confirm it sounds like the resolution was to increase the docker image RAM allocation to 16GB. Closing this issue for now.

[prielgaier]

Great to hear! So to confirm it sounds like the resolution was to increase the docker image RAM allocation to 16GB. Closing this issue for now.

is it possible that the baking process is only using a single ram module? i have 4 ram sticks 8 gb each and in the entire duration of the baking process i see only 8 gb out of 32 gb (memory used) in the task manager

[NoelCross]

@prielgaier it is possible that your Docker configuration caps the Docker VM at 8GB which I think is the default setting. You should be able to modify the Docker settings to allocate more of your host system resources to the Docker VM.

[MikeChemi]

We have made plenty of optimizations since this thread was posted in 2020. Many bake configurations only need 8GB of RAM these days, so there's nothing to worry about unless you're seeing specific failures.

[prielgaier]

Is a docker being created the moment i run the RunLocalBake.bat? Because im not baking through a virtual machine (unless it runs a vm on its own) I had no failures its just that i upgraded my cpu from an i7 9700k to an i9 13900k and the local bake times haven't noticeably improve, is it possible that im limited by ram after all? Im baking 500 probes

[NoelCross]

If you are using Unity, then the RunLocalBake.bat tool utilizes Docker Desktop for executing the local bakes. The Unreal Engine plugin requires downloading additional local bake tools and those tools run natively without Docker Desktop.

[MikeChemi]

The processing doesn't scale linearly with number of cores. I'd expect some improvement, but I wouldn't expect 16 cores to be strictly 2x faster than 8 cores, for example. Looking at the processors you listed, I can't say for sure what I'd expect since the i9 has more cores overall but the efficient cores are at a lower clock rate.

[prielgaier]

@NoelCross I'm using the Unreal Engine's additional bake tools, then i guess i do have a problem with limited ram usage? @MikeChemi the i9 13900k has 24 cores and 32 threads compared to my old 8 cores 8 threads, and even the efficiency cores run a touch faster at 4.3 GHz compared to 4.2 GHz on my last cpu (locked it due to limited cpu cooling)

[MikeChemi]

Gotcha. Could be I/O bound. Each probe that bakes does fresh I/O. How fast are you seeing a single probe bake taking? I've seen that if a probe only takes a few seconds to bake, we can take a couple seconds of I/O for each one, so now the disk reads are the slow thing, not anything to do with the actual processing.