Plasm and Open Cascade integration

In this page I will describe a possible evolution of my CScheme project that is actually under object of analysis.

All the CScheme software has been developed to facilitate software libraries collaboration and integration. Hence it is very simple and quite immediate (from an operative point of view) to embed every other component we would like to embed: it is the case of the integration of PLaSM that is a design language developed by CADGroup within a parallel project of "Università Of Roma Tre".

One of PLaSM main feature, and which would led to a very significant improvement of Open Cascade modelling features, is its property to be dimension-independent. Whereas in Open Cascade we can build only 2 dimensional or 3 dimensional objects using pre-codified and ad-hoc primitives, using PLaSM we have the possibility to solve solid modelling problems using a dimension-independent approach.

And Also PLaSM defines some modelling operators (such as skeleton, product, && and others) that we hardly find in any other solid modelling library (Open Cascade included). It is my opinion that these two software could cooperate and could give each other support to build a more complex "super set" of geometric tools.

PLaSM: a declarative design language implemented in Scheme and C++

The design language PLaSM introduces a very high level approach to constructive or generative modelling, where geometrical objects are generated by evaluating suitable language expressions. Language scripts are used both to formalize the design intent and to generate shape instances. In this approach a complicated design may be described hierarchically and developed either top-down or bottom-up, and also by using some mixed strategy.

The language takes a dimension-independent approach to geometry representation and algorithms. In particular it implements an algebraic calculus over embedded polyhedra of any dimension. The generated objects are always geometrically consistent since the validity of geometry is guaranteed at a syntactical level.

Using a syntactically validated programming approach the design updating becomes easier in both cases: when the changes concern some specific components and when they apply to the overall design organization. In either case it is sufficient to update some program units at suitable hierarchical levels.

It can be noted that some program units, which are either evaluated more frequently or are formalized more elegantly, may be abstracted as operators and may enter a design knowledge base (i.e. some specialized package) and then re-used during the development of different design projects.

A complex design may be described in such a way that a unique definition exists of components with different parameterizations, or simply instantiated in different positions, so that any correction in a class of components would automatically extend to every derived class and to every class instance within the design. Such an abstraction mechanism is very useful in real designing, and should allow the definition of higher-level parameterized objects.

The design intent can be straightforwardly associated to language expressions in PLaSM. At this purpose, the design structure may be very close to the structure of the source script to be used as the generating expression of the geometric shape. In particular, the user can be only concerned with the semantic meaning of the script and not with the writing of efficient code. In other words, a script in such a declarative design language may express what to do rather than how to do it.

PLaSM is a functional language developed at the University of Rome "La Sapienza" between the years 89 and 94. Such language is a geometric extension of a subset of the functional language FL by John Backus and others, that was developed at Almaden's IBM Research Division in late eighties.

PLaSM is characterized by a multidimensional approach to geometric data structures and algorithms, and so works with geometric objects of dimension 1,2,3 (curves, surfaces, solids) as well as with manifolds of higher dimensions. The language defines an algebraic calculus upon geometries and allows for implementing parametric representations of multivariate manifolds in a natural and compact way.

Generally speaking, each PLaSM program is a function. When applied to some input argument each program produces some output value. Two programs are usually connected by using functional composition, so that the output of the first program is used as input to the second program.

In PLaSM, a name can be assigned to a geometric model by defining it as a function without formal parameters. In such a case the body of the function definition will describe the computational process that generates the geometric value. The parameters which it depends on will normally be embedded in such a definition. In this case the dependence of the model upon the parameters may be implicit. In order to modify the generated object value it is necessary (a) to change the source code in either the body or the local environment of its generating function, (b) to compile the new definition and (c) to evaluate again the object symbol.

A parametric geometric model may be also defined, and easily combined with other such models, by using a generating function with formal parameters. Such kind of function will be instantiated with different actual parameters, so obtaining different output values. It is interesting to note that such a generating function of
a geometric model may accept parameters of any type, including other geometric objects, or the generating functions of subparts.

