Editing old revision 4. Saving this page will replace the latest revision with this text.
<commblock> <author>Qianqian Fang</author> <email>email@example.com</email> <inst></inst> <comment> hi Sanket do a "help remeshsurf" see the possible options. For simplicity, you can set opt as a scalar, which will be the desired maximum element diameter of the resulting mesh; in that case, the grid-size will be set to opt/4 automatically. Please do a meshresample first to reduce the mesh density and then do a remeshsurf; this can save a lot of memory for you. By the way, do you have to keep the original surface more than 50%? FreeSurfer produces very dense surface mesh, for me, I usually keep only 5~10% of the elements. If you have a very dense surface mesh, tetgen will take a long time to make tetrahedral mesh. You can also try [http://meshlab.sourceforge.net/ MeshLab] to manually select and correct these bad elements in the original mesh, but generally speaking, this is pretty difficult. I've chatted with the FreeSurfer developers in our building, but at this point, there is nothing we can do about it. </comment> <timestamp>: Tue Jul 27 2010 13:03:21 GMT-0400 (EST)</timestamp> </commblock> <commblock> <author>Sanket Jain</author> <email>firstname.lastname@example.org</email> <inst></inst> <comment> What is the opt structure in remeshsurf function? I am not sure what the values for its opt.gridsize and others would be in my case. Is there any way I use the same gridsize and elemsize as my original surface mesh? or Does it nullify the whole objective of performing the resurfmehs. </comment> <timestamp>: Tue Jul 27 2010 10:45:21 GMT-0500 (Central Daylight Time)</timestamp> </commblock> <commblock> <author>FangQ</author> <email>email@example.com</email> <inst></inst> <comment> hi Sanket this the most [http://iso2mesh.sourceforge.net/cgi-bin/index.cgi?Doc/FAQ#I_am_getting_a_Two_subfaces_are_found_intersecting_each_other_error_what_should_I_do frequently encountered error] with iso2mesh (or tetgen). It is very likely that your original mesh contains self-intersecting elements, and mesh simplification (decimation) usually won't fix it (If you are using FreeSurfer, the pial surface it produced usually have this type of issue). There is a work-around, but you might have to play with the options to get it to work. Please look into the sample script <tt>sample/demo_remesh_surface.m</tt>. It calls a function named <tt>remeshsurf</tt> in the toolbox. What this function does is to first convert a closed surface into a binary image, and then re-extract a surface from the volume, and the extraction script guarantees that the produced mesh is self-intersection free. If your mesh is complex, you may have to use a large volume to re-voxelize your surface. Give it a try and let me know if it works. Qianqian </comment> <timestamp>: Mon Jul 26 2010 19:54:04 GMT-0400 (EST)</timestamp> </commblock> <commblock> <author>Sanket Jain</author> <email>firstname.lastname@example.org</email> <inst>Medical College of Wisconsin</inst> <comment> I used a cortical surface and created a volumetric mesh using the surf2mesh function. If I use the keepratio value <=0.5; the mesher works really well. But if I use the keepratio value>0.5, I get the following message. Error: Invalid PLC. Two subfaces (17561, 18027, 83603) and (83474, 83572, 18027) are found intersecting each other. Hint: Use -d switch to find all intersecting facets. volume mesh generation is complete I am not sure the reason for this message and also if there is any potential work around it. Thanks, Sanket </comment> <timestamp>: Mon Jul 26 2010 16:05:00 GMT-0500 (Central Daylight Time)</timestamp> </commblock> <commblock> <author>Qianqian Fang <email>email@example.com <comment> it is not needed. the mexglx files are compatible with 64bit systems. please see my email. </comment> <timestamp>: Thu Feb 26 2009 17:51:31 GMT-0500 (EST)</timestamp> </commblock> <commblock> <author>Edouard Oudet <email>firstname.lastname@example.org <comment> Dear all, Thanks a lot for your toolbox. In my distribution the cgal*.mexa64 files are missing. Is it normal ? Does it come from a problem of compilation of cgal in 64b ? Best regards, Edouard. </comment> <timestamp>: Thu Feb 26 2009 17:31:55 GMT+0100 (CET)</timestamp> </commblock>
This change is a minor edit.
(Current user name is anonymous)