CATIA, Component Based Design, Research, xGenerative Design

High Detail Modeling through Component-Based Design

The goal here is to populate a model with a template to create a highly detailed facade. The concept behind this process is called Component-Based Design.

Whereas you might think in a more traditionally-architectural sense in terms of a building being made up of a core, shell, and interiors, this approach focuses on the individual parts which make up the whole.

Hopefully, the prior posts, and this culminating one, shows that it’s very possible to have a workflow in which both design and production can be integrated into a more holistic process.

Creating an Object Type

First, an object type must be created. An object types stores things like the engineering template and user-defined feature, which will be explain later.

When creating new content, search for ‘Covering type’ and select it. And for the product instantiation method, select ‘Adaptive’. This allows the template to adapt per the inputs created.

The template and user-defined feature (UDF) are stored in the Resource Table. Within the table, you will see two rows, one for each resource.

You need to create a UDF in order to instantiate the template. The two resources are linked, with the idea being that the UDF will be a more simplified version of the Template, acting as an anchor for the more detailed product.

Creating a User Defined Feature

Again, the UDF needs to be super simple, so in this case, it will only contain an Axis System that will act as the anchor.

Note that there are two Axis Systems. The first will be referenced in the UDF; the second is a formula-based Axis System that is linked to the first Axis System.

Within the Building Engineering 3D Design app, highlight the first Axis System in the tree and then select the ‘User Defined Feature’ tool. This will automatically link both Axis Systems to a new Knowledge Template for the UDF.

So, an anchor for the UDF is now live. But, now an anchor for the template needs to be created too!

Simply create a new Axis System and use the ‘Define Component’ tool to associate this new axis system as the anchor. Notice that the axis system then becomes published, which means that is now exposed for other processes to use it.

Creating a High LOD Facade Model

Instantiated panels of one side of the skylight facade

In order to truly merge a design with the reality of the physical, the inputs from the design and the inputs of the template need to match. And to reiterate, these inputs are a set of points which define the boundary of the panel and the axis system, which ultimately is a coordinate location of where that panel lives.

To set this up, first the design model modified using xGen must be inserted into the site,which was previously used to test the template.

The main tool to use is ‘Capture Component Specifications’, where the inputs from the design model are linked up with several items, which include:

  • Object type – Click on the search icon and find the Covering object type
  • Part Body – create a new 3D shape where the specifications will live
  • Inputs – Includes axis systems, and three points from the design model
  • Parameters – Used in the template; offset and thickness, in this case

The inputs are associated using a selection pattern; a manual process of selecting the whole list of axis systems within the tree.

Once the selection pattern is processed, the inputs are then associated with a panel.

Note that in the screenshots above, the panels have already been exposed ⁠— its a very easy step from here though!

Back to the concept of level of development, a specific tool called ‘Change Level of Development’ actually populates the template individually.

Again, the UDF is this example is super simple, made up of just the axis system. This is because the simple version of the model lives in Rhino, and only extracted the essential geometrical data with xGen.

You can imagine, however, that the UDF could also contain a simple surface to represent the panels as well.

One of the benefits of this approach is that the panels are organized in a list, each with a unique name, generated automatically. You can then export these details into an Excel sheet or convert this model into IFC and link into a architectural Revit model.

Another benefit is the idea of continuous LOD, which means that I can update the template, adding more details to the panel, and reinstantiate the templates fairly quickly following the steps above, due to the links created between the design model and the template.

In other words, a conceptual design can rapidly become a highly detailed model — the stuff dreams are made of!

See the video above to see the quick change in level of development for yourself! 🙂

CATIA, Research, xGenerative Design

xGen + CATIA – Publishing Geometry

In order to populate the engineering template, we need get the inputs from the design model, which are living within the Rhino model.

This requires importing the Rhino model into xGenerative Design, exporting as a STEP file and then importing this file into a new 3D product.

But before moving on, all surfaces must be assembled, or joined, using the ‘Join’ tool. Otherwise, when you try to use the surfaces in xGen, you will have to import each surface individually. It is much more convienent to have the surfaces in just one list!

Extracting Geometry with xGen

After opening the new product within xGen, you can import the joined surfaces. The current workaround for this is to click on the ‘Join’, and then click any tool, such as translate, which appears in the 3D browser. This automatically creates the connected nodes and simulaneously imports all the surfaces. Now, on to the fun part: deconstruction!

The main nodes used for the importing and extracting of inputs were:

  • Dissassemble – Connecting the ‘Import’ node to this will give you the full list of surfaces
  • Sub Elements – Plug the output from the ‘Disassemble’ node here to get all three vertices of each surface; main inputs for template instantiation
  • Centroid – Use this node with the next one on this list; used as the reference point to get Axis Systems
  • Axis System on Surface – Get Axis Systems for each surface; an main input used for the template instantiation process
  • Publish – Don’t forget to add this to the final outputs! This exposes the main inputs (the three vertices/points and axis systems) for use later down the line
Full graph used to get geometrical data from the imported surfaces
Highlighting of main inputs: 3 points and Axis System

Next, we can start to actually use these inputs and the template created together! How exciting is that?!