Visual Engagement with Modeled Worlds

‘TGN’ is New Equipment for Looking

These few short articles describe a forthcoming evolution in the development of equipment for visual close study (VCS) within digital models of all kinds in the architecture, engineering, and construction (AEC) industry and similar industries:

On this page is a development proposal for evolution in our equipment for visual close study (VCS) of digital models, new equipment for looking, to be built into modeling software of all kinds in the architecture, engineering and construction (AEC) industry (and similar). This new equipment for visual close study, designated for now as ‘TGN’, will evolve and expand the role formerly played by ‘technical drawing’.

It is proposed to enter the market through an open source set of core features to be developed, shared, and promoted to existing and new software companies and relevant standards organizations (e.g., Open USD), with myriad business opportunities for software companies for extending beyond the open core with additional development serving more particular (less generalized as with the open core) market needs.

This page includes a summary outline explanatory text describing the 8 core features of ‘TGN’ VCS equipment in digital models., a more comprehensive TGN VCS specification for software developers, and demonstration videos simulating TGN functionality in a visual mockup.

Here’s my background https://tangerinefocus.com/about-2/, with a link to a page about the results of my previous efforts in this space, which started with my proposal in 2007 for the automated fusion of technical drawings in-situ within digital models, a concept that found its way into 9 different software products from 9 different companies, some of those leading their segment in AEC, the first of which hired me to lead the development team to build it: https://tangerinefocus.com/tgn/earlier-media-innovations/.

There is also a blog with commentary and discussion: https://tangerinefocus.com/blog-tangerine/

TGN, the open source VCS development proposal, is a triple fusion, of:

  1. digital modeling, in any combination of formats typical in AEC
  2. technical drawing, instantiated within the models and evolved in form of expression, and
  3. cinematic camera rigging techniques, from a hundred years of the history of film, etc.

TGN open source Core VCS Features (8)

8 common software features, packaged together and standardized as TGN OPEN CODE:

The 8 features are described in outline form below, with links to a developer specification document below the outline.

TGN OPEN CODE is intended for implementation in all model-handling apps and platforms by both commercial and open source developers. A proof of concept of TGN rigs in at least two AEC modeling apps, including portability of TGN rigs from one modeler to the other, is proposed.

How can that be done?

Through a code transformation layer.

There is proposed a code transformation layer between eight features that every modeling application already has, and an open standardized definition of the same features, along with a packaging into coherent function of the eight features.

More on the transformation layer after the outline.

What would drawing look like if it were invented today instead of long ago when models were mental and physical but not digital? I propose that it looks like this:

8 FEATURES of TGN OPEN CODE

(1) ADMINISTRATIVE PARAMETERS (a,b):

  • where are the models stored?
  • do I need credentials to get to them?
  • what’s the coordinate system of the model?
  • who created THIS TGN rig?
  • Is this rig issued at some milestone or is it work in progress?
  • etc.

(2) SCOPE BOX (a):

  • Some narrowing scope boundary/volume in the model.
  • WHERE am I narrowing my focus? A rectangular volume or some more complex boundary, as with aircraft cutaways and whatnot.
  • In other words, however the bounding scope is defined, a bounding scope where attention is focused is made clear.

(3) A BUILT-IN CAMERA PATH (b):

  • for easily inspecting the bounding scope.
  • The camera path here takes some lessons from a hundred years of the history of film and makes it easy for the author of the TGN rig to provide an easily controllable viewing experience. This is similar to conventional drawing where the viewing experience is COMPLETELY controlled (one fixed vantage point only).
  • With TGN inside digital models, we mimic the mental activity we all experience when contemplating a drawing. We imagine a drawing in-situ within our mental model of the whole project, and we move ourselves around it back and forth, the way we move around a coffee cup, a chair, a person, a cat. Right? It’s never a permanently fixed single orientation. We wobble back and forth at least partially around it.
  • So this wobbling is built-in to each TGN rig. And there is, (next, 4):

(4) a UI SLIDER BAR (b):

  • that moves the camera back and forth along the TGN rig viewing arc/curve/path (3).
  • As you move along the viewing path looking at the scope volume, that volume has a primary face (the section or plan cut plane for example). When the camera is brought to the normal direction looking straight at the primary face of the scope volume, there the camera transitions itself to parallel projection.
  • The result of this is you are now looking at what unmistakably appears to be a conventional drawing. And, of course TGN can support linking graphics here (see 7, below) from external graphics apps, or, from external HAND DRAWINGS (photographed).

(5) FILTERING (a):

  • When a viewer (or author) is engaged with a TGN rig, what elements of the model are shown within the scope volume can be controlled by the usual model-filtering methods.
  • These just tell the software which stuff to show and which to hide. Different criteria can be used.
  • Interesting thing about the TGN concept is that the show/hide filter can be activated continuously along the entire rig viewing path, OR, the filtering can change at different points along the path. You can use multiple different named MODEL FILTERS at different points along the viewing path.

(6) GRAPHICS STYLES (a):

  • You can do whatever you want with the style of model elements that you can see.
  • Use style strategically, to make things CLEAR, to show what you intend to show, to make yourself and others understand what’s going on.
  • As with filters, these graphics styles can change at different points along the viewing path. The rig author controls this. Viewers of the rig experience this the way the author set it up, as with filtering.

