View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0032076 | Community | OCCT:Visualization | public | 2021-01-22 15:06 | 2022-11-01 18:30 |
| Reporter | alexzkw | Assigned To | alexzkw | ||
| Priority | normal | Severity | minor | ||
| Status | feedback | Resolution | open | ||
| Platform | Windows | OS | Windows | ||
| Product Version | 7.3.0 | ||||
| Summary | 0032076: Strange mesh normal in cone apex | ||||
| Description | In OCC 7.3.0 the normal of the node in the apex of the cone was (0,0,0), now it is some strange direction | ||||
| Steps To Reproduce | 1) Load cone shape in .brep file 2) Use the following mesher to generate the appropriate mesh: BRepMesh_IncrementalMesh mesh(cone_face, 0.56993390835593716, 0 0.87266465028127038); TopLoc_Location loc; const Handle_Poly_Triangulation& triang(BRep_Tool::Triangulation(cone_face, loc)); auto normal = triang.Normal(5); //Was 0, 0, 0 in OCC 7.3.0, now strange direction | ||||
| Tags | No tags attached. | ||||
| Test case number | |||||
|
|
cone.brep (2,984 bytes) |
|
|
@alexzkw, Due to the fact that there are several methods to compute normals, it is not responsibility of BRepMesh which is used to produce triangles only. In particular, normals are useful in context of visualization, thus visualization part generates normals on its own and further uses Poly_Triangulation to cache this data. So, having initial shape without triangulation and passing it to BRepMesh, you will obtain result with triangulation, but without normals which looks like the behavior you need (do not forget to use Poly_Triangulation::HasNormals() method to check that there is normal data at all). By the way, it is rather incorrect to rely on hardcoded index in hope that it will always correspond to the apex. Depending on some conditions or order of processing it may be different. Like this, the reported problem seems representing some side effect of your application, but, unfortunately, not the true state of the things. Probably, it would be the following issue: - you generate or have a shape with already generated mesh; - this shape is displayed in 3d viewer (which generates and updates normals data); - then the shape is passed to incmesh which leaves previous data untouched as fitting the specified deflection; - you check existing triangulation pre-processed by visualization part for normals and notice that normal data is far different from expected. You can prove yourself by adding the same check for normal data right before the call to BRepMesh_IncrementalMesh. If there is triangulation and normal data, that's it. However, if the problem is also in changed directions of normals produced by visualization part, you may figure it out directly with visualization experts. I will change category of the issue anyway. In general, I see no issue here in context of BRepMesh, so it could be closed. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2021-01-22 15:06 | alexzkw | New Issue | |
| 2021-01-22 15:06 | alexzkw | Assigned To | => oan |
| 2021-01-22 15:06 | alexzkw | File Added: cone.brep | |
| 2021-01-22 15:10 | kgv | Relationship added | related to 0021753 |
| 2022-11-01 18:27 | oan | Note Added: 0111826 | |
| 2022-11-01 18:28 | oan | Assigned To | oan => alexzkw |
| 2022-11-01 18:28 | oan | Status | new => feedback |
| 2022-11-01 18:28 | oan | Category | OCCT:Mesh => OCCT:Visualization |
