UI Composer FAQ

The best examples for UI Composer users can be found where you installed Studio. A typical install places these files in: C:\Program Files\NVIDIA Corporation\UI Composer %version%\Studio\Content\

Tip: You may find it useful to add a Storage Palette entry to the Samples folder, for easy access to the sample assets and behaviors.

COLLADA is the primary 3D import format for Studio. The installers for the COLLADA exporters we recommend are installed along with UI Composer.

For DCC packages that do not have COLLADA exporters, Studio also supports native import of the .3ds file format. You can translate your 3D assets into the 3ds format prior to importing into Studio.

Artists have a number of options when synchronizing external assets with their UI project:

• Refresh from File: Inside NVIDIA UI Composer, you can easily refresh existing assets (such as models, images, sounds, behaviors, and so on) with a newer version on disk. Animation tracks and events are preserved.
• Reference file path in the exported data file: Whenever an external file is imported into Studio, the path to the original file is associated with the asset inside Studio. During export, loading, or even at runtime, this path may be used to read in the latest version of the asset from the file on disk.
• The Remote Source feature of images causes Studio to use assets from disk via a specified path, rather than using the imported data for them.

For basic placement, our system for visualizing pivot points allows you to also see your cameras and lights. Make sure under the View menu that Pivot Points is checked (Hotkey: Ctrl-Alt-P) and select the object you wish to see. The blue line of the visible pivot point represents the direction of the camera/light (i.e. which way it is pointing), while the green line represents the local 'up'.

Tip: You can attach a cone object to the camera or light, with the material for that cone set to wireframe mode. While the angle of that cone does not automatically match the camera or light field of view, it can help provide a stronger visual of item placement.

By using the COLLADA format, animation can be imported directly from 3ds Max or Maya into Studio.

When you import resources into your scene, they are stored in the Library. If you remove these items from the scene, they are not automatically removed from the Library. This provides an easy way to include resources in your presentation that may not be present in the scene originally, but are still there if you want to add them later.

Removing this extra "bloat" if you don't need it is easy. In Studio, right-click anywhere in the background area of the Library palette and choose Delete Unused Resources. All items that are not instanced in your scene will be purged.

Tip: If you see some items still in the Library that you don't think are in the scene, select the item and press Ctrl-I (for "instance"); Studio will highlight the first item in the scene that uses that Library item. Successive presses of Ctrl-I will highlight successive instances.

Z-sorting is difficult, especially when there are multiple renderers involved. There render engine in Studio is different enough from the render engine in Viewer that there may be subtle differences:

Studio's renderer does perform z-sorting on transparent objects, but it does so on a per-model basis. This means that two intersecting, partially-transparent objects will always have one drawn over the other. There is no per-polygon or per-pixel z-sorting.

NVIDIA UI Composer brings the most value as a solution for creating the user interface for your application. However, the capabilities of NVIDIA UI Composer are sufficiently robust to prototype a wide variety of applications.

• Studio can be used to create compelling interactive storyboards, illustrating key application elements or environments.
• You can prototype early concepts without heavy investment in application technologies.
• Your investment in learning Studio to create a UI translates directly into the skills necessary to prototype your application.

The focus of Studio's design has primarily been on authoring interactive 3D presentations. As such, it is (currently) lacking features common in 2D layout tools, such as guides, grids or automatic alignment. Such tools are high on our priority list for adding in a future release; however, similar functionality can be achieved to some degree right now:

• The Snapping Ruler feature of Studio allows you to cause the rendered edges of items to snap when dragging. This feature can be used to quickly snap the edges of items to a predetermined grid. (You can set the grid size and snapping resolution in the Studio preferences dialog.)
• Items can be precisely placed using the Inspector palette. This does not mean that you have to perform visual layout by typing numbers, however. If you have a field selected in the Inspector palette, the mouse wheel allows you to change it in a controlled manner:
  • The mouse wheel alone will change the values by 1 unit at a time.
  • Holding Shift and using the mouse wheel will increment it by 10 units.
  • Holding Ctrl and using the mouse wheel will increment it by 1/10ths of a unit.

  Thus, using the mouse wheel and shift can be used to cause objects to move along a grid of 10 units.

