Do 3D Graphics Need to be Near Global Origin/Do Solids Working Areas [SWA] Still Apply?

Forum,



[MS v8i Products]

Ive read many posts on Global Origin and Solids Working Area, and am none the wiser. Do 3D Graphics still need to be Near Global Origin of a file so that they fall within Solids Working Areas [SWA]? or is this not the case now, on v8i products anyhow

Som posts say yes,some say no. Others talk about GOs and moving them. Surely there is knowledge on this?

If i have a Project in the London area then the Origin of the survey grid, 0, is a long way away. KIf my Seed has been set with a true 0, does this matter or should the seed file be set up to have a Global Origin in the centre of the Project?

Additionally, I have played with moving the GO as a test but when i use GO=, Monument Point, Click a defined point, my GO changes for that session, but as soon as i exit an MS Session and reload that file, the GO is back to where it was. So i cant even test moving the GO!!

Parents
  • We always setup the project at the origin but redefine the origin using go= to be the real world OS coordinate. Programs like Revit, Rhino & Sketchup still need geometry to be near the origin.

  • i work on large infrastructure Porjects where the Seed is already set up, so i assume this is also theprocess for these, as were required to b aligned to Real World coordinates. Do does this compiund the 'distance from SWA' issue or is it not an issue?

  • i work on large infrastructure Porjects where the Seed is already set up

    Unfortunately, there are still a lot of large client CAD departments who do not set up their seed files correctly. We have been told by one client that if SWA is a problem with their seed file it is up to us to fix it.

    I think that some of the confusion stems from the fact that the seed files tend to be based on Mstn work and not Aecosim / Dynamic View restrictions which require higher precision. The recommendation is to use georeferencing. See Marc Thomas' blog which has recently updated info on SWA.

    Moving the GO does not help. Ideally the geometry needs to sit near the Design File Center.

    I have also seen some Brien Bastings posts on some Mstn solids being designed to have their own localised SWA awhile back. This does not appear to apply to all solids or Aecosim / Triforma Solids or DVs or Building View unification engine restrictions.

    Snakegrid is a separate thing, which I think you realise already. I don't really think is relevant for most users or applications. All building models will need to be in 'cartesian' space so that when you exchange/import survey info from those lasers etc it all coordinates... as a default. All that warping to generate a unified linewide coordinate system is only useful for the railway systems guys. Apparently, you can't even warp all of Mstn's 3d elements anyway so it's a bit of a distraction.

  • Unfortunately, there are still a lot of large client CAD departments who do not set up their seed files correctly. We have been told by one client that if SWA is a problem with their seed file it is up to us to fix it.


    Is there a difference between MS work and AC work, thus should seed files be differetn dependant on this?

    I think that some of the confusion stems from the fact that the seed files tend to be based on Mstn work and not Aecosim / Dynamic View restrictions which require higher precision. The recommendation is to use georeferencing. See Marc Thomas' blog which has recently updated info on SWA.


    Do you have a link to Mark Thomas Blog?

    I have also seen some Brien Bastings posts on some Mstn solids being designed to have their own localised SWA awhile back. This does not appear to apply to all solids or Aecosim / Triforma Solids or DVs or Building View unification engine restrictions.

    Do we know which Solid types this does apply to, and can we see this in Information with DGN? Useful as we have to continually work across AECOSim to Microstation SS3 and it causes many issues. [im aware SS3 is old tech and out of support but thats what the client uses so we have to use it]

    Snakegrid is a separate thing, which I think you realise already. I don't really think is relevant for most users or applications. All building models will need to be in 'cartesian' space so that when you exchange/import survey info from those lasers etc it all coordinates... as a default. All that warping to generate a unified linewide coordinate system is only useful for the railway systems guys. Apparently, you can't even warp all of Mstn's 3d elements anyway so it's a bit of a distraction.

    Yes SG has other issues and yes the warping on items which cant be warped is a continuing battle: BSplines, Solids, Surfaces, all the import items. We might  want to park that conversation as thats a whiole other forum and can be discounted here

  • Is there a difference between MS work and AC work, thus should seed files be differetn dependant on this?

    Yes, I think that is the recommendation from Bentley.

    Do you have a link to Mark Thomas Blog?

    https://communities.bentley.com/other/old_site_member_blogs/peer_blogs/b/marc_thomass_blog/posts/series-index-setting-up-in-the-real-world

    Do we know which Solid types this does apply to, and can we see this in Information with DGN? Useful as we have to continually work across AECOSim to Microstation SS3 and it causes many issues. [im aware SS3 is old tech and out of support but thats what the client uses so we have to use it]

    I think that Feature Solids were one. There should be more info in the blog above.

    We might  want to park that conversation as thats a whiole other forum and can be discounted here

    Yup. Agreed.

  • Reading the Blogs... thank you.

    What happens when the Project is AECOSim but then needs input from a Bentley bolt on package which uses an oler Microstation version? Were experiencing issues here and have no idea why.

    Any ideas on if I have a Project which is AECOSim driven, where the UOR is10000/m giving a SWA of 429km, would this be causing issues? In addition Solids are modelled in their real world coordinate [London area] and the 0,0 of file is 0,0 realworld coordinate?

    Possibly too late to change now but would be interesting to note the proper set up. Im assuming:

    UOR 1000/mm creating an SWA of 4.29km
    a GCS set near Project centre and related back to Real World Coords for 3rd party data referencing and Project Coords,
    Where Project Worksite is approaching a 4.29 size, consider breaking project into multiple Sites
    No Solids larger than the 4.29km


  • Were experiencing issues here and have no idea why.

    Wnat kind of issues?

    Any ideas on if I have a Project which is AECOSim driven, where the UOR is10000/m giving a SWA of 429km, would this be causing issues?

    Yes. We have had problems with Aecosim V8i. Also, BBES has a lot of problems with the larger 429km.

    Solids are modelled in their real world coordinate [London area] and the 0,0 of file is 0,0 realworld coordinate?

    The 'real world' coordinates can be produced by changing the GO but the modeling shoud be within the recommended range "Do not model more than  5,000,000,000 UOR away from Design File Centre." See Marc's blog.

    a GCS set near Project centre

    Don't think that the GCS is required to be near the Project Centre.

    Where Project Worksite is approaching a 4.29 size, consider breaking project into multiple Sites

    Yes. I tthink that this would be advisable. Even if there were not solids issues, I've heard that V8i's DEM moves the elements to the DFC before extracting the 2d graphics which leads to even slower processing. Not sure if DV's do this as well, but I wouldn't be surprised.

    No Solids larger than the 4.29km

    Yes.

    As mentioned elsewhere: in this age of the Digital Twin, Mstn users should be starting from a geolocated context from the get go.

    It would be great if Bentley could provide a 'New Seed File' wizard that utilises Bing or Google Maps so that this kind problems can be nipped in the bud.

    One of the main reasons Aecosim had been losing market share is its pretty bad DEM drawing extraction tools. Dynamic Views has been introduced going on a decade ago but is still struggling to match what is available elsewhere in terms of ease of use, quality and RELIABILITY. When SWA problems start impacting $drawing production$ I think it is a much more serious problem compared to some solids commands not working.

