(Flight Simulator 10 Animations 101) Part 3 - Controling Model Part Visibility

If you looked at the XML file posted in my previous post, you may have noticed an interesting tidbit inside the definition for the "c_tire_blurred_key" model information. This is the <Visibility> tag which seems to contain some sim-related paramerers. Here is the relevant blob of XML code...

ModelDef.XML

  12:   ...

  13:    <PartInfo>

  14:      <Name>c_tire_blurred_key</Name>

  15:      <Copy>tire_anim</Copy>

  16:      <AnimLength>100</AnimLength>

  17:      <Visibility>

  18:          <Parameter>

  19:              <Sim>

  20:                  <Variable>CENTER WHEEL RPM</Variable>

  21:                  <Bias>-5.0</Bias>

  22:                  <Scale>0.01</Scale>

  23:                  <Units>grads</Units>

  24:              </Sim>

  25:          </Parameter>

  26:      </Visibility>

  27:    ...

Obviously I am going to be technical here but will be kind enough to explain what this all boils down to for the end-user in practical terms. In Flight Simulator 9, several parts on an aircraft were swapped out based on a specific set of conditions. For example, the prop on an aircraft would change from a solid model to a blurred texture once the RPM of the engine reached a certain point. Overall, this makes sense, but the major problem was that these model changes were significantly hard coded within the game engine.

For example, to add a helicopter after the product had shipped could be difficult unless you were willing for the rotor to be considered in the same way as the prop of an aircraft is. In addition, this behavior was strongly tied to the naming convention used within the 3D modeling package. As we develop Flight Simulator further and add a more dynamic user experience (such as airport ground vehicles, cars on highways, ...) we needed the ability to move away from this hard-coded behavior and introduce something which could achieve the same results, yet be configured externally from the application.

By allowing sim-driven code (which is similar to the code used for gauges within the panel system), we can increase the flexibility of within our models and in the end means a better realism and visual experience for the end-users.

The visibility of a model part is essentially determined by running the specified code and using the result value. For any result < 0, the part is not visible. For any result > 1 the part is visible. For results between 0 and 1, we consider it as a transition state (in which we could eventually fade-in a part) but for the moment the 0-1 range is considered as visible. Here is another code example which shows how more complex code could be used to control the visibility of a tire model based on a range of rotational speed.

<Visibility>
<Parameter>
<Code>
(A:CENTER WHEEL RPM, grads) 400 > if{ 0 } els{ 1 }
</Code>
</Parameter>
</Visibility>

Note that the code in the above expression could also have been written as: (A:CENTER WHEEL RPM, grads) 400 >

Another example which might be even nicer comes from the fact that effects can now be attached to various parts of a model. And such effects can also be lights. Instead of having a set of lights baked into the model definition, they can be defined externally and controlled directly through the use of simulation states. For example:

<PartInfo>
<Name>general_light</Name>
<AnimLength>100</AnimLength>
<Visibility>
<Parameter>
<Sim>
<Variable>LIGHT LANDING ON</Variable>
<Units>bool</Units>
</Sim>
</Parameter>
</Visibility>
</PartInfo>

Overall, we are moving away from hard coded values and putting as much of our logic externally. This not only allows us but also third party addon developers to be more flexible in their creations and thus deliver a greater experience to the end user.