File too heavy but limited element only

KERLOO

The item that in this drawing is only a few but why it is so lag?

Michael Mayer

Looks like there is any Element or "something" where far away from
Origin or from the rest of your things in your Layout.
That seems to cause problems to view display.

You realize that when you Zoom Extends.
I could not find or select anything, which should be on the opposite
side of the screen from your objects.
Could maybe be something within a block or such things.

Michael Mayer

EDIT
it seems it's the 2 external References not included in your attachments.
I think if you move them back to place it should work again (?)

EDIT EDIT
Model Space looks ok but even after deleting these and purging,
there might be more problems, it still lags for me in Paper Space.

Tom Foster

The newish(?) Structure panel, in Mechanical mode, is brilliant at listing everything that's in the drawing. In that, you can hide and unhide elements selectively, so with box-select select everything that's in your 'proper' drawing area and hide it all with HIDEOBJECT, then the Structure panel will tell you what's still unhidden, hence outside your 'proper' drawing area. But not sure it lists strange and non-visible elements.

You know about simply Copy>Pasting all the visible elements into a new dwg file? That usually leaves behind the strange and non-visibe elements.

Roy Klein Gebbinck

There are more than 1800 entities in model space, including inserts of 'complex' blocks. So I do not understand why the OP speaks of 'only a few'. The file size seems appropriate.

Hans De Backer

The drawing contains a block named BOUNDARY, with a minimum elevation of -999999987000000000 units and a maximum elevation of 999999987000000000 units.
There is also the polyline with handle 5209 which is located at an elevation of 999999987000000000 units.

This looks unintended.

Many hatches use a Grass pattern that contains many dashes, which causes redraw to become slower in medium-zoomed views, because more than a million dashes need to be drawn. When zoomed in closer, less dashes need to be drawn, when zoomed out further, the small dashes are filtered out, both leading to faster redraw.

As Roy correctly points our, the nested blocks indeed contain lots of geometry, more than 100 thousand entities.

KERLOO

@Hans De Backer said:
The drawing contains a block named BOUNDARY, with a minimum elevation of -999999987000000000 units and a maximum elevation of 999999987000000000 units.
There is also the polyline with handle 5209 which is located at an elevation of 999999987000000000 units.

This looks unintended.

Many hatches use a Grass pattern that contains many dashes, which causes redraw to become slower in medium-zoomed views, because more than a million dashes need to be drawn. When zoomed in closer, less dashes need to be drawn, when zoomed out further, the small dashes are filtered out, both leading to faster redraw.

As Roy correctly points our, the nested blocks indeed contain lots of geometry, more than 100 thousand entities.

SO HOW DO I SOLVE IF THERE'RE MAY NESTED OBJECT?

KERLOO

@Roy Klein Gebbinck said:
There are more than 1800 entities in model space, including inserts of 'complex' blocks. So I do not understand why the OP speaks of 'only a few'. The file size seems appropriate.

THATS THE THING ! WHEN YOU LOOK AT THE DRAWING CAREFULLY, THERE'RE NOT MUCH BLOCK IN USE SAME AS GOES TO THE OTHER ITEMS. iT HAS LOTS OF NESTED OBJECT AND SEEMS TO BE MAKE THING COMPLEX AND LAG BUT I DONT KNOW HOW TO SOLVE.
i BELIEVE YOU DONT EVEN TAKE A CAREFUL LOOK OF THE DRAWING AND BELIEVE ALL THE NUMBER WHEN YOU AUDIT. NOT HELPING.

RSW

@Michael Mayer said:
Looks like there is any Element or "something" where far away from
Origin or from the rest of your things in your Layout.
That seems to cause problems to view display.

Being far away form origin has traditionally never been a problem with AutoCAD (and BricsCAD) unlike Vectorworks where it used to be an issue.
As mentioned in the later replies lots of items and complex object will slow down BricsCAD (and AutoCAD) but that depends a lot on computer hardware too.

RSW

@KERLOO said:

THATS THE THING ! WHEN YOU LOOK AT THE DRAWING CAREFULLY, THERE'RE NOT MUCH BLOCK IN USE SAME AS GOES TO THE OTHER ITEMS. iT HAS LOTS OF NESTED OBJECT AND SEEMS TO BE MAKE THING COMPLEX AND LAG BUT I DONT KNOW HOW TO SOLVE.
i BELIEVE YOU DONT EVEN TAKE A CAREFUL LOOK OF THE DRAWING AND BELIEVE ALL THE NUMBER WHEN YOU AUDIT. NOT HELPING.

