Mesh Blog

Technical discussions
Post Reply
nickz
Site Admin
Posts: 236
Joined: Fri Jul 26, 2013 3:58 am

Mesh Blog

Post by nickz »

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
Attachments
TeapotMesh.jpg
TeapotMesh.jpg (35.73 KiB) Viewed 12674 times

nickz
Site Admin
Posts: 236
Joined: Fri Jul 26, 2013 3:58 am

Mesh Blog. Problems

Post by nickz »

1. The main problem with meshes is that they are not parametric :lol: 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

nickz
Site Admin
Posts: 236
Joined: Fri Jul 26, 2013 3:58 am

Feel the horse

Post by nickz »

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

nickz
Site Admin
Posts: 236
Joined: Fri Jul 26, 2013 3:58 am

Normals and faceted meshes

Post by nickz »

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
Attachments
CylFaceted.jpg
CylFaceted.jpg (14.12 KiB) Viewed 12652 times
CylAveraged.jpg
CylAveraged.jpg (10.55 KiB) Viewed 12652 times

nickz
Site Admin
Posts: 236
Joined: Fri Jul 26, 2013 3:58 am

Disjoined (unlinked) meshes

Post by nickz »

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)

nickz
Site Admin
Posts: 236
Joined: Fri Jul 26, 2013 3:58 am

Advanced operations with meshes

Post by nickz »

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

Post Reply