AEC: From Files to Data Exchange

Hearing about the possibilities USD can afford architects is exciting. Chatting with Aksel Alvarez , I got to share this with him:

USD has been around for a while, and its possibility of non-destructive workflows is so good. I confess that non-destructivity is tricky to visualise in a 3D environment. It helped me to use Photoshop’s non-destructive methods as an example. The “tree” of actions in CATIA or Digital Project is a better illustration.

Auditing is a thing, as well as versioning!

I heard about USD from HOK’s Director of Design Technology, Greg Schleusner AIA . Peter Leuchovius and I met with him a while ago when he had just started thinking about the need to be able to use the data we generate and share and consume in a project. USD also offers the externalisation of data. We move from file formats to data frameworks. Greg S. suggests moving from “Object Oriented Programming” to “Data Oriented Programming”. He mentions an “ECS” (Element Component Scene ) as a great example, gathering popularity in the game industry. The whole idea, once more, is to externalise the data.

When trying to understand this myself, HTML is a good example. The videos or the images we see on a webpage are not part of the code written in the webpage (the .html file). The webpage calls another place and asks for the video or the image. And even more, the look of the webpage elements (text, background, etc.) is controlled by a .css file that the webpage also calls (actually, the webpages read first what device you are using and call the .css file that has been written for that device. Web designers write different .css files for specific devices).

The exciting part here is that Greg S. is an active part of BuildingSmart and is helping in the conceptualisation and development of IFC 5. He is trying to make IFC an open “data frame” (not a file type) with ECS and USD characteristics . Last year, he gathered Bentley, Autodesk and Trimble to discuss ECS implementation!

It is exciting, indeed!?

Takeaways

On the Computational Design side of things, we should start learning to use “Data Oriented Programming”. A few Python packages are already to help do this (Snecs , for example). We will see some incredible new possibilities to design and collaborate on the software side of things!

On the theory/conceptual side of things, yesterday, I saw a video clip from Michael Levin saying that “evolution... doesn’t just produce specific solutions to specific challenges; instead, it creates... “problem-solving machines.” These machines are made up of hierarchical biological hardware with incredible adaptability, capable of tackling various challenges without assuming specific environmental conditions. Contrary to commonly held ideas about evolution, it doesn’t just search for the best possible physical characteristics in organisms. It also uses signals and behaviours to shape how organisms function, so when things change or get damaged, the different parts of an organism can continue to function.”?

Greg’s and the Future AEC Software Specification are needed, but a data-oriented design prioritises the late stages. Maybe Levin’s ideas can help us push how we use programming for the ideation/conceptualisation stage.

Kudos to my colleague Martin Johnson for introducing me to USD a year ago or so! Martin, as always, is keeping the pulse on viz tech!