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
hi Ian,
I follow up with you via SR.
Regards
Maria
Maria Garcia
Hi Ian,
My understanding is SWA is no longer a volume fixed at the center of the design cube. It is more of a volume limit per solid.
See Brien Bastings comments in this thread.
Regards,Ron
The tool that Ian is referring to is part Aecosim Building Designer CE U4
Brien's info has been pretty cryptic and somewhat contradictory
"* You want to model close to 0,0,0 because that's where double precision floating point numbers are most accurate. You setup the global origin to position your model where you want it in the world and use Coincident World reference attachments. This doesn't have anything to do with the SWA, it's just good practice."
Elsewhere, he also washes his hands of any ABD Triforma solids.
The fact that ABD U4 includes a tool to visually identify the SWA reinforces previous experience with V8i where Bentley recommends that you do not model outside the SWA. This has been blamed for defective extractions and problems with ABD's Electrical tools.
It also seems that CE's DV drawing extraction process also suffers from elements being outside the SWA. Still looking at this.
It may be the case that Mstn solids are not affected (as you could interpret Brien's post as saying) but since most projects require BIM delivearables, ABD's TF solids will need to be considered... especially for those in charge of setting up seed files for others. The potential for disruption is great.
I think there is general confusion on this issue. The current advice seems to be that a 3d object can be modeled anywhere as long as it is no bigger than the solid working area. My experience is that anything modeled along way from the 0,0,0 can be problematic so I always set project up with the project coordinates mapped to the global origin using the go= keyin. That way the coordinates can be real world but the project is at the origin.
Even if as Bentley now seem to contend the SWA cube is meaning less it is still very useful to demonstrate the concept of modelling near the origin.
Duncan Macdonald said:Even if as Bentley now seem to contend the SWA cube is meaning less it is still very useful to demonstrate the concept of modelling near the origin.
Duncan,
The reason I don't like a tool that shows a cube the size of the SWA centered at 0,0,0 uors is that it suggests that anything drawn outside it is invalid and will prompt someone to take the action of increasing the size of the SWA to try to include all their geometry.
Increasing the size of the SWA is rarely desirable, the entire purpose of the SWA is to control the linear precision of the solid modeler (i.e. how far apart 2 points need to be in MicroStation in order for the solid kernel to consider them to be distinct), it is literally just a scale from uors to meters in the solid kernel.
There was a recent internal discussion regarding bringing back this tool for Connect; hopefully everyone that was involved in that discussion is now on the same page and will communicate the best practices for working with solids that were discussed. 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.
What I suggested was letting people specify the extents for their project, 10 km, etc. and show a cube of that size to help them model inside their specified project boundary. Keep the SWA out of it and don't try to conflate it with the project extents, let the SWA remain 1 km and serve the purpose for which it was intended, to control linear precision.
HTH
-B
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.
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