Does anyone have a Solid Working Area file that works in CE ie SWA.ma
Ian
Ian Lapper said:Solid Working Area
What does SWA.ma do for MicroStation V8?
Regards, Jon Summers LA Solutions
Hi Jon
It places a temporary 3d cude that is the size of the solid working area, so you can see if your data is outside it or not. once loaded you then unload it
I'm happy with a project cube. That would be an easier concept to explain to users.
Brien Bastings said:If some operation still exists that is discovered to be coded to require solids all be inside a SWA size cube centered at 0,0,0, a defect needs to be filed and it needs to be corrected.
If ????
Brien,
Please do us a big favour and ask your colleagues over at ABD (for that matter, the platform DV team) whether their code needs solids etc to be within the SWA centred at 0,0,0 uors to work properly.
You seem to be just talking about your own code, but disowning the rest of your fellow coders at Bentley.... which is not really helpful.
The fact that the ABD team felt it necessary to provide a visual SWA tool is telling.
ABD recommendation:
"Where to Model?
How near is ‘near’ to the Design File Centre?
A good guide is:
The UOR is the critical factor."
"However, for any solid elements modelled beyond the SWA, MicroStation and ABD behind the scenes mathematically translate and scale them to a location near the centre of the SWA, store that transformation, perform the required operations, then transform the modified elements back to their original position and size. This is known as the floating SWA approach."
"The Electrical tools require the default 1000/mm resolution so never change the resolution used for any electrical files."
"If you need to model complete elements larger than the default SWA in extent, the SWA can be increased in project seed files.
However our recommendation would be to break the elements down to smaller units."
All superseded now in Connect?
dominic SEAH said:
> I have spoken to them as I've previously mentioned. I am hopeful that after the recent internal discussions on this SWA app they take the correct steps and end the confusion on this issue.
> No, I am talking about the V8 file format and what the rules for BReps are. A solid that is created/placed in plain MicroStation (ex. Parametric solid) and considered valid can not be declared invalid by ABD.
> This is a good guideline for keeping uor values small. The reason for this is double precision floating point limitations, not the SWA.
> I doubt the electrical tools use the solids kernel at all, this recommendation also has nothing to do with the SWA. If this is still being recommended, I'd be inclined to follow this guideline.
> Nothing wrong with this either. If you need to create a single solid 2 km across (I don't know what that would be), the SWA would need to be larger than 2 km. If you have 2 solids, each 3 m across, that are 2 km apart, the SWA can remain the recommended default of 1 km.
HTH
-B
Brien Bastings said:> I have spoken to them as I've previously mentioned. I am hopeful that after the recent internal discussions on this SWA app they take the correct steps and end the confusion on this issue.
You are not answering the question. Yes: Aecosim's TF solids etc and Building Views do not require to be within the recommended SWA (4.29km) at 0,0,0 uors. No: you have not checked and it is down to the ABD team 'to discover' if there is 'defective' code.
Maybe the ABD team should rename the SWA tools to be the Aecosim Solids Working Area to avoid 'confusion'. This would be treating the symptom and not the disease. But, I suppose, a first step.
Brien Bastings said:> No, I am talking about the V8 file format and what the rules for BReps are. A solid that is created/placed in plain MicroStation (ex. Parametric solid) and considered valid can not be declared invalid by ABD.
Not sure how ABD would 'invalidate' a Mstn solid, but what we have problems with is to do with the quality of the DV/ BV Visible Edges extractions. These processes require 'hidden line' calculations that require the intersections, splitting elements based on whether they are obscured and unification (BV). The DV/BV either crashes or produces defective results. The advice we are getting is that everything has to be within the SWA and near the DFC etc. See link above.
Yes: you or someone on the DV team has confirmed the VE code can handle all solids etc (not just a few simple slabs) properly.
No: it's an optional extra that hasn't been addressed... yet
Brien Bastings said:> This is a good guideline for keeping uor values small. The reason for this is double precision floating point limitations, not the SWA.
This is not good enough. We need to know what the maximum 'SWA' is. Please note the ABD recommendation that all files use the same precision / SWA settings. This would mean that all those civils and landscaping files outside the station or fixed asset would have to be split up a lot more if they need to be referenced in for DV/BV production, for example. And even then I doubt it would be possible to ensure that the civils/landscaping solids will be within 5km of the DFC... which would result in some kind of dodgy 'floating SWA' workaround.
Yea... in practice this is a huge limitation and not much bigger than the 'SWA'. For most infrastructure jobs, this will mean having to use georeferencing. This is uncommon practice... probably due to inadequate advice.
Brien Bastings said:> I doubt the electrical tools use the solids kernel at all, this recommendation also has nothing to do with the SWA. If this is still being recommended, I'd be inclined to follow this guideline.
Sounds like you haven't checked and are guessing.
Brien Bastings said:> Nothing wrong with this either. If you need to create a single solid 2 km across (I don't know what that would be), the SWA would need to be larger than 2 km. If you have 2 solids, each 3 m across, that are 2 km apart, the SWA can remain the recommended default of 1 km.
Nice one... It sounds like Mstn should have a SWA tool to check for the max size or elements and their separation.
Hi Brian
I'm with Dominic on this one.
In the UK almost ALL infrastructure projects are modeled in AECOsim. A lot of clients do not understand that working in real world coordinates seriously effects the Dynamic View (DV) outputs. We are seeing the DV outputs are incorrectly displayed, even if they are 1% wrong ie missing data or extra data that does not reflect the model they acannot be trusted and it takes a lot of time to review the DV and in the end we have to draw the data in 2d...... thi sis so bad... its criminal, when tools like REVIT just do it in seconds, they are bad news for Bentley.... We are seeing and hearing a lot of these MAJOR clients are getting frustrated with Bentley inability to produce accurate DVs and are NOW ACTIVELY LOOKING at REVIT. We are seeing this on the largest infrastructure project in the UK £15b size project, once this gets hold.... it is seriously BAD new for Bentley.
So her is the thing...
A DGN BIM project will need to collaborate with other BIM authoring tools ie Revit. Revit likes to work at 0,0,0, as well as other BIM tools. so in order to collaborate better, we need to do the same and work at 0,0,0. we should then adopt the GEO Referencing tools to make it appear the model is at real world coordinates.
Not only does this help the project, in AECOSim we are seeing accurate (ish) DVs
the AECOsiom team have released this blog, which is related to SWA and 0,0,0
https://communities.bentley.com/other/old_site_member_blogs/peer_blogs/b/marc_thomass_blog/posts/setting-up-in-the-real-world-uk-coordinate-systems
So something is wrong... its either MS or AECOsim or both.. the SWA is a factor in poor outputs
....... we need better tools if we are to work in real world coordinates and Bentley need to make sure the DVs are 100% accurate
Sadly, as you know, Bentley has form on this. There was a time when virtually all the major London Architectural practices used Microstation. Not any more. REVIT is king and Microstation has been reduced to a sketching tool if it is used at all. All our projects go into Revit post planning.
Ian Lapper said:A lot of clients do not understand that working in real world coordinates seriously effects the Dynamic View (DV) outputs.
I am absolutely not suggesting working in world coordinates, I've failed miserably in my explanation if you've come to that conclusion. It's not good to let uor values exceed 10 digits.
Ian Lapper said:A DGN BIM project will need to collaborate with other BIM authoring tools ie Revit. Revit likes to work at 0,0,0, as well as other BIM tools. so in order to collaborate better, we need to do the same and work at 0,0,0. we should then adopt the GEO Referencing tools to make it appear the model is at real world coordinates.
This is indeed the suggested/recommended workflow.
So.. this is not going away.
I have just opened a 3d DGN that was drawn in real world coordinates. I opened this file in OBD CE6 and I got this message...
So as mentioned in this thread, the Building team seem to think there are issues with the SWA