Sat, 05/21/2016 - 10:13
Hi. I'm lust starting to study OCC and there are some issues I failed to understand reading documentation on this site.
Is there some class of curves defined by my own parametric equations? With a constructor accepting something like std::function for x(t), y(t) and z(t)? Same question for 2D curves and 2D and 3D surfaces.
Is there a way to create a 3D curve defined by a reference to some non-planar surface and a reference to some 2D curve, so that the 2D curve is drawn in a parametric space of the surface making the 3D curve? I mean, the 2D curve is [u(t), v(t)], the surface is [x(u,v), y(u,v), z(u,v)] and consequently the 3D curve is [x( u(t), v(t) ), y( u(t), v(t) ), z( u(t), v(t) )]. Such an object would be automatically rebuilt when the surface or the 2D curve changes its form. I need it generally to split faces. I saw some hints in the "Shape healing" chapter of the "User Guide" but found no concrete descriptions. How, for example, an edge or a wire is added to a face? It must be done by defining a 2D curve in the face parametric space or by creating an independent 3D edge, then checking if it belongs to the surface with some tolerance value or even projecting the edge to the face. The latter is rather expensive. Even for edges shared by several faces describing edge's curve as a 2D curve on a face surface would make the process faster, wouldn't it? I'm asking because calculation speed is very important for my purposes.
Is it necessary to use OCCT collections? I would be happy to use only C++ STL containers.
Sun, 05/22/2016 - 13:08
Consider sub-classing Geom_Curve for implementation of your own 3D parametric curve. You will have to implement methods D0(), D1(), etc. But be careful when passing your custom geometries to OpenCascade's algorithms: they may happen to require some other methods which you also have to implement (you will realize it once you get a failure). Another option is to convert your custom geometry to standard NURBS with tools from AdvApprox package (there are some examples in the sources of OpenCascade), but this can be CPU costly. Generally, do not hesitate to introduce your own geometries to OpenCascade as it allows you to do whatever your want. Personally, few years ago I have implemented Gordon surface and Klein bottle inheriting from Geom_Surface, and had a lot of fun with them.
As for collections, in your own code there are no limitations. But for OpenCascade's API, it requires what it requires.
Sun, 05/22/2016 - 19:25
So it IS necessary and there are no implementations for those kinds of curves. Thank you for your help, especially for pointing at derivatives, as it makes me reconsider some parts of my concepts. Anyway, I apparently have to dig deeper in the documentation and the sources.
Mon, 05/23/2016 - 07:00
You can also have a look on Adaptor3d_CurveOnSurface and grep for its usage examples in the sources. It does nearly what you have described: binds an abstract parametric curve with an abstract surface, thus giving you the usual CONS (Curve ON Surface) data structure. It implements a well-known "adapter" pattern, so you may inject your logic there even without inheriting Geom_Curve. The only concern here is that not all OpenCascade's algorithm are designed to work with adapters, some require sub-classes of Geom types.
Mon, 05/23/2016 - 21:14
Oh, thanks! But actually I need to have an edge defined this way and I just found what seems to be exactly what I need in the documentation:
BRepBuilderAPI_MakeEdge(const Handle< Geom2d_Curve > & L,
const Handle< Geom_Surface > & S,
const Standard_Real p1,
const Standard_Real p2
)
I should have found it before asking questions perhaps.
Mon, 05/23/2016 - 21:33
Honestly, documentation is sometimes too verbose, and sometimes says nothing at all. I believe, it is always good to make some knowledge explicit here. Thus the forum plays as a knowledge database for community.