Reply
  • Were experiencing issues here and have no idea why.

    Wnat kind of issues?

    Any ideas on if I have a Project which is AECOSim driven, where the UOR is10000/m giving a SWA of 429km, would this be causing issues?

    Yes. We have had problems with Aecosim V8i. Also, BBES has a lot of problems with the larger 429km.

    Solids are modelled in their real world coordinate [London area] and the 0,0 of file is 0,0 realworld coordinate?

    The 'real world' coordinates can be produced by changing the GO but the modeling shoud be within the recommended range "Do not model more than  5,000,000,000 UOR away from Design File Centre." See Marc's blog.

    a GCS set near Project centre

    Don't think that the GCS is required to be near the Project Centre.

    Where Project Worksite is approaching a 4.29 size, consider breaking project into multiple Sites

    Yes. I tthink that this would be advisable. Even if there were not solids issues, I've heard that V8i's DEM moves the elements to the DFC before extracting the 2d graphics which leads to even slower processing. Not sure if DV's do this as well, but I wouldn't be surprised.

    No Solids larger than the 4.29km

    Yes.

    As mentioned elsewhere: in this age of the Digital Twin, Mstn users should be starting from a geolocated context from the get go.

    It would be great if Bentley could provide a 'New Seed File' wizard that utilises Bing or Google Maps so that this kind problems can be nipped in the bud.

    One of the main reasons Aecosim had been losing market share is its pretty bad DEM drawing extraction tools. Dynamic Views has been introduced going on a decade ago but is still struggling to match what is available elsewhere in terms of ease of use, quality and RELIABILITY. When SWA problems start impacting $drawing production$ I think it is a much more serious problem compared to some solids commands not working.

