TriForma is locking files...

Mike

If I remember correctly it isn't the file that is locked, it is the TFelements. And I think keyin TFREMOVE from Triforma makes them editable in ustn - but lost for further use in TF/BA.

But what use of a changed 3d-model do you have if you can't run new DEM "calculations"?

Bear point to an important thing > for 8,5 (and 8,9?) you can load Triforma as a "engeneering configuration" and have edit rights to TF forms and run DEM calcs. Not sure if this works all the way, but may be worth investigating.

Also isn't there a license schema  that allow you to run different product at different times.

Unknown said:

If I remember correctly it isn't the file that is locked, it is the TFelements. And I think keyin TFREMOVE from Triforma makes them editable in ustn - but lost for further use in TF/BA.

Correct.  The file itself is just like any other file, it's the elements themselves that contain the dependencies.   So if you place MicroStation elements while in a Building product, those elements should behave as though they were placed using plain MicroStation.

Regarding TFREMOVE, that's also correct.  It strips off the building intelligence, which includes things like part & family, DG data, as well as the dependencies.  In some cases you may have to use the keyin multiple times if there are nested cells.   Good for making "MicroStation-able" files, but not so good if those elements need to be reused as building data!

Unknown said:

If I remember correctly it isn't the file that is locked, it is the TFelements. And I think keyin TFREMOVE from Triforma makes them editable in ustn - but lost for further use in TF/BA.

Correct.  The file itself is just like any other file, it's the elements themselves that contain the dependencies.   So if you place MicroStation elements while in a Building product, those elements should behave as though they were placed using plain MicroStation.

Regarding TFREMOVE, that's also correct.  It strips off the building intelligence, which includes things like part & family, DG data, as well as the dependencies.  In some cases you may have to use the keyin multiple times if there are nested cells.   Good for making "MicroStation-able" files, but not so good if those elements need to be reused as building data!

Sounds like there should be a middle way whereby the BIM data can be 'cocooned' for hibernation and the 'part and family' info retained for DEM or BV's ?

Editable i-models that contain components or items? Can Element Templates be used to control symbology in lieu of the 'parts and family' dataset? Or maybe something like Bentley Map's XFM? This would streamline things a bit.

The question of dependencies is interesting. What kind of dependencies do the BIM elements have? Are these just callbacks that wake up the associated BA tool? There will be links back to the dataset (part and family) and DG attached attribute database. I guess there will also be some inter part links ? The 2d/3d bridge stuff comes to mind.

I suppose once the BIM data is exported to a spreadsheet, then the vanilla Mstn users could then just do the updates normally. I guess this has the advantage of understandability and not having to pay and train users for BA.

I don't think this is a question about changing TF or ustn.

I think Mike has to look at how they organize work, people and their licensing. Of course I don't know, but it sounds really weired.

Hello

Seems the original question has been sort of answered.

Though (apologies Bear!) ........"The reality is that have 2 groups working on different approaches just doesn't work. " ......... I can't agree ....... I'm afraid that we pretty much have to ...... certainly from my experiences (which is in architecture rather than civils or engineering) ...... the overall standard of Microstation aptitude is pretty low (75% of them are still struggling .... a lot ... with plain vanilla 2D CAD)

When you have a team of 15-20 architects, there is no way you are going to be able to migrate the whole team to a BIM workflow (even on projects where they claim, in various magazines, to have carried out a BIM project, the reality is that most of the team were NOT doing BIM) ...... so you might be able to get 3-4 people using BA and the rest will still be using standard Microstation.

Exchanging info between BA and Microstation is still potentially quite confusing and is an area that Bentley need to work on. I think it's totally unrealistic to expect that architectural practices are going to move from Microstation to BA en mass in one big "upgrade". You would probably have a handful of people starting to use BA in certain situations, whilst the rest of them are still using Microstation.

Though we'd all like to see BIM taking off ..... rather than just staggering along ... the reality is that for many years yet there will be a considerable number of designers that will just need/want to quickly move around building elements/geometry (quick being the operative term here!) without having the need (or complexity) of having the geometry linked to all sorts of other information (why do you think SketchUp took off so quickly?). This info (potential changes to the design) then needs to be feed back to the 'full BIM model".

Anyway, rant over for now, I welcome your comments

Hi Danny,

I agree that it will be difficult to get the traditional 2d users to 3d. But, I think the question is whether BIM has to be accessed thru the 3d model all the time? BIM is about information, whether it's in door schedules, specs, photos, material samples or 2d production info drawings.

SS3 is supposed to enable a 2d/3d mixed mode working using DV's. I think that this should help ease 2d users transitioning to 3d working. DV's I think will replace the old 2d/3d bridge work flow, which was intended to allow 'traditional' manipulation of 2d representations of 3d objects that are 'cut' in the drawing section plane. Your old skool users can draw as normal in 2d and ref the 3d model and see/activate/modify the 3d model, and vice versa in comfort.. with a bit of luck.

Hopefully, BV's will subsume DEM, and will be production ready soon for all verticals, so that all teams can reference each others drawings with the correct symbology / rules processing. I think it would make a lot of sense to make the drawing rules stuff a platform technology. It is a logical extension of DV's and needs to be pretty pervasive if we are to be able to reference across disciplines (and there are so many if you include mapping/GIS, civils, plant etc). Family and parts are overdue for a big revamp, IMHO. Something feature based like XFM seems much more promising.

Your experience of non-BIM working outweighing a small core of 3d specialists rings true, and highlights the need to keep 2d and 3d information coordinated as long as possible. The old BIM way of thinking relied on a 'single source of truth', usually a 3d model, that 2d drawings are extracted from, and annotated as a 'formality' using dims, hatches, notes to communicate the what is already in the 3d model. This ignored reality and we find that, actually, the bulk of the info is in the 2d / non-3d info, hacked in by the office grey beards and not the younger 3d experts. Bentley is starting to understand this, looking at Bhupinder's Be Conference keynote.

Dependencies: I guess BA is still your best bet if you want to coordinate your scheduled data like quantities, door info etc. I think DG can do much better, and sympathise with anyone who need to learn it now, but I guess that's changing as well.

The way the TF tools work in 2d section cuts (DV or BV) also need work, especially if we want to make the transition easier. 3d tools should recognise 'cut edges' of 3d elements as faces and be able to modify them accordingly, for example. I won't even get into what GC BIM elements needs to make adoption less like 'staggering along'.

Dominic

Unknown said:

Exchanging info between BA and Microstation is still potentially quite confusing and is an area that Bentley need to work on. I think it's totally unrealistic to expect that architectural practices are going to move from Microstation to BA en mass in one big "upgrade".

I would hazard a guess that some companies wont go from MicroSation to BA, as they are more than likely to migrate to Revit. Especially as Revit is more 'user friendly' at the moment, and by the time Bentley sort this BA problem out it will be too late.