This topic is related to an internal representation of MeshSection type of object. In KernelCAD we are trying to keep everything on high level. So theoretically there is no need to know about these issues. For advanced users, though, it can be an important topic, particularly when there are performance issues with the application.
So what is mesh? It simply speaking a triangulated surface. See the picture
Let us to step back a little: There are two major types of surface (of objects) representation in computer generated 3D graphics: Mesh and parametric. Parametric surfaces are defined with mathematical equations. Mesh is a raw data representation. Its is rather sampling or digitising of a surface
Parametric surfaces should always be the preferred way to keep objects, but it is not always possible. The main example is 3D scanning. In 3D scanning there is simply no information about the surface other than 3D sample points
It is a trivial work to generate a mesh out of a parametric surface. The reverse is not possible in general case. It is an unsolved (and not a good to solve) problem
It is easy to modify a parametric surface by changing few parameters in the equations. Mesh on the other hand is practically not modifiable. This is because in any useful surface there are too many elements and there is no obvious rule for their modification, apart form few simple operations like offset
There are more problems with the mesh. Little later about that. Despite that meshes are ubiquitous in 3D graphics and CAD. This is mostly because they are simple to store and display. The software does not need extremely extensive modelling capabilities, so it is normally relatively small
Another reason is that mesh is very flexible. Any type of surface can be approximated by mesh. Parametric surfaces on the other hand often are designed for a specific type of geometry like SOR, Pipes and 3Ds objects to some extent in KC
The main reason for popularity of meshes though is that computers currently in the end can only display meshes. This is because of the way the graphical hardware (graphics cards/adaptors) works
This parametric vs mesh defines division between 3D/CAD applications. Many CAD systems, particularly specialised in mechanical etc design, work only with parametric objects (Pro engineer, Catia, etc). Others, like 3D Studio Max, work only with meshes. There are systems (including KernelCAD) which handle both. 3D games and other mostly rendering applications work exclusively with meshes
Mesh Blog
Mesh Blog. Problems
1. The main problem with meshes is that they are not parametric Meaning that it is an approximation of a surface. It does not contain the surface itself. So for example when you need a finer mesh (better approximation) there is no way to know what the original surface was exactly
2. Ambiguity. Computer geometry deals with surfaces. Mesh is not a surface in real sense - there is no way to calculate even precise location of a point on the original smooth surface. Also important information about normals to the surface is very approximate
3. Size. To have a nice and smooth surface on the screen for some curved shapes the mesh often has to be huge in hundreds of thousands of triangles (simplexes or faces). It is often OK to render with the modern graphical hardware and memory size, but it quickly becomes problem when there are some geometric operations like Boolean are needed. Execution of those can grow exponentially with increasing the mesh size, so any hardware capabilities are exhausted very quickly
4. Precision. Geometric calculations with meshes are very approximate. This is mostly consequence of the size issue. For example when you need to calculate a section of a curved object (2D KC sample) the resulting intersection curve is sampled very roughly. To reduce the sampling step twice one would need to increase the mesh size four times
5. Quality. Often meshes, coming from various sources, have various issues like: Some simplexes can be degenerated into a segment or a point.; There can be folded (coplanar) areas; The surface can be non-manifold (three or more simplexes joined by the same edge; etc, etc. Any of these can drive algorithms crazy and cause exceptions. Because there is no information about the original surface it is very hard to handle all the exceptions
2. Ambiguity. Computer geometry deals with surfaces. Mesh is not a surface in real sense - there is no way to calculate even precise location of a point on the original smooth surface. Also important information about normals to the surface is very approximate
3. Size. To have a nice and smooth surface on the screen for some curved shapes the mesh often has to be huge in hundreds of thousands of triangles (simplexes or faces). It is often OK to render with the modern graphical hardware and memory size, but it quickly becomes problem when there are some geometric operations like Boolean are needed. Execution of those can grow exponentially with increasing the mesh size, so any hardware capabilities are exhausted very quickly
4. Precision. Geometric calculations with meshes are very approximate. This is mostly consequence of the size issue. For example when you need to calculate a section of a curved object (2D KC sample) the resulting intersection curve is sampled very roughly. To reduce the sampling step twice one would need to increase the mesh size four times
5. Quality. Often meshes, coming from various sources, have various issues like: Some simplexes can be degenerated into a segment or a point.; There can be folded (coplanar) areas; The surface can be non-manifold (three or more simplexes joined by the same edge; etc, etc. Any of these can drive algorithms crazy and cause exceptions. Because there is no information about the original surface it is very hard to handle all the exceptions
Feel the horse
Having in mind that we have to live with meshes the main problem we have control over is size (the problem no 3)
This mostly means how fine the mesh is. A fine mesh does look better on the screen, but memory consumption and performance of various operations can deteriorate exponentially.
It is very common mistake to make a mesh unreasonably fine. So the rule should be: Make the mesh as coarse as possible while keeping the acceptable rendering quality. We do have plans to automate this, but it is some way ahead
How fine mesh is generated is determined by its source. For parametric objects in KC (all types other than MeshSection) how fine is mesh generated for rendering and export to mesh-only formats (vrml and stl) is determined by the Geometric Resolution set via ISection.SetGeomResolution() http://www.dynoinsight.com/Help/ISectio ... Resolution in code or via Current Object > Options > "Simplex per dim" in Modeling Studio
All 3D scanners should have an option about how fine a scanned mesh should be. The same is true when exporting from other CAD software to the mesh formats
Normally it takes only several experiments to arrive at the correct resolution. It is important to do this as it can dramatically improve performance of the application
This mostly means how fine the mesh is. A fine mesh does look better on the screen, but memory consumption and performance of various operations can deteriorate exponentially.
It is very common mistake to make a mesh unreasonably fine. So the rule should be: Make the mesh as coarse as possible while keeping the acceptable rendering quality. We do have plans to automate this, but it is some way ahead
How fine mesh is generated is determined by its source. For parametric objects in KC (all types other than MeshSection) how fine is mesh generated for rendering and export to mesh-only formats (vrml and stl) is determined by the Geometric Resolution set via ISection.SetGeomResolution() http://www.dynoinsight.com/Help/ISectio ... Resolution in code or via Current Object > Options > "Simplex per dim" in Modeling Studio
All 3D scanners should have an option about how fine a scanned mesh should be. The same is true when exporting from other CAD software to the mesh formats
Normally it takes only several experiments to arrive at the correct resolution. It is important to do this as it can dramatically improve performance of the application
Normals and faceted meshes
To draw a surface properly any graphical software needs to be able to calculate normal to the surface (perpendiculars to the surface at corners of the mesh triangles). Because mesh does not really define a smooth surface the normal has to be specified as an additional information. Incorrect normals affect lighting of the surface. The surface appears to have some unnatural black of white spots or can look completely weird if all of them are bad
Normals can be defined per face (triangle of the mesh) or they can be precise ones defined by the original smooth surface at each vertex. Per face normal are very bad. See the pictures and the faceted look of the first cylinder. Those most often come from stl format. During an stl import KC can perform smoothing out (averaging) of the per face normal. For huge meshes this calculation can take long time. I strongly recommend performing the analysis always and saving the resulting model as glm or any other than stl format.
This issue can be identified by turning on normals in context menu of the control and zooming in on a single vertex. Faceted case has several normals one per each adjacent face. Good surface has a single normal which looks averaged for all faces
Supplying correct normals (by using vrml format) or performing the analysis at lest allows relatively coarse meshes to look OK on the screen, which helps with the size problem
In code normal can be recalculated using IMeshMods.FixupNormals() http://www.dynoinsight.com/Help/IMeshMo ... xupNormals See OnFixupNormals() in C:\Projects\KernelCAD_4_4\Samples\NET\C#\Enterprise\Morphe\Morph.cs for an example. This method does a good job in most cases, but theoretically it is better to use the original normals imported via vrml, for example
Stl BTW is the simplest format possible. It is better to avoid it altogether. It was not designed originally even to contain more than one object. In case when there are nearly coinciding surfaces in an original model importing via stl can wreck havoc as some surfaces cam become welded and whole mesh becomes invalid
Normals can be defined per face (triangle of the mesh) or they can be precise ones defined by the original smooth surface at each vertex. Per face normal are very bad. See the pictures and the faceted look of the first cylinder. Those most often come from stl format. During an stl import KC can perform smoothing out (averaging) of the per face normal. For huge meshes this calculation can take long time. I strongly recommend performing the analysis always and saving the resulting model as glm or any other than stl format.
This issue can be identified by turning on normals in context menu of the control and zooming in on a single vertex. Faceted case has several normals one per each adjacent face. Good surface has a single normal which looks averaged for all faces
Supplying correct normals (by using vrml format) or performing the analysis at lest allows relatively coarse meshes to look OK on the screen, which helps with the size problem
In code normal can be recalculated using IMeshMods.FixupNormals() http://www.dynoinsight.com/Help/IMeshMo ... xupNormals See OnFixupNormals() in C:\Projects\KernelCAD_4_4\Samples\NET\C#\Enterprise\Morphe\Morph.cs for an example. This method does a good job in most cases, but theoretically it is better to use the original normals imported via vrml, for example
Stl BTW is the simplest format possible. It is better to avoid it altogether. It was not designed originally even to contain more than one object. In case when there are nearly coinciding surfaces in an original model importing via stl can wreck havoc as some surfaces cam become welded and whole mesh becomes invalid
- Attachments
-
- CylFaceted.jpg (14.12 KiB) Viewed 12652 times
-
- CylAveraged.jpg (10.55 KiB) Viewed 12652 times
Disjoined (unlinked) meshes
One issue which comes up often is that a mesh is normally expected to be a single linked piece of surface representing a solid or a patch. This is not enforced though. KC handles disjoined/unlinked meshes well. They often appear as a result of Boolean Subtract, when the first object is cut in two pieces or when union of two non-intersecting objects is performed
STL files often contain more than a single object. During STL load if the "separate objects" is skipped you get a disjoined mesh in the case as well
It is good idea though to keep linked pieces as separate objects when possible. It is simply a better information about structure of your model. For that use IBoolSectionEx.Execute2() with context.separateComponents set to true. Internally we do separate linked components often. Unfortunately this operation is missing from interface. We will add it in 5.0 Give us a yell if it is urgent for you. We will add it to v4.4 or v4.3 right away. As a workaround you can also save a mesh as an STL and reload with the separate objects option (can be done in code too)
STL files often contain more than a single object. During STL load if the "separate objects" is skipped you get a disjoined mesh in the case as well
It is good idea though to keep linked pieces as separate objects when possible. It is simply a better information about structure of your model. For that use IBoolSectionEx.Execute2() with context.separateComponents set to true. Internally we do separate linked components often. Unfortunately this operation is missing from interface. We will add it in 5.0 Give us a yell if it is urgent for you. We will add it to v4.4 or v4.3 right away. As a workaround you can also save a mesh as an STL and reload with the separate objects option (can be done in code too)
Advanced operations with meshes
We have heaps of unexposed functionality related to mesh handling. We often just lack motivation to do a quick job of providing an interface
So if you need:
- mesh healing
- Refine / coarser mesh
- Smoothing
- cutting, trimming
- extraction
- Volume or area calculations
- momentums calculations
etc; Please let us know. You might get it pretty quick
So if you need:
- mesh healing
- Refine / coarser mesh
- Smoothing
- cutting, trimming
- extraction
- Volume or area calculations
- momentums calculations
etc; Please let us know. You might get it pretty quick