Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add documentation on best practices for 3D designs #308

Open
j-rivero opened this issue Sep 21, 2022 · 6 comments
Open

Add documentation on best practices for 3D designs #308

j-rivero opened this issue Sep 21, 2022 · 6 comments
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@j-rivero
Copy link
Contributor

Mostly a compilation of useful configurations or procedures to help the 3D model integration in simulation code such as SDF/URDF.

@ColeOSRF has an script that could provide some hints about the topic.

@j-rivero j-rivero added documentation Improvements or additions to documentation enhancement New feature or request labels Sep 21, 2022
@j-rivero
Copy link
Contributor Author

I was drafting the skeleton and first ideas:

# Best practices for 3D designers to facilitate the integration of designs

Collection of best practices for 3D designers in order to help the integration
of the models in the simulation code.

## Use just the file name textures (no subdirectories or absolute paths)

When using textures it is best to export the textures files (png/jpeg) using
just the name. This way they can be organized in the simulation code using any
particular subdirectory.

### For Collada (DAE) files

#### How to check for the error

DAE files should not have something like:
\```xml
    <image id="foo_texture_png" name="Foo_Texture_png">
      <init_from>../Textures/Foo_Texture_png</init_from>
\```
instead the right configuration should look like:
\```xml
    <image id="foo_texture_png" name="Foo_Texture_png">
      <init_from>Foo_Texture_png</init_from>
\```
##### How to do it in Blender
(TODO)
...

@j-rivero
Copy link
Contributor Author

j-rivero commented Sep 21, 2022

More ideas to include in the best practices:

  • Provide coordinates for the different model parts: if the coordinates need to be absolute or relative to other parts of the model.
  • Follow https://www.ros.org/reps/rep-0105.html for coordinate frames when designing (at least?) a vehicle

@ColeOSRF
Copy link

Do we actually need to use the .dae file for textures? These should be defined in the SDF correct? Would there be any downsides to changing the behavior of Gazebo so that it just ignores the texture maps in the .dae files?

@j-rivero
Copy link
Contributor Author

Do we actually need to use the .dae file for textures? These should be defined in the SDF correct?

Several of our most common tools only support DAE for textures, Gazebo Classic and RVIZ, as far as I can tell.

Would there be any downsides to changing the behavior of Gazebo so that it just ignores the texture maps in the .dae files?

I have no idea about the implications of ignoring the "textures" maps. @iche033 can probably help.

@iche033
Copy link
Contributor

iche033 commented Sep 23, 2022

These should be defined in the SDF correct? Would there be any downsides to changing the behavior of Gazebo so that it just ignores the texture maps in the .dae files?

If the texture file is specified in SDF, it overrides the one specified in the dae file - this was something new added in the new Gazebo but not available in Gazebo-classic. So that's why we see a lot of the models out in the community relying on textures being specified in the dae file. It would be nice to continue supporting both approaches to help Gazebo-classic users transition to the new Gazebo.

@j-rivero
Copy link
Contributor Author

j-rivero commented Oct 4, 2022

More ideas:

  1. The model files should reflect models aligned with the 0.0.0 coordinates so URDF/SDF code can position them without dealing with offsets in object files. For example, a diff on a DAE file not positioned at 0.0.0 in original Blender vs the same object scaled 0.6 but positioned in the 0.0.0:
@@ -96,12 +96,12 @@
   <library_visual_scenes>
     <visual_scene id="Scene" name="Scene">
       <node id="WheelRight" name="WheelRight" type="NODE">
-        <matrix sid="transform">1 0 0 0.587966 0 1 0 1.84429 0 0 1 0.499755 0 0 0 1</matrix>
+        <matrix sid="transform">0.6 0 0 0 0 0.6 0 0 0 0 0.6 0 0 0 0 1</matrix>
         <instance_geometry url="#Cylinder_001-mesh" name="WheelRight">
           <bind_material>
             <technique_common>
               <instance_material symbol="WheelRight-material" target="#WheelRight-material">

Collada is probably using a Transform Matrix to represent the object, probably parsed by pycollada MatrixTransform.

  1. Meshlab (according to the documentation for inertias in Gazebo) can detect problems or raise warnings on some models. It would be great to automate meshlab checks to run them inside a CI code.
  2. Checking in CI files SDF/URDF files with the current QA/linters that are available from them: gz/ign sdf and check_urdf. DAE files can be checked with pycollada.
  3. A more crazy idea would be to use CI to auto-generate the images in gz-sim/gazebo-classic that shows: collisions views, center of masses and/or other physical images.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
Status: To do
Development

No branches or pull requests

3 participants