Tip to Speed up bricscad
I noticed a big slowdown when working with some large files.
I then discovered a workaround that speeds up everything: viz, bolean op. , extrudes...
You just have to place the model near the world origin!
That's it! It seems bricscad can't handle georeferenced models!
Comments
-
That is a common problem in many CAD systems, not just affecting speed but also causing errors within commands.
0 -
I always thought that Autocad/dwg would somehow not being
effected by drawing far from origin.
As nearly all Files I got from Autocad users over decades were
always drawn far from origin. Kind of georeferenced location.In Vectorworks we get in trouble already when being just 4+ kilometers
from internal origin. We need to set a invers user origin in such cases
to keep the model around internal origin.
I always that that Vectorworks only would be especially picky.I always thought DWG would somehow autofocus to the geometry
bounding to get max resolution, no matter where it lays in space.So should I better care about origin in Bricscad too and also better move
imported geometries every time back to drawing origin ?0 -
An important factor in all this is the drawing unit. if 1 DU = 1mm you are more likely to have issues with a geo-referenced DWG than if 1DU = 1m.
0 -
You mean INSUNITS ?
If you want to change these you would have to scale the geometry.
And if they were wrong from the source, scaling would bring
in all rounding errors anyway ?0 -
In the Dutch situation city and landscape planning is done in meters with the origin, for historical reasons, located in Paris (distance Amsterdam-Paris is ca. 400 km). If you design in millimeters, insert such a plan at the origin and scale it up by a factor of 1000, you end up with larger coordinates (400*1000*1000) than if you work in meters and do not scale the plan.
Actually the accuracy stays the same in term of significant figures, it is just that more of those figures are before the decimal separator for larger coordinates. In a DWG the number of significant figures is ca. 16.
0 -
It's the same thing in Revit, there's 16km limit from the internal origin before errors creep in.
Working for a Surveying company we feel, this is a good thing. The world is not flat after all (or is it?!?
)Personally I always draw near origin and have a mark stating the real world coordinates, should the user wish to overlay a survey or DTM etc.
0 -
@fegis said:
It's the same thing in Revit, there's 16km limit from the internal origin before errors creep in.
Working for a Surveying company we feel, this is a good thing. The world is not flat after all (or is it?!? )Personally I always draw near origin and have a mark stating the real world coordinates, should the user wish to overlay a survey or DTM etc.
This is fine for local coordinates (i.e. site coordinates), but when it comes to georeferencing then in my opinion shifting origins relative to the hard coded origin in a drawing (WCS in DWG , internal origin in Vectorworks) is a recipe for potential disaster. E.g. Vectorworks seems to import DWG files based on its WCS (comparable to Vectorworks' internal origin) and not the DWG UCS. Not to mention shifting and rotating the UCS relative to the WCS.
I've had to deal with supposedly georeference drawings where things were off by 40+ km because of this "manual adjusting for convenience (or whatever reason)". I'm not even taking projection issues into account.For small sites this is less of an issue, but for large(r) areas this is something to keep in mind.
0
