Display current zoom scale

Tom Foster

Is there any way to dynamically display current zoom scale, in the Status bar, or elsewhere?

I frequently zoom in and in to be sure I'm snapping to the exact spot, but there comes a point, even in max-accuracy 2dWireframe VisualStyle, where entities appear to jump about and the snap point may or may not display on the entity end. If two or three entity-ends are supposed to be snapped together, you can't check that visually - they may well be but their ends appear scattered, tho if measurable the scatter is only 0.001mm or something. A 3dConnexion 3D controller gets uncontrollably over-sensitive - the slighest touch and you've panned to some empty space, no idea which way to move back except by e.g. Zoom Extents then in again.

The limit of display accuracy has been reached and there's no point in zooming that far in. I'm sure there's a zoom ratio which is the useful minimum, for extreme accuracy, but it's difficult to know when you've reached it.

It would be great to have that number dynamically displayed in the Status bar so when zooming in I could stop short of trouble. Sure it would be usefui other ways too.

Michael Mayer

Tom Foster said:

I frequently zoom in and in to be sure I'm snapping to the exact spot, but there comes a point, even in max-accuracy 2dWireframe VisualStyle, where entities appear to jump about and the snap point may or may not display on the entity end.

The limit of display accuracy has been reached and there's no point in zooming that far in. I'm sure there's a zoom ratio which is the useful minimum, for extreme accuracy, but it's difficult to know when you've reached it.

I remember this behavior from Microstation.

In Vectorworks this is usually only when geometry is far from internal Origin
and therefore drawing resolution is too coarse.
(It is enough to have some forgotten geometry rests that are far away,
even if your main geometry is centered)
Usually happens if you import geometries that are placed in real world coordinates
and draw over it. This does not happen when the file is proper geolocated, which
allows centered geometry - and real world coordinates (which I never want).

With centered architectural sized geometries you do not see these problems of
snapping points differing from geometry when zooming in.
I assume VW just stops you from zooming in further.

Maybe that would be useful for Bricscad too ?
Rather the need to check and read zoom scale manually. And what would be the
last useful zoom scale or is this even variable depending on project size, INSUNITS
and such ?

Tom Foster

With centered architectural sized geometries you do not see these problems of
snapping points differing from geometry when zooming in.

Lucky you - I'm plagued by it, nothing to do with far-from-origin elements, aren't any - also unreliable snapping even when taking greatest care. Wonder if it's my graphics card or something.

Michael Mayer

No, you aren't alone.
I just tried it.
You can zoom in nearly infinite.

If you do it enough, you will have no control over your geometry
which will leave your view, instead you will get a text on the top
left view border, in a very fancy font, saying "VERASSEMMAUS"
(Easteregg ? Belge for "verdammte Maus" ?)

And zooming out again to find the sweet spot where Snapping cursor
reappears (I think there is a little shaking once you exceed that point),
which made Bricscad crash and disappear from screen.


So I think Bricscad should just not do this - zoom in more than it makes
sense or Bricscad can bear ....
(Or zoom out, when you have such a "fast scroll = endless scroll to top/end
of a website - or out to nirvana in Bricscad)

I don't think there is anything wrong with your GPU or Driver.

Tom Foster

Ha - that's cheered me up! Verrassen = surprise, delight, impress, ambush, in Dutch https://dictionary.reverso.net/dutch-english/verrassen .

