Faceted look of meshes
Closed this issue · 16 comments
I think we should be able to improve the lighting of the meshes. Here we get 'facets' whereas we should get smooth lighting.
If I remember well my graphics days, this is likely to come from having per-face normals instead of per-vertex normals. I guess we take the normals from the URDF (?), but we can certaintly recompute them if the vertex order is right.
Examples:
Here we get 'facets' whereas we should get smooth lighting.
I noticed this also for Talos.
I guess we take the normals from the URDF (?),
The normals are defined in the dae files, we just read them as is and render the mesh. We could of course recompute them. I just need to alter the magnum-integration for this (see here).
If I remember well my graphics days, this is likely to come from having per-face normals instead of per-vertex normals.
If I remember well what I wrote, we get what the file has. If it has per-face we do per-face, if it has per-vertex, we do per-vertex. I need to check though. We could generate smooth normals though by default (I think Magnum has built-in functions for this). Let me check this and come back at some point. I guess this is not super high-priority for now, right?
Not high priority but we will want nice videos of Talos :)
Are those DAEs or STLs? I know that with STL you get only per-face normals, so in order to get smooth ones, you need to throw away the per-face ones, deduplicate the positions and generate smooth ones based on the information coming from index buffer. Noting prevents DAEs from having smooth normals directly, but the process would be similar as for STL.
In Magnum there's MeshTools::generateSmoothNormals() and for example MeshTools::removeDuplicates() that could be used to achieve this. Tho since you're using Assimp underneath, I think it should be possible to convince it to do the same during load.
Are those DAEs or STLs?
These are dae files, but I guess they were generated from stl ones? @jbmouret @dalinel do you know this?
Tho since you're using Assimp underneath, I think it should be possible to convince it to do the same during load.
Will we need to patch DART for this (they are loading the mesh with Assimp)? Or can we do it with Magnum's openData() (i.e., change the post-processing flags)?
The post-processing flags are applied when opening the file. The magnum integration uses openState(), and at that point it's too late. Patching DART seems like a good idea, since the processing flags it enables cause excessive loading time on meshes that already are deduplicated and have proper normals.
Looking at the flags there, it should be enough to change GenNormals to GenSmoothNormals to achieve what you want -- or maybe remove the flag entirely, so it doesn't throw away existing normals.
Looking at the flags there, it should be enough to change
GenNormalstoGenSmoothNormalsto achieve what you want -- or maybe remove the flag entirely, so it doesn't throw away existing normals.
This does not change the appearance of the mesh. We still get facets. I will try re-generating normals with Magnum..
This is ignored if normals are already there at the time this flag is evaluated. Model importers try to load them from the source file, so they're usually already there.
source ... so I guess you're just reusing the original STL normals after all :)
so I guess you're just reusing the original STL normals after all :)
Yes I loaded the objects in Blender. They look awful! 😛
@jbmouret using Magnum's generateSmoothNormals I managed to get a better view for Talos. See:
But this broke the visualization of KUKA (if you check closely, there are some small artifacts in Talos also):
As correctly identified by @mosra, this is because of "bad" geometry provided in the STL/DAE files. There are two solutions:
- Provide much more detailed meshes or better meshes for visualization (dae files can have per-vertex normals and we can ask PAL robotics to provide those; we could also load them in Blender and export them in files so that they have smooth normals)
- Provide a workaround implementation of
generateSmoothNormalsto take into account corner cases like having very big angles, etc.
I think for the purpose of this library, providing higher quality meshes is the best option.
In any case, I'll leave this issue open for future reference or for when I actually have some free time and I might improve generateSmoothNormals.
Yes, much nicer! I also think a good option would be to find a way to load the DAE and export them again with the right normals.
Maybe meshlab can do it (http://meshlabstuff.blogspot.com/2009/04/on-computation-of-vertex-normals.html).
However, maybe we could keep generateSmoothNormals as an option when loading a file? The artefact of Talos are not too bad for a robotic application.
Maybe meshlab can do it (http://meshlabstuff.blogspot.com/2009/04/on-computation-of-vertex-normals.html).
In theory yes. Can you try and check how the meshes look like?
However, maybe we could keep generateSmoothNormals as an option when loading a file? The artefact of Talos are not too bad for a robotic application.
I have to patch magnum-integration to allow for this optionally. It is doable (I wrote the integration for DART), but not high priority for me at the moment (I have many other things to do).
I also think a good option would be to find a way to load the DAE and export them again with the right normals.
I'm currently working on a magnum-sceneconverter tool that is able to do this (along with many other things such as mesh decimation and various optimizations). Are the URDF files limited to DAE/STL or can they reference any format? There's already a plugin for creating PLY files, but no DAE or STL at the moment.
artifacts
Just for the record -- as I mentioned in our private conversation with @costashatz, generateSmoothNormals() could be extended to have some kind of angle limit to keep some edges sharp. Of course no automagic beats manually adding correctly beveled edges in Blender or the like.
I tried using meshlab: meshlab has the tool to smooth the per-vertex normals and it looks nice in their preview. However, when I save the mesh I do not see any difference in robot_dart.
My hypothesis is that the face normals are still there and are used instead of the vertex normals. Is it possible?
I'd bet Assimp happily converts whatever it gets back to per-face normals on load :)
I think this is fixed with the new glTF meshes. Closing this..