Viewport Control and Input Event Nodes

In Kit-based configurators, the default behavior of the viewport (such as WASD navigation and prim selection) is typically disabled to create an undecorated viewport. This approach allows for precise control over user interactions within the viewport environment.

Review the Action Graphs developed for the Concept Car example in the following file: /03_ConceptCar_Example_080524/03_Configured/ConceptCar_Configurator.usd

Viewport Mode

Modifying viewport control begins with changing the interaction mode via the “Set Viewport Mode” node. This action disables default viewport interactions and requires development of custom interaction methods to replace the defaults. In the example file, the viewport nodes are found in the \Graphs\SystemStartup graph.

Default mode maintains standard Kit viewport functionality. Scripted mode disables all interactions, including camera movement, prim selection, and UI button functionality. In scripted mode, all desired behaviors must be explicitly defined through Action Graph.

The state management for both modes must be performed in the same graph. It cannot be set to “scripted” in one graph, and set to “default” in a different graph.

The checkboxes enable the various viewport event nodes.

enablePicking	Enables support for the viewport pick nodes, to track the clicking and selection of prims on the stage
enableViewportMouseEvents	Enables support for the viewport mouse event nodes, which react to mouse interactions in the viewport only (detailed below)
passClicksThru	This keeps the viewport mode active, but allows mouse clicks to pass down into the stage like in default mode. This would be used when you want to still support default behavior, but also keep scripted behaviors running in parallel. In practice, this is not a very common requirement.

Input Event Nodes

All Action Graphs start from an event node of some kind. An event node is the originator of the chain of graph computation, triggering a chain of nodes and their downstream connections. In the example file, event nodes are mostly found in the \Graphs\SystemStartup and \Cameras\Camera_BasicOrbit graphs. An event can originate from many sources:

• User input like pressing a keyboard key, or clicking on a mouse button.

• Called from an external source or from elsewhere in a graph.

• Something happening in the stage (like the prim hierarchy changing).

• A trigger from a tracked attribute changing in the stage (a variable changing).

You may wish to review some common event nodes used to control the viewport and react to user inputs.

On Viewport Dragged	One of the nodes enabled by a scripted viewport mode. This node simplifies the tracking of a click-drag mouse interaction on the viewport. This includes helpful outputs to track the distance and speed the user is dragging.
On Mouse Input	This event will trigger when the user clicks on the matching mouse buttons set on the node. This event also has multiple outputs, so you can respond to a click, release, or mouse movement. Note this also includes scroll wheel inputs (often used for camera zooms)
On Stage Event	An event that will trigger when certain stage conditions are met. Use this node to trigger when a stage is loaded, or playback is started.
On Tick	A unique event that fires a single execution pulse every tick. A tick basically corresponds to a frame. Use this event for when you want something to always be running. In the examples, you will often see tick events paired with some gating logic so a condition must be true before letting the tick pass through (such as a mouse button being held down). This helps reduce the overhead of the downstream computations being calculated unless absolutely needed; otherwise, these computations process every frame, all the time.

Refer to the Event Node Tutorials for a more in-depth exploration of event nodes.