I’ve been struggling to figure out why some objects in my gazebo simulation were missing from what I exported from Blender, and I’ve finally figured out - though I don’t have a solution to fix it yet. Below is one of the export options for DAE in Blender 2.91:
If using this “Use Object Instances” option when exporting the DAE, Gazebo will only load one instance of every object in it. For example, if I have a robot with 10 identical screws in it, only one of those screws will display in the Gazebo simulation. Now my first thought was that it was a Blender problem, but I can load the DAE no problem in other tools like this online 3D viewer.
If deselecting this option in Blender, or even going as far to just merge all the individual objects into one, then Gazebo can load it but… the file size goes up dramatically. Object instances is obviously a very effective way of reducing file size, especially if your robot has a lot of re-usable parts - imagine the file reduction you would get from something like a LEGO robot for example, it would be so wasteful to include copies of every one of those reusable parts in the DAE.
So, does anyone know how to fix this? Is there a Gazebo configuration for this sort of thing? Or is it just an incompatibility between the DAE and whatever tool is importing it (Ogre3D?)
For now, I’m just deselecting this option so I can keep going but I’d really like to get that file size down in the future.
I haven’t looked at the code that actually does the loading, but intuitively, what I would do with a model for physical simulation to begin with, is to remove all the parts that are unnecessary. That would eliminate small things like screws - really, things like that shouldn’t be in the simulation anyway, because round meshes like screws introduce a ton of triangles and are bad for performance.
The second thing I would do is to apply a modifier in the 3D modeling software to optimize the mesh. This usually allows you to strip the triangle count to as little as 5-10% of the original, and the mesh will still look the same to the human eye. That reduces the file size considerably, but more importantly, it improves the simulation performance. This should reduce the file size so much that using instances or copies isn’t a problem.
The third thing I would do is to create simple primitives for collision. You may have already done this. Meshes shouldn’t be used for collision. That would speed up performance a lot – I know you didn’t ask about this but just for completeness in the answer.
So screws were just an example, I am working with a modular robot (similar to something like LEGO) so many of the same parts are re-used and must be part of the visual geometry - being able to use object instances instead of repeating the same mesh for every one of the identical components makes the file size go up significantly. Do you have any idea how this could be fixed? It must be an issue with Gazebo as the file loads fine in basically every other piece of software I tried to load them in.
And yes, I am using primitive shapes for the collision meshes
The quickest thing to try is to apply a mesh optimization modifier (e.g. Decimate in Blender) to reduce the triangles. That should reduce your file size by a lot, even if you’re using copies. I would start at 5% triangle count (it’s usually a parameter you can specify) and incrementing a few percent points until the appearance is acceptable. Then export without instances and see how big the file is.
How big a robot / file are we talking about? Are you running on a resource-constrained machine? I’m thinking of quite complex robots like the PR2, which doesn’t have many repetitions in meshes, and it’s been simulated fine. So… not sure what the scale of the problem is.
Another option is to export the repeated part(s) to its own COLLADA file, and then piece it together either in the SDF file (use the same <uri> link in all the <visual> blocks), or in the model editor in the Gazebo GUI. But I have the impression that you have too many parts to do that manually. So I would go with the optimizer route and see how small you can get your file.
For local simulation it’s fine, but when using with gzweb it takes some time to load (even on a local machine) - on some parts I can get the file size down by another 50% if the object instances option worked
I took a look at the COLLADA files. Is this before or after optimization? The biggest files look very detailed. Do they need all the internals and the detailed surface markings? I would pull out all the guts and draw 6-face boxes to replace the external surfaces that currently have all the screw holes and tiny slots.
@mabelzhang thanks for taking a look! I did optimize them slightly yes and you’re right there is still a lot of detail - I’m trying to strike a balance between a realistic-looking robot and a low file size.
Obviously if this was just for internal use I wouldn’t care very much but we want to have users interact with this virtual robot, there isn’t much magic in programming a virtual robot that looks like a bunch of blocks But you are right, more can definitely be done!
You could fake those realistic surfaces with a texture that has those holes and details. Just an idea.
gzweb probably has a different set of things, I’m not famliiar with it. If it’s meant to be loaded on the web, I can see how it’d need to be as small as it can get.
I agree that the object instances might be valuable for the visualization. But for simulation, you should define simple collision elements. I.e., do not use <mesh> in <collision> tags, but use <box>, <cylinder> and <sphere>. This speeds up the simulation a lot and makes it more stable. You can then decide what you’ll do with the visual meshes.
Or - one more idea. You said you have modular robots. Do you actually need to compose the whole robot in Blender? You can also create a Gazebo link for each of the building blocks and connect them via fixed links.
@peci1 thanks for the info! I do use collision geometry for the simulation, it’s purely visual that I need the object instances for. I could compose some of the modular elements in Gazebo but since most of the elements are fixed it’s not necessary to add the extra complexity - I’ve already broken it down into only the parts that move relative to each other are separate links
But you are right, more can definitely be done!