Interactions (like moving the camera or mouse picking) no longer depend
on needing an mjvScene. Instead, everything is done relative to the
camera directly.
This duplicates some code in engine_vis_visualize which we will try to
resolve and recombine at a future time.
PiperOrigin-RevId: 828461259
Change-Id: If26329c1a7c37516f0213b18056c3e31760f60ae
This enables two workflows:
1) Users that parsed some other format into MjSpec, or built it programmatically can export animated USD easily with as minimal as possible interaction with USD.
2) Creating a spec from USD, then modifying the spec, should not cause a duplication of data when writing to USD.
PiperOrigin-RevId: 827627520
Change-Id: I02c8c14a18569547710e54f3704d52ac0bf70ce6
- When `mjData.nefc` was 0 (solver not run at all), we were plotting the stale diagnostics from the last run; now fixed.
- In the case where islands were used, the semantic of the plotted diagnostic `sqrt_nnz` (square root of Hessian nonzeros) is changed. It used to be the sum of square roots of solver nonzeros per island, it is now the square root of the sum of all nonzeros in all islands. The semantic `sqrt(sum(nnz_i))` was found to be more consistent than `sum(sqrt(nnz_i))`, in the sense that switching islanding on/off leads to smaller changes and is more in line with the interpretation of islanding as [block-diagonalization](https://mujoco.readthedocs.io/en/3.3.7/computation/#constraint-islands).
PiperOrigin-RevId: 827624908
Change-Id: I5fc86364ead585a4752a6d44823fb75cf6c7c318
Since we don't do any on demand data loading for USD and always convert everything it should be safe to use the SdfLayer API instead of the SdfAbstractData API. This enables other codepaths such as the USD writer class to reuse the same logic to generate USD specification from an mjSpec.
PiperOrigin-RevId: 827431722
Change-Id: I60a581e0c9577164a4a66229ea9dcb8912afcf74
This includes the filament, toolbox, and studio projects.
Adds a MUJOCO_BUILD_STUDIO option to enable building of the `studio` app (disabled by default).
Adds a MUJOCO_USE_FILAMENT to allow the studio app to use the filament rendering backend. A separate MUJOCO_USE_FILAMENT_VULKAN flag can be used to enable vulkan rendering.
PiperOrigin-RevId: 824602367
Change-Id: I26d46c16211ae2118f96c163c4194fea5b5a15a9
This is intended as a drop-in replacement for mjr_render to enable high
quality, physically-based rendering (PBR) using the filament render engine.
This is a work-in-progress and, as such, some features may be missing. This
is also a code-only drop; build files (including instructions on how to
generate the filament materials) will be provided at a later date.
This library is intended to be run with the experimental studio app.
PiperOrigin-RevId: 817593684
Change-Id: Ib9cd14c1881e4897c1111275bd749aa38ebb5317
Previously this was just used for the USDA file format token, which we can confidently just construct ourselves.
Since [this PR in OpenUSD](https://github.com/PixarAnimationStudios/OpenUSD/commit/5bb9ad1fb2a034e1f9b48c7db936f296b5b78e25) the file lives in a different place now and public usage will be deprecated anyways.
PiperOrigin-RevId: 816801204
Change-Id: I42e92d2af52b0f9ff0a679ecb96f3d2dbf623531
*** Reason for rollback ***
mjv_makeScene does not call mjv_defaultScene directly. Instead, it calls mjv_freeScene which calls mjv_defaultScene. However, mjv_freeScene attempts to free pointers if they are not NULL and if you don't call mjv_defaultScene then you'll have garbage data in those pointers.
*** Original change description ***
Remove redundant mjv_defaultScene call since its called by mjv_makeScene
***
PiperOrigin-RevId: 810442645
Change-Id: Ica50493d6769a0afb086f9ead99d731cdf0d75d9
Also:
- update the namespace to `toolbox` (instead of `filament`)
- Add copyright notices to all files
PiperOrigin-RevId: 808474353
Change-Id: Id1fe86c5d183c8e91bec8509b6c0830b5fe84c1c
Haroon Qureshi