Remove "Main struct types" subsection from APItypes.rst, for quicker access (fewer clicks) to main struct reference.

PiperOrigin-RevId: 539525003
Change-Id: I01a3b7e4b054c3acda0a0070c227d50d7f43ea72
This commit is contained in:
Yuval Tassa
2023-06-11 19:59:27 -07:00
committed by Copybara-Service
parent 4a086edb43
commit 6434001747
2 changed files with 18 additions and 18 deletions
+10 -12
View File
@@ -20,7 +20,12 @@ MuJoCo defines a large number of types:
- :ref:`C struct types<tyStructure>`. These can be classified as:
- :ref:`Main struct types<tyMainStructure>`. These are :ref:`mjModel`, :ref:`mjOption` and :ref:`mjData`.
- Main structs:
- :ref:`mjModel`.
- :ref:`mjOption` (embedded in :ref:`mjModel`).
- :ref:`mjData`.
- :ref:`Auxillary struct types<tyAuxStructure>`, also used by the engine.
- Structs for collecting :ref:`simulation statistics<tyStatStructure>`.
- Structs for :ref:`abstract visualization<tyVisStructure>`.
@@ -581,21 +586,14 @@ Capabilities declared by an engine plugin.
Struct types
------------
.. _tyMainStructure:
Main
^^^^
The three central struct types for physics simulation are :ref:`mjModel`, :ref:`mjOption` (embedded in :ref:`mjModel`)
and :ref:`mjData`. An introductory discussion of these strucures can be found in the Overview under :ref:`Separation of
model and data<Features>`.
and :ref:`mjData`. An introductory discussion of these strucures can be found in the :ref:`Overview<ModelAndData>`.
.. _mjModel:
mjModel
~~~~~~~
^^^^^^^
This is the main data structure holding the MuJoCo model. It is treated as constant by the simulator. Some specific
details regarding datastructures in :ref:`mjModel` can be found below in :ref:`tyNotes`.
@@ -607,7 +605,7 @@ details regarding datastructures in :ref:`mjModel` can be found below in :ref:`t
.. _mjOption:
mjOption
~~~~~~~~
^^^^^^^^
This is the data structure with simulation options. It corresponds to the MJCF element
:ref:`option <option>`. One instance of it is embedded in mjModel.
@@ -618,7 +616,7 @@ This is the data structure with simulation options. It corresponds to the MJCF e
.. _mjData:
mjData
~~~~~~
^^^^^^
This is the main data structure holding the simulation state. It is the workspace where all functions read their
modifiable inputs and write their outputs.
+8 -6
View File
@@ -80,19 +80,21 @@ Model compilation
the built-in compiler into the low-level data structure :ref:`mjModel`, which is cross-indexed and optimized for
runtime computation. The compiled model can also be saved in a binary MJB file.
.. _ModelAndData:
Separation of model and data
MuJoCo separates simulation parameters into two data structures (C structs) at runtime:
- ``mjModel`` contains the model description and is expected to remain constant. There are other structures embedded
in it that contain simulation and visualization options, and those options need to be changed occasionally, but
this is done by the user.
- ``mjData`` contains all dynamic variables and intermediate results. It is used as a scratch pad where all
- :ref:`mjModel` contains the model description and is expected to remain constant. There are other structures
embedded in it that contain simulation and visualization options, and those options need to be changed
occasionally, but this is done by the user.
- :ref:`mjData` contains all dynamic variables and intermediate results. It is used as a scratch pad where all
functions read their inputs and write their outputs -- which then become the inputs to subsequent stages in the
simulation pipeline. It also contains a preallocated and internally managed stack, so that the runtime module
does not need to call memory allocation functions after the model is initialized.
``mjModel`` is constructed by the compiler. :ref:`mjData` is constructed at runtime, given
``mjModel``. This separation makes it easy to simulate multiple models as well as multiple states and controls for
:ref:`mjModel` is constructed by the compiler. :ref:`mjData` is constructed at runtime, given
:ref:`mjModel`. This separation makes it easy to simulate multiple models as well as multiple states and controls for
each model, in turn facilitating :ref:`multi-threading <siMultithread>` for sampling and :ref:`finite
differences <saDerivative>`. The top-level API functions reflect this basic separation, and have
the format: