How to Make Models with Sound for vrNav2

vrNav2 release 7.0 beta2
3D Scene Navigation Program
for VR Juggler 2.0.1

Academic Technology Services
University of California, Los Angeles
rnd@ats.ucla.edu
Web: www.ats.ucla.edu/portal/research_activities/vrNav
Developers: Kejian Jin, Joan Slottow, Chris Johanson
Authors: Bruce McCrimmon, Joan Slottow
March 2006

Contents

Introduction

Integrating interactive, real time sound into an interactive, real time model for use with vrNav2 and the DySE Builder must begin with some basic planning. What sounds go into what areas of the model, where do they originate from and how far do they reach?

There are two files that the modeler must prepare in order to add sounds to a model and they must work with each other:

The locations of sounds in a model are called sound sources. A sound source is the exact location from which the sound radiates. Each sound source in a model has a specific sound file in the Dyse Builder that is associated with it.

There are two types of activities with respect to sounds that a modeler can undertake when creating a model:

The modeler must provide named nodes in the model to act as sound sources and bounding regions. The bounding regions must be completely or mostly enclosed spaces and, when bounding regions are used, the modeler must pay attention to how the model hierarchy is created if any or some bounding regions will enclose other bounding regions.

Attaching Sound

There are several ways to attach sound to models, depending upon the effect you wish to achieve.

  1. Attach a Sound to a Visible Object or Group of Polygons

    The sound source will be at the center of the object.

    1. Determine the object or polygon group that will act as your sound source.
    2. Assign a name to that node in Creator or whatever modeling program you are using.
    3. Specify a sound source in the .dyse file and associate a node in the model to it as follows:
      /load SoundSourceAlias SoundFileAlias
          /attachtoobject NodeName
      Replace SoundSourceAlias with the name you will use for this sound source. This is a made up name. Replace NodeName with the node name that you assigned to the object in your model. Replace SoundFileAlias with a sound file alias you specified earlier in the .dyse file and associated with a specific sound file. The actual sound file resides on the DySE Builder Sound Server.

  2. Attach a Sound to a Group of Objects

    The sound source will be at the center of the group of objects.

    1. Determine the group of objects that will act as your sound source.
    2. Assign a name to the group node in Creator or whatever modeling program you are using.
    3. Specify that sound source in the .dyse file and associate a group node in the model to it as follows:
      /load SoundSourceAlias SoundFileAlias
          /attachtoobject NodeName
      Replace SoundSourceAlias with the name you will use for this sound source. This is a made up name. Replace NodeName with the node name that you assigned to the group node in your model. Replace SoundFileAlias with a sound file alias you specified earlier in the .dyse file and associated with a specific sound file.

  3. Attach a Sound to an XYZ Location in Model Space.

    No changes have to be made to the model by the modeler for these sound sources. Sounds attached this way are added to the model by vrNav2 as part of loading the model for navigation.

    1. Specify that sound source in the .dyse file and associate a sound file alias to it as follows:
      /load SoundSourceAlias SoundFileAlias
          /attachtoposition x y z

      Replace SoundSourceAlias with the name you will use for this sound source. This is a made up name. Replace SoundFileAlias with a sound file alias you specified earlier in the .dyse file and associated with a specific sound file. Replace x y and z with the exact coordinates in the model where you want this sound source to be.

    There are disadvantages to locating sound sources by specifying their exact coordinates:


  4. Attach a Sound to an Invisible Object

    If there is no actual object in your model at the sound source location, you can create an object or a geometry in the model at the sound source location and designate that it not be visible when the object is navigated. The procedure for doing this is identical to the one for attaching a sound to a visable object or group of polygons except that the node name must either start with hide_ or end with _hide. Thus if you name the node: hide_NAME or NAME_hide, when the model is navigated with vrNav2, the sound source will be at the location where that object was but vrNav2 will remove the geometry of the object from the model as part of loading the model when it starts up. The object will still be visible when the model is being edited in Creator but it will be invisible when the model is navigated with vrNav2.

    Naming Nodes in Creator

    When you are creating and naming objects and group nodes in creator for use with vrNav2 and for use with sound, do not use names whose total count of alpha-numeric characters are multiples of 4. This is because a bug in the .flt file Performer loader, makes it so that vrNav2 cannot find those nodes. The following names are okay:

    object1
    group1
    column1
    elevation_1

    The following are not:

    objects1
    group_14
    columns1
    elevation_12

    Bounding Regions or Bounds

    A model can be subdivided into distinct sound environments called bounding regions. Each of these regions or bounds can have unique audio sources, mixes and processes. Bounding regions can be based on visible elements of the model such as a building object, or a room object within a building. You can also make totally transparent simple objects and use them as bounds rather than using the more complex real objects of the model. Bounding regions are not to be confused with the bounding volumes that can be modeled and defined in Creator.

    Bounding Regions and Hierarchies

    It is important that the objects or group comprising the bounding regions be correctly placed within the nodal hierarchy of the scenegraph. (Scenegraph is the form the model takes after it has been loaded by vrNav2.) If bounding Object2 is inside of bounding Object1 in the model then is must be beneath bounding Object1 in the hierarchy view. The following image illustrates a simple hierarchy of bounding groups and objects.

    Note that the greenBo object is inside of the redBox object in the model, and that in the hierarchy view the greenBo object (group) is underneath the redBox object (group), adjacent to its constituent polygons. The orangeB and the blueBal objects, which are also inside of the redBox object are also placed underneath it in the hierarchy view. The purpleB object which is inside of the greenBo object is placed beneath the greenBo object (group), adjacent to its constituent polygons, in the hierarchy view. In other words the redBox group is the parent of the greenBo group, the orangeB object, the blueBal object and the purpleB object.

    The following images illustrates a slightly more complex hierarchy of bounding groups and objects.

    You must list the node names of the or groups containing bounding objects in the .dyse file associated with this model as follows:

    /bounds nodeName 0.

    Replace nodeName with the node name you are using.

    There are a few rules that determine which bounding region name must be placed into the .dyse file:

    1. List all of the group node names as bounding regions that between the one at the highest level you will use and the last one of interest on that particular branch of the model graph. Include the names of group nodes you may not want to use as bounds but that are in the hierarchy chain.

    2. If there are multiple children of the same group node all on the same level and you want to use one or more of them as bounding regions, a) you must either use all of them as bounding regions or b) you must also name the parent group node as a bounding region. gSince that parent group node, is not actually of interest, it must be given the name modelg .

    When you navigate a model for which bounds are defined, vrNav2 continuously sends DySE Builder the name of the bounds that you are in as you fly around. If you do not follow these rules, vrNav2 will send DySE Builder the wrong name for some locations. This is undesirable as the wrong sounds will then be generated at those locations in the model.

    For example based upon the following model:

    If you want redBox and greenBo defined as bounding regions then the following must be entered in the .dyse file:

    /bounds redBox 0.
    /bounds greenBo 0.

    If you want redBox and purpleB defined as bounding regions then according to rule 1, you must also include greenBo as a bounds in the .dyse file:

    /bounds redBox 0.
    /bounds greenBo 0.
    /bounds purpleB 0.

    According to rule 2, if you want to define greenBo as a bounds, rule 2a says that both orangB and blueBal must also be designated as bounding regions.

    /bounds greenBo 0.
    /bounds orangeB 0.
    /bounds bluebal 0.

    If you don't want to do that, you must specify the parent group node as a bounds:

    /bounds redBox 0.
    /bounds greenBo 0.

    If you do it this way and are not really interested in redBox, rename redBox to model inside of the model and change the .dyse file to:

    /bounds model 0.
    /bounds greenBo 0.

    Hierarchy Optimizing

    While organizing the hierarchy of nodes that will define your bounding regions, be sure to orchestrate the overall hierarchy such that polygons and objects that are close in spatial proximity are located in the same overall hierarchal groups. Organize and group nodes according to their physical location in the scene. If none of the objects in a group are currently in view at some point during model navigation then the whole branch of the scene graph headed by that ggroup node does not have to be traversed in order to render that frame which greatly enhances performance. The result is navigation at a greater frame rate.

    DySE Files, JCONF files and Model Files

    For interactive sound to work with vrNav2 and the BySE Builder, a .dyse file and a (.jconf) model configuration file must be created for each model. Bear in mind that the .jconf file and the .dyse file you use must be tailored for the specific model. In effect, they must work in concert to achieve interactive sound. They cannot be put together randomly. When you run vrNav2 you supply a model configuration file which names a specific model and provides information about it. vrNav2 loads that model and initializes it and navigates it based on the information provided in the model configuration file. The .dyse associated with a model includes specific information about how sounds are to be added to the model. The commands in a .dyse file are tailored to the specific model in that they reference the node names and the hierarchy used in that model and associate them with sounds or sound effects.