With some sucess importing IGES files into Eclipse using Xtext, it is time to consider how we would go about turning these imported 'Entities' into objects that ICE can work with and that EAVP can visualize in the geometry editor. It seems there should be an extension of our current model to include some bare minimum geometry components or entities. We do not want to go forward trying to support every entity imaginable, however. As Greg points out, this approach is not sustainable. Rather, we need to agree on some bare minimum pieces to represent the vast majority of curves, objects, and surfaces someone might try to construct or to convey in a geometry file. For example, CUBIT has an affinity for converting even simple geometries completely down to spline curves and surfaces when it exports to IGES. We need to eventually get the triangles out of a surface to display it in the editor with JavaFX, but in the model there are more options or representing geometric constructions than converting those spline surfaces to triangles and, equivalently, the spline curves to polylines.
There seem to be four simple categories for how the data is represented:
CSG- we already have implementations for CSG trees- almost no work needs to be done for these objects
B-Rep- We do not have this infrastructure, but some additions to the model (namely Edges, Loops, Faces, and Shells) could handle B-Rep geometries
Curves and Transformations- This can be seen as part of the B-Rep model. Most entities are represented as curves that define boundaries or areas that are then put through volumetric processes - Trimming surfaces, sweeping areas, or extrusion are good examples. Again- this seems to be the preferred method of writing data to IGES, as it can be rather compact. However, it also means more computation on our end to get the resultant geometry.
Mesh- We already have a mesh editor, and STL can be viewed as a sort of mesh format. A fine mesh of triangles is how JavaFX (and many other) 3D rendering codes view complex objects. Of course, we are not trying to view Mesh formats in the Geometry editor, but STL is a mesh of sorts so it is included. These files can be very large because of the loss of data occuring when meshing down from the geometry to the tessellated surface that STL represents.
If we can cover these categories cohesively, we should be able to write converters for most geometry formats, including IGES, to work with the model and editor we have.