Plasm Triangle Strip Example

A common geometry constructor in graphics systems is the triangleStrip primitive. A triangleStrip produces a set of n - 2 triangles starting from an ordered sequence of n points. In particular, the k-th triangle is generated by points pk, pk+1 and pk+2.

We define the triangleStrip primitive in a dimension-independent way, as a function from sequences of points to polyhedra, where the points in the input sequence may belong to any Euclidean space E^d, with 2<=d. The primitive output is a 2-dimensional polyhedral complex embedded in E^d. Hence we have:

triangleStrip : (E^d)ⁿ -> P^2,d 2<=d, 3<=n

where (E^d)ⁿ is the set of sequences of at least 3 d-points.

The implementation given below is done using the proper FL style, i.e. without using formal parameters. When the triangleStrip function is applied to some sequence of points, first the function[ID, cells, pols] is applied to points, then the resulting triple of points, convex cells and polyhedral cells is passed to the MKPOL primitive geometry constructor, so generating the output polyhedral complex.

Notice that the symbols "~" and ":" respectively denote infix composition and application of functions.

DEF triangleStrip = MKPOL~[ID, cells, pols]
WHERE
cells = TRANS~AA:FROMTO ~[[k:1, LEN-k:2],[k:2, LEN-k:1],[k:3, LEN]],
pols = LIST~INTSTO~(LEN - k:2)
END;

When a geometric object is defined in PLaSM by using a triangleStrip primitive with 2D input points, then the generated polygon in P^2,2 can be considered solid. In this case the geometric kernel of the language stores in its internal data structure all the adjacencies between the triangles of the strip. This fact allows extracting the boundary of the polygon, both external and internal, by using the 1-skeleton extractor operator, denoted as @1.

Hence in the following script we extrude the boundary of the house2 polygon generated by a triangleStrip operator. The "*" operator denotes an infix Cartesian product of polyhedral complexes, QUOTE : R*->P^1,1 is a function producing 1D complexes from sequences of reals; STRUCT performs the hierarchical aggregation of polyhedral complexes defined in local coordinates; EMBED:n embeds a d-complex in m-space into the x_m+1 = · · · = x_m+n = 0 subspace of E^m+n.

DEF house2 = triangleStrip: <
<5,4>,<4,4>,<5,2>,<4,0>,<6,2>,<8,0>,<6,4>,
<8,6>,<5,4>,<4,8>,<4,4>,<0,6>,<2,4>,<0,0>,<2,0> >
DEF object1 = @1:house2 * QUOTE:<1>;
DEF object2 = STRUCT:< object1, EMBED:1:house2 >;

Open Cascade and Plasm via MzScheme

This a possible internal structure on which the integration between Open Cascade and Plasm could be realized (note: it is only one of a set of possible solutions; therefore there could be important changes in the future).

[Open Cascade] Open Cascade will remain the central solid modelling library of all the software system thanks to its unique features. Being recently released under Open Source licence, Ocas will probably improve more and more in the near future and it is yet a valid alternative to other commercial products which offer similar geometric services (Acis above all).

[SimpleXn/BSP] It is an alternative modelling library very powerful thanks to its dimension independent approach. Actually the porting of the SimpleXn library in C++ programming language has been quite completed (I estimate the work is actually about at 80%). This library is based on the Hierarchical Polyhedral Complex (HPC) representation which is at the same time extremely readable (every model could be printed to output stream and this output is comprehensible even to a human reader) and very easy to use and/or to extend (actually we are studying some innovative new primitives by which introduce some attributes grouped in a Data User Container within polyhedral cell).
It is also important to focus the attention on the presence of a Binary Space Partitioning trees (BSP) module embedded within SimpleXn library which supports N-dimensional boolean operations (such as union, or and intersection).
This is probably the best feature of all Plasm language which could make the difference with every other modelling software.

