TriForma

This month, in the third and final instalment of the “Planning the Upgrade” series, Whitby Bird and Partners present their findings on MicroStation TriForma v8.

Whitby Bird and Partner’s upgrade to MicroStation v8 is now underway. Our extensive testing, both under laboratory conditions and on live projects has proven the software to be both robust and more efficient for the design process than any other commercially available CAD software. However, MicroStation is not the only consideration. We employ a wide range of Bentley products, including a large proportion of seats of both PowerDraft and ProjectReview, neither of which are currently available in v8. There is also a considerable reliance on TriForma within the company now, which has prevented us from globally upgrading the complete CAD systems, without first undertaking the same investigative processes as we initially carried out with MicroStation.

It was important to understand the implications of the changes to the various flavours of TriForma utilised by Whitby Bird, namely Structural for TriForma, HVAC for TriForma, Architectural for TriForma and of course vanilla TriForma itself, in order to fully appreciate how our modelling workflow would be affected. To achieve this, we followed exactly the same protocol as with MicroStation, firstly testing off-line in a laboratory-type scenario, and then on a controlled live project. The following discoveries were made.

Installations

All CAD installations in Whitby Bird and Partners are based on network deployments to allow us better management and maintenance of multiple platforms and the various discipline-specific operations. When we carried out the initial isolated testing of v8 TriForma, we’d installed the software locally on our laptops to remove network factors from the equation. Rigorous testing demonstrated that the software was surprisingly stable for a first release. This gave us the confidence to start introducing shared network-based workspace components to gradually migrate to the true network installation. It wasn’t until we’d completed our own trials and attempted a full deployment on a standard workstation that we realised there was a fundamental problem in running TriForma from the network. TriForma v8 is closely inter-related with the Windows environment and without performing at least a minimal local installation necessary dll’s and xml handlers are not registered, preventing TriForma from functioning. Being reluctant to switch to local deployments because of the high level of management efficiency we have achieved, we settled on a compromise of installing the software locally to register the required components, removing the local executables and shortcuts, and continued to run TriForma v8 from the network in our traditional manner.

Configurations

A noticeable difference immediately is the variation of configuration management with TriForma v8. The development teams have taken the opportunity to re-think their approach to the ucf-based organisation providing application-level settings. We’d previously formatted v7 to operate in this manner, but the overhead of maintaining this configuration was not especially efficient due to having office-specific shortcuts and having to cut and paste the supplied ucfs and application cfgs into our own configuration files. V8 has solved this problem for us and has provided the additional benefit of now being able to run Architecture, Structural and HVAC together in the same session. 

Interfaces

After we’d installed TriForma v8, our first task was to copy across our existing data and interfaces from the v7 directories. It was at this simple stage that we encountered our first problem - there was no TriForma directory in Workspace\Interfaces. Strangely enough, these have now been moved to Program\TriForma\Interfaces, which is acceptable provided if you make any customisations, you remember to make backups of these files when re-installing the product! Why they are not supplied in their original locations is a mystery and contradictory to the whole Workspace ethos. 

Despite our initial discontent, our immediate impressions of the new interface configuration were positive. With the TriForma interface loading subsequently to the MicroStation one and transparently, we no longer require duplicated resource files for each application: a positive move which will hopefully be reflected as other applications port to v8. Once we had comprehended the configurations, we were able to begin our real investigations.

Our earlier experiences when testing MicroStation v8 revealed that only minor modifications were required in order to migrate our existing v7 interfaces, and so we came to expect the same of TriForma. The TriForma pull-down menu functions in a similar manner to MicroStation’s, that we had designed for working in 2d, aiding the user by setting the active level, colour, linestyle, line weight and in addition, the family and part to Whitby Bird CAD standards. Previous investigations had brought to our attention some changes in the key-in syntax due to the v8 enhancements, so when we noticed that the old key-ins for setting the active part no longer worked, it was obvious what the cause was. Establishing a solution was simply a case of contacting Select Support as the supplied documentation omitted most of the important key-in changes. Bentley has to improve the extent of their documentation to ensure it corresponds to the functionality provided in the version of software it relates to.

