.. include:: substitutions.rst

omni.graph.core: OmniGraph
###########################

**Extension Version**: |omni.graph.core.version|  **Documentation Generated**: |today|

What is it, and why are we doing it?
************************************

Omniverse will be made up of many extensions - from animations, to physics, to inferencing algorithms with DNNs, to name
just a few.  In order for all these systems to interact with each other, we need a graph framework to "glue" it all
together - not only those prebuilt components, but also provide a compute framework where clients can integrate their
own functionality as well.  The framework is to be flexible enough to address all of the above range of use cases,
and more, as well as handling a large range of granularity of compute - from sub-millisecond warp level to hours long
training of neural networks as some examples.


OmniGraph Overview
******************

Current Capabilities
====================

Currently OmniGraph is being used to define deformer pipelines, in particle and fluid simulations, as part of Drivesim for some of its nodes, and to trigger runtime logic based on the receipt of events, though it will grow into more use cases in the future.

At present OmniGraph is already capable of a variety of things, although it still is very much a work in progress.  We are able to:

- Write nodes in C++, Python, and Cuda
- Writes scripts in Python using commands and the OmniGraph API that is bound to Python
- Employ a code synthesizing framework (OGN) to substantially simplify the development process by generating boilerplate and hiding it away from the developer
- Provide an efficient, and flexible data model.  Efficient, because the data model is built on top of Fabric, which in short takes USD data and puts into a vectorized, compute friendly form, with the data available on both CPU and GPU.  The data model is flexible, because we employ constructs like bundles, which allows an arbitrary amount of data to be passed from node to node, without having to be pre-declared.  We also employ constructs like extended and dynamic attributes.  Extended attributes allows data of any type to be connected to an attribute, and it resolves at runtime to the correct type.  This allows nodes to be created without accounting for an combinatorial explosion of possible types.  Dynamic attributes allow new attributes to be tacked onto the node instance at runtime.
- Last, but certainly not least, OmniGraph is not a single type of graph.  One can create any type of graph, with any semantics with OmniGraph.  We do this by clearly separating graph description from graph evaluation.  Three graphs are already supported: busy evaluation graph (push), Lazy evaluation graph (dirty_push), and event handling graph (action), with more to come.


Ready To Start?
***************

.. toctree::
   :maxdepth: 1
   :caption: Let's Go Through Some Tutorials
   :glob:

   Getting Started Tutorials<https://docs.omniverse.nvidia.com/prod_extensions/prod_extensions/ext_omnigraph.html>
   Node Writing Guides<nodes>
   Bird's eye view of the OmniGraph Architecture<architecture>
   Core Concepts<core_concepts>
   File, Class, Node, and Attribute Naming Conventions<naming_conventions>
   Python Documentation<../../omni.graph/docs/index.rst>
   How-To Guides<how_to>

Administrative Details
**********************

.. toctree::
   :maxdepth: 1
   :caption: Administrivia
   :glob:

   CHANGELOG
   Roadmap<roadmap>