Some exciting announcements made at YII22 this week. Listening to KB's presentation, 78:55 in, the iTwin engine will be offering up a lot more capabilities to Mstn in all phases : 'input', 'operation' and 'output' (Duh.. pretty much everything, then?)... starting next year, Mstn U19? Now that the Bentley Infrastructure Cloud avant guard is safely launched and out of the way, its time to bring up the rest of the troops? Good move that would help avert a Bentley version of the Revit letters?
The investment in iTwins, advanced interop ie 'openness' etc had to happen. Mstn as CAD users need to break out of the Tron-universe and operate in the messy User ie real world. Need to get more context and data-centric BIM and not only CAD drawing production-centric. All the other major vendors are doing the same thing... but like a lot of 'Next Big Things' a lot of stuff won't actually get traction or are too 'far ahead of its time' regardless of how great the tech is.
Bentley has the added problem where a lot of the interop stuff is already being addressed within the Bentley stable of apps... which are still struggling under its Open X, companions apps etc efforts. When will GC be implemented by all Mstn verticals, for example? Sure, maybe the demand is not there or has already left having voted with their feet?
I suppose that Connect Services is the new 'viral membrane' for tunneling between the new iTwin cloud and old Mstn desktop universes. ProjectWise was bigged up, and already manages 3d models in addition to the old 2d drawing staple. Sure, now that Item Types are now part of dgns, you will be able to index and mine all those drawings etc in additon to 3d dgns as well as any imodels... which can already be Ref attached and leveraged in your Mstn file-based workflows. OpenPlant, Bentley Map, Bentley Facilities Manager are already using Items, schemas extensively. OP's PlantSight also offers data-centric component <> file-based workflows that integrate dgns. Bentley should have a big lead on Autodesk, Trimble etc here.
Not sure, but:
'Input' sounds like Mstn users will be able to get a lot more use out of referenced 'imodels' via iTwins investment in Connectors / Bridges to other formats. In many ways Connectors are enhanced ISM repositories that will automate and enhance format translations. Nice one!
'Operation' sounds like Mstn users will be able to query elements at a granular level to find out who is working on the element, leave notes, isolate work areas etc. Sounds like OpenPlant's Component Mode is coming to Mstn / platform level. Great! Should kick Revit's clunky Worksharing, element borrowing, synch-to-central butt.
'Output' sounds like Mstn will get an 'imodel' mode, where Mstn will write to directly to imodels, not just dgn or dwg. This is big!
Hi,
This is a bit disheartening to me... I'm still looking for the basics of Microstation CE to work correctly. Instead of fixing things that fail every day, Bentley is adding new features that don't help us. They need to get the core program working before making all these enhancements.
--Robert Arnold
dominic SEAH said: I would not underestimate the number of fee-paying "customers that are not explicitly planning to deliver digital twins" that just want faster bug fixes. As mentioned: "The move to build in automated/parallel iModel creation perhaps indicates that previous innovative work at Bentley has failed to gain traction, in an industry that can be notoriously slow to adopt new technology." A reference to OpenPlant's ModelServer, ISM, imodel v1 etc? Yes, "Drawings are stupid and the goal of BIM is to automate drawing creation" But, that does not mean that producing drawings will disappear.
I would not underestimate the number of fee-paying "customers that are not explicitly planning to deliver digital twins" that just want faster bug fixes. As mentioned:
"The move to build in automated/parallel iModel creation perhaps indicates that previous innovative work at Bentley has failed to gain traction, in an industry that can be notoriously slow to adopt new technology." A reference to OpenPlant's ModelServer, ISM, imodel v1 etc?
Yes, "Drawings are stupid and the goal of BIM is to automate drawing creation" But, that does not mean that producing drawings will disappear.
I am in an industry that I suspect will take a LONG time to adapt to new technology (Civil/transportation), and for which Bentley's innovation in other areas will not make up for issues with drawing production. Design models are great, but the actual production of project plans is...There are a lot of potential automations that are not practical at this point in the development. There are also far too many bugs and regressions still happening.
Our DOT is going to want plan sets for the foreseeable future. While there are some DOTs that seem prepared to accept digital models in addition to plan sets, there are plenty that seem to have no interest at this stage. "Customers that are not explicitly planning to deliver digital twins indeed"!
MaryB
Power GeoPak 08.11.09.918Power InRoads 08.11.09.918OpenRoads Designer 2021 R2
"The iModel tells you when someone else just changed something that affected the thing you’re working on. So we can start improving the process of creating the data, even though the master copy is still a DGN file. "
I think these 'improvements' will eventually need mods to the code at tool level. But it would be good to prioritise key road blocks in Mstn. I would not underestimate the number of fee-paying "customers that are not explicitly planning to deliver digital twins" that just want faster bug fixes. As mentioned:
Yes, "Drawings are stupid and the goal of BIM is to automate drawing creation" But, that does not mean that producing drawings will disappear. Or that Mstn is very good at producing them. There are still a lot of gaps in Mstn's tool line up and drawings will still at the core of any deliverables for the foreseeable future. I would say that this is the primary reason Mstn has been displaced by Revit, which has been unashamedly about efficiently producing drawings using a 'model-based solutions' from the start. No hope of reclaiming these lost accounts without good drawing production tools. Ditto for any aspirations for 'new names' in the SME market.
Here, imodels don't seem to be the battlefield at all. This needs to be tackled on the dgn side. Sure, at some point when all of Mstn's code is imodel mode, drawing production could go to the next level with innovations like AI. Swapp.net for example is betting the farm on AI to generate 'dumb' drawings. Swapp.net Connector coming soon?
As 3d modelers are starting to work in a wider non-CAD geometry context, immersed in laser/photo scans, 2d modelers will also need to work in context with the old 2d print and GIS world... through an AI lens. In a Digital Twin, it's all just info, some bits may be 'dumber' than others.
What would be useful and work with 'real' projects?
"When we start giving them ways that they can be more productive, add more value, they’ll wish for a digital twin."
Agreed. But, it would be good to start by prioritising iTwins functionality that can help address key road blocks or weaknesses in Mstn. Could iTwins provide the 'microservices' to Mstn that address the longstanding lack of:
"Today, the way it works in the demos that we’ve been showing at YII, with our iTwin format, customers change the data on their desktop, they push that up to the cloud, where we run a copy of a programme that effectively mirrors MicroStation in the cloud and it updates the iModel in the cloud."
Mstn Cloud Edition beta available? Nice! Complete with solid modeling and constraints and GC support? It would be good to target fresh markets where Bentley has no or little legacy dgn-based tools: Look for new promising startups for landscape architecture, urban design, real estate, factories, and err.. architecture?
More clues and hints in this interview with KB.
Mark Shamoun said:key to this being implemented in a way that actually works with "real" project delivery and workflows.
Yes, I think that this will be hugely important as it will divert dev and debugging resources away from ongoing problems and gaps. Not as if dev pace is very rapid as it is for a flagship product.
Yea, this the $64m question. Reading the interview, its clear that the long term goal is to replace dgn and go imodel.
Step 1: It sounds like the existing Connectors -which are essentially conversion tools which require cloud services- will be modfied for the desktop. Sort like a ProjectWise Local Document Organizer that manages the synchs between the locally cached imodels with the imodelHub in the cloud?
Step 2: Mstn is famous for incrementally saving to the file. It would make sense to embed the Connector in Mstn's memory space to speed things up. Mstn's Design History should be the focus here?
It would essential to support fast incremental updates like this old AutoPlant Design Synch example. Today, Navigator would be running off an imodel in web browser as Connect Service Design Review session. I can see users used to similar 'side-by-side' workflows popularised by Revit-Enscape welcoming the productivity that comes real time feedback.
Reatime delta updates would also help extend Mstn's big file scalability. At the moment, imodels in a browser can handle much larger files, being based on a streaming file format. Apparently the same HLOD tech is available to imodels that are ref attached, but not dgns. I can see a lot of users Ref attaching imodels in lieu of dgns as a standard worklow for large projects. The active model would remain dgn to enable Mstn's tools to write to it as usual. It would be good to support this kind of hybrid working in Mstn Ref dialog, by transparently swapping between the two formats?
Step 3: But DH is mainly about Mstn geometry. For non-geometric attribute business info, Item Types come to mind. Apparently BIS is the next gen version of EC Frameworks which has been slowly exposed in the Mstn CE API... that is better than the tools that OpenPlant, Bentley Map, OpenRoads, Bentley Facilities Planner etc are built on? If imodels are based on SQLite, then maybe all of Mstn's Items code should save in parallel to the 'shadow' imodel. Verticals like OpenFlows already embed an SQLite database could eventually transfer the database across. It would be good to enable transparent queries from Mstn w/o needing to manually synch to the imodel.
Buildingsmart 2022 Emerging Data Design Patterns 2.
"Over time, the iModel part of it grows and the DGN part of it shrinks, and by the time we are done, you’ve gone through the transition and you are only working on iModels."
This would also open the way for anyone who has written apps using iTwins.js or other platforms to process the imodel info. Again, I can see a lot of 'side by side' working with Mstn and browser open, in the interim. Automation: User calling VBA macros in Mstn, and java or python scripts found on the internet in the browser?
"Maybe it’s in a separate window, but wouldn’t it be really cool if we then start adding some new capabilities that are in the iModel part of it?"
Even better, if the 'browser window' is actually a window inside Mstn. Kind of like a Bentley version of Rhino.Inside or Spekle? GC / Bentley Scenario Services re-written for Java VM? TypeScript?
Step 4: Cells, the smaller manifestation of dgns need to be better team players. Dgn = imodels => Cells = imodelets? Component Center would be the new Cell library? Cells have been very problematic within Mstn. Troubles with accessing and manipulation nested elements seem to be intrinsic to the current implementation, with users having to 'flatten' any assemblies using 3rd party apps etc.
If the imodels are in a database format like SQLite, it should be easier to tunnel in and make the changes? At least for the non-geometric Items type info? Mstn's Connector works in a uni-directional way, throwing Mstn info over the wall to the imodel. A bi-directional Connector would be far more useful. Precedent workflows: ConceptStation <> OpenRoads, OpenBuildings Edit in Excel mode? Rhino.Inside, Speckle?
Mark Shamoun said:We all know user feedback / consultation is key to this being implemented in a way that actually works with "real" project delivery and workflows.
You leave me with little hope...