Version 2.1.5: Fix GLAD loading on Linux, experimental multi-CCD.
PiperOrigin-RevId: 441482552 Change-Id: I16b7ba81cd81ca2293a9a12bfa08a40ab24c70bb
This commit is contained in:
+24
-21
@@ -111,7 +111,10 @@ mjtEnableBit
|
||||
mjENBL_FWDINV = 1<<2, // compare forward and inverse dynamics
|
||||
mjENBL_SENSORNOISE = 1<<3, // add noise to sensor data
|
||||
|
||||
mjNENABLE = 4 // number of enable flags
|
||||
// experimental features:
|
||||
mjENBL_MULTICCD = 1<<30, // multi-point convex collision detection
|
||||
|
||||
mjNENABLE = 5 // number of enable flags
|
||||
} mjtEnableBit;
|
||||
|
||||
| Defined in `mjmodel.h <https://github.com/deepmind/mujoco/blob/main/include/mjmodel.h>`_
|
||||
@@ -2898,13 +2901,13 @@ mjcb_control
|
||||
|
||||
extern mjfGeneric mjcb_control;
|
||||
|
||||
| This is the most commonly used callback. It implements a control law, by writing in the vector of controls
|
||||
``mjData.ctrl``. It can also write in ``mjData.qfrc_applied`` and ``mjData.xfrc_applied``. The values written in these
|
||||
vectors can depend on position, velocity and all other quantities derived from them, but cannot depend on contact
|
||||
forces and other quantities that are computed after the control is specified. If the callback accesses the latter
|
||||
fields, their values do not correspond to the current time step.
|
||||
This is the most commonly used callback. It implements a control law, by writing in the vector of controls
|
||||
``mjData.ctrl``. It can also write in ``mjData.qfrc_applied`` and ``mjData.xfrc_applied``. The values written in these
|
||||
vectors can depend on position, velocity and all other quantities derived from them, but cannot depend on contact forces
|
||||
and other quantities that are computed after the control is specified. If the callback accesses the latter fields, their
|
||||
values do not correspond to the current time step.
|
||||
|
||||
| The control callback is called from within :ref:`mj_forward` and :ref:`mj_step`, just before the controls and applied
|
||||
The control callback is called from within :ref:`mj_forward` and :ref:`mj_step`, just before the controls and applied
|
||||
forces are needed. When using the RK integrator, it will be called 4 times per step. The alternative way of specifying
|
||||
controls and applied forces is to set them before ``mj_step``, or use ``mj_step1`` and ``mj_step2``. The latter approach
|
||||
allows setting the controls after the position and velocity computations have been performed by ``mj_step1``, allowing
|
||||
@@ -3411,7 +3414,7 @@ Print internal XML schema as plain text or HTML, with style-padding or `` `
|
||||
Main simulation
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
| These are the main entry points to the simulator. Most users will only need to call ``mj_step``, which computes
|
||||
These are the main entry points to the simulator. Most users will only need to call ``mj_step``, which computes
|
||||
everything and advanced the simulation state by one time step. Controls and applied forces must either be set in advance
|
||||
(in mjData.ctrl, qfrc_applied and xfrc_applied), or a control callback mjcb_control must be installed which will be
|
||||
called just before the controls and applied forces are needed. Alternatively, one can use ``mj_step1`` and ``mj_step2``
|
||||
@@ -3419,21 +3422,21 @@ which break down the simulation pipeline into computations that are executed bef
|
||||
in this way one can set controls that depend on the results from ``mj_step1``. Keep in mind though that the RK4 solver
|
||||
does not work with mj_step1/2.
|
||||
|
||||
| mj_forward performs the same computations as ``mj_step`` but without the integration. It is useful after loading or
|
||||
resetting a model (to put the entire mjData in a valid state), and also for out-of-order computations that involve
|
||||
sampling or finite-difference approximations.
|
||||
mj_forward performs the same computations as ``mj_step`` but without the integration. It is useful after loading or
|
||||
resetting a model (to put the entire mjData in a valid state), and also for out-of-order computations that involve
|
||||
sampling or finite-difference approximations.
|
||||
|
||||
| mj_inverse runs the inverse dynamics, and writes its output in mjData.qfrc_inverse. Note that mjData.qacc must be set
|
||||
before calling this function. Given the state (qpos, qvel, act), mj_forward maps from force to acceleration, while
|
||||
mj_inverse maps from acceleration to force. Mathematically these functions are inverse of each other, but numerically
|
||||
this may not always be the case because the forward dynamics rely on a constraint optimization algorithm which is
|
||||
usually terminated early. The difference between the results of forward and inverse dynamics can be computed with the
|
||||
function :ref:`mj_compareFwdInv`, which can be though of as another solver accuracy check (as well as a general sanity
|
||||
check).
|
||||
mj_inverse runs the inverse dynamics, and writes its output in mjData.qfrc_inverse. Note that mjData.qacc must be set
|
||||
before calling this function. Given the state (qpos, qvel, act), mj_forward maps from force to acceleration, while
|
||||
mj_inverse maps from acceleration to force. Mathematically these functions are inverse of each other, but numerically
|
||||
this may not always be the case because the forward dynamics rely on a constraint optimization algorithm which is
|
||||
usually terminated early. The difference between the results of forward and inverse dynamics can be computed with the
|
||||
function :ref:`mj_compareFwdInv`, which can be though of as another solver accuracy check (as well as a general sanity
|
||||
check).
|
||||
|
||||
| The skip version of mj_forward and mj_inverse are useful for example when qpos was unchanged but qvel was changed
|
||||
(usually in the context of finite differencing). Then there is no point repeating the computations that only depend on
|
||||
qpos. Calling the dynamics with skipstage = mjSTAGE_POS will achieve these savings.
|
||||
The skip version of mj_forward and mj_inverse are useful for example when qpos was unchanged but qvel was changed
|
||||
(usually in the context of finite differencing). Then there is no point repeating the computations that only depend on
|
||||
qpos. Calling the dynamics with skipstage = mjSTAGE_POS will achieve these savings.
|
||||
|
||||
.. _mj_step:
|
||||
|
||||
|
||||
+10
-2
@@ -99,7 +99,7 @@ XML schema
|
||||
| | | +-------------------------+-------------------------+-------------------------+ |
|
||||
| | | | :at:`override` | :at:`energy` | :at:`fwdinv` | |
|
||||
| | | +-------------------------+-------------------------+-------------------------+ |
|
||||
| | | | :at:`sensornoise` | | | |
|
||||
| | | | :at:`sensornoise` | :at:`multiccd` | | |
|
||||
| | | +-------------------------+-------------------------+-------------------------+ |
|
||||
+--------------------------+----+------------------------------------------------------------------------------------+
|
||||
| |_|:el:`size` | \* | .. table:: |
|
||||
@@ -1791,11 +1791,19 @@ from its default.
|
||||
This flag enables the simulation of sensor noise. When disabled (which is the default) noise is not added to
|
||||
sensordata, even if the sensors specify non-zero noise amplitudes. When enabled, zero-mean Gaussian noise is added to
|
||||
the underlying deterministic sensor data. Its standard deviation is determined by the noise parameter of each sensor.
|
||||
:at:`multiccd`: :at-val:`[disable, enable], "disable"` **(experimental feature)**
|
||||
This flag enables multiple-contact collision detection for geom pairs that use the general-purpose convex-convex
|
||||
collider based on :ref:`libccd <coChecking>` e.g., mesh-mesh collisions. This can be useful when the contacting geoms
|
||||
have a flat surface, and the single contact point generated by the convex-convex collider cannot accurately capture
|
||||
the surface contact, leading to instabilities that typically manifest as sliding or wobbling. Multiple contact points
|
||||
are found by rotating the two geoms by ±1e-3 radians around the tangential axes and re-running the collision
|
||||
function. If a new contact is detected it is added, allowing for up to 4 additional contact points. This feature is
|
||||
currently considered experimental, and both the behavior and the way it is activated may change in the future.
|
||||
|
||||
.. _size:
|
||||
|
||||
**size** (*)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~
|
||||
|
||||
This element specifies size parameters that cannot be inferred from the number of elements in the model. Unlike the
|
||||
fields of mjOption which can be modified at runtime, sizes are structural parameters and should not be modified after
|
||||
|
||||
+30
-9
@@ -2,17 +2,38 @@
|
||||
Changelog
|
||||
=========
|
||||
|
||||
Version 2.1.4 (Apr. 4, 2022)
|
||||
Version 2.1.5 (Apr. 13, 2022)
|
||||
-----------------------------
|
||||
|
||||
General
|
||||
^^^^^^^
|
||||
|
||||
1. Added an experimental feature: multi-contact convex collision detection, activated by an enable flag. See full
|
||||
description :ref:`here <option-flag>`.
|
||||
|
||||
Bug fixes
|
||||
^^^^^^^^^
|
||||
|
||||
2. GLAD initialization logic on Linux now calls ``dlopen`` to load a GL platform dynamic library if a
|
||||
``*GetProcAddress`` function is not already present in the process' global symbol table. In particular, processes
|
||||
that use GLFW to set up a rendering context that are not explicitly linked against ``libGLX.so`` (this applies to the
|
||||
Python interpreter, for example) will now work correctly rather than fail with a ``gladLoadGL`` error when
|
||||
``mjr_makeContext`` is called.
|
||||
|
||||
#. In the Python bindings, named indexers for scalar fields (e.g. the ``ctrl`` field for actuators) now return a NumPy
|
||||
array of shape ``(1,)`` rather than ``()``. This allows values to be assigned to these fields more straightforwardly.
|
||||
|
||||
Version 2.1.4 (Apr. 4, 2022)
|
||||
----------------------------
|
||||
|
||||
General
|
||||
^^^^^^^
|
||||
|
||||
1. MuJoCo now uses GLAD to manage OpenGL API access instead of GLEW. On Linux, there is no longer a need to link against
|
||||
different GL wrangling libraries depending on whether GLX, EGL, or OSMesa is being used. Instead, users can simply
|
||||
use GLX, EGL, or OSMesa to create a GL context and ``mjr_makeContext`` will detect which one is being used.
|
||||
|
||||
#. Add visualisation for contact frames. This is useful when writing or modifying collision functions, when the actual
|
||||
#. Added visualisation for contact frames. This is useful when writing or modifying collision functions, when the actual
|
||||
direction of the x and y axes of a contact can be important.
|
||||
|
||||
Binary build
|
||||
@@ -26,13 +47,13 @@ Binary build
|
||||
Simulate
|
||||
^^^^^^^^
|
||||
|
||||
4. Fix a bug in simulate where pressing '[' or ']' when a model is not loaded causes a crash.
|
||||
4. Fixed a bug in simulate where pressing '[' or ']' when a model is not loaded causes a crash.
|
||||
|
||||
#. Contact frame visualisation is added to the Simulate GUI.
|
||||
#. Contact frame visualisation was added to the Simulate GUI.
|
||||
|
||||
#. Rename "set key", "reset to key" to "save key" and "load key", respectively.
|
||||
#. Renamed "set key", "reset to key" to "save key" and "load key", respectively.
|
||||
|
||||
#. Change bindings of F6 and F7 from the not very useful "vertical sync" and "busy wait" to the more useful cycling of
|
||||
#. Changed bindings of F6 and F7 from the not very useful "vertical sync" and "busy wait" to the more useful cycling of
|
||||
frames and labels.
|
||||
|
||||
Bug fixes
|
||||
@@ -40,7 +61,7 @@ Bug fixes
|
||||
|
||||
8. ``mj_resetData`` zeroes out the ``solver_nnz`` field.
|
||||
|
||||
#. Remove a special branch in ``mju_quat2mat`` for unit quaternions. Previously, ``mju_quat2mat`` skipped all
|
||||
#. Removed a special branch in ``mju_quat2mat`` for unit quaternions. Previously, ``mju_quat2mat`` skipped all
|
||||
computation if the real part of the quaternion equals 1.0. For very small angles (e.g. when finite differencing), the
|
||||
cosine can evaluate to exactly 1.0 at double precision while the sine is still nonzero.
|
||||
|
||||
@@ -57,13 +78,13 @@ General
|
||||
Python bindings
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
3. Add a ``free()`` method to ``MjrContext``.
|
||||
3. Added a ``free()`` method to ``MjrContext``.
|
||||
#. Enums now support arithmetic and bitwise operations with numbers.
|
||||
|
||||
Bug fixes
|
||||
^^^^^^^^^
|
||||
|
||||
5. Fix rendering bug for planes, introduced in 2.1.2. This broke maze environments in
|
||||
5. Fixed rendering bug for planes, introduced in 2.1.2. This broke maze environments in
|
||||
`dm_control <https://github.com/deepmind/dm_control>`_.
|
||||
|
||||
|
||||
|
||||
+26
-9
@@ -354,15 +354,15 @@ purpose of including an asset is to reference it, and referencing can only be do
|
||||
undefined.
|
||||
|
||||
Mesh
|
||||
MuJoCo can load triangulated meshes from binary STL files. Software such as `MeshLab <https://www.meshlab.net/>`__
|
||||
can be used to convert from other formats. While any collection of triangles can be loaded and visualized as a mesh,
|
||||
the collision detector works with the convex hull. There are compile-time options for scaling the mesh, as well as
|
||||
fitting a primitive geometric shape to it. The mesh can also be used to automatically infer inertial properties - by
|
||||
treating it as a union of triangular pyramids and combining their masses and inertias. Note that the STL format does
|
||||
not support color; some software packages write color information in unused fields but this is not consistent.
|
||||
Instead the mesh is colored using the material properties of the referencing geom. In contrast, all spatial
|
||||
properties are determined by the mesh data. MuJoCo supports a custom binary file format that can additionally specify
|
||||
normals and texture coordinates. Meshes can also be embedded directly in the XML.
|
||||
|
||||
MuJoCo can load triangulated meshes from OBJ files and binary STL. Software such as `MeshLab
|
||||
<https://www.meshlab.net/>`__ can be used to convert from other formats. While any collection of triangles can be
|
||||
loaded and visualized as a mesh, the collision detector works with the convex hull. There are compile-time options
|
||||
for scaling the mesh, as well as fitting a primitive geometric shape to it. The mesh can also be used to
|
||||
automatically infer inertial properties -- by treating it as a union of triangular pyramids and combining their
|
||||
masses and inertias. Note that meshes have no color, instead the mesh is colored using the material properties of the
|
||||
referencing geom. In contrast, all spatial properties are determined by the mesh data. MuJoCo supports both OBJ and a
|
||||
custom binary file format for normals and texture coordinates. Meshes can also be embedded directly in the XML.
|
||||
|
||||
Skin
|
||||
Skinned meshes (or skins) are meshes whose shape can deform at runtime. Their vertices are attached to rigid bodies
|
||||
@@ -593,6 +593,23 @@ section is to preemptively clarify the aspects that are most likely to be confus
|
||||
and a tutorial on selected topics. We will need to refer to material covered later in the documentation, but
|
||||
nevertheless the text below is as self-contained and introductory as possible.
|
||||
|
||||
.. _Divergence:
|
||||
|
||||
Divergence
|
||||
~~~~~~~~~~
|
||||
|
||||
Divergence of a simulation happens when elements of the state tend quickly to infinity. In MuJoCo this is usually
|
||||
manifested as an :ref:`mjWARN_BADQACC<mjtwarning>` warning. Divergence is endemic to all physics simulation and is not
|
||||
necessarily indicative of a bad model or bug in the simulator, but is rather a hint that the timestep is too large for
|
||||
the given choice of integrator. In physics simulation there is always a tension between speed (large time steps) and
|
||||
stabillity (small timesteps). A model which is well-tuned for speed has the largest possible timestep that does not
|
||||
diverge, which usually means that it *can* be made to diverge under extreme conditions. In that sense *rare* cases of
|
||||
divergence can actually be indicative of a well-tuned model. In all cases it should be possible to prevent divergence by
|
||||
reducing the timestep and/or switching to a more stable :ref:`integrator <geIntegration>`. If that fails, the culprit is
|
||||
different. For example in models where bodies are initialized in penetration, large repulsive forces could push them
|
||||
away and cause divergence.
|
||||
|
||||
|
||||
.. _Units:
|
||||
|
||||
Units are undefined
|
||||
|
||||
+2
-2
@@ -19,9 +19,9 @@ library:
|
||||
|
||||
Windows: mujoco.dll (stub library: mujoco.lib)
|
||||
|
||||
Linux: mujoco.so.2.1.4
|
||||
Linux: mujoco.so.2.1.5
|
||||
|
||||
macOS: mujoco.2.1.4.dylib
|
||||
macOS: mujoco.2.1.5.dylib
|
||||
|
||||
Even though MuJoCo is a single dynamic library with unified C API, it contains several modules, some of which are
|
||||
implemented in C++. We have taken advantage of the convenience of C++ for functionality that is used before the
|
||||
|
||||
+2
-2
@@ -29,14 +29,14 @@ _____
|
||||
|
||||
The MuJoCo app needs to be run at least once before the native library can be used, in order to register the library as
|
||||
a trusted binary. Then, copy the dynamic library file from
|
||||
``/Applications/MuJoCo.app/Contents/Frameworks/MuJoCo.framework/Versions/Current/libmujoco.2.1.4.dylib`` (it can be
|
||||
``/Applications/MuJoCo.app/Contents/Frameworks/MuJoCo.framework/Versions/Current/libmujoco.2.1.5.dylib`` (it can be
|
||||
found by browsing the contents of ``MuJoCo.app``) and rename it as ``mujoco.dylib``.
|
||||
|
||||
Linux
|
||||
_____
|
||||
|
||||
Expand the ``tar.gz`` archive to ``~/.mujoco``. Then copy the dynamic library from
|
||||
``~/.mujoco/mujoco-2.1.4/lib/libmujoco.so.2.1.4`` and rename it as ``libmujoco.so``.
|
||||
``~/.mujoco/mujoco-2.1.5/lib/libmujoco.so.2.1.5`` and rename it as ``libmujoco.so``.
|
||||
|
||||
Windows
|
||||
_______
|
||||
|
||||
+4
-1
@@ -69,7 +69,10 @@ typedef enum mjtEnableBit_ { // enable optional feature bitflags
|
||||
mjENBL_FWDINV = 1<<2, // record solver statistics
|
||||
mjENBL_SENSORNOISE = 1<<3, // add noise to sensor data
|
||||
|
||||
mjNENABLE = 4 // number of enable flags
|
||||
// experimental features:
|
||||
mjENBL_MULTICCD = 1<<30, // multi-point convex collision detection
|
||||
|
||||
mjNENABLE = 5 // number of enable flags
|
||||
} mjtEnableBit;
|
||||
|
||||
|
||||
|
||||
+1
-1
@@ -24,7 +24,7 @@ extern "C" {
|
||||
#endif
|
||||
|
||||
// header version; should match the library version as returned by mj_version()
|
||||
#define mjVERSION_HEADER 214
|
||||
#define mjVERSION_HEADER 215
|
||||
|
||||
// needed to define size_t, fabs and log10
|
||||
#include "stdlib.h"
|
||||
|
||||
+2
-1
@@ -51,7 +51,8 @@ ENUMS: Mapping[str, EnumDecl] = dict([
|
||||
('mjENBL_ENERGY', 2),
|
||||
('mjENBL_FWDINV', 4),
|
||||
('mjENBL_SENSORNOISE', 8),
|
||||
('mjNENABLE', 4),
|
||||
('mjENBL_MULTICCD', 1073741824),
|
||||
('mjNENABLE', 5),
|
||||
]),
|
||||
)),
|
||||
('mjtJoint',
|
||||
|
||||
@@ -42,7 +42,8 @@ class EnumsTest(absltest.TestCase):
|
||||
('mjENBL_ENERGY', 1<<1),
|
||||
('mjENBL_FWDINV', 1<<2),
|
||||
('mjENBL_SENSORNOISE', 1<<3),
|
||||
('mjNENABLE', 4)))
|
||||
('mjENBL_MULTICCD', 1<<30),
|
||||
('mjNENABLE', 5)))
|
||||
|
||||
# values mostly increment by one with occasional overrides
|
||||
def test_mjtGeom(self): # pylint: disable=invalid-name
|
||||
|
||||
@@ -55,7 +55,7 @@ include(FindOrFetch)
|
||||
|
||||
# ==================== MUJOCO LIBRARY ==========================================
|
||||
if(NOT TARGET mujoco)
|
||||
find_library(MUJOCO_LIBRARY mujoco mujoco.2.1.4 HINTS ${MUJOCO_LIBRARY_DIR} REQUIRED)
|
||||
find_library(MUJOCO_LIBRARY mujoco mujoco.2.1.5 HINTS ${MUJOCO_LIBRARY_DIR} REQUIRED)
|
||||
find_path(MUJOCO_INCLUDE mujoco.h HINTS ${MUJOCO_INCLUDE_DIR} REQUIRED)
|
||||
message("MuJoCo is at ${MUJOCO_LIBRARY}")
|
||||
message("MuJoCo headers are at ${MUJOCO_INCLUDE}")
|
||||
|
||||
@@ -660,7 +660,7 @@ Euler integrator, semi-implicit in velocity.
|
||||
self.assertEqual(mujoco.mjtEnableBit.mjENBL_ENERGY, 1<<1)
|
||||
self.assertEqual(mujoco.mjtEnableBit.mjENBL_FWDINV, 1<<2)
|
||||
self.assertEqual(mujoco.mjtEnableBit.mjENBL_SENSORNOISE, 1<<3)
|
||||
self.assertEqual(mujoco.mjtEnableBit.mjNENABLE, 4)
|
||||
self.assertEqual(mujoco.mjtEnableBit.mjNENABLE, 5)
|
||||
self.assertEqual(mujoco.mjtGeom.mjGEOM_PLANE, 0)
|
||||
self.assertEqual(mujoco.mjtGeom.mjGEOM_HFIELD, 1)
|
||||
self.assertEqual(mujoco.mjtGeom.mjGEOM_SPHERE, 2)
|
||||
@@ -672,11 +672,6 @@ Euler integrator, semi-implicit in velocity.
|
||||
def test_enum_from_int(self):
|
||||
self.assertEqual(mujoco.mjtJoint.mjJNT_FREE, mujoco.mjtJoint(0))
|
||||
self.assertEqual(mujoco.mjtGeom.mjGEOM_ARROW, mujoco.mjtGeom(value=100))
|
||||
# mjENABLE_FWDINV and mjNENABLE have the same int value. Default to the
|
||||
# first defined one.
|
||||
self.assertEqual(
|
||||
mujoco.mjtEnableBit.mjENBL_FWDINV,
|
||||
mujoco.mjtEnableBit(mujoco.mjtEnableBit.mjNENABLE.value))
|
||||
with self.assertRaises(ValueError):
|
||||
mujoco.mjtJoint(1000)
|
||||
with self.assertRaises(ValueError):
|
||||
|
||||
+1
-1
@@ -30,7 +30,7 @@ from setuptools import find_packages
|
||||
from setuptools import setup
|
||||
from setuptools.command import build_ext
|
||||
|
||||
__version__ = '2.1.4'
|
||||
__version__ = '2.1.5'
|
||||
|
||||
MUJOCO_CMAKE = 'MUJOCO_CMAKE'
|
||||
MUJOCO_CMAKE_ARGS = 'MUJOCO_CMAKE_ARGS'
|
||||
|
||||
+7
-7
@@ -5,12 +5,12 @@
|
||||
COMMON=-O2 -I../include -L../lib -std=c++11 -pthread -Wl,-no-as-needed -Wl,-rpath,'$$ORIGIN'/../lib
|
||||
|
||||
all:
|
||||
$(CXX) $(COMMON) testxml.cc -lmujoco -o ../bin/testxml
|
||||
$(CXX) $(COMMON) testspeed.cc -lmujoco -o ../bin/testspeed
|
||||
$(CXX) $(COMMON) compile.cc -lmujoco -o ../bin/compile
|
||||
$(CXX) $(COMMON) derivative.cc -lmujoco -fopenmp -o ../bin/derivative
|
||||
$(CXX) $(COMMON) basic.cc -lmujoco -lGL -lglfw -o ../bin/basic
|
||||
$(CXX) $(COMMON) record.cc -lmujoco -lGL -lglfw -o ../bin/record
|
||||
$(CXX) $(COMMON) testxml.cc -lmujoco -o ../bin/testxml
|
||||
$(CXX) $(COMMON) testspeed.cc -lmujoco -o ../bin/testspeed
|
||||
$(CXX) $(COMMON) compile.cc -lmujoco -o ../bin/compile
|
||||
$(CXX) $(COMMON) derivative.cc -lmujoco -fopenmp -o ../bin/derivative
|
||||
$(CXX) $(COMMON) basic.cc -lmujoco -lglfw -o ../bin/basic
|
||||
$(CXX) $(COMMON) record.cc -lmujoco -lglfw -o ../bin/record
|
||||
$(CC) -c -O2 -I../include uitools.c
|
||||
$(CXX) $(COMMON) uitools.o simulate.cc -lmujoco -lGL -lglfw -o ../bin/simulate
|
||||
$(CXX) $(COMMON) uitools.o simulate.cc -lmujoco -lglfw -o ../bin/simulate
|
||||
rm *.o
|
||||
|
||||
@@ -12,12 +12,12 @@ CFLAGS=-O2 -I$(MUJOCO_INCLUDEDIR) -I$(HOMEBREW)/include -pthread
|
||||
ALLFLAGS=$(CFLAGS) -L$(MUJOCO_LIBDIR) -L$(HOMEBREW)/lib -std=c++11 -stdlib=libc++ -Wl,-rpath,/Applications/MuJoCo.app/Contents/Frameworks
|
||||
|
||||
all:
|
||||
clang++ $(ALLFLAGS) testxml.cc -lmujoco.2.1.4 -o testxml
|
||||
clang++ $(ALLFLAGS) testspeed.cc -lmujoco.2.1.4 -o testspeed
|
||||
clang++ $(ALLFLAGS) compile.cc -lmujoco.2.1.4 -o compile
|
||||
clang++ $(ALLFLAGS) derivative.cc -lmujoco.2.1.4 -o derivative
|
||||
clang++ $(ALLFLAGS) basic.cc -lmujoco.2.1.4 -lglfw -o basic
|
||||
clang++ $(ALLFLAGS) record.cc -lmujoco.2.1.4 -lglfw -o record
|
||||
clang -c $(CFLAGS) uitools.c
|
||||
clang++ $(ALLFLAGS) uitools.o simulate.cc -lmujoco.2.1.4 -lglfw -o simulate
|
||||
clang++ $(ALLFLAGS) testxml.cc -lmujoco.2.1.5 -o testxml
|
||||
clang++ $(ALLFLAGS) testspeed.cc -lmujoco.2.1.5 -o testspeed
|
||||
clang++ $(ALLFLAGS) compile.cc -lmujoco.2.1.5 -o compile
|
||||
clang++ $(ALLFLAGS) derivative.cc -lmujoco.2.1.5 -o derivative
|
||||
clang++ $(ALLFLAGS) basic.cc -lmujoco.2.1.5 -lglfw -o basic
|
||||
clang++ $(ALLFLAGS) record.cc -lmujoco.2.1.5 -lglfw -o record
|
||||
clang -c $(CFLAGS) uitools.c
|
||||
clang++ $(ALLFLAGS) uitools.o simulate.cc -lmujoco.2.1.5 -lglfw -o simulate
|
||||
rm *.o
|
||||
|
||||
@@ -3,17 +3,17 @@
|
||||
# from https://github.com/glfw/glfw/releases, and copy files as follows:
|
||||
# - Copy the entire `include/GLFW` subdirectory to `mujoco/include/GLFW`.
|
||||
# - Copy glfw3dll.lib from the subdirectory corresponding into your compiler
|
||||
# choice to `mujoco/lib/glfw3.lib`.
|
||||
# choice to `mujoco/lib/glfw3dll.lib`.
|
||||
# - Copy glfw3.dll from the same subdirectory into `mujoco/bin/glfw3.dll`.
|
||||
|
||||
COMMON=/O2 /MT /EHsc /arch:AVX /I../include /Fe../bin/
|
||||
|
||||
all:
|
||||
cl $(COMMON) testxml.cc ../lib/mujoco.lib
|
||||
cl $(COMMON) testspeed.cc ../lib/mujoco.lib
|
||||
cl $(COMMON) compile.cc ../lib/mujoco.lib
|
||||
cl $(COMMON) derivative.cc /openmp ../lib/mujoco.lib
|
||||
cl $(COMMON) basic.cc ../lib/glfw3.lib ../lib/mujoco.lib
|
||||
cl $(COMMON) record.cc ../lib/glfw3.lib ../lib/mujoco.lib
|
||||
cl $(COMMON) simulate.cc uitools.c ../lib/glfw3.lib ../lib/mujoco.lib
|
||||
cl $(COMMON) testxml.cc ../lib/mujoco.lib
|
||||
cl $(COMMON) testspeed.cc ../lib/mujoco.lib
|
||||
cl $(COMMON) compile.cc ../lib/mujoco.lib
|
||||
cl $(COMMON) derivative.cc /openmp ../lib/mujoco.lib
|
||||
cl $(COMMON) basic.cc ../lib/glfw3dll.lib ../lib/mujoco.lib
|
||||
cl $(COMMON) record.cc ../lib/glfw3dll.lib ../lib/mujoco.lib
|
||||
cl $(COMMON) simulate.cc uitools.c ../lib/glfw3dll.lib ../lib/mujoco.lib
|
||||
del *.obj
|
||||
|
||||
@@ -35,7 +35,7 @@ public class MujocoBinaryRetriever {
|
||||
if (AssetDatabase.LoadMainAssetAtPath(mujocoPath + "/mujoco.dylib") == null) {
|
||||
File.Copy(
|
||||
"/Applications/MuJoCo.app/Contents/Frameworks" +
|
||||
"/MuJoCo.framework/Versions/Current/libmujoco.2.1.4.dylib",
|
||||
"/MuJoCo.framework/Versions/Current/libmujoco.2.1.5.dylib",
|
||||
mujocoPath + "/mujoco.dylib");
|
||||
AssetDatabase.Refresh();
|
||||
}
|
||||
@@ -43,7 +43,7 @@ public class MujocoBinaryRetriever {
|
||||
if (AssetDatabase.LoadMainAssetAtPath(mujocoPath + "/libmujoco.so") == null) {
|
||||
File.Copy(
|
||||
Environment.GetFolderPath(Environment.SpecialFolder.UserProfile) +
|
||||
"/.mujoco/mujoco-2.1.4/lib/libmujoco.so.2.1.4",
|
||||
"/.mujoco/mujoco-2.1.5/lib/libmujoco.so.2.1.5",
|
||||
mujocoPath + "/libmujoco.so");
|
||||
AssetDatabase.Refresh();
|
||||
}
|
||||
|
||||
@@ -83,7 +83,7 @@ public const int mjMAXOVERLAY = 500;
|
||||
public const int mjMAXLINE = 100;
|
||||
public const int mjMAXLINEPNT = 1000;
|
||||
public const int mjMAXPLANEGRID = 200;
|
||||
public const int mjVERSION_HEADER = 214;
|
||||
public const int mjVERSION_HEADER = 215;
|
||||
|
||||
|
||||
// ------------------------------------Enums------------------------------------
|
||||
|
||||
Reference in New Issue
Block a user