Introduction
In history-based parametric modeling, the reevaluation of a model is a powerful feature allowing a user to easily generate variations of an object without the hassle of manually reiterating the complete modeling process.
In order to reevaluate an object, the applied operations and their parameters (both topological and geometric) making up its modeling process need to be recorded. Such a record, called parametric specification, can then be reevaluated in order to produce the very same object if it was not edited or a new one if it was edited.
However, a well-known issue in model reevaluation is about referencing the topological cells used as topological parameters in the applied operations. An object may change at reevaluation and, naturally, the same goes for its topological cells. As a result, using identifiers and pointers to reference these entities is vowed to failure or to unexpected results at least.
A solution is to reference topological cells using a persistent naming scheme, i.e. a naming scheme allowing the matching of a referenced entity during reevaluation.
In this post, we present our approach to provide a reevaluation mechanism using graph transformation rules throughout the creation of an object
Creating an object
Jerboa, just like many modelers, allow users to use graph transformation rules in order to create an object. In the GIF below, we create the initial object presented above. At each step, the pink dots are darts selected by the user in order to apply the rules and transform the object. The panel on the right displays information about these darts, their embeddings (such as the persistent name) and their incident orbits.
Once the object is created, it is possible to open the « File » panel and click « Save » in order to save the parametric specification in a .json file.
Understanding a parametric specification
A parametric specification is basically a listing of the applied rules with both their topological and geometric parameters and, thus, represents the modeling process of an object.
Here is an excerpt of our newly created object’s parametric specification.
[
{
"ID": 1,
"type": "INIT",
"rule": {
"name": "CreateSquareFace"
},
"PNs": [],
"dartIDs": []
},
{
"ID": 2,
"type": "INIT",
"rule": {
"name": "ExtrudeIndependentFace"
},
"PNs": [
{
"PersistentName": "[{1 - n6}]",
"orbitType": "(0, 1)"
}
],
"dartIDs": []
},
{
"ID": 3,
"type": "INIT",
"rule": {
"name": "InsertVertexFolded"
},
"PNs": [
{
"PersistentName": "[{1 - n5; 2 - n5}]",
"orbitType": "(0, 2, 3)"
}
],
"dartIDs": []
},Three rules are shown in this exceprt and, for each, there is
- an application number: « ID »
- an application type (INIT, ADD, DELETE or MOVE): « type »
- a rule with its name: « rule » and « name »
- a list of persistent names: « PNs »
- a list of dart IDs: « dartIDs »
By default, « type » is set to INIT which means that an application was not edited.
Understanding a persistent name
As said in the introduction, a topological parameter must be a persistent reference allowing the matching of a specific topological entity at reevaluation.
Since rules use darts as topological parameters, our persistent naming scheme is based on said rules and must represent a unique dart. Logically, there would be ambiguities if more than a single dart were represented by a single persistent name.
In order to represent a unique dart, a persistent name must represent a dart’s history, i.e. a list of the successively applied rules and their respective nodes that either filtered or led to the creation of said dart.
Let’s use the second and third rule applications’ persistent names as examples.
For example, the second application (the face extrusion rule)’s topological parameter is a dart which history is represented by the persistent name [{1 – n6}]. This persistent name represents a dart created by the node n6 of the first rule application which is the square creation rule (shown above). Since this rule has no left side and its right side nodes are labelled <>, each node creates a single dart and, thus, there is only one dart corresponding to the history.
For the third application (the vertex insertion rule), the persistent name is [{1 – n5; 2 – n5}]. In this dart’s history, the first rule application’s node n5 creates a dart. The second rule application then matches this dart and creates of copy of the dart with its node n5. Therefore, the dart designated is created by the face extrusion rule’s node n5 and is a copy of the only dart created by the square creation rule’s node n5.
Editing a parametric specification
Editing a parametric specification means adding, removing or moving applications or even modifying their parameters. Let’s edit the previous parametric specification.
[
{
"ID": 1,
"type": "INIT",
"rule": {
"name": "CreateSquareFace"
},
"PNs": [],
"dartIDs": []
},
{
"ID": 9,
"type": "ADD",
"rule": {
"name": "InsertVertexFolded"
},
"PNs": [],
"dartIDs": [3]
},
{
"ID": 2,
"type": "INIT",
"rule": {
"name": "ExtrudeIndependentFace"
},
"PNs": [
{
"PersistentName": "[{1 - n6}]",
"orbitType": "(0, 1)"
}
],
"dartIDs": []
},
{
"ID": 3,
"type": "DELETE",
"rule": {
"name": "InsertVertexFolded"
},
"PNs": [
{
"PersistentName": "[{1 - n5; 2 - n5}]",
"orbitType": "(0, 2, 3)"
}
],
"dartIDs": []
},In the excerpt of the edited parametric specification above, we can see there are an added rule’s application and a deleted one.
The added application’s ID is set to 9. This is because last INIT application’s ID is 8 and any addition is a simple ID increment. Another thing is this application has no persistent name to serve as a topological parameter. Instead, since the user explicitly select a dart to use at reevauation, there is a dartID.
For the deleted application, the only thing to do is to edit its tag from INIT to DELETED. This tells the engine not to reevaluate the application.
Once our parametric specification is edited, we can proceed to reevaluate our object.
Reevaluating a parametric specification
The reevaluation of a parametric specification triggers two processes. Firstly, the evaluation of all the persistent names in an initial parametric specification. Secondly, the matching of the topological parameters within the model being reevaluated.
Evaluating the persistent names
In order to be able to match the correct topological entities during reevaluation, it is necessary to once again represent the history of a unique topological entity.
A dart is incident to several topological entities. Since these entities are expected to change at reevaluation, we need to trace their histories, i.e. to represents all the changes that led to the creation or modification of a topological entity. To this end, an history is built from start to end.
The persistent name [{1 – n5; 2 – n6; 3 – n0}]’s DAG represents the history of a cube’s face. From the bottom-up of the DAG, this face was modified by the third rule’s application which inserts a vertex on an edge. Before being modified, this face was actually extruded, and therefore created, from another face matched by the second rule’s application. Finally, the face extruded by the second rule’s application was created by the first rule’s creation.
Matching the topological parameters
Once all persistent names have been processed and the topological parameters’ histories computed, we can proceed to match the correct topological entities.
At reevaluation, topological entities are matched by adapting the histories previously computed to the different changes applied to the parametric specification. For example, adding a vertex insertion does modify the face created by the first rule’s application and its extrusion creates two faces instead of one from the edge on which the vertex was inserted. Also, the deletion of the third rule’s application prevent the face incident to dart 59 from being modified.
The reevaluation
At last, after modifying the parametric specification of the object we created earlier, we can reevaluate it and produce a variation.
