View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0033726 | Community | OCCT:Mesh | public | 2024-05-23 13:46 | 2024-06-28 21:01 |
| Reporter | Dikran | Assigned To | oan | ||
| Priority | normal | Severity | minor | ||
| Status | new | Resolution | open | ||
| Platform | Windows | OS | VC++ 2017 | ||
| Product Version | 7.8.0 | ||||
| Summary | 0033726: Mesh - Failure to adequately render meshes containing B-Spline surfaces | ||||
| Description | The meshes generated for parts containing B-Splines present significant visual artefacts. The meshes are not visually acceptable to our clients. In the image provided, you will see that not enough points are added to reflect the part's shape. This is especially prevalent in high-curvature regions. In my assessment, this issue is caused by how nodes are appended to the mesh in the function GenerateSurfaceNodes within BRepMesh_NURBSRangeSplitter.cxx. I hope you can fix this issue soon. I remain at your disposal. Thanks in advance. Dikran | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
|
|
Coil-free_lin-def_0.8_ang-def_0.4.obj.png (304,842 bytes) Coil-free.step (88,354 bytes) |
|
|
Dear @Dikran, I am unable to reproduce the reported problem using current master (see attached screenshot). The following tcl script was used to simulate the use case: pload ALL stepread coil-free.step a * donly a_1 vinit vdefaults -autoTriang 0 vsetdispmode 1 # 0.4 rad is ~ 22.9 deg incmesh a_1 0.8 -a 23 vdisplay a_1 trinfo a_1 #This shape contains 4 faces. # 8034 triangles. # 4215 nodes. # 12 polygons on triangulation. Triangles number is very fine. Mesh on your screenshots obviously contains less triangles. Are you sure that the parameters are correct and the result is not influenced by some other functionality of your application? image.png (66,346 bytes) |
|
|
Dear @oan, thanks for the response! I have conducted further testing and obtained a similarly-looking render to yours by setting EnableControlSurfaceDeflectionAllSurfaces = true and ControlSurfaceDeflection = true. These changes have resulted in a visually acceptable part. However, the mesh associated with the part is highly irregular, with no apparent pattern in the nodes added. We require as regular a mesh as possible to conduct our post-processing tasks, so this mesh is still unacceptable. Moreover, enabling these parameter options has resulted in file sizes roughly 200 times larger in most parts tested (from 4MB to 980MB). File size is another limiting factor in our operation, so these substantial increases are problematic. Did you use EnableControlSurfaceDeflectionAllSurfaces = true and ControlSurfaceDeflection = true to generate the mesh you have attached? And if so, what does the output mesh look like? Lastly, is there a parameter that might improve the visual render without compromising the mesh quality? Thanks again for your assistance. I look forward to hearing from you. Kind regards, Dikran Coil-free_mesh_lin-def=0.8_ang-def=0.4.png (631,203 bytes) |
|
|
Hello @Dikran, that is it, by setting EnableControlSurfaceDeflectionAllSurfaces to false, you disable insertion of any of the surface points into the mesh. In this case only boundary nodes are used and here you just skip the ones that add "volume" to your shape. By disabling ControlSurfaceDeflection, you skip deflection checks for the base mesh avoiding further optimization. At this point, angular deviation between the normals as well as some naive deflection checks are performed, so additional nodes can be added to make the mesh more tight and smooth. Taking the above features into account, BRepMesh is simply not intended to produce regular grids, but ones that give to some extent tolerant result with possibly minimum number of points according to the implemented logic. Elsewhere, in most common case with arbitrary NURBS, number of surface points with regular structure would be enormous and the algorithm will end up with another issue, but related to performance. Moreover, all the implemented approaches of surface approximation are rather empirical, and there is no certain way to get fine and precise representation for any value of deflection (just note that it is just a discrete representation upon a continuous model). If you need custom results for your models, you can try to implement your own descendant of BRepMesh_DefaultRangeSplitter with necessary GenerateSurfaceNodes() logic producing regular grids for particular surface types that you are interested in. Regarding the file size, you need to play with meshing parameters and choose the ones that give you results appropriate for your application, there is no magic wand or automatic procedure to produce fine mesh without any interception from the developer's side. There is some math behind the viewer-related part that provides some default values for the mesher, but it is rather naive approach with some empirical values as well, applied to the bounding box of target model. Which parameters do you use that give you such a boost of the file size? Another way to reduce the file size if simply clean up the model from mesh data before saving and generate it again after loading back. Like this, there is not any parameter that might improve the visual render without compromising the mesh quality, because visual representation actually IS the mesh. So to improve visual quality, you need to produce more fine mesh. In general case, BRepMesh does not guarantee the specified tolerance to be fulfilled due to its nature. BRepMesh is not a mesher that is intended to provide precise result, this is a general purpose tool used mostly for visualization needs and provides results UP TO the specified deflection depending on the shape specifics. Its tolerance checks do not implement any complex approach and by the definition can skip even the very obvious cases if those cases lie outside the considered test points. If you find the results produced by the default mesher still unacceptable, require more regular results, and interested in a solution providing more quality result, please consider evaluation of our commercial ExpressMesh component: https://www.opencascade.com/components/express-mesh-component/ You are also welcome to provide your patches improving functionality of the component and making it more precise and reliable according to your needs and expectations. |
|
|
By the way, note that the spring model consists of two separate faces, it is not a single tube with a seam edge. Here the density of points along the edges is different than density of the internal points lying on the surface, so that is why there are several areas of irregularity on the screenshots. There are two separate parameters to control angular deflection of these two aspects. So, you can try to adjust them using some ratio or math function that will give you more or less coherent result acceptable for your needs. image-2.png (204,956 bytes) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-05-23 13:46 | Dikran | New Issue | |
| 2024-05-23 13:46 | Dikran | Assigned To | => oan |
| 2024-05-23 13:46 | Dikran | File Added: Coil-free_lin-def_0.8_ang-def_0.4.obj.png | |
| 2024-05-23 13:46 | Dikran | File Added: Coil-free.step | |
| 2024-05-23 14:43 | dpasukhi | Summary | Failure to adequately render meshes containing B-Spline surfaces => Mesh - Failure to adequately render meshes containing B-Spline surfaces |
| 2024-05-23 14:43 | dpasukhi | Steps to Reproduce Updated | |
| 2024-05-24 13:13 | oan | Note Added: 0115898 | |
| 2024-05-24 13:13 | oan | File Added: image.png | |
| 2024-05-24 13:17 | oan | Note Edited: 0115898 | |
| 2024-05-24 13:46 | oan | Note Edited: 0115898 | |
| 2024-06-10 13:15 | Dikran | Note Added: 0116009 | |
| 2024-06-10 13:15 | Dikran | File Added: Coil-free_mesh_lin-def=0.8_ang-def=0.4.png | |
| 2024-06-28 20:42 | oan | Note Added: 0116091 | |
| 2024-06-28 21:01 | oan | Note Added: 0116092 | |
| 2024-06-28 21:01 | oan | File Added: image-2.png |
