DLL Support for BREP Entities

[justingravett]

DLL API support is missing for must of the entities needed to define a BREP solid in IGES (types 186, 502, 504, 508, 510, & 514). To avoid having to use the lower level entities directly, would it be possible to add DLL wrappers for each of these?

If nobody is available to support this request, I may be able to add them with a little guidance.

[cbernardo]

I haven't worked on the code for so long that I can't recall how to manipulate these objects. The DLL API exposes C++ classes for manipulating entities and there are a number of clues about how to implement these and how to manipulate the objects. For example, see src/include/api/dll_entity100.h -- this declares a wrapper for a CURVE (Entity 100). Two constructors are declared, one with argument IGES* and the other DLL_IGES&; this is mainly so users can use their preferred methods for creating and manipulating objects. Aside from the constructors, a virtual destructor and a NewEntity function must be declared. All other functions are for manipulating data. Any data passed must be simple scalars, arrays, or IGES entity pointers. Pointers to any other structures or classes must be avoided since that introduces problems with the manipulation of data in the event that the structure or class definition should change. See src/dllapi/dll_entity100.cpp for the corresponding implementation of the wrapper. Tutorial1.cpp shows some examples of how objects can be manipulated to create an actual IGES model.

Of course you will also have to be familiar with the IGES specification; the latest spec before the format was abandoned is V5.3. I can't offer much help at the moment but if you wish to implement the DLL wrapper for those entities I can review and push your patches. Keep in mind that existing MCAD software uses the right-hand rule to determine which side of a surface is the 'outside' (visible) and which is the 'inside'. IGES does not specify this and so there are many valid IGES models out there that cause MCAD software to behave in unexpected ways when importing.

[justingravett]

Thank you for the informative response. So far I've been able to build the code and establish a basic understanding of the DLL wrapper templates. My working branch is here, and I will issue a pull requests when everything is ready for review and integration.

Looking into the entity files for types 186 and 514, it looks like I'll first need to add some functions to define those entities (i.e.).

The goal of this effort is to provide a BREP IGES export capability in OpenVSP. I've currently implemented trimmed surface representation through type 144 entities. However, import behavior differs widely between CAD packages, so the hope is additional information for surface connectivity should improve this.

[cbernardo]

Ah, OK. I'll see if I can find some time to help then. One issue I remember with MCAD import and OpenVSP is that MCAD generally imposes a condition that splines be second-order continuous. I can't recall now if that means splines must have only single knots in the middle or if there must be no knots at all. Implementations also vary somewhat; for example some MCADs will recognize a few forms with multiple internal knots describing a circle and translate them into a form that the MCAD can handle, but in general multiple knots in the middle of a spline causes undefined behavior for the MCAD and the curve has to be described instead as a series of splines rather than a single spline.