Wwise Help

Before you start building your hierarchy you need to think about the best way to organize your objects to save authoring time, but also to manage your project's memory consumption. Depending on what you are planning to do, here are some suggestions about how you can group different objects efficiently in your project.

The actor-mixer is the ultimate memory and CPU saver because some of the actor-mixer's properties, such as positioning and RTPCs, are shared by all of its child objects. So when you are considering how to organize your objects, think about grouping objects under actor-mixers to:

	Caution
	Effects applied at the actor-mixer level is an efficient way to apply the Effect but will not save CPU usage. When you apply an effect at the actor-mixer level, an instance of the Effect is applied to all child objects. The effect is processed for each object in real time and can therefore take up a great deal of CPU.

To optimize memory usage, consider grouping objects into actor-mixers to share the following properties:

Let's say you have an actor-mixer containing 10 sounds and you want to set the sound positioning to 3D. You could set the sounds individually to 3D by using the override parent option for each sound. However, doing it this way uses 10 times more memory at run time than if you had set the actor-mixer positioning properties to 3D. Now if you wanted some of the sounds to be 2D, you would still be optimizing memory if you set the actor-mixer's positioning to 3D game-defined. In this case you would override the actor-mixer and apply 2D to the specific sounds because 2D sounds do not require additional memory.

While the actor-mixer is usually your best choice, in certain situations, you can decide to apply properties in containers to optimize memory consumption. If, for example, you are only applying positioning to specific objects within a container, for example footstep sounds in a Random Container, you could save memory by applying the positioning properties to the container and not to the parent actor-mixer. If, however, you want all the objects in the structure to share the positioning properties, you would apply these at the actor-mixer level.

Let's have a look at how you can group objects in an actor-mixer effectively using some of the concepts we have just discussed. In this example you are working with dialogue assets for your game. Some of the assets will be used as character voices and others for radio communications. You could group these under a Dialogue actor-mixer because you know that you want your dialogue to share properties such as volume, for example.

Now that you have set your volume for the actor-mixer, you have decided to add a Parametric EQ effect on the radio dialogue only. You could edit each radio voice and override the actor-mixer settings for each and apply this effect. But you could also work more efficiently by grouping all the radio voice files together in a container and then override the actor-mixer settings and add the Effect on the container.

When you are connected to a game or the Game Simulator you can modify the values of the following relative properties from within Wwise in real time:

	Note
	As a general rule, any property that can be mapped to a Game Parameter, can be modified in real time in game.

To be able to do this however, you need to load the object whose property you want to modify in the Transport Control or the Soundcaster. If the object is not loaded, your changes will not take effect because the object is not registered in the sound engine. For Actor-Mixers, which cannot be loaded into the Transport Control, you can load a child object of the Actor-Mixer and this will register its parent objects in the sound engine. After you have registered the object, it will remain registered for the time that you are connected to the game.

	Note
	Keep in mind that if you pin an object in the Transport Control, other objects cannot be loaded until you unpin the first object. If, however, you have loaded the object in the Soundcaster, the object will be registered in the sound engine.

In Wwise, certain relative properties such as pitch can affect performance on the different platforms. The mechanism for managing pitch in Wwise is based on the sample rate. Applying pitch to sounds increases CPU usage because the files must be resampled.