For all issues regarding the Forums use, please, refer to the Forum Rules.

Our Solutions

Need professional assistance?
Consider our:

Support Offerings

 

Need to speed up your development?
Have a look at our:

Samples & Tools

 

Need some functionality extending standard OCCT capabilities?
Check out our:

Adv. Components

Related pages

triangulation of geometry

hpc hpv's picture
Forums: 

do the triangulation algorithms (BRepMesh::Mesh) and all functions below it return only the coordinates of the triangle vertices? or can they be made to also return the precise surface normal at each of the locations as well? the few examples i have seen show only a return of coordinates, not normal vectors.

thanks

Rob Bachrach's picture

Once the mesh has been created, it's kind of dumb about the surface it came from. If you need the surface normal at a vertex, your best bet is to average the normals of the triangles connected to that vertex. It's not prices, but it should be pretty close.

A more precise option is to project the vertex onto the surface to get its parameters. Then, use the parameters to get the normal. This could be very time consuming and may still be a poor answer on boundary of 2 (or more) non-tangent surfaces.

ruud waij's picture

After meshing the TopoDS_Shape with BRepMesh::Mesh, how do I access the mesh data?

Rob Bachrach's picture

To access the triangulation (mesh) you need to iterate through the faces of the shape and get the triangulation from the face. Look at the Triangulation sample that comes with OCC. It gives some pretty good examples.

ruud waij's picture

Thanks, that works. Unfortunately IGES model MotorMount.IGS in self extracting archive igimp.exe in page http://www.algor.com/service_support/tutorials/4710_518/ crashes in BRepMesh::Mesh.

I have successfully meshed hammer.igs (from the OCC distribution) so I seem to have that working. I have checked my triangle output on a private viewer and it looks good.

I can display MotorMount.IGS in samples\standard\Qt\win32\bin\IESample.exe (import/export) so that seems correct as well.

What should I try next?

ruud waij's picture

Thanks, that works. Unfortunately IGES model MotorMount.IGS in self extracting archive igimp.exe in page http://www.algor.com/service_support/tutorials/4710_518/ crashes in BRepMesh::Mesh.

I have successfully meshed hammer.igs (from the OCC distribution) so I seem to have that working. I have checked my triangle output on a private viewer and it looks good.

I can display MotorMount.IGS in samples\standard\Qt\win32\bin\IESample.exe (import/export) so that seems correct as well.

What should I try next?

ruud waij's picture

Thanks, that works. Unfortunately IGES model MotorMount.IGS in self extracting archive igimp.exe in page http://www.algor.com/service_support/tutorials/4710_518/ crashes in BRepMesh::Mesh.

I have successfully meshed hammer.igs (from the OCC distribution) so I seem to have that working. I have checked my triangle output on a private viewer and it looks good.

I can display MotorMount.IGS in samples\standard\Qt\win32\bin\IESample.exe (import/export) so that seems correct as well.

What should I try next?

Rob Bachrach's picture

If you load the MotorMount file into the test harness, it meshes fine using the "mesh" command. This uses BRepMesh_Discrete.

I have never found the standard mesher (BRepMesh::Mesh) to be very reliable. The BRepMesh_Discrete mesher seems to do a much better job. Our code looks something like this:

try {
myMesh = new BRepMesh_Discret(myDeflect, myShape, myAngle, Standard_True, Standard_True);
}
catch (...) {
BRepMesh_IncrementalMesh(myShape, myDeflect, false, myAngle);
}

ruud waij's picture

thanks, that works. Sorry about the repeated messages, posting appeared not to work.

1- As I understand it, deflection is a number that represents the precision of the meshing, but what does angle do?
2- If you set inshape to true, there is no need to assign it to myMesh, is there?
3- what causes the exception in BRepMesh_Discret?

Rob Bachrach's picture

1 - As far as I understand it, the angle is the angular deflection. I think that this takes two subsequent vertices on the meshed edge. It then find the approximate midpoint on the edge between these vertices. The angular deflection is the sign of the angle between the vectors formed by two vertices and the midpoint. The closer this number is to 0, the closer these points must be toward linear (ie. less distance to the original curve).

2 - True, there is not need to record myMesh. I actually did it to make sure the pointer did not come back null.

3 - I don't know, but I know catching it solved a lot of problems.

ruud waij's picture

I incorporated the meshing into my program but found out that the result is not always similar to the images on this website. For instance the "axis assembly" (http://www.opencascade.org/showroom/shapegallery/ballbearing/) only has one ball in my case, see http://img215.imageshack.us/my.php?image=occbrepaxis2ce.png

I suspect it has to do with the way I handle shapes. This is what I do:

Handle(TopTools_HSequenceOfShape) Importer::importBREP( const string& file )
{
Handle(TopTools_HSequenceOfShape) aSequence;
TopoDS_Shape aShape;
BRep_Builder aBuilder;

Standard_Boolean result = BRepTools::Read( aShape,
const_cast(file.c_str()), aBuilder );
if ( result )
{
successVal= true;
aSequence = new TopTools_HSequenceOfShape();
aSequence->Append( aShape );
}
else errorMsgStr= "Import BREP: Error";

return aSequence;
}

Any pointers on how to improve this?