Starting this thread to discuss how we should manage assets (e.g., non-source code resources that need to be distributed with the simulator). In particular, I would like to discuss where to store the OBJ models for robots.
Initially, I was going to place OBJs under plugins/simulator/visualizations/qt-opengl/models and handle them in the same way as we do with the icons and the textures. However this doesn't play well with robot plugins (especially external ones). It seems that it would be more logical to keep the robot OBJ model as part of the robot plugin (e.g., plugins/robots/spiri/simulator/spiri.obj, etc.).
If we go with storing the OBJs inside the robot plugins, then we need to decide how to install them (and ideally, do so in a way that ARGoS can still find the models when it is run directly from the source tree). I can think of two solutions:
Create some utility classes for handling resources and assets in a generic way
Embed the OBJs directly inside the shared objects using the linker
The second method may be the quicker solution, but I think the first method will be better in the long term (consider for example a potential webgl-based visualization plugin that needs to install static assets for its front end)
@ilpincy The Lua scripts in the testing directory are another example of assets for which we have no standard way of installing and hence accessing via the XML.
Starting this thread to discuss how we should manage assets (e.g., non-source code resources that need to be distributed with the simulator). In particular, I would like to discuss where to store the OBJ models for robots.
Initially, I was going to place OBJs under plugins/simulator/visualizations/qt-opengl/models and handle them in the same way as we do with the icons and the textures. However this doesn't play well with robot plugins (especially external ones). It seems that it would be more logical to keep the robot OBJ model as part of the robot plugin (e.g., plugins/robots/spiri/simulator/spiri.obj, etc.).
If we go with storing the OBJs inside the robot plugins, then we need to decide how to install them (and ideally, do so in a way that ARGoS can still find the models when it is run directly from the source tree). I can think of two solutions:
The second method may be the quicker solution, but I think the first method will be better in the long term (consider for example a potential webgl-based visualization plugin that needs to install static assets for its front end)