I have a quick question about .vtp and .stl geometry file visualization in OpenSim 4.x.
I have several key OpenSim models that I use for teaching whose geometry displayed fine in OpenSim 3.3. However, when I open these models in OpenSim 4.x, some of the geometry files no longer display properly, with stray polygons going in different directions.
I tried re-saving the geometry with Rhinoceros and Paraview, but nothing changed.
Is this geometry file display problem a known issue in OpenSim 4.x (I could not find any information about it on the Forum), and is there something I can do to existing geometry .vtp and .stl files to make them display properly in OpenSim 4.x?
Geometry that Displayed Properly in OpenSim 3.3 Displays Incorrectly in OpenSim 4.x
-
B.J. Fregly
- Posts: 51
- Joined: Wed Mar 12, 2008 6:55 am
-
Ayman Habib
- Posts: 2252
- Joined: Fri Apr 01, 2005 12:24 pm
Re: Geometry that Displayed Properly in OpenSim 3.3 Displays Incorrectly in OpenSim 4.x
Hello Dr. Fregly,
In version 3.3 and earlier we used VTK (third-party visualization toolkit) to parse/load mesh files. These were widely used parsers that worked for variety of mesh files out of the box. In version 4.0 we switched to a new visualization toolkit, and stopped using VTK altogether. A side effect of this transition is that we switched to using our internal parsers for mesh files (so that we continue to support the same file formats). These parsers were developed in house to support Contact/Collision detection primarily. Examples of where these "may" behave differently:
1. Mesh files with multiple volumes or disconnected pieces (need to split into multiple files)
2. Mesh files with mixed normals (contact requires consistent normals, visualization does not necessarily require that)
3. Mesh files with missing faces or that are not water-tight (since these can't be used for contact in general)
4. Binary vtp files are not supported.
We had no issues with our bone files since none of them exhibited these behaviors but it's not totally surprising for arbitrary off-the-shelf meshes.
It would be good to get a minimal set of files that exhibit problems with the current parsers so we can explore solutions/workarounds.
Hope this explains and please let us know if you have any further questions.
Best regards,
-Ayman
All the best,
-Ayman
In version 3.3 and earlier we used VTK (third-party visualization toolkit) to parse/load mesh files. These were widely used parsers that worked for variety of mesh files out of the box. In version 4.0 we switched to a new visualization toolkit, and stopped using VTK altogether. A side effect of this transition is that we switched to using our internal parsers for mesh files (so that we continue to support the same file formats). These parsers were developed in house to support Contact/Collision detection primarily. Examples of where these "may" behave differently:
1. Mesh files with multiple volumes or disconnected pieces (need to split into multiple files)
2. Mesh files with mixed normals (contact requires consistent normals, visualization does not necessarily require that)
3. Mesh files with missing faces or that are not water-tight (since these can't be used for contact in general)
4. Binary vtp files are not supported.
We had no issues with our bone files since none of them exhibited these behaviors but it's not totally surprising for arbitrary off-the-shelf meshes.
It would be good to get a minimal set of files that exhibit problems with the current parsers so we can explore solutions/workarounds.
Hope this explains and please let us know if you have any further questions.
Best regards,
-Ayman
All the best,
-Ayman