So, in 3D using Visualstyle 2dWireframe (which is the only one that's 'native', not a 'rendered' style, hence the most accurate, least ambiguous by far, and prob much less reliant on the graphics card). I'm using 3D as a geometry-solving engine, for a building that's 'freehand', with off-angles and curves in plan and section but nevertheless constructed of straight timbers and flat boards. Then transfering resultant dimensions and angles to 2D drawings.

But still suffering much from unreliable accuracy of snapping, even when zoomed in to maximum 'optimal'. With length units = mm, I am admittedly looking for trouble, with Linear unit precision = 8 (0.00000000) (which doesn't affect underlying precision, just how it's displayed in Properties and tooltips). Why? I can explain!

I lay out the Geom of overhead beams etc as guide-lines, flat at z=0, with X's to mark intersections and key points along those beams. I then erect lines vertically from those X's; some lines of spec'd length (so the lines' tops are at spec'd ht above z=0); some lines as 'queries' i.e. to see what length (ht above z=0) they turn out to be. Then between the tops of the spec'd lines I draw the top-centre line of the sloping beam. Thus the beam should be precisely above its z=0 Geom guide-line.

First problem - it's usually fractionally off. Despite great care in snapping, first the vertical lines to the flat guide-line X's, then the beam to the tops of the verticals, the beam is not exactly above the guide-line. The result is that Trim and Extend don't work, in projecting the 'query' lines to meet the beam, so's to find out what length (ht above z=0) they need to be. The guide-line, the vertical lines and the beam line all need to be ever-so precisely in plane, for Trim and Extend to work. But by grabbing the top of the vertical line, dragging the grip with or without Shift-locking to axial, or using Stretch or Extend, a snap is usually found, but there's either a tiny gap, not a true intersection, or the vertical line ends up not absolutely vertical. So Trim/Extend is much more fussy than grip-dragging, Stretch or Extend. I've put this to Support but they don't agree, can't reproduce.

Second-problem - consulting Properties I find that in 3D many of those z=0 guidelines, and X's on them, are not exactly at z=0, by e.g 0.000004mm one end, 0.00002mm the other end (yes, I'm looking for trouble!). I can rectify that by editing in Properties (or Flatten, which I don't trust). Then select one line and one X, get the tooltip distance between them, which I need to read 0.00000000 exactly; if not, move the X away and bring it back to snap properly to the line.

Third problem - often takes more than one attempt to achieve 0.00000000. Then the same procedure with the verticals, to snap properly to the X's. Then the overhead beam-line, to the tops of the spec'd lines. It is arduous!

Why do I get this trouble, when in demo videos snapping is easy-peasy, even when in one of the 'rendered' styles? In my experience, any kind of snapping accuracy is hopeless, in the rendered styles. I've had this forever, on three different computers of ascending power, in Windows from XP onward. I first did this geometry-solving in Microstation, way back - no problem then.

Michael Mayer

Michael Mayer said:

If you do it enough, .... , instead you will get a text on the top
left view border, in a very fancy font, saying "VERASSEMMAUS"
(Easteregg ? Belge for "verdammte Maus" ?)

Secret lifted ....

It was just the IFC Building Name ..... which is the top part of the new V23 (?)
IFC Story Editing Mode switcher HUD on the left side of the screen ....

Tom Foster

Cross-posted - comment on mine, above, appreciated

Michael Mayer

Hi Tom,

could you upload a small demo file that includes some of these geometries
for better imagination and to test/reproduce ?

Michael Mayer

Tom Foster said:

Ha - that's cheered me up! Verrassen = surprise, delight, impress, ambush, in Dutch https://dictionary.reverso.net/dutch-english/verrassen .

Ha, cool.
I did not find something in the Internet that would have made sense ...

It was not a fancy font.
Just some strange white background behind black text.
Realized that when I opened Bricscad again ....

My IFC Building's name was "TERRASSENHAUS" (terrace house, stepped building)

Anthony Apostolaros

In Vectorworks, when I was using it (25 years ago), there was always a virtual paperspace, though you couldn't see it. It was defined by the scale of the active layer. A layer in VW was a virtual space, and each layer had a scale associated with it, similar to the scale associated with viewports in DWG files. So zoom scale related the size of the geometry in the real world to its size on paper at the scale of the active layer.

DWG files don't have layers in that sense. What we call layers aren't layered and they don't have geometric properties. But DWG files do have paperspace, and any view from paperspace into modelspace has a current zoom scale that's visible and editable in the Properties panel.

Michael Mayer

I wouldn't call that virtual paperspace.

Yes, there are VW Layers (= ACAD not existant)
vs VW Classes (= ACAD Layers)

Pretty much the same are
"Design Layer Space" (= ACAD Model Space) vs
"Sheet Layers" (= ACAD Paper Space Tabs)
Also Viewports work basically the same.

Yes, VW Design Layers (in Model Space do have a Scale.
But this happens in VW Design Space only and is nothing more than a WYSIWYG mode.
That way you can check if your Text and Dimension scales will work.
But you basically work in a 1:1 environment. Once that Scale is properly set,
it has no further meaning and should be ignored.

Unfortunately there is still some legacy crap in it.
Each Layer can have its own scale, Unified View Settings, ....)
From times when users printed from Design Space (some still do !)
And you won't be lucky for several reasons when not just use the recommended
Layer Scale = Scale that is used by most of your Plans in Sheet Layers.
E.g. do not set Design Layer to 1:1 scale.


There are lots of discussions about VW's non standard naming and terms that not
only differ from the rest of the CAD/3D but are often also mixed up.
Like VW calls Materials = (Renderworks) "Textures"
(Which can include (Image) Textures !?)
or Layers.


If you forget those legacy inconsistencies ....
In VW you work in 1:1 scale in Model Space as in ACAD.
In Paper Space you have your Sheets for Print size and resolution,
but all Scaling is done by Viewport's scales only

Tom Foster

Michael Mayer said:

Hi Tom,

could you upload a small demo file that includes some of these geometries
for better imagination and to test/reproduce ?

Working on it - trouble is, in creating same, I'm finding yet more wierdness, as well as finding partial solution. So a WIP.

Tom Foster

Actually, I give up, can't pinpoint much in the way of what works when and within what limits of accuracy, UCS orientation etc. Can't even reproduce the snapping unreliability that I was getting in my working model.