[CScheme] CScheme will play the role of the main communication bus of all software modules. It will allows the contemporary use of both C++ libraries and Scheme functional script which will be executed under the same process, directly controlled by MzScheme shell. As CScheme will be released in its first stable release it will possible for developers not to mind about CScheme (say Foreign Function Interface) presence: in fact it will performs its entire works in a totally transparent and hidden mode.

[MzScheme] It will remain the perfect Scheme implementation for our needs. It is the principal "front-end" component for final users since all scripts will be developed (in all modelling sessions or at least in the first phase of prototypes realization) using the scheme language. It is also important to remark that non-standard Scheme extensions that MzScheme provides (such as modularization of source code in unit and XML native support) are all important properties which give us open source valid tools at zero cost.

[Plasm] As SimpleXn module, Plasm language is actually being porting under C++/MzScheme. In CADGroup hopes we would like to offer a complete environment where it is possible to develop geometric model by using contemporary the Plasm language and Scheme foreign calls to Open Cascade services. In such environment it would be possible to develop models and to convert from one representation to the other, either from Open Cascade to HPC or the inverse (details about this argument is given in the following section).

For example consider the following typical situation:

(export-vrml
    (make-compound
        (sphere-in-space 1 5 5 5)
        (hpc-to-ocas
            (plasm "
                DEF cube=CUBOID:<1,1,1>;
                DEF cyl=CYLINDER:<1,3,12>;
                DEF mypol=cube TOP cyl;
                mypol;"))))

Import and export operation through XML language

Plasm internal representation is very simple and its new porting to C++/MzScheme environment has been realized to facilitate in particular importing and exporting operations. We use Scheme feature to handle Scheme object through its external representation that is a string-based representation to be evaluated by the scheme interpreter.

Actually we are able to dump the internal representation of a HPC object to any output stream (it could be a file if we choose to save calculated models; or it could be output streams simply to check the correctness of the model).

The following is the dump of a HPC object which correspond to the evaluation of a (cuboid:<1,1,1>) Plasm expression:

<PolComp SpaceDim="3" Rep="ONFACE">
<PolNode Rep="FACE" Mat="Identity">
    <Polyhedron PolSign="POS" Rep="FACE" PointDim="3" SpaceDim="3">
      <PolFaces val="(((1 0 0) 0) ((-0.7 0 0) 0.7)
                      ((0 1 0) 0) ((0 -0.7 0) 0.7)
                      ((0 0 1) 0) ((0 0 -0.7) 0.7))" />
            <Cell Sign="POS" Rep="ONFACES"
                  InPol="1" PointDim="3" SpaceDim="3">
                <adj val="(-1, -1, -1, -1, -1, -1)"/>
                <faces val="(((1 0 0) 0)((-0.7 0 0) 0.7)
                            ((0 1 0) 0) (0 -0.7 0) 0.7)
                            ((0 0 1) 0) ((0 0 -0.7) 0.7))" />
                <polFaces val="(0, 1, 2, 3, 4, 5)" />
                <facesSigns val="(1, 1, 1, 1, 1, 1)" />
                <fpoints val="((5,3,0)(5,3,1)(5,2,0)(5,2,1)
                              (4,3,0)(4,3,1)(4,2,0)(4,2,1))" />
            </Cell>
        </Polyhedron>
    </PolNode>
</PolComp>

In our project we want HPC internal representation to be XML compatible (actually there are only some little modification to be fully in compliance with XML syntax): this will facilitate our work to write the HPC parser and will facilitate the importing and exporting of Plasm models to other model representation (for example that used by Open Cascade).

On the opposite direction (Open Cascade models that should be converted to HPC) our algorithms will use the recently written methods to export Ocas models to VRML via a triangulation of the models: every VRML index set will be converted to a polyhedral cell; every index-set composition will be converted to a polyhedron; finally every model transformation (such as VRML scale or translation) will be embedded in a Polyhedral Nodematrix.