• When an item is selected, the current tool (move/scale/rotate) can be applied to it by clicking and dragging in the matte (gray) area surrounding the scene window. Holding the shift key while applying these tools with the mouse will cause only one axis to be affected at a time.
• If a visual alignment grid is desired, an image of a grid can be created in Photoshop and then placed on an orthographic Layer behind (or in front of) everything else. The Lock and Visibility Toggle features in Studio can be used to easily toggle this asset on and off.
• An "alignment" behavior can be written that, at runtime, ensures that all items inside a group are aligned in a particular way.

Rest assured that we do not consider the above workarounds to be ideal, or even long-term solutions. However, they are ways to work with content in Studio to achieve specific 2D layout goals.

Studio will be adding additional 2D layout features in future releases.

There is no canvas in the sense you are thinking; everything in Studio is represented in 3D. There is no flat image to zoom in or out of. What you can do is:

• Move the camera closer to or farther away from the subjects of the scene. By default the center of the world is at (0,0,0) and the default camera is looking directly at that point moved away from the origin by -600 on the z axis. Moving the camera closer to the origin (e.g. to -400 on the z axis) will give the same effect as zooming in.
• Change the size of the presentation. The Presentation Size section in the Project Settings dialog allows you to specify how large Studio renders the output of the camera. Setting a presentation to Preserve Aspect Ratio will cause Studio to use the largest amount of space available to render the UI. (Since the contents of a UI are full 3D scenes, they may be scaled naturally and cleanly to arbitrary sizes.)
• Resize the contents of the scene. Placing all items in a Layer inside a single group and scaling that group also provides a way to "zoom" into the scene.

For design purposes, there is a feature called edit cameras. There is a new drop down in the tool bar that allows you to choose different "editing" views without disturbing the location of your actual scene camera.  Zooming the canvas can now be achieved by selecting the Front View edit camera, and using the mousewheel to zoom in and out.

To design your presentation against specific layout guidelines, you can create an image showing one (or more than one) of these features and bring it into your presentation. Place this image in a Layer behind (or in front) of all others, with the camera for that Layer set to Orthographic. Simply hide the Layer prior to exporting your presentation to ensure that it is not included in the scene.

Remember that each Layer in Studio is a full 3D scene, with depth and 3D objects. It is not a 2D canvas.

Studio was designed primarily for 3D composition and authoring interactivity, not content creation. It imports 3D models rather than being a modeler; it imports images rather than being an editor. As such, Studio does not include tools for 'drawing' a 2D interface. In a pinch, however, models may be pulled out from the Basic Objects palette (such as a rectangle) and manipulated to achieve the desired shape.

UI Composer supports masking of textures applied by geometry by using the alpha channel of images as an opacity mask. By applying multiple images and animated UV coordinates, complex masking effects can be achieved on the surface of an object.

Studio's text has limited support for text "styles". Drop shadows are not supported at this time.s

Certain items in Studio are not multi-selectable (in the current release). You can select multiple keyframes at once, either by 'rubber-band' selecting them or by shift-clicking the object in the timeline. Multiple keyframes may be moved, copy/pasted, have their interpolation changed, or deleted all at once.

It is also possible to select multiple files in Windows Explorer and drag them onto the library palette to import more than one file at a time.

A future version of Studio will include the ability to select and modify multiple objects at once.

Studio allows you to import PNG, PSD, JPG, TGA, TIF and BMP files. PNG, TGA, and PSD files support alpha channels. JPG files support lossy compression. Once imported, however, Studio uses the uncompressed raw buffer in its representation. It is this raw buffer of data which is exposed to the exporter, along with the path to the original file.

If your application supports JPG or PNG files, then you may use them (when appropriate) in Studio. Exporting the presentation to your application, your conditioner should use the path to the original file, and then load that file from disk directly.