From our involvement in the development of TriForma since its inception it has become clear that one of the key obstacles for a MicroStation user’s confidence in TriForma is the constant re-organisation of tool frames. MicroStation/J had seen this settle to some extent, but now with v8, we are once again faced with the frustration of re-familiarising ourselves with the tool locations. In the long-term v8’s new layout strategy will probably be far more beneficial, but for now it’s one more stumbling block in the upgrade process. An example of the confusion this has caused was the apparent removal from the MicroStation Attributes Toolbar of the Set Active Part and Family fields. TriForma v8 now has a separate toolbar for these settings, but frustratingly it neither loads as default, nor is it named as we would expect. The toolbar from which it was removed was MicroStation Attributes tools; the new TriForma counterpart is TriForma Primary. Comparatively, MicroStation’s Primary toolbar contains “Models”, “Level Manager”, “AccuDraw” etc. and not the active element settings. 







The contents of the TriForma Primary toolbar are directly comparable with MicroStation’s Attributes toolbar and not its Primary.

There are redeeming features of this change. Firstly, that you no longer have to cope with tools shifting position in the Main toolbar when switching between MicroStation and TriForma as TriForma now has its own Main tool frame. Secondly, the addition of drop-down menus in the TriForma Primary toolbar to select Part/Active Symbology allows you to set the attributes of forms to either those active at the time or those defined as the active part’s default.

Datasets (XML)

We’d anticipated that upgrading our existing v7 dataset would not cause us too many problems, and at first, it seemed pretty straightforward. It appeared that all that was required was to allow TriForma to automatically convert the dataset to xml format before continuing to model. It wasn’t until we’d built three-quarters of our test project model that we came to realise that the dataset had in some way become corrupt and was causing problems with placement of TriForma forms. Elements were being placed on incorrect levels and could not be changed. On advice from Select Support, we recreated the dataset, which seemed to cure the problem. This was no real misfortune, as we were in the process of adopting the new AEC (UK) layer standards, which meant building a new dataset anyway. For those companies tied to an existing corporate standard or large dataset, it is crucial to test the integrity of the families and parts once converted to xml.

The one problem we did encounter once the dataset had been rebuilt, was that the workstations could not interpret the xml data. This was because the installations have historically been based on network deployments with minimal components locally installed. With the increased interaction between MicroStation v8 and Windows it has become necessary for us to move away from such a strict network deployment and have more of the application resident on every workstation. This does increase the support overhead, but there appear to be no other alternatives.

Previously our dataset management and revisions were conducted using Excel, whose spreadsheet and organisational capabilities allowed us to quickly and efficiently construct data externally to the TriForma environment. By simply cutting and pasting the Excel cells into the text-based Parts, Components and Families files, it was possible to import the data directly into MicroStation. With the advent of xml and its rigid organisational file structure, the link to Excel has become less fluid. We began to produce an Excel spreadsheet which was formatted in a manner that would allow us the same benefits, but shelved this work after being sent a test application from Bentley Systems, which automatically converted an xml file into Excel and vice-versa. This utility works very well and should be included as part of the TriForma core functionality.

Although we carried out the majority of dataset definition work within Excel, there were a few occasions when it was simpler to modify a part using the TriForma interface. In doing so, we discovered a flaw in the interaction between the dialogue boxes and the DGNlibs - it was only possible to select levels that physically existed in the active file. This is due to be resolved in the Q3 release. 



When defining a part’s default level through the TriForma interface, only the active dgn’s levels are selectable. 

One of our aspirations for TriForma v7 was to have the ability to perform unification across families within a dataset. Our previous dataset was structured to BS1192, and so the parts concrete wall and concrete slab were in different families. In order to perform unification between the two parts when generating sections, we had to create “dummy” unifier parts. When v8 was released, we’d hoped that this much-awaited improvement would be included, but to our disappointment, it wasn’t, although it is promised for the next major release. Also with strict access permissions to our company dataset directories, we have defined a hierarchical search path whereby project-specific parts may be created when necessary and co-exist with the office standard parts. A minor drawback of TriForma v8 is its inability to read two separate instances of the same family name, again relying on cross-family unification.

On the positive side, TriForma has provided a number of highly beneficial enhancements. The v8 file format has meant the removal of the previous limitation of form vertices, allowing far more complex elements to be created. The introduction of the Corus steelwork library and the asymmetrical, double-T and plate girders has greatly empowered Structural for TriForma.

