Loading tetrahedra models

8 views
Skip to first unread message

Ricardo Ortiz

unread,
May 4, 2015, 5:58:43 PM5/4/15
to opens...@simquest.com
Hi folks,

I am in the process of creating some models to load in OSS.

What mesh formats are supported by OSS at the moment? 
I can only find the PLY loaders. 
What tools (if any) do you use to create/export/manipulate tetrahedral meshes in PLY format?

Thank you!

/Ricardo

Harald Scheirich

unread,
May 5, 2015, 8:14:49 AM5/5/15
to Ricardo Ortiz, opens...@simquest.com
Hey Ricardo, 

For any mesh on the simulation side (i.e. Collision and Fem meshes) only the ply file format is supported. The Fem mesh information is not read from the geometric ply information (i.e. the face element)   but from a special fem element in the ply file that indicates the type of Fem that is being read (1d_element, 2d_element, 3d_element). As I am looking at the sample files in Physics/Unittests/Data/PlyReaderTests I see that we did not document the format very well if you would like I can write up a better description. The reason we chose ply is exactly for the extensibility in this case and the ability to take on extra elements without having to break the file format.

For graphical objects any format that is supported by your OSG build can be used. The long term plan (this means we are not currently working on it) would be to utilize OSG as a model converter that lets us generate an OSS mesh from any scenegraph the ground work is there through the Graphics::Model class that could encapsulate the access to an Graphics::OsgModel without having to expose OSG to the rest of the system. 

Currently there is no fixed toolchain for authoring FEM, Julien the physics lead should be able tell you more when he is back from vacation next week. I think he uses TetGen (http://wias-berlin.de/software/tetgen/) and then integrates the information from that tool into the ply file. With the graphics and structural information separate, you can use the same ply file for the FEM and the graphics and just transfer the FEMs positional information to the graphics mesh as is done in the Stapling example.

We are currently in the process of extending and refactoring the way FEMs are being read and built, the added flexiblity will be in specifying which kind of fem element should be constructed, the type will be less generic than , we would love to hear about any requirements on your side, or see contributions. (Sorry for the plug there)

I hope this helps a little bit, what file format would you want to use ? 
What is the process that you envision ? 
What do you want to do with the model that you are loading ?

Harry

--
You received this message because you are subscribed to the Google Groups "openSurgSim" group.
To unsubscribe from this group and stop receiving emails from it, send an email to opensurgsim...@simquest.com.
To post to this group, send email to opens...@simquest.com.
Visit this group at http://groups.google.com/a/simquest.com/group/opensurgsim/.



--
Harald Scheirich
Principal Software Engineer
Simquest Solutions Inc. 

Ricardo Ortiz

unread,
May 5, 2015, 9:59:50 AM5/5/15
to Harald Scheirich, opens...@simquest.com
Hi Harald,

Thanks for the great feedback!

On Tue, May 5, 2015 at 8:14 AM, Harald Scheirich <hsche...@simquest.com> wrote:
Hey Ricardo, 

For any mesh on the simulation side (i.e. Collision and Fem meshes) only the ply file format is supported. The Fem mesh information is not read from the geometric ply information (i.e. the face element)   but from a special fem element in the ply file that indicates the type of Fem that is being read (1d_element, 2d_element, 3d_element).

I believe material properties and boundary conditions are also read (and required) from special elements in the PLY, right?
 
As I am looking at the sample files in Physics/Unittests/Data/PlyReaderTests I see that we did not document the format very well if you would like I can write up a better description.

I think this will help for future references...

The reason we chose ply is exactly for the extensibility in this case and the ability to take on extra elements without having to break the file format.

This is understandable but AFAIK not many PLY readers support tetra elements or custom elements, just face elements, so exporting models to OSS PLY format could be tedious. So I was wondering if someone had written a tool (class or script) to do this already before getting into that.

We are currently in the process of extending and refactoring the way FEMs are being read and built, the added flexiblity will be in specifying which kind of fem element should be constructed, the type will be less generic than , we would love to hear about any requirements on your side, or see contributions. (Sorry for the plug there)

:)... It would be great to have a FEM delegate reader for vtk file formats (at least for unstructured grids). I don't think this would be a huge effort and I think would streamline model creation for me and others. I would be more than happy to help with this.
 
I hope this helps a little bit, what file format would you want to use ? 

Most of my tetrahedral models are in vtk unstructured file format, the collision and visual models are ply.
 
What do you want to do with the model that you are loading ?

I want to set up an interactive simulator and be able to do basic interaction (poking and pulling) with a couple of omni devices. 

