Wwise Authoring is currently not compatible with macOS Catalina. We recommend that you remain on the current version of your operating system until further notice.

Community Q&A

Where Wwise users help each other out!

Audiokinetic's Community Q&A is the forum where Wwise users ask and answer questions within the Wwise community. If you would like to get an answer from Audiokinetic's Technical support team, make sure you use the Support Tickets page.

Unity doesn't create assets for new Wwise objects until you select them

0 votes

Hi guys,

I am using Wwise 2019.1.3 with Unity 2019.2.2

It seems that the current Wwise integration in Unity doesn't create its assets for newly added Wwise objects (Events, SoundBanks etc.) until they are used (selected for a property in the inspector or similar).
And by assets I mean the assets created in the folders within Wwise/Resources/{ObjectType} with long names like for example 1C1B17F2-9A82-46F0-B19E-C825D68D5621.asset.
It is strange because when a Wwise object is deleted in Wwise, its asset is immediately removed in Unity.

The problem is that when the assets for newly created Wwise objects are not created immediately, it can easily lead to conflicts when using version control. For example if two developers both use a newly added event, they will both independently create the event's asset file along with its meta file. This meta file will most likely be different, leading to a conflict. And it is not really convenient to have the audio designer manually select all new Wwise objects in Unity before committing.

I seem to have located the file responsible for updating these assets according to changes in WWUs, namely the AkWwiseWWUBuilder.cs located in Wwise/Editor/WwiseWindows/.
And if I add a single line of code to that file in the function UpdateFiles() at around line 526 (in version 2019.1.3) marked with green below, it seems to create the assets for newly added objects immediately – as desired:

...
foreach (var pair in _WwiseObjectsToAdd)
{
   System.Collections.Generic.List<AkWwiseProjectData.AkBaseInformation> removeList = null;
   if (!_WwiseObjectsToRemove.TryGetValue(pair.Key, out removeList))
      continue;

   removeList.Sort(AkWwiseProjectData.AkBaseInformation.CompareByGuid);
   foreach (var info in pair.Value)
   {
      var index = removeList.BinarySearch(info, AkWwiseProjectData.AkBaseInformation.CompareByGuid);
      if (index >= 0)
         removeList.RemoveAt(index);

      WwiseObjectReference.FindOrCreateWwiseObject(pair.Key, info.Name, info.Guid);

     }
}
...


But I would rather not modify the integration code, also because it has to be maintained if we update Wwise.
And I am wondering if the current behaviour is intended from Wwise's side, and if there is some issue with my modification that I just haven't thought of... (?)

Does anybody have thoughts on this?

Best, Jakob

 

asked Sep 20 in General Discussion by Jakob Hougaard Andersen (170 points)
edited Sep 20 by Jakob Hougaard Andersen

... okay, It seems that just adding that one line doesn't handle SwitchStateGroups, StateGroups and the Switches/States within them. So my version 2.0 looks like this (again, my addition is marked with green):

foreach (var pair in _WwiseObjectsToAdd)

{

            //Add objects

            var type = pair.Key;

            foreach (var info in pair.Value)

            {

                WwiseObjectReference referenceObject = WwiseObjectReference.FindOrCreateWwiseObject(type, info.Name, info.Guid);

 

                //Handle the case of referenceObject being a StateGroup

                if (type == WwiseObjectType.StateGroup)

                {

                    WwiseStateGroupReference stateGroupReferenceObject = referenceObject as WwiseStateGroupReference;

                    var groupValue = info as AkWwiseProjectData.GroupValue;

                    if (groupValue != null)

                    {

                        foreach (var value in groupValue.values)

                        {

                            WwiseStateReference stateReferenceObject = WwiseObjectReference.FindOrCreateWwiseObject(WwiseObjectType.State, value.Name, value.Guid) as WwiseStateReference;

                            stateReferenceObject.GroupObjectReference = stateGroupReferenceObject;

                        }

                    }

                }

 

                //Handle the case of referenceObject being a SwitchGroup

                else if (type == WwiseObjectType.SwitchGroup)

                {

                    WwiseSwitchGroupReference switchGroupReferenceObject = referenceObject as WwiseSwitchGroupReference;

                    var groupValue = info as AkWwiseProjectData.GroupValue;

                    if (groupValue != null)

                    {

                        foreach (var value in groupValue.values)

                        {

                            WwiseSwitchReference switchReferenceObject = WwiseObjectReference.FindOrCreateWwiseObject(WwiseObjectType.Switch, value.Name, value.Guid) as WwiseSwitchReference;

                            switchReferenceObject.GroupObjectReference = switchGroupReferenceObject;

                        }

                    }

                }

            }

 

            System.Collections.Generic.List<AkWwiseProjectData.AkBaseInformation> removeList = null;

if (!_WwiseObjectsToRemove.TryGetValue(pair.Key, out removeList))

continue;

 

removeList.Sort(AkWwiseProjectData.AkBaseInformation.CompareByGuid);

foreach (var info in pair.Value)

{

var index = removeList.BinarySearch(info, AkWwiseProjectData.AkBaseInformation.CompareByGuid);

if (index >= 0)

removeList.RemoveAt(index);

            }

        }


However, this has made me notice another bug (?) – namely that if you delete a State or Switch within a group, its object reference asset will not be deleted in Unity.
If you delete the whole group, the States/Switches within will be deleted, except from any States or Switches that you deleted directly – they become somehow untracked and will exist forever (if you don't delete them manually).

Best, Jakob

Please sign-in or register to answer this question.

...