V7 Workmode

To test TriForma v8 in a controlled live project scenario, we chose an existing project that had already been produced two-dimensionally in MicroStation/J. The intention was to use the original design files as 2d references from which the 3d model would be setout. When we tried to open these drawings to view them, we discovered that TriForma v8 does not support v7 workmode, therefore preventing us from doing so. Our immediate reaction was one of great concern, and so we contacted Bentley, who informed us that this had been intentional and that TriForma v8 will never support v7 workmode. Returning to our investigations into how this would affect Whitby Bird, we discovered that it would still be possible to attach v7 files as references to v8 TriForma models, but that any existing v7 TriForma models would have to be migrated to v8 in order to edit them. The ability to save a v8 file as v7 from TriForma has not been removed, although when doing this the application crashes out. The reason for this is that whenever doing a “save-as” in v8, the resulting file is always automatically opened. We found a work-round for this is to use the Batch Converter instead.



Our strategy for migrating existing projects to v8 was to leave all data in its original format to avoid any unnecessary disruption over and above the whole company trying to adopt new software. We have been forced to re-think this policy due to TriForma v8’s inability to even view v7 files. The problem is further compounded by the fact that several of our most prestigious (and largest) projects are v7-based. To take time out from an already tight project program to migrate all data is one thing, but without the ability to save as v7, we have to ensure that the rest of the design team upgrades concurrently in order to exchange information.

Text

In our attempts to write a platform-independent CAD standard for Whitby Bird and Partners it has been necessary wherever possible to maintain cross-compatibility with AutoCAD. One of the crucial aspects of accomplishing this is defining text styles with zero height, which is common practice when working in DWG format. Our use of text is based on the principle of a single text style any instance of which then has an independent height override. While this causes no discernable disadvantages in either MicroStation or Vanilla TriForma, in Structural for TriForma, it has raised some issues with drawing annotation. When defining a resymbolisation rule using a pre-defined text style, the text attributes fields become inactive, preventing overrides from being set. The reasoning behind this is understandable: text style height is multiplied according to the scale of the section. This is fine if the text style has a non-zero height, but in our case with a zero text height, we are unable to control annotation output.

DWG Output

We have already witnessed how well MicroStation v8 handles DWG exchange, so the burning question was how well would TriForma v8 solids interact with Architectural Desktop elements? There was no question that we would be unsuccessful in translating object attributes, but our previous experiences in 3d have highlighted certain geometric and solid/surface inconsistencies. To test compatibility, we built two models, one in TriForma, the other in Architectural Desktop, exchanged both via v8’s DWG capability, edited the resultant elements and round-tripped them back to their originating software. Despite our concerted efforts to break the files, we have been singularly unsuccessful and can only praise the robust nature of TriForma v8 and its DWG Workmode.

Drawing Extraction

So far, our expectations of TriForma v8 had been pretty much fulfilled, but for us the proof of the objectively modelled pudding would almost certainly be in the eating - section generation. We’d got to the point with v7 where we’d pretty much mastered the art of understanding the whole process and had learnt ways of achieving the desired results, even if this meant bypassing the “text-book” methods. 

The extremely powerful addition of Models in V8 has meant far more flexible model management, even though the term “Model” is one of the most confusing ever in a CAD system, especially when related to drawing extraction. We were greatly impressed by TriForma v8’s ability to output sections to either a single model (analogous to the old output to single file option), or output the .r, .f, .s etc to separate models within the same file. The only question that remains to be addressed from this, is of course how that translates to AutoCAD DWG format, which does not have multiple model capability. Technically, this has been addressed with the translation of non-default models to DWG blocks, although how this integrates with data exchange and reuse is yet to be witnessed. If creating section cuts within different models of the same file, the Drawing Extraction Manager now reports the source model from which each definition has originated. Superficially, this is exactly what you’d expect, but the added flexibility of model, revision and drawing management this provides exceeds the simplicity of initial impressions.



The Edit Drawing Definition dialogue box showing the benefits TriForma gains from the addition of Models.