With all respect but you are mistaken:
When opening the drawing and cleaning up items in model space that are double or not intended to be there (like the bits and pieces in the legend area that make no sense I end up with the following:

1. Select all give 1407 items, of which 870 are a block reference, use the quickfilter to select only the blocks
2. Explode those block reference gives (3)
3. Purge non-used blocks from 2 and then select all gives now 10630 items, of which 1899 are block references.
4. Explode these 1899 block references, whichs gives (5)
5. Purge non-used blocks from (4) and then select all gives now 47898 items, of which 3130 are block references
6. Explode the 3130 block references from (5)
7. Purge non-used blocks from (6) and then select all gives now 133861 items, of which 2564 are block references
8. Explode the 2564 block references from (7)
9. Purge non-used blocks from (8) and then select all gives now 156679 items, of which 93 are block references
10. Explode the 93 block references from (9)
11. Purge non-used blocks from (10) and then select all gives now 175510 items and no more blocks left

As you can see from above with a few steps the number of items increase with a factor of almost 125 and the number of blocks by almost a factor of four at some point.
So there is a lot of geometry in your drawing and considering that the file size is not that big but depending on your hardware it can cause a slowdown depening on what you want to do.

Nested blocks may not be ideal to work with but given the drawing it does make sense to nest blocks into larger identical groups as it will keep the file size down quite a bit. Your file is 612 KB, after exploding and purging all blocks as described above the file size increased to 10994 KB.

Michael Mayer

Yes I know,
but I am not sure how can this work in ACAD when the origin being far away.
Anyway, my experience with DWGs I got for import, shows that ACAD users
have no problem with it.

But how should I work best when I want to :

1.
Somehow keep the world position

2.
Always draw 3D near to the (File) Origin because of Rulers, DYNDIM, ...
(Like setting the file origin to a Grid Axis Crosssing)

3.
For Export/Exchange to
a) export with world coordinates (DWG/DXF)
or
b) export with local coordinates around file origin for Exchange with
3D Apps that can't deal with far Origins (DAE, FBX, C4D, .... and DWG)

2. Should be easy by UCS (?)
   For 3. I hope for a Project Setting or Spatial Location where I could enter
   the distances from my UCS to the exact World Location.

RSW

@Michael Mayer said:
Yes I know,
but I am not sure how can this work in ACAD when the origin being far away.
Anyway, my experience with DWGs I got for import, shows that ACAD users
have no problem with it.

But how should I work best when I want to :

1.
Somehow keep the world position

2.
Always draw 3D near to the (File) Origin because of Rulers, DYNDIM, ...
(Like setting the file origin to a Grid Axis Crosssing)

3.
For Export/Exchange to
a) export with world coordinates (DWG/DXF)
or
b) export with local coordinates around file origin for Exchange with
3D Apps that can't deal with far Origins (DAE, FBX, C4D, .... and DWG)

2. Should be easy by UCS (?)
   For 3. I hope for a Project Setting or Spatial Location where I could enter
   the distances from my UCS to the exact World Location.

World coordinate system (WCS) is the same as the internal origin of V-thing (aka Vectorworks or VW), that's one thing to keep in mind if you want/need to stay close to the internal origin.
Set out your surface area when in WCS
Then you set up one or more UCS's to get the desired coordinate range, angle etc. you want or need and work in that.

Now.. when importing into VW it will use the WCS as its base for importing. This won't cause much troube as long as the UCS not set under an angle. If it is you will get improper imports in VW (i.e. it won't end up where you would expect it to end up). So if you need to get it into VW it is best to set the UCS back to WCS, For the other applications you mention I don't know if they use the WCS as their base point for importing and ignore the UCS or that they use the UCS origin as their base point.

In all other cases I would just leave it at WCS and work at world coordinates, esp. when you are using projection settings.

Michael Mayer

I meant the best way to work in Bricscad.
If I got you right,
a)
if someone sends me a DWG "Reference" (normally far away).
I will just reference that file as is and start drawing on top of the
reference. I will not have any disadvantages with precision.
b)
To keep my drawing comfort, I should set a UCS to my liking for
rotation and location.

c)
when I export any time later, my geometry is at real world location,
there is no way to adjust my export optionally that it uses object
locations from my UCS, right ?

In VW it is a bit different :
DWG (far away)
Import with relocating UCS (> moves DWG to File Origin)

• VW is happy
• DWG Exports stay in world position
• DAE/FBX/C4D/.... Exports using object locations from UCS automatically

RSW

@Michael Mayer said:
I meant the best way to work in Bricscad.
If I got you right,

[..]

b)
when I export any time later, my geometry is at real world location,
there is no way to adjust my export optionally that it uses object
locations from my UCS, right ?

Basically yes to the first two regarding location.
If you export it without resetting the UCS to WCS then it will still use the UCS to show the coordinates if opened in another DWG based program.
Vectorworks however seems to use the WCS as its reference point for importing DWG files, I've run into this issue with DWG files that had the UCS rotated and its origin not aligned with the WCS origin.

In VW it is a bit different :
DWG (far away)
Import with relocating UCS (> moves DWG to File Origin)

• VW is happy
• DWG Exports stay in world position
• DAE/FBX/C4D/.... Exports using object locations from UCS automatically

As long as you are not working with georeferencing then this should be ok. (We've had that discussion on the VW forum in the past about moving origins etc. in georeferenced drawings )

Michael Mayer

Thanks, I think I got it for Bricscad now.

I just need to look carefully into DAE and FBX exports again to
be sure what's going on and find a workflow.
Maybe I should just keep my work around origin workflow and
relocate my references anyway. As it is more comfortable for me
and I have mostly no need for exchanging my models back.

(Yes, VW's user origin having neither rotation nor Z height isn't
very helpful either)