If your application requires a file format not supported by Studio, then you may as well use PNG files for the visual representation. Your conditioner should convert the path to the original PNG file into a path to an image saved in your file format.

Studio's Layer objects provide a way to visually stack one scene on top of another. This feature should not, however, be used as the primary layering technique.

Each Layer object is actually a distinct 3D space with objects positioned inside it. To visually layer one item on top of another, bring that object closer to the camera within the space. By default, the camera is looking along the z-axis of the scene. With a default camera placement, decreasing an item's z position will bring the item closer to the camera.

With perspective rendering, bringing an item closer to the camera also makes it larger and (for items at the edge of the view) may cause one item to no longer appear on top of another. (Just like perspective in the real world.) Such problems may be avoided by setting the camera for the layer to Orthographic mode by checking the Orthographic checkbox at the top of the Inspector palette.

There are two answers to this question: "Lua" and "Whatever you want" 

• Lua is a proven technology used by many embedded applications, preferred for its speed, cross-platform nature, ease of integration, and small runtime size. We provide an example Lua Framework with the NVIDIA UI Composer offering. The Lua Framework is fast, robust, and embedded-ready. Many of UI Composer's customers have already chosen Lua as their lightweight, powerful scripting language of choice for including in the application; more still are choosing to adopt the Lua Framework included with UI Composer wholesale. In addition to existing and ongoing efforts in improving this framework, choosing to use our framework allows you to reuse the Behaviors and Components we have already written that use it.
• However, at the core, UI Composer is scripting-language agnostic. In addition to the potential for reuse in your engine, the Lua Framework is included as an example showing how to integrate any script framework into Runtime. This allows you to write Behaviors in Studio using any language that you choose, be it Python, Ruby, Lisp, Eiffel, Haskell, and so on.

Mash your fists against the keyboard. It's really that easy, and something cool is BOUND to happen.

Well, OK, maybe it's not that easy. But it's not that hard, either. 

To start with, drag a Behavior from the Basic Objects palette. Select the behavior in the Library and set the Script Type (in the Inspector Palette) to Lua. Double-click on the behavior to begin editing the script, and you're on your way.

UI Composer's integration of Lua is well documented. You can find this documentation on the Lua Bindings page of this manual.

If you prefer to start with working code (rather than a blank canvas), we recommend looking at some of the example behaviors that ship with UI Composer. These example behaviors are located at C:\Program Files\NVIDIA Corporation\UI Composer %version%\Studio\Content\Behavior Library\. 

The Lua integration is high powered. You can gain access to any element in the scene, affect its properties, and control state-to-state flow, among many other things. Custom properties can be added to Behaviors (like any other object) through the Edit Custom Parameters dialog to expose script parameters in an artist-friendly way. Additionally, custom events can be exposed, and used by the Lua script or Studio's point-and-click Action system.