Children
  • Wnat kind of issues?

    Very slow screen updates,
    Frequent crashing of models where not near the maximium memory usage,
    Crashing of signal sighting software which runs on Micriostation SS3 after Project solids built in AECOsim,
    Behaviour of solids in Signal Sighting as they sometimes show and sometimes dont, also some complete solids show only in part


    Yes. We have had problems with Aecosim V8i. Also, BBES has a lot of problems with the larger 429km.

    BBES?

    As mentioned elsewhere: in this age of the Digital Twin, Mstn users should be starting from a geolocated context from the get go.

    Everything i do and manager, i force Geolocation. i have for all the years ive been doing this as it always works out easier.

    It would be great if Bentley could provide a 'New Seed File' wizard that utilises Bing or Google Maps so that this kind problems can be nipped in the bud.

    Most Projects i work on these days provide generic seeds and fail to set them up at all. By the time we get to use any Project data, the Project is in full swing and its too late to be able to do anything

  • Very slow screen updates,

    Hmmm... it would be good to hear from Bentley about what the effects are. The display system also seems to be affected by remoteness from the DFC (jaggies) but not as acutely.

    Frequent crashing of models where not near the maximium memory usage,

    Not sure if this would be down to SWA when just displaying the model. Depends on the size of your models. It could just be a 32bit, max 3GB memory problem. But I suspect when generating drawings, the SWA would be a factor due to the need to transfer the model closer to the DFC.

    Crashing of signal sighting software which runs on Micriostation SS3 after Project solids built in AECOsim,
    Behaviour of solids in Signal Sighting as they sometimes show and sometimes dont, also some complete solids show only

    Is your Signal Sighting app a Bentley product? The V8i Mech and Electrical components are prone to problems put down to SWA issues.

    BBES?

    BBES: Bentley Building Electrical Systems. The electrical addon to Aecosim.

    By the time we get to use any Project data, the Project is in full swing and its too late to be able to do anything

    You can correct the resolution using VBAs etc which Bentley can provide. The problem is the disruption that this will cause in a production environment. And they will want to bill you !

    Everything i do and manager, i force Geolocation. i have for all the years ive been doing this as it always works out easier.

    Geolocation is not always necessary. The GO can be outside the SWA so that your coordinates report correctly. Then all your client needs to do is use Coincident World when referencing. I think the problem is a lot of them probably think that they don't need to bother when they can just make the extents large enough to cover their area of operations.

    PS: Not sure what happens when the user activates a Ref. Do the calcs use the activated Ref's SWA or the host file's SWA? Maybe Brien B can confirm?

  • Maybe Brien B can confirm?

    if you want to mention someone on a Forum, use @Name. is more visible than Brien B.

    When you type @ followed by the first few letters of the person's name, the Forum software starts a lookup.  You have to be patient. 

     
    Regards, Jon Summers
    LA Solutions