Structure Permissions

Introduction

Structure permissions control access to a structure so performance optimization can take place. The application developer is signaling PEXlib that the given structure or element is static and should now be altered to improve performance. The two levels of permission are write-only and locked. The structure can be made write-only to allow only additions and replacements or it can be locked so no editing is allowed.

Background Information

The motivation for this feature is to improve performance without burdening the developer with implementation-dependent knowledge. After a structure is locked or made write-only an implementation is free to operate on the structure to improve performance. Permissions are easy to use but require some planning by the application developer to deal with related issues.

This creates another reason for developers to consider using structures because they can achieve performance gains and still have interoperability. Because there are two levels of permission in PEX structures there are some additional benefits for using PEX.

Performance optimizations cannot be automatically applied in immediate mode, so implementing them in structures increases the performance gap between immediate mode and structure mode (traversals already run somewhat faster than the same rendering via immediate mode). Most applications choose between these modes based on one or more of the following considerations: rendering performance, data stability, and data size.

Using Permission Features

Here is an overall summary of the edit operations that are allowed on structures with the various permissions:

To get the maximum benefits from this feature, the design of the application must accommodate the constraints of permissions. After a structure is locked it may not be edited. But many applications mix rendering and editing of structures.

The main reason to lock a structure is to increase its rendering speed. If the data in the structure is static for a long period of time (e.g. while a model is being interactively viewed but not modified), then locking is probably a worthwhile performance improvement. Perhaps even an entire structure hierarchy or sub-hierarchy may be locked. Some examples where static data might be viewed include:

Tradeoffs and careful choices need to be made in cases where the data in structures may be modified, especially at interactive or animation speeds. Once a structure is locked, it cannot be unlocked, so the application must have a way to regenerate the data in a ReadWrite or WriteOnly structure.

An application that supports an alternating edit/view cycle of user interaction might operate on an editable hierarchy during the edit session, and then create a separate locked structure hierarchy while viewing or animating. However, the amount of extra data space required for the extra copy must be traded off against the performance improvement. One strategy is to keep a ReadWrite copy of the structure and edit it, then lock it after editing. Another strategy is to make the structure WriteOnly, retaining the ability to add and delete elements; this would allow only some performance optimizations to be performed, but no duplication of storage (such as is implied by keeping a separate Locked structure) would be required. Whatever strategy is used, applications must be designed to preserve or re-create structures or elements, changing of permissions must be optimized and the partitioning of structures must be well designed.

Here is another example: In an animated, articulated model (such as a robot arm), it would be impractical to lock the structures containing the modeling matrices that control the positions of dependent parts of the arm. It would be better to keep the actual attributes and primitives that make up each part of the arm in separate structures that can be locked, and keep the modeling matrices in editable structures.

An extra consideration arises in the case of an application that is going to perform picking on its structure hierarchy. WriteOnly permission preserves the element offsets of all elements in the structure, so a path returned by picking on a WriteOnly structure can be used for editing. Locked structures preserve offsets to execute structure commands however, primitive element offsets are not guaranteed to be preserved in a Locked structure, and several primitive elements may be merged and so become indistinguishable. This means that the path returned when a hit occurs on a primitive in a Locked structure is valid for that (locked) structure hierarchy, but may not be useful to guide editing on the ReadWrite version of the same structure. Therefore, it is recommended that picking traversals be done on ReadWrite or WriteOnly structures, even if the image with which a user might interact during picking was created with a Locked structure.

All these strategies come together when a complex model is built and modified by picking pieces to modify. The following outline shows how this might be done by keeping a ReadWrite copy of the structure.

PEXCreateStructure A
PEXCreateStructure ALocked          

    .

    .

    .

                     
(add
elements or edit existing                                      
elements of structure A)

while( event )
 
VIEW:
    PEXCopyStructure A->ALocked
    PEXSetStructurePermission ALocked
    PEXStructureLocked 

    PEXRenderNetwork ALocked        
(rendering
performance is optimum                                       at
this point because optimization                                
      was done)

PICK:
set pick aperture
path = PEXPickOne( A )
PEXBeginRendering                   

PEXAccumulateState( path )          
(the
path returned by PEXPickOne                                    
  can be used to change line color or                          
            to redraw the picked element in some               
                       other color)

PEXRenderElements( path )           

PEXEndRendering                     
(the
old structure is destroyed                                     
 because it cannot be changed to                               
       ReadWrite and copying to it is not                      
                allowed)

PEXDestroyStructure ALocked         

PEXFreePath(path)                   
(exit
PICK with an editable structure                                
      "A" that can be further edited and                       
               locked again as shown at the start              
                        of this example)