Add new KinBody::ExtraGeometryInfo struture for KinBody::Link::_mapExtraGeometries

[zax147]

Add support for serialization and deserialization of the extraGeometries field.

The extraGeometries in OpenRAVE is saved as std::map< std::string, std::vector<GeometryInfoPtr> > while the schema supposes to be:

         "extraGeometries": [
              {
                  "id": "extraGeometry_id",
                  "name": "extraGeometry_name",
                  "geometries": [
                      {
                          "id": "geom_id",
                          "name": "geom_name",
                      }
                  ]
              }
          ]

[cielavenir]

just to comment, he is zirui.xie@mujin

[woswos]

I think you missed handling the id field here and in deserialization

[snozawa]

thanks for offline conversation, I think you can put id instead of name here.
the key of the std::map is now represented by id.

[snozawa]

talked in person.
It looks we still need both id and name.

The user of id can handle limited characters.

Meanwhile, we want to use the more characters for the key of the mapExtraGeometries.
In the upcoming safety-related geometry handling (c.f. #1402), we want to define the key based on the KinBody::GetName, ...etc. Thus, the supported characters should be the same level as KinBody::GetName and others.
Therefore, we also need name field.

That means, we need to introduce the new data structure for mapExtraGeometries...

[justism]

can you update the param comments

[justism]

you can just reuse ExtraGeometryInfo::SerializeJSON

[justism]

please use camel case

[rdiankov]

The problem with serializing extra geometry infos is that "self" geometry group gets serialization, which is just a copy of the regular geometry. Furthermore, a lot of other geometries are auto-generated (like padding), so there's really no reason to serialize them as part of the JSON, which then gets into the saved files, and significantly increases the save/load times of the files along with increasing the size on disk.

Perhaps you can begin with talking about the problem you are trying to solve here, and we can think about the right solution.

[zax147]

The problem with serializing extra geometry infos is that "self" geometry group gets serialization, which is just a copy of the regular geometry. Furthermore, a lot of other geometries are auto-generated (like padding), so there's really no reason to serialize them as part of the JSON, which then gets into the saved files, and significantly increases the save/load times of the files along with increasing the size on disk.

Perhaps you can begin with talking about the problem you are trying to solve here, and we can think about the right solution.

The problem we're solving is that in the latest MCD, we would like to use the extraGeometries (or geometry groups) field in Webstack, for example, to store extraGeometries in webstack and to selectively show extraGeometries on the UI.

We've added the extraGeometries field and its related function in webstack, and now trying to match with the changes in Webstack.

[rdiankov]

Why does webstack need to handle extra geometries at the moment?