Thanks again!

Cheers,

/Ricardo

Harald Scheirich

unread,
May 13, 2015, 11:04:35 AM5/13/15
to Ricardo Ortiz, opens...@simquest.com
First of all sorry for the delayed replay I had looked at this email on the phone and missed the comments, i think it would be worth to set up a conference call, skype, google or other shared medium then we could talk your requirements through, What would be a good time for you ? 

I am also adding some more comments in the threaded conversation with further explanations. 

Harry 

On Tue, May 5, 2015 at 9:59 AM, Ricardo Ortiz <ricard...@kitware.com> wrote:
Hi Harald,

Thanks for the great feedback!

On Tue, May 5, 2015 at 8:14 AM, Harald Scheirich <hsche...@simquest.com> wrote:
Hey Ricardo, 

For any mesh on the simulation side (i.e. Collision and Fem meshes) only the ply file format is supported. The Fem mesh information is not read from the geometric ply information (i.e. the face element)   but from a special fem element in the ply file that indicates the type of Fem that is being read (1d_element, 2d_element, 3d_element).

I believe material properties and boundary conditions are also read (and required) from special elements in the PLY, right

Yes they are both in there, the concerned elements are 

element boundary_condition 
property uint vertex_index
Takes a number of vertex indices, each vertex index is treated as a boundary condition, i.e. does not have any degree of freedom

element material 1
property double mass_density
property double poisson_ratio
property double young_modulus

Material parameters for the whole FEM, this could be extended to do per node material properties (which we do not support at the moment)

Additionally the 1DFem format supports 

element radius 1
property double value
This is the radius of the FEM swept along the Elements

and the 2DFem format supports 

element thickness 1
property double value
The thickness of the simulated sheet

 
As I am looking at the sample files in Physics/Unittests/Data/PlyReaderTests I see that we did not document the format very well if you would like I can write up a better description.

I think this will help for future references...

The reason we chose ply is exactly for the extensibility in this case and the ability to take on extra elements without having to break the file format.

This is understandable but AFAIK not many PLY readers support tetra elements or custom elements, just face elements, so exporting models to OSS PLY format could be tedious. So I was wondering if someone had written a tool (class or script) to do this already before getting into that.

If you know any compound formats please let us know and we can have a look, ply is one of the few ones that even lets us combine data of different dimensionalities, and also lets us extend the format. The other choice would have been to represent objects by different types of files and via multiple files and we did not want to do that. We also looked at the vtk formats but we did not see an easy way to implement vtk readers without burdening OSS with a depency on VTK. 
 
We are currently in the process of extending and refactoring the way FEMs are being read and built, the added flexiblity will be in specifying which kind of fem element should be constructed, the type will be less generic than , we would love to hear about any requirements on your side, or see contributions. (Sorry for the plug there)

:)... It would be great to have a FEM delegate reader for vtk file formats (at least for unstructured grids). I don't think this would be a huge effort and I think would streamline model creation for me and others. I would be more than happy to help with this.

We are not changing the file format itself, but Julien Lenoir is working on a better way to create the structure used by the FEMRepresentation, so that it is easier to set up this structure, copy and query it. I think the working title is FEMElementMesh. The underlying architecture of Reader and ReaderDelegate is not really going to change, we are rewriting the delegate to create the new structure. But i talked  to Paul Novotny this morning, and I think we came up with a good way to integrate a VTK reader into OSS, all of this would be easier to talk through.

Ricardo Ortiz

unread,
May 14, 2015, 11:00:24 PM5/14/15
to Harald Scheirich, opens...@simquest.com
Hi Harry,

Thanks for the follow up.
I am pretty much open next week, anytime except Monday 10-11AM works for me.

/Ricardo

Harald Scheirich

unread,
May 15, 2015, 1:00:13 PM5/15/15
to Ricardo Ortiz, opens...@simquest.com
How about Monday at 2pm then, I will set up a hangout and publish it here as well if other people want to join 

Harry

Paul Novotny

unread,
May 18, 2015, 3:54:06 PM5/18/15
to opens...@simquest.com, Ricardo Ortiz
We are scheduled to discuss loading tetrahedral models tomorrow
(Tuesday) at 10am EDT. I think we will focus on how it is currently done
in OpenSurgSim, along with possible extensions for adding other formats
(ie, VTK unstructured grids).

Let's use Appear.in at the following link, unless anyone has an issue.

https://appear.in/opensurgsim

All are welcome. Currently Julien, Ricardo, and I are attending. See you
tomorrow.

-Paul
Reply all
Reply to author
Forward
0 new messages