[Unity plugin] Dynamic heightfield syncing #1268
Conversation
…mujoco into feature/unity-hmap-dyn Merge in format from GitHub
|
Thanks for spotting that, I believe that should be all the whitespace issues sorted. |
| if(terrain.transform.parent != transform) Debug.LogWarning($"The terrain of heightfield {transform.name} needs to be parented to the Geom for proper rendering."); | ||
| else { | ||
| if((terrain.transform.localPosition - new Vector3(-HeightMapLength * HeightMapScale.x / 2, terrain.transform.localPosition.y, -HeightMapWidth * HeightMapScale.z / 2)).magnitude > 0.001) { | ||
| Debug.LogWarning($"Terrain of heightfield {transform.name} not aligned with geom. The terrain will be moved to accurately represent the simulated position."); |
There was a problem hiding this comment.
This seems like weird indentation. Should be just 2 spaces.
Can you try to follow the rules in https://google.github.io/styleguide/csharp-style.html#whitespace-rules?
There are also some really long lines here that should be broken up.
Balint-H
force-pushed
the
feature/unity-hmap-dyn
branch
from
6cf9b5d to
d0b505c
Compare
|
Thanks for the patience, I made an effort now to familiarise myself with formatting tools, and will try to be more consistent from now on. |
|
Writing to hfield_data is supposed to work fine. We should try to understand this. Can you try and make a MWE (in a new issue) which recreates the crash? (Ideally via Python or C, not Unity) Thanks! |
|
Thanks for encouraging a further examination Yuval. I tried to recreate a MWE in python and everything worked as I expected with dynamic hfields. I went back to Unity and tried with the latest version of the plugin and binary (3.1.1) and dynamic heightfields now work as intended! My original try was with 3.0.1, so the issue was possibly related to that. Running the same scripts when I reverted back to 3.0.1 gave the same crashes. In any case, the |
… feature/unity-hmap-dyn Merge with main to keep branch up to date
|
With a quick profiling only in editor, writing to hfield_data is approximately 5-10 times faster then recompiling the scene. Now this method will be used if no export path for the hfield png is given for the component (the default), but I haven't removed the scene rebuilding and image exporting approach completely as I see them being useful in case someone is building a hfield scene in Unity and exports it for use with other MuJoCo sim options. Exporting scenes with the editor window tool works, and multi hfield scenes work too. |
In this PR the HField component optionally requests a rebuild of the scene during runtime if the Unity terrain changes (with optional rate limit), to allow dynamic deformable environments, (e.g. when resetting an episode of locomotion learning, or to simulate destructible terrain).
I had a go at trying to use
model->hfield_databy simply writing changed heightmap pixel values to it (as floats), making sure its at the right address and right number of elements and that scene is properly initialized already. I expected that to be a cleaner and more performant approach, however this was met with crashes. Are there any limitations of writing tohfield_dataI'm not aware of that might prevent its use with plugin this way?This PR also provides edits to the HField geom's components to be a bit more robust to different terrains (taking into account assumptions of a MuJoCo hfield), and provides warnings and tooltips for configuring a terrain so that it matches with the hfield on the MuJoCo side.
Movie_007.mp4