OPEN VCS, a lens for looking at models

TGN is compatible with IFC-compliant models and all other kinds of models, in AEC and beyond AEC. It’s equipment for looking, for visual close study, built into modeled environments in all fields where visual close study of complex spatial visual environments matters.

VCS (visual close study) has a very long history in AEC.

Its primary form of expression is the set of technical drawings. Technical drawings are VCS equipment for interpretive engagement with mental models, formerly. Today they’re used for the same purpose against both mental models and digital models.

VCS is due for an upgrade in its FORM of expression, because of that transition in the medium of modeling itself (from mental to digital models).

I propose VCS’s new form of expression as ‘TGN’. TGN is a package of 8 user engagement (with the digital model) features that I describe in outline form near the top of a TGN software development proposal page:

Visual Engagement with Modeled Worlds

A project’s set of technical drawings can be automatically upgraded to the TGN form of expression in the model. And the reverse: TGNs can revert back to drawing in it’s traditional form on demand.

Users and developers can start on either end of that.

For example:

• in a model authoring app (say, Revit or any others), with TGN VCS equipment built into the app, users can do visual close study of their models, for interpretation, evaluation, affirmation. And they can deliver their models for use by others, with that VCS equipment built-in and intact for downstream use by people who need to look, closely, engage, interpret, understand the model more than superficially. With the legacy form of technical drawing also supplied automatically coming out of the same VCS pipeline.

Users can develop their project’s VCS articulations through TGN, and the output of that effort is supplied in both forms (TGN and technical drawing) without additional user effort. They DO their visual close study along the way of their model development and they GET their VCS articulations in both forms at the same time, without extra effort.

• in a model-handling review or analysis environment (say, a CDE), the situation can be the same as above, for project models delivered by authoring apps that delivered TGN VCS equipment. Or, alternatively, it could be, also, the same as above by automatic upgrade to TGN form, of a set of technical drawings that were created without the involvement of TGN VCS rigs. Upgrading a set of technical drawings to TGN form is automat-able. The logic is straightforward.

In both examples, the utility of TGN is: more effective support for the purpose of visual close study: interpretive visual engagement that develops understanding adequate to complex tasks.

See the contrast:

1. Presenting VCS equipment in the digital model (as TGN) and taking advantage of the visual capabilities supplied there,
   
   versus
2. technical drawing in its traditional form that effectively supports visual close study of models only via drawing’s expression in-situ within MENTAL MODELS, through mental exercise only, unassisted by the digital modeled environment.

Failure to provide that assist is counterproductive, a baffling underutilization of digital models. One day the industry will look back and wonder how we could have gone so many decades without seeing that.

So TGN requires technology that reads drawing documents to produce a TGN experience for the user?

It depends on the developer, and on the purpose of the app into which TGN features are implemented. If it’s a model authoring app, then the user can engage their models with VCS functions in the form of TGN rigs in the models, to start with. At the same time, TGN articulations can be automatically transformed into technical drawings in their traditional form. This transformation is OPTIONAL. Some users can say, the TGN rigs in the models are adequate. We don’t need drawing in its traditional form. Others may say, we like both.

This requires development but the logic is straightforward, and much of the neccesary code already exists. It just needs packaging for coherent function and tuning for standardization that supports cross-app portability.

Going in the OTHER direction, for projects where technical drawings exist through non-TGN means, (drawn by hand, or CAD, or BIM automation or AI automation), then those can be upgraded to TGN form and expressed in-situ in the models automatically. Again this is proposal only, does not exist, but the logic is straightforward.

I am only trying to get people at different ends of the spectrum, looking at AEC work from different perspectives from different disciplines in different work phases to see that this upgrade in the FORM of VCS expression obviously makes sense to everyone, so that developers can start to get the sense that they ought to do something about it.

And not just fragmented half steps. But really put thought into this. And collaborate so that a core feature set supporting VCS can be standardized for the industry, for portability. And then extended and added to however is desired by anyone, beyond the standardized open core.

There is business opportunity there that I believe is very large. So, for example, we’re in our fourth decade now of commonplace digital modeling in AEC. And still, AutoCAD (a technical drawing app primarily) remains almost 60% of Autodesk’s AEC revenue today. That ‘people are stupid’ is not a satisfactory explanation for that.

I have demo videos, a feature outline, a detailed dev spec, and commentary on my proposal page.