Sun, 03/28/2021 - 20:00
First let me apologize for the long winded background but I suspect it is needed to understand the issue.
In a nutshell, I created a hyperboloid surface geometry, made a face and shape and tried to display it. The result is in the attached figure (hyp01.png). From this, it can be seen that the left side of the white frame of the shape appears to follow the correct outline of a hyperboloid (upper sheet of 2 sheet version) but the actual shape is more like a cone. The right side 'frame' also appears to show a cone rather than a hyperboloid. I know the basic math is correct because I have tested in other software (sagemath) and it correctly displays the hyperboloid. I have also tested the return values of D0 and D1 throughout the u,v parameter space and all give correct values.
So my question is, did I create the shape correctly in the first place? Is there a better alternate method? Is there something obvious that I've missed? Any insight would be greatly appreciated.
Here is how I created this shape:
I created a new class derived from Geom_ElementarySurface for a hyperboloid. Included appropriate implementations of all the necessary procedures (D0, D1, D2, ... etc.) and then tested that I got the correct values back by succesive calls to D0. I then set about making a displayable shape using the following code snippet:
Handle(Geom_SQsurface) hypSurf = new Geom_SQsurface(hypAx3, 0.5,0.5,-1.25,0.0,0.0,0.0,1.0);
BRepBuilderAPI_MakeFace hypFace(hypSurf,0,(2*M_PI),0.0,3.0,1.0E-7);
Handle(AIS_Shape) hypShape = new AIS_Shape(hypFace.Shape());For a little context the inputs to Geom_SQsurface are basic parmaters for a generic surface of the form: Ax^2 + By^2+Cz^2+2Dx+2Ey+2Fz+G=0
Given non zero parameters for A, B, C, and G you can convert to a basic form for a hyperboloid (2 sheets in this specific case).
The u and v parameters in the BRepBuilderAPI_MakeFace call are the usual angle from the +x axis in the X-Y plane and an inclination value (See wikipedia entry on hyperboloids for further details on the math and parameterization).
The above does work and a shape is displayed with:
myModelView->getContext()->Display(hypShape, Standard_True);The problem is that the shape looks like a cone vs a hyperboloid as noted above and in the attached picture.
Mon, 03/29/2021 - 10:15
I'm afraid that sub-classing Geom_ElementarySurface at application level wouldn't reliably work in many cases, as there are a lot of places in OCCT polling surface/curve types (see GeomAbs_SurfaceType/GeomAbs_CurveType enumerations). Geom_Surface/Geom_Curve hierarchies are treated more like fixed set of curves (with missing "final" world, as there was no such thing in C++ language when Geom package was first introduced) rather than abstract interfaces in OCCT itself.
There is GeomAbs_OtherSurface type, but it is difficult to say how far one could go with it into OCCT algorithms without breaking something, as this capability is rarely used... Cannot say, though, that the issue you are experiencing is coming from this.
Mon, 03/29/2021 - 17:27
So OCCT has no basic way of dealing with basic surfaces described by equations? This seems something that would be fundamental for a graphics library that supports CAD/Engineering software.
I'll look into the GeomAbs_OtherSurface but it may be that I'll need to explore other alternatives.
Mon, 03/29/2021 - 17:39
Follow up - Where can I find documentation on GeomAbs_OtherSurface? A search yielded little other than an obscure and terse reference page for GeomAbs_SurfaceType.hxx with no actual details.
Mon, 03/29/2021 - 19:49
GeomAbs_OtherSurface is what you have already created - there is nothing more to search in documentation.
That's not exactly what I meant. You can implement basic surface interfaces in OCCT (I cannot say in this context if you have implemented interfaces correctly or not - this is another question), however such surface is not guaranteed to work everywhere. Consider exporting such a surface into STEP file - how it could be written without STEP writer actually knowing the surface type? And I guess there are much more scenarios, where definitions of D0/D1/DN black-box functions will not be enough to do something useful with the surface.
Maybe some experts in modeling would clarify better what is possible and what is not...
Mon, 03/29/2021 - 22:34
Thanks for the followup. I think you hit upon the key issue I am running into which is being able to do something useful with the resulting surface. For my needs, divorcing the created surface from the underlying equations that define it is a non-starter. Converting to a set of equations that OCCT can handle (e.g., rational bezier or bsplines) is something I'm still exploring but I need to be careful because any manipulation of the resulting surface perform with OCCT would need to be translated back into the orginal equation form (e.g., quadratic or generic surface equations). That was the problem I had hoped OCCT could help to solve or at least make a little easier. I'll also explore conversion to STEP but I don't believe that will be viable in this case.