ipab-slmc / exotica

Extensible Optimization Framework
https://ipab-slmc.github.io/exotica
BSD 3-Clause "New" or "Revised" License
149 stars 70 forks source link

Redundant visuals in KinematicElement #662

Open christian-rauch opened 5 years ago

christian-rauch commented 5 years ago

The KinematicElement stores visuals in two ways.

It (1) stores a path to the resource and a shape pointer directly as members: https://github.com/ipab-slmc/exotica/blob/9e1da605f2b191a17410b2f19be19b5e256c7abc/exotica_core/include/exotica_core/kinematic_element.h#L124-L125 but is (2) also stores an array of VisualElement: https://github.com/ipab-slmc/exotica/blob/9e1da605f2b191a17410b2f19be19b5e256c7abc/exotica_core/include/exotica_core/kinematic_element.h#L129

This appears to be redundant and confusing because it is not documented, if they are used in different ways. Can the members (shape and shape_resource_path) be removed?

In my scenario, the members are empty and the VisualElement actually contains the mesh reference.

wxmerkt commented 5 years ago

These are from different times and serve different purpose:

I agree documentation and some clean-up once the new visualisers are ready is in order.

christian-rauch commented 5 years ago

I see that shape_resource_path is used for the visualization_msgs/Marker. Is the shape then only set, when a collision scene if created?

wxmerkt commented 5 years ago

From what I recall, yes. The shape is technically the collision shape.