OmniGraph Naming Conventions

The mandatory naming conventions are noted where applicable. The rest of these conventions have been set up to make it as easy as possible for you to write your own nodes, and to be able to read the nodes that others have written.

File And Class Names

Class and file naming is InterCaps with the prefix Ogn. For example, OgnMyNode.ogn, OgnYourNode.py, class OgnMyNode, and OgnHerNode.cpp.

As with regular writing, active phrasing (verb-noun) is preferred over passive phrasing when a node name refers to its function.

Weak	Preferred
OgnSumOfTwoValues	OgnAddTwoValues
OgnAttributeRemoval	OgnRemoveAttribute
OgnTextGenerator	OgnGenerateText

Tip

Some of the automated processes use the Ogn prefix to more quickly recognize node files. Using it helps them work at peak efficiency.

Node Names

Although the only real restriction on node names is that they consist of alphanumeric, underscore, or dot characters there are some conventions established to make it easier to work with nodes, both familiar and unfamiliar.

A node will generally have two names - a unique name to identify it to OmniGraph, and a user-friendly name for viewing in the UI. The name of the node should be generally related to the name of the class, to make them easy to find.

The name will be made unique within the larger space by prepending the extension as a namespace. The name specified in the file only need be unique within its extension, and by convention is in uppercase CamelCase, also known as PascalCase. It’s a good idea to keep your name related to the class name so that you can correlate the two easily.

Warning

You can override the prepending of the extension name if you want your node name to be something different, but if you do, you must be prepared to ensure its uniqueness. To override the name simply put it in a namespace by including a . character, e.g. omni.deformer.Visualizer. Note that the omni. prefix is reserved for NVIDIA developed extensions.

The user-friendly name can be anything, even an entire phrase, in Title Case. Although any name is acceptable always keep in mind that your node name will appear in the user interface and its function should be immediately identifiable from its name. If you do not specify a user-friendly name then the unique name will be used in the user interface instead.

Here are a few examples from the OmniGraph extensions:

Class Name	Name in the .ogn file	Unique Extended Name	User Facing Node Name
OgnTutorialTupleData	TupleData	omni.graph.tutorials.TupleData	Tutorial Node: Tuple Attributes
OgnVersionedDeformer	VersionedDeformer	omni.graph.examples.cpp.VersionedDeformer	Example Node: Versioned Deformer
OgnAdd	Add	omni.graph.nodes.Add	Add

Attention

The unique node name is restricted to the alphanumeric characters, underscore (_), and dot (.). Any other characters in the node name will cause the code generation to fail with an error message.

Attribute Names

As you will learn, every node has a set of attributes which describe the data it requires to perform its operations. The attributes also have naming conventions. The mandatory part is that attributes may only contain alphanumeric characters, underscore, and optional colon-separated namespacing.

The preferred naming for attributes is camelCase and, as with nodes, both a unique name and a user-friendly name may be specified where the user-friendly name has no real restrictions.

Attributes have some predefined namespaces depending on their location with the node as well (inputs:, outputs:, and state:) so you can use this to have inputs and outputs with the same name since they will be in different namespaces. Here is an example of attribute names on a node that adds two values together:

Full Name	User Facing Name
inputs:a	First Addend
inputs:b	Second Addend
outputs:sum	Sum Of Inputs

Attention

The unique attribute name is restricted to the alphanumeric characters, underscore (_), and colon (:). Any other characters in the attribute name will cause the code generation to fail with an error message.

Tip

You will find that use of your node will be easier if you minimize the use of attribute namespaces. It has some implications in generated code due to the special meaning of the colon in C++ and Python.

Directory Structure

It is advantageous to consider nodes as a separate type of thing and structure your directories to make them easier to find. While it’s not required in order to make the build work, it’s recommended in order to keep the location of files consistent.

The standard Kit extension layout has these directories by default:

omni.my.feature/
    bindings/
        Files related to Python bindings of your C++
    config/
        extension.toml configuration file
    docs/
        index.rst explaining your extension
    plugins/
        C++ code used by your extension
    python/
        __init__.py
        extension.py = Imports of your bindings and commands, and a omni.ext.IExt object for startup/shutdown
        scripts/
            Python code used by your extension

The contents of your __init__.py file should expose the parts of your Python code that you wish to make public, including some boilerplate to register your extension and its nodes. For example, if you have two scripts for general use in a utility.py file then your __init__.py file might look like this:

"""Public interface for my.extension"""
import .extension
import .ogn

from .scripts.utility import my_first_useful_script
from .scripts.utility import my_second_useful_script

The C++ node files (OgnSomeNode.ogn and OgnSomeNode.cpp) will live in a top level nodes/ directory and the Python ones (OgnSomePythonNode.ogn and OgnSomePythonNode.py) go into a python/nodes/ subdirectory:

omni.my.feature/
    bindings/
    config/
    docs/
    nodes/
        OgnSomeNode.ogn
        OgnSomeNode.cpp
    plugins/
    python/
        nodes/
            OgnSomePythonNode.ogn
            OgnSomePythonNode.py

If your extension has a large number of nodes you might also consider adding extra subdirectories to keep them together:

omni.my.feature/
    ...
    nodes/
        math/
            OgnMathSomeNode.ogn
            OgnMathSomeNode.cpp
        physics/
            OgnPhysicsSomeNode.ogn
            OgnPhysicsSomeNode.cpp
        utility/
            OgnUtilitySomeNode.ogn
            OgnUtilitySomeNode.cpp
    ...

Tip

Although any directory structure can be used, using this particular structure lets you take advantage of the predefined build project settings for OmniGraph nodes, and makes it easier to find files in both familiar and unfamiliar extensions.