The following is an outline of a topic discussed at the OpenFlight User Group Meeting I/ITSEC 2009.

We invite your comments...

Problem:

User wants to “model” non-visual geometry in Creator to use in their application. They need to "mark" the geometry in such a way that it is ignored in the OTW display but is used by other parts of the simulation. In the example presented here, the simulation is in VBS2 and the geometry to model is:

-- Geometry LOD (for Collision Detection)

-- Fire LOD (for Weapons Fire)

-- Shadow LOD (casts a shadow)

These geometries are used by the simulation engine but are not "displayed" in the visual representation of the VBS2 entities.

Proposed Solution:

-- Add a new boolean field to mark a Group Node (and by definition all children) as a “non visual” node

-- In general, runtime chooses how to interpret the Group Node

-- For VBS2, use OpenFlight Extension to further describe non-visual node (Geometry/Fire LOD)

The key point I see here in the discussion is an intent to violate the normal extension behavior. When a file contianing Tag-along extension data is read by a tool that does not understand the extension data, the tool recieves the nodes in the files with the unknown extensions stripped off.

The intent there seems clear -- The renderer should make a best-effort attempt to render the node, even though it may not be able to do as good a job as a renderer which does understand the extension data.

By contrast, the discussed cases... Shadow LOD, etc... are fundamentally cases that (1) require extension data to fully define the use of the nodes, becuase rendering them visually is not the reason they're in the database... and (2) should not be rendered or dealt with if you do not understand the extension. In other words, if you don't understand the "Shadow LOD" extension being used, you should ignore the nodes completely, and not make a best-effort attempt to render the nodes. This would apply not only to shadow volumes, or collision hulls, but also to any other very specialized nodes where a renderer could only make fundamentally flawed rendering decisions unless it understood specifically what the extension told it to do with the nodes. I can think of some examples in sensor applications where it would be more appropriate to not render a face at all, if you don't know how to read the appended data which is there becuase it is necessary for sensor processing.

From this perspective, it seems to me that the distinction being sought is not a "Visual vs nonvisual" classification distinction, but a "Best-effort vs ignore-if-unknown" rendering intent distinction.

It seems like a more appropriate means may be to tag the extension data itself, in a standardized way. In other words, the extension header on a node should have a field which defines the rendering intent of the node, if the extension data is not understood. The default case, of course, would be "best-effort", consistent with previous versions of the API.

If the renderer sees a node tagged as "Ignore if unknown" and it does not understand the extension data, then it would cull the nodes to which that extension data was attached.

A database editing tool which sees the "ignore if unknown" extension that it does not understand should still render the nodes, for the sake of editability, perhaps with some alternate rendering mode to highlight the difference to the user.

A renderer which sees the node tagged as "ignore if unknown" and it does understand the extension, obviously gets to do whatever it pleases with the node, based on what the extension data says. It may use it purely as a collision volume, or as a shadow volume (if it's daytime and clear skies and the mode is enabled...) or whatever else the extension data tells it to.

If multiple extensions are present on a node, some saying "best effort" and other saying "ignore if unknown", then the "ignore if unknown" portion should override in the mixed case.

Summary:

Do not attach the field to group node, attach to extension data header itself.

New field specifies whether renderer should try to render nodes with unknown extensions or ignore them.

It seems like a more appropriate means may be to tag the extension data itself, in a standardized way. In other words, the extension header on a node should have a field which defines the rendering intent of the node, if the extension data is not understood. The default case, of course, would be “best-effort”, consistent with previous versions of the API.

The key here is that the data is identified in a standardized way. Even if it was, it would be up to the app to read and interpret the extension header. The solution proposed in the previous post would obviate the need for the app to look at the extension data. It could learn from the group attributes that the node (and the extension data) could be simply ignored (if it chose to ignore non-visual data altogether)

Another solution to this problem was proposed at the OpenFlight User Group Meeting at the Image Conference July 13, 2010. In this solution, instead of adding a single boolean field to simply mark the node as "non visual" (without giving a clue as to what the node really was), it was suggested that several boolean fields could be added to the Group Node to identify the node as exactly what it is. For example, new boolean fields to mark the group as one or more:

-Collision

-Shadow Caster

-Navigation

These classes of non-visual geometry seem fairly general, hence the suggestion to recognize these as first class citizens of OpenFlight format. Note that these fields are not mutually exclusive. That is, a node could be one or more of these geometry types simultaneously. For example, a node could be marked as both a collision and shadow caster. This would be useful if the same geometry was intended to be used as both a collision volume and a shadow caster. If the group node could be marked as just one of these geometry types, you'd have to duplicate the geometry (needlessly) for one node to be the collision volume and one node being the shadow caster. If the geometry was identical, why force duplicate nodes.

Let us know what you think of this.

Thanks.