DebugView.exe by SysInternals displays standard debug message output using OutputDebugString (which is what Lua's output uses internally). The function you are looking for is:

output( 'Any old string can go here!' )

For more information on output(), see the Lua Binding Documentation included in this manual

With the Lua framework included in UI Composer, there are five times when Lua code inside Behaviors can be run:

1. Global code (code outside any function) is run once for each Library behavior.
2. Code inside an onInitialize function is run once for each instance of the Behavior in the scene.
3. Code inside onActivate or onDeactivate is run when a behavior instance becomes active or inactive.
4. Code inside an onUpdate function is run once for each frame of each instance of the Behavior in the scene.
5. Functions can be invoked in response to registerForEvent.

When do each of these occur, and what is the 'self' scope for each?

Let's look at an example. Assume that a Behavior has the following code:

 
     1 output( tostring( self ) .. " is being created." )
 
     2
 
     3 function self:onInitialize( )
 
     4 output( tostring( self.element ) .. " is being initialized." )
 
     5 registerForEvent( 'onPoke', self.element, self.sayHey )
 
     6 end
 
     7
 
     8 function self:onActivate( )
 
     9 output( tostring( self.element ) .. " is being activated." )
10 end 
11
12 function self:onUpdate( )
13 output( tostring( self.element ) .. " is being updated." )
14 end 
15 
16 function self:onDeactivate( )
17 output( tostring( self.element ) .. " is being deactivated." )
18 end 
19
20 function self:sayHey( )
21 output( tostring( self ) .. " says hello." )
22 end

1. At load time the 'global' code will be executed. A unique Lua table is created and stored for this instance of the behavior, and all functions are defined in that table.

2. If this Behavior is just in the Library of a presentation, no code will ever be run. As soon as the scene moves to a slide where there is an instance of this Behavior active in the scene, the onInitialize function (if present) is invoked. In this case, the value of self passed to the function is the Lua table created above.

3. Line 4 of the above Behavior will produce output like "userdata: 1337feeb is being initialized." for each instance. You will also see the output from the onActivate handler as the behavior is being activated.

4. After the initialization occurs, then the onUpdate function (if present) is run every frame, for each instance of the Behavior. The self is (again) set to the Lua table representing that behavior.

   Each frame, every active instance will produce output like "pointer 0x12341234 is being updated.".

5. If an onPoke event is fired on an instance of the Behavior, the sayHey function on lines 20-22 will be run. The self passed into the function is again the Lua table representing this behavior.

6. If the behavior ever goes out of scope, say the presentation switches to a slide where it doesn't exist or is visibility toggled off, you will see the output from the onDeactivate handler.

For more information on the rhythm of frames see the Frame Update page of this manual.

When do these occur when multiple Behaviors are present?

1. Step 1 occurs at load time and in the order the instances are seen in the Timeline (i.e. a depth-first traversal). All 'global code' is run before any callbacks are called.
2. The first frame a behavior is active, step 2 (initialization) occurs. Again, this occurs according to the Timeline order of the instances. If instances of different behaviors are interleaved, initialization still occurs per instance Behavior. (For example, assume that three Behaviors are in the Timeline, Foo1, Bar, Foo2, with Foo1 and Foo2 being instances of the same "Foo" Behavior in the Library. The order of initialization is the order as listed: Foo1, Bar, Foo2.)
3. After all initialization occurs, THEN onUpdate calls will run for all active Behaviors. Again, these are processed in timeline order.

Custom action parameters are passed as normal parameters to the Lua function specified in Studio.

What's up with scripting the 'active' Attribute?

There are several frequently asked questions about scripting the 'active' Attribute.

"I see that setting active to false makes the Element disappear, what else does it do?"

That's 95% of it. If it's active = false, it won't be drawn. It can be compared to a component with two slides with an object that only exists on slide 2. When you're on slide 1, the object on slide 2 exists, but it is inactive. Also, events that are targeted at inactive Elements will not be handled.

"Will inactive Elements be destroyed or garbage collected?"

No. Elements are only destroyed upon destruction of their owning Presentation.

"Are inactive Elements still accessible from script?"

If you have a handle to an inactive Element, you can still use that handle in calls like setAttribute. Getting handles to inactive objects can be a bit tough however, for example getChildren() only returns a list of the 'active' children.

"Will changes I make to the attributes of an inactive Element persist when it becomes active again?"

You can modify the attributes of an inactive Element, and the changes will persist. Unless, of course, something else changes them. (e.g, an animation track, or slide change)

Please see the Integration Overview page of this .chm for information on how to integrate UI Composer with your application.

Studio has a toolbar called the Preview Bar. The preview bar is connected to an external NAnt based conditioning and preview pipeline that sits next to Studio in the Build Configurations directory. By editing the supplied NAnt files, or by creating your own, you can can easily expose different previewing options to your artists using Studio.

You can add custom properties, events, or actions to any object in Studio using the Custom Parameter dialog. These custom properties will show up in the interface with artist-friendly combo boxes, sliders, checkboxes and so on. The values specified by the artist are then available in exported files and, ultimately, your application.

The amount of memory that a presentation takes up is largely dependent upon the assets used in that presentation. The UI Composer Runtime itself is quite lightweight. At the time of writing, a release build uses less than 150k of memory on a PC with no presentation loaded. Memory requirements will obviously increase as your UI's complexity increases.

The example exporter that ships with UI Composer includes the full information for each asset (such as raw image buffers and model vertices) as well as the source path to the original file for that asset. Every item in a presentation is represented by an Element in the core of the Runtime. Each element may have an arbitrary number of named attributes stored on it.

The above information combined means that elements in the Runtime may be used to cache "heavy" information about assets, or may be used simply as unique lightweight references to the nodes. If the latter approach is chosen, your own framework context may be used to load, cache, and unload heavy information for assets as appropriate.

A single UI Composer instance can dynamically load and unload individual presentations, giving control to update and/or render only specific presentations at different times.

Anark Client was the core to Anark's web-enabled playback renderer and standalone playback application, Anark Player. After NVIDIA acquired Anark Studio and Anark Gameface, Anark Player was deprecated in favor of the new UI Composer Viewer.

Yes. You can set up custom events on a "UIContract" behavior that emulate various types of input from your application. Assets in your presentation can then be hooked up to respond to these events. Studio ships with an example file showing how to set this up.

Finding contracts is a simple matter of using the CContractManager, which is typically accessed from a presentation. Setting properties on an element is done with the CElementManager.

Assuming that xAxis and yAxis are custom properties exposed on your UIContract, you can do something like this:

IContractManager& theContractManager = somePresentation->GetContractManager();
IElementManager& theManager = somePresentation->GetElementManager( );
SAttributeKey theAttributeKey;
UVariant theValue;
TEventList theEventList;
CElement* theContract = theContractManager.GetContractByIndex( 0, theEventList );
theAttributeKey.m_Hash = CHash::HashAttribute( "xAxis" );
theValue.m_FLOAT = 0.5f;
theManager.SetAttribute( theContract, theAttributeKey.m_Hash, theValue );
theAttributeKey.m_Hash = CHash::HashAttribute( "yAxis" );
theValue.m_FLOAT = -0.5f;
theManager.SetAttribute( theContract, theAttributeKey.m_Hash, theValue );

and then in Lua:

-- Assumes that the UIContract is attached to the scene
local theContract = getElement( "Scene.UIContract" )
output( getAttribute( theContract, "xAxis" ) )
output( getAttribute( theContract, "yAxis" ) )

Events have two typed parameters that can be passed along with them if they are fired from C++ or Lua. The default keyboard implementation uses this to send keycodes along with keyboard events, but arbitrary events can use the parameters for whatever you like.

Each Presentation has a member called m_EventCallbacks. The CEventsCallbacks class has a method called RegisterCallback which allows you to register a static callback with the event processing system. This allows for easy notification of certain events being fired on certain elements.

In many custom UI creation solutions, seeing the UI changes requires constant attention and occasionally implementation work by a dedicated UI programmer. A simple preview of new functionality can take hours or, in some cases, days. UI Composer offers two major improvements over this method.

Preview directly in NVIDIA UI Composer

• You have the ability to preview animations and composition directly within the Studio authoring environment. There is no wait to see your UI composition or animation.
• You also can preview your full presentation with interactivity on the PC using Viewer, the example viewer included with NVIDIA UI Composer.

Preview directly in your application

Exporting from NVIDIA UI Composer directly into your application is fast enough that artists can use it as an integral piece of their daily workflow.

• A "typical" presentation takes between 10 seconds to one minute to export and then import into a application.
• We recommend that during the integration process, the programmers take the time to ensure that your artists can quickly launch your application and immediately see the UI. Depending on this step, total elapsed time between hitting the preview button and viewing the live UI in your application could be less than 30 seconds.
• This is rapid enough that artists can directly preview their UI in the application dozens of times per hour.

These two terms can be confusing for a newcomer to Studio. Here's a short summary of each:

• Behaviors are encapsulated script objects. They are represented in Studio by a green arrow icon. Behaviors can be dragged and dropped onto different items, and customized by the artist (modifying properties in the Inspector palette). Generally, behaviors add additional functionality, or "behavior", to the objects that they are attached to.
• Components bundle up models, slides and animation into a self-contained, reusable object. They are represented in Studio by an orange circle with a dot in the middle. Components have their own timelines that run independently from the rest of the scene. Components often use Behaviors to be "self-aware". A Behavior can be used to fire and respond to events, as well as switching slides and changing animation programatically.

Components! Components!

Sorry, I got a little over-excited. Components are possibly the coolest feature of Studio that new users often miss. Using components to create a button gives you four major benefits:

1. A component wraps multiple objects together (like a group). The button can then be positioned and animated as a whole, even though it may be comprised of many pieces.
2. Components have their own independent time. Effects on the button can be animated, and this animation plays independently of how the component as a whole is being animated.
3. Components have their own slides. A single UI screen may have any number of buttons on it. Each of these buttons can be independently switched to a "focus" slide or a "disabled" slide (or whatever), without requiring any extra slides in the Scene to represent the various button states.
4. Components are reusable. By saving a pre-made button to an AMC file (right click on the component and choose Export Component), you can reuse the button in new projects or places by simply dragging the component from your Storage Palette.

A little script in a Behavior placed inside the component allows the button to become self-managing. The script can extend the component to add a custom interface, such as adding a "focus()" method or a "selectedState" property. The script handles methods or messages on the parent object and reacts accordingly.

For example, asking the button to focus may cause the script to internally unfocus any other focused object, and then fire an onFocus event. The component may listen for this event to switch to a slide where the button is visually focused.

Currently, there is no integrated connection with content management systems inside NVIDIA UI Composer. Studio project files are binary files that can then be placed in a source control or content management system like any other binary file.

When an asset is imported into Studio, the path to that asset is stored along with the asset in the Library palette. If the asset on disk is updated (e.g. a newer version is synced down) Studio will present a yellow "yield" icon letting you know that it needs to be refreshed in the presentation.

In the future, we plan to implement standard source control support inside NVIDIA UI Composer. This feature is not currently scheduled. If you have specific needs in this area, NVIDIA would love to hear from you.

Keywords: localization, internationalization, i18n, l10n

See the Localization page of this manual.

A dynamic UI, by its very nature, cannot be fully and explicitly designed by the artist. Or, more accurately, the more control an artist has over the appearance, the less flexibility and dynamism is possible. The point at which to trade artist control for programmatic variation is up to you, and helps dictate the implementation.

For example, assume that your UI needs to display a table of text (like a scoreboard). Here are various ways to accomplish this goal, along the continuum from no artist control to near-total control.

• Direct Manipulation - The artist drags out a component or behavior that simply says "(table goes here)". The application calculates the scores, and creates text objects for each cell in the Runtime. The application places the text nodes in the scene graph, and, in addition to setting the text for each object, controls visual attributes like font, size, color, alignment and layout.
• Semantic Separation - The artist drags out a component with a Lua behavior and a single text object in it. The artist chooses the font and style of the text object, and, when appropriate, asks the application to turn it into the appropriate table. The application invokes methods on the Lua behavior such as "addRow( 'Player Name', score, time )"; in response, the Lua behavior duplicates the text object for each cell (treating headers and other items identically). The Lua behavior lays out the table, and fills out the appropriate values. The application no longer knows about the visual aspects, but the layout is still in (Lua) code, and the artist has limited flexibility.
• Templates and Layout Properties - As above, the artist drags out a component with a Lua behavior, but with template objects for the row and column headers, and the table cells. The behavior has custom properties allowing the artist to choose table or column width, cell alignment, and so on. At runtime, the Lua behavior watches for a property on UIContract to be filled out with an array of values. The behavior creates the table, and lays it out (at runtime) per the artist's options. The table can have an arbitrary number of rows and columns, but is reasonably generic.
• Placeholder Content - The artist lays out a full table with a fixed number of columns and rows. The artist has full control over the appearance of each item independently. At runtime, the Lua behavior simply swaps out values on the existing items. The artist has near-total control over the appearance, at the cost of a generic, flexible component. (Not only are the number of rows and columns pre-chosen, but the table's layout does not change if multi-line or very long cells are added.)

The two extreme examples above are non-ideal, but hopefully serve to illustrate the variety of ways that UI Composer can be used to create dynamic content.

The behaviors and components that UI Composer supplies fall more into the middle ground. We suggest providing the artist with a customizable component with a single Lua behavior inside it. Custom properties on the outside of the component provide a simple way to customize the basic functionality. Custom properties on the Behavior inside the component allow the artist more control. Editing assets inside the component allow the artist to control other visual aspects of the component.

We suggest that the "control" Behavior inside the component communicate with the application through one or more custom properties on a global item like our suggested "UIContract" behavior. The component should reflect information from the application and "suggest" changes to that information - the UI should not be the sole repository of application or interface state.

The "Data Table" sample component included with NVIDIA UI Composer is designed like the third item above. See the UI Composer Samples Reference for more information.

Split it into multiple presentations.

UI Composer includes a module called Flow that can be used to easily manage multiple presentations. The benefits of working with multiple, smaller presentations are many. It can allow you to partition the work of creating your UI as well as keep Studio responsive by working with smaller .amw files.

By contrast, the following is how not to create a menu. Do not place all the menu items on a master slide, and then use a variety of slides (along with unlinked properties) to show each menu item being selected. This is a seemingly simple approach that does not require any script, but as the menu grows large it can get out of hand. It becomes most unmanageable if concepts like disabled or locked are to be added, or if menu items are designed to show different options within each state.

Short answer: the same as models, images, or behaviors. :)

Long answer: view the Working with Refreshable Components document in this manual.

One of the following two situations has occurred:

1. You imported a component from one file, and changed the name or location of the file, and then tried to import it a second time. Or,
2. Two components were created from the same original source file, and you've already imported one of them. Because they came from the same source, they have conflicting internal identifiers.

If it's the first case, you can just say "OK" to the dialog and the component will be refreshed. (In the future, you can use the Refresh File... command explicitly instead of attempting to reimport the component.)

If it's the second case, then you (or the author of the component) need to update the components to have unique IDs. For more information (including step-by-step instructions on how to do this) see the section "Creating Refreshable Components" in the Working with Refreshable Components page of this manual.

The Studio application targets several different runtimes. (i.e., playback engines) Not all of these runtimes have exactly the same capabilities. To account for the differences in the various runtimes, and specifically to avoid showing artists using Studio a bunch of options/features that aren't going to function in their runtime, Studio has a feature that allows you to show and hide certain properties in the Inspector palette.

The mechanism that shows and hides built-in properties in the Inspector palette is called "startup.lua" and is so named because you interact with it by editing the file "startup.lua" that sits next to Studio.exe (typically in Program Files).

It is possible to edit startup.lua to expose a number of other features not supported by the UI Composer runtime, but settings you make for those properties will be ignored at runtime, as those features are unsupported. However, it is of course possible to augment UI Composer's integration with a given runtime to support these additional features, at which time it may make sense to re-expose them in the Inspector palette using startup.lua.

UI Composer presentations are fully 3D in all their aspects, so it is trivial to create a resolution-independent interface. 3D objects in UI Composer applications are, by their very nature, scalable. NVIDIA UI Composer also uses high resolution images that can then be exported in whatever reduced size that your target engine requires.

The Project Settings dialog of Studio allows you to change the size of a presentation. For presentations using perspective cameras, different size presentations (with the same aspect ratio) are completely equivalent.

"But how," you ask, "do I create a single presentation that works in 4:3 and 16:9?"

The answer is Lua Behaviors. If Lua script has knowledge about the size of a presentation, it is relatively trivial to write a "Screen Position" Behavior. Such a Behavior, when attached to an object, can position the object in an appropriate location on the screen, such as top left, bottom middle, and so on. Using this Behavior, an artist can create a UI that automatically adapts to arbitrary resolutions, specifying where each object should go on the screen.

Such a Behavior is supplied with Studio, but written in JavaScript for use with NVIDIA Player. (The behavior is called "Stick to Screen", and is documented in the JavaScript Behavior Reference.) Unfortunately, the Lua framework currently does not expose all the information necessary for this behavior to work.

In summary: have your renderer provide information about screen size (or aspect ratio) to your script framework, and write a Behavior to distribute objects as desired.

UI Composer exposes variable aspect ratios and information about presentation size to Lua script. The "Stick to Screen" sample Behavior included with NVIDIA UI Composer demonstrates this technique.

The right answer obviously depends on your team's setup and the roles people play in the process. Here are two approaches that we've seen our users take:

• Component builders versus UI compositors - One way to have multiple artists working on the same screen is to have some artists busy in Photoshop and Maya (or your 2D and 3D content tools of choice), while another artist uses those assets to create the UI. In addition to this, various artists may be creating reusable Components in different Studio presentations, and saving these out to AMC files. An artist working on the UI screens can then load these Components (buttons, menus, sliders, etc.) and composite them into the final UI Composer presentation.
• Multiple Presentations - UI Composer can load multiple presentations at once and the Flow module makes managing them easy. This way, different sections of the UI can be loaded independently. Support for this on the back end means that different artists may work on different AMW presentations concurrently. This may be used for different logical sections of the UI (one artist on the options screen, one on the contacts screen, and so on) or even for different layers of the UI (e.g. one artist on the background presentation, one on screen content, one on HUD gadgets).

UI Composer has a polished, proven system for quickly putting together complex interactive projects. With the Slide palette, you can rapidly set up the various states of menus or buttons complete with animation and layout. With the Actions and Events palette, you can easily trigger various states based off button events or other event triggers. The entire system is easy to learn and capable of handling very large scale projects.

After several years of professional use on large training and industrial projects involving hundreds of interactive elements, our current customers have repeatedly told us that they prefer Studio's method to other multimedia tools that rely on a flowchart or hyper graph based authoring system. Studio produces clean, easily comprehensible presentations. Hyper graphs often produce a spaghetti nest of crossing links that are hard to decipher in practice.

If you have suggestions about what you would like to see in terms of visualization, NVIDIA would love to talk to you. We are always looking at making our interactivity authoring easier and more comprehensible, so your input in this area is welcome, and valued.

An artist working in Studio edits a presentation both visually and informationally.

• Examples of visual editing includes dragging objects on screen to effect their final placement, or setting the diffuse color of a model and seeing the effects in real time. The intent is a WYSIWYG environment.
• Examples of informational editing include adding Behaviors to an object and customizing the parameters, or adding custom properties such as "Drop Shadow Amount" to objects in the scene. Studio does not include a script engine, and cannot provide a preview of the UI as Behaviors may affect it. Further, custom properties (like "Drop Shadow Amount") may be added to any object and interpreted by your renderer in any way.

So, Studio provides a certain amount of live preview built-in. To see scripts and final rendering, you'll want to run the presentation with UI Composer integrated into your application.

The ideal answer is that if you want to see what your presentation will look like in your application, you should view it in your appliation. You can set up Studio so that pressing F12 (the shortcut key for File->Preview) will export your presentation using your own custom exporter and view it in the application of your choice. This allows artists to easily view the UI in the true final environment, iteratively designing and tweaking.

For those evaluating NVIDIA UI Composer, however, it would be unreasonable to require them to integrate UI Composer into their application before their artists can preview their work. NVIDIA UI Composer comes with a Viewer application that allows artist's to preview presentations.

In summary: view your presentation while you're editing it, and (as necessary) preview it in the playback application of choice. Initially, that playback application will be Viewer. When you have an integration with your own application, you will want to use that for true WYSIWYG results.