(7) EXTRA GRAPHICS (a):

  • You add any graphics you want, to what’s shown of the model according to the conditions set in 1 through 6.
  • So, you can add whatever non-model graphics that help you make clear what’s being shown and what matters.
  • You can add lines, shapes, curves, notes, dimensions, whatever.
  • Also interesting that these graphics can be added anywhere along the TGN rig viewing path.
  • TGN can support linking graphics from external graphics apps, or, from external HAND DRAWINGS (photographed).
  • Note that extra graphics may be authored within TGN rigs either by using graphics tools native to the modeling app, or optionally, by linking graphics authored in graphics apps external to the modeler, or both.
  • No matter the source (native to modeler, or linked external graphics), extra graphics are handled by TGN OPEN CODE such that they ‘sink’ down to an open standard graphics format (likely SVG) within each TGN rig in support of graphics fidelity when TGN VCS rigs are shared from one modeler to another, among all modelers that implement TGN OPEN CODE.
  • Graphics sourcing, inclusion in rigs, transformation, portability, and development strategies are discussed further in an upcoming article to be inserted here soon.

(8) PORTABILITY (a):

  • The entire package of features above is designed to be portable to other modeling apps. So, you can create these rigs in one modeling software, and share them to people using other modeling software.
  • The receiver gets what you authored with graphical fidelity intact at least to the minimum standard defined by the OPEN TGN standard.

You may have noticed that these 8 features are characteristic of technical drawing in its conventional centuries-old form

The features with the suffix (a) are embodied directly within the medium of drawing. The features denoted (b) are characteristic of drawing but not embodied in the drawing medium. Rather, (b) are aspects of cognitive processing concomitant with human perception and the activity of viewing and interpreting the drawing medium.

With TGN, a and b are embedded within the digital model.

The TGN concept is not confined only to these eight features.

TGN is a minimum set of just the right features that get seeing and thinking and clarifying started, and that together can become an open standard of a minimum set of features that do this. It’s easy to imagine adding more features to AFR (attention-focusing rigs) implementations in any software. I described 19 or so possible features in the specifications linked below.

SPECIFICATION

I wrote a developer specification (free, of course and open source), twice, first in 2018 and updated in 2021. The spec includes detailed description of the 8 TGN OPEN CORE features, plus a dozen or so related features, among many other possible features beyond the proposed, shared, standardizable TGN OPEN CORE feature set.

TGN developer specification
Download:

TGN: a digital model INTERACTIONS format standard (Apple Book)

TGN: a digital model INTERACTIONS format standard (ePub)

TGN: a digital model INTERACTIONS format standard (PDF)

DEMO:

Some partial demo in a mockup here:

https://www.youtube.com/watch?list=PLAiyamA5WoZZOMO8TGQl3UAjpTHOyKruF&v=GjQIF83X4OQ

More demo at this playlist.

THE CODE TRANSFORMATION LAYER:

Consider for example, TGN features 5 and 7.

Model FILTERING (5) is implemented by methods unique in every modeling software.

But the filtering product is always the same: a list of GUIDS.

The proposed TGN Open Code accounts for method differences in each modeling app, and the distinction between method and product. Unique feature methods, for TGN core features 1 through 8, are reconciled through a code transformation layer that transforms the product, no matter the method, down into a standardization layer (TGN OPEN CODE) to deliver a TGN package that’s recognizable in other apps that implement TGN OPEN CODE.

This way, TGN rigs are portable from app to app, with graphics fidelity intact at least to the minimum standard defined by the TGN OPEN CODE.

Extra Graphics (7)
Another example, feature 7, extra graphics, no matter the methods your app uses to produce/automate or manually enable any kind of extra (non-model) graphics (lines, curves, text, labels, notes, dimensions, shapes, stylized graphics…), whatever you do, however you do it, and whether you link external graphics from other apps or not, these graphics need to sink down through a transformation layer to SVG format graphics. That may introduce some limitations. But at least you maintain control over the minimum required aspects of extra graphics, with these surviving transport as TGN rigs are shared from one modeling app to another.

At the same time, you can extend and do more than the minimum in your app, with extra graphics as you wish. TGN is designed to support the best of both standardization and unlimited freedom of graphical expression.

OVERALL SCOPE OF THE TGN PROJECT:

(download to pan and zoom in your image viewer)

https://tangerinefocusdotcom.files.wordpress.com/2023/07/tgn-package-and-transform-2.png

Features that exist in all modeling software, are packaged together and transformed into an equivalent, defined in an open standard for portability to other modeling apps that implement TGN OPEN CODE.

SIMPLE IDEA / SIMPLE SOFTWARE IMPLEMENTATION:

  1. all the software features proposed for TGN functionality already exist in all modeling apps (more or less).
  2. Existing features are transformed through a code transformation layer to TGN OPEN CODE, so TGN rigs created in one modeler can be shared to other modelers.
  3. TGN OPEN CODE is an open standard definition of each of the 8 features. The pioneering developer community can discuss, develop, and define the standard, and push it forward into Apache or some other open source house.

App developers will tune the transformation code layer (2) to fit their apps individually, matching TGN OPEN CODE features to equivalent features in their own apps.

TGN is about packaging existing features together for coherent function, plus code standardization for portability.

Leave a comment