As the use of TriForma within Whitby Bird has increased, we’ve become more focussed on further developing our CAD standards to cover the scope of 3d working. Our standard file naming convention had already been written with 3d modelling in mind, and users have been encouraged to employ this not only for naming 3d models, but also the sections generated from them. Although we’ve tried to restrict the naming convention to include only those fields necessary to the engineering environment, the average file name is still ten characters long. Until now, this has not caused us great problems - in fact if you compare it with the average Architectural model file name, it’s probably quite short! However, when we tried referencing extracted sections (written to separate Models) into other files, we couldn’t distinguish the .s from the .f. This was because the drop-down menu to select the required Model in the Attach Reference dialogue box was not wide enough to display the entire Model’s name.

Our experiences in structural modelling have revealed a long-standing problem in section generation: replicating the conventional representation of a rib slab. Traditionally, these were denoted on drawings as having a solid outline with dashed lines showing the vertices of the ribs below. When we modelled a rib slab in TriForma, the plan that was produced was not to this specification, the representation was too “literal”, showing every detail of the rib instead of only an illustrative silhouette. We had already identified this problem in v7 and had developed working methods to overcome it. The introduction of the Place Concrete T-beam in Structural for TriForma appeared to be the answer, although on testing, it would seem not. The results are no different to the more labour-intensive method of extruding a profile. Oh well, maybe next time… at least we got a new tool that helps us to create them quicker!

There are a number of enhancements, which while not ground-breaking have improved extraction management greatly. The ability to import and export section definitions increases efficiency particularly on larger, repetitive projects where information is still unavoidably duplicated. In Structural for TriForma, the inclusion of Excel-based reporting has made quantification far more effective. We have been so impressed by this, that we have developed the macros further to check steel member annotation and section sizes. This spreadsheet-based method should without a doubt be included in all flavours of TriForma.

AccuDraw & AccuSnap

V8’s enhanced element location utilities promised to offer improved performance within the 3d/TriForma environment. Tied -in with Structural for TriForma’s Flyover Snaps, AccuSnap should have realised this promise. The reality was unfortunately a little more disappointing. Using TriForma highlighted bugs with AccuDraw that had previously gone unnoticed. SmartLock, for example failed to function correctly in the z-axis when snapping a tentative point. The complexity of 3-dimensional elements requires a greater sensitivity than is offered by AccuSnap alone, leading us to revert to tentative snapping when trying to identify specific element surfaces. AccuSnap appeared to be completely dysfunctional with certain files - a bug that has since been identified in MicroStation. Despite appearing to be minor flaws, as work-rounds are available for all these issues, we are at a critical juncture with the widespread adoption of TriForma, so managing expectations is crucial. We felt the users’ methods would be so severely compromised that we have delayed the roll-out of TriForma v8 until these problems are suitably resolved.

Training

For experienced users of TriForma v7, the adoption of v8 has proven to be of minimal concern. The bulk of the changes within TriForma v8 have been made behind the scenes and once we, the CAD Development Team, had upgraded the datasets and configured the systems to our standards the users were left with little noticeable change to familiarise themselves with.

Where do we go from here?
Our testing of v8, TriForma and related applications is now complete. The full roll-out is now underway, migrating our teams slowly and carefully onto what we consider to be a revolutionary CAD package. It has already made considerable improvements to our working methods despite the predictable teething problems, and once the teams have familiarised themselves with all v8 has to offer we are convinced it will exceed even our expectations. We eagerly anticipate the release of Bentley Redline with its “Sketch” interface, replacing Project Review upon which Whitby Bird and Partners has become reliant. Preparations are already underway for upgrading to MicroStation 8.1 which promises to lead the industry with its digital signature and file security technologies. 

Bentley has excelled once again in producing yet another successful release of MicroStation which certainly hasn’t turned out to be their “Release 13”! If Autodesk remain their usual blasé selves and choose to ignore the impact v8 will have on the AEC industry, although it is unlikely their market share will noticeably reduce due to the high levels of investment already committed, they will without a doubt witness the rise of a true contender to their AutoCAD crown. V8 is not just a simple CAD system providing only DWG interoperability, but is a powerful and flexible platform with something to offer at all stages of the design and construction process. Why settle for less?

Related Links
www.the-e-shop.co.uk - .the-e-shop's website
www.whitbybird.com - Whitby Bird's website