line-weight
-
Posts
3,763 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by line-weight
-
-
Yes, a big advantage of it happening automatically is not just time saving but makes it much easier to spot errors - if you know the level is always correct and can't be moved accidentally then you can easily see when things are not in the right place (same with vertical grid lines).
-
1 minute ago, LarryO said:
This avoids the pitfalls of the American Imperial system of nominal verses actual size of products
We still have that here in the UK, you'll commonly ask the builder's yard for a 2" by 4" but what shows up is not 2" by 4". It might also be sold as "nominal 50mm x 100mm" or something like that, and again what shows up won't be that. Unfortunately it can be all sorts of things, like 45mm x 95mm or 45mm x 90mm or 47mm x 97mm and so on, and I'm often not 100% sure what's best to actually draw. In some cases it's not really critical and in some it is.
-
1
-
-
21 minutes ago, zoomer said:
Maybe that will help me to finally do the switch 🙂
But it is still not as logically as thinking about 6 m comma/dot 20 cm
Plus the mnemonic for Millimeter, which needs a 00 behind comma.
(which is only needed for values smaller than 10 mm)
But it seems to me that it is more likely that a dimension will be 6202mm or 6204mm or 6208mm than 6200mm. And then what do you say, 6m comma 20cm-and-2-mm?
I just say, six, two hundred & 2. Or six, 2-0-2.
-
1
-
-
1 hour ago, Tom W. said:
But likewise @line-weight do you really think of a building as 12,000mm long or 6,000mm high for example, and not 12m + 6m? I use mm mainly but start switching to metres once we’re into 4 digits + definitely once we’re in 5 digits. But then I also use feet + inches a lot – ¾” ply, 8x4 boards, 4x2 timber, etc – I guess it’s just a matter of the right unit for the circumstances. With VW I am set predominantly to mm but I do have a dim standard that has metres as the dual dimension so for large floor plans I can dimension in metres then switch back to mm for the rest.
In my head I'd be thinking 6200mm rather than 6.2m, at least while I'm drawing.
In my head it's "six two hundred" rather than "six thousand, 2 hundred".
Of course, we can write 6,200mm or 10,450mm which can make it more easily readable but runs the danger of causing confusion when read by a continental type who reads the comma as a decimal point, so I have got out of the habit of writing the comma.
-
43 minutes ago, zoomer said:
That is a wish I see all the time on the German forum.
Hm, so not even this is possible at the moment?
-
I'm also realising that because 'levels' can only really be used by a few object types, they are not as useful as I was imagining they'd be.
I'd like to be able to (for example) extrude a rectangle to create a solid, and then send it to sit relative to a certain level.
Another question, which I've not investigated... if I do set up levels, can I then use them automagically in sheet layer viewport annotation to quickly and accurately show significant levels like FFL and so on? Because that would save some time and help with drawing coordination.
-
1
-
-
15 minutes ago, zoomer said:
I am so terribly used to think in meters for buildings.
Does this mean that when you think of the thickness of say plywood, it's 0,018m in your head?
And then half a metre is 0,5m or is it 0,500m?
-
42 minutes ago, zoomer said:
Levels belong to Stories.
They will only be accessible for Layers that belong to a Story.
So you would need at least a single Story Container for your Levels
but as you proposed, you would need Level duplicates for each virtual
"Story", which
a) wouldn't be that fun to work with by scrolling in an endless Level Dropdown
and
b) you would need Wall Style duplicates for each virtual "Story" to assign
the correct related Levels.
Yes... well here is the very basic setup I have made so far on the drawing I'm trying this out on.
-
36 minutes ago, zoomer said:
Not sure if I really got the problem
I suppose I am thinking of a scenario where eg. I am drawing up from a survey, and I have some element at 2nd floor level that I want to place offset from, say, some datum lower down like ground floor FFL, or DPC level, or window sill level or something, because that's where I took the measurement from when I did the survey. Maybe when I was measuring in a stairwell for example, or on the outside of the building.
But thinking about it, maybe this is a fairly rare use case, and relating it in that way is not actually useful in the longer lifespan of the drawing.
-
1 hour ago, Christiaan said:
Correct, all levels are offset from their relative storey. Levels relative to ground are not possible except if you hack it as described. Levels relative to ground could be a nice feature request though.
I'd be interested to hear how your experiment goes. What you'd be missing of course is levels relative to floor levels. For me these is big advantage of Stories. They're really great when it comes to making changes to floor to floor heights hallway through a design. Or making changes to parapet heights, say. With storey levels these things can be coordinated consistently with ease.
Yes, I can see that (in my system) if I change a floor level, then any walls or slabs that I've got hooked relative to that floor level will move with it, but other things (furniture, doors&windows(?) ) won't, whereas they would if I changed the layer height or if the layer height were changed along with the storey.
This is not really an issue for most stuff I do which tends to involve existing buildings and therefore storey heights mostly are what they are.
In fact for me when it is most useful to shuffle floor levels about is when I am drawing up from a survey and need to shift things around until they are right. For this process, I mainly get things like floor levels and wall locations right first and then they don't change, after which I add further detail.
It's annoying that doors and windows can't be hooked to 'levels' (or am I missing something?) because surely this would be useful with either approach.
-
56 minutes ago, zoomer said:
It is a real problem for me that we still don't have any option in VW,
when assigning Objects to another Layer,
which may have a different height,
that we can optionally keep the Object's World Height
vs
Default of moving it in Z, according to Layer Height Differences.
As an example,
I could now replace and update my simplified Interior Walls easily with
more developed Walls from IFC or Revit imports.
But if I want to keep Layer Heights, no matter if Story based or manually,
for now, I would have to tediously bring over Story by Story and each time
carefully select the replacement Geometry and move it back down manually
in Z by the negative delta of Layer Height.
Which is no fun at all.
I agree; this is something I would like to have too.
-
Spending this afternoon trying to get my head around storeys. As usual, VW builds the UI to make things as confusing as possible. Anyway, that complaint has been covered elsewhere.
Most projects I work on have a maximum of 3 or 4 floors. I don't really need the automation to change something on 100 floor levels at once, that sort of thing. So at first sight storeys might not be for me (and that's the approach I've taken so far).
However - it seems to me that the potentially most useful aspect of 'storeys' is the use of 'levels'.
I'd quite like to be able to define or place objects relative to a set of defined levels.
But say I am placing a wall or some other thing at the 2nd storey. For sure, I will mostly want to define heights relative to that storey's finished floor level, or ceiling level, or whatever. But sometimes I might want to define them relative to a building-wide datum. So, for whatever reason, I want to make a height relative to the ground floor finished floor level, or the roof ridge, or something. As far as I understand, I can't do that with storey levels. Is that right? I can only place relative to levels on that storey, or the storey above or below it?
And it's not possible to have a "storey-less" level. Is that also right?
This made me think, would it work to just have one, overall storey? It would contain all the design layers, and I would set up all the levels I wanted as "default story levels". So I'd have one named FFL-1st, one named FFL-2nd, and so on. And then any element in any layer could relate to any of these levels.
This would let me give all design layers an elevation of zero. I do this sometimes already, because it means I can paste-in-place objects between layers without them jumping according to the layer elevations (a frequent frustration for me because I usually have quite a lot of directly-modelled objects). Then I would be able to set wall tops and bottoms relative to my levels, rather than working out relative to the project zero.
Has anyone tried something like this? Is there something that will mean it will be a disaster? I might give it a go anyway.
-
2
-
-
On 12/15/2016 at 7:55 PM, zoomer said:
Thanks a lot for the updated Stories and Level Tutorial.
Nevertheless I think the Story and Level System is unneeded complex on one side and not very flexible
on the other. I needed to go through the your first Tutorial to understand how it is meant and even back
to the old VW feature release videos (former Model Setup) even to understand where that complexity
originated.
It is hard to understand that System.
The reason for me is the integration of an auto-create Layer feature into Levels.
While being a nice feature to auto-create Layers when creating Stories, when you use a lot of Stories,
I see it as a low priority feature and add on that makes things complicated when included in this way.
Like when you start to add multiple Default Levels with same nam, just for the sake of auto-creating a
Layer or not.
Multiple Layers used on a single Story were mandatory as long as there didn't exist any Levels.
(former Model Setup)
Like for for Slab+Wall or even more Layers as the only option to parametrize height levels of PIO's.
Today, since we have Levels, at best, you want only 1 Layer per Story.
If you want to have more Layers per Story it is just for organizational purposes or as a drawing aid.
In most cases it really works for my by 1 single Story Layer. And it is easy to bind a Layer to a Story
later or while creation. I even never thought of any other way to need to do this nor did in a different
way.
If you exclude all those Layers from Stories+Levels System,
you have a simple System that any user can understand.
Set Stories for each Story = normally your Finish Floor Levels
Set different Levels = Height Levels that you can bind your PIOs top and bottom boundaries in Z axis.
Easy.
If there wouldn't exist Stories in VW, it could be even done by Layers only, which could include these
Levels. So why Stories at all ?
Currently the only advantage or flexibility from having a Story definition is the Automation to adapt all
adjacent and following Stories Z level, if you change the vertical Z level of a Story in between of these.
(+ "the auto creation of Layers")
Beside that Stories are mandatory because needed as they carry the Levels, there isn't much use of
these if we are talking about buildings with less than 4 Stories only.
Stories are useful when having a certain amount of these. And this is exactly where you will need a
a certain Flexibility and parametrical options which are currently not available.
Why not include something like Story Styles or Default Stories, so that you can parametrically adjust
the height of all Standard or Basement or Technic Story Prototypes of your skyscraper in one go ?
Which would also allow to create 27 new Stories on top of Story 1 by using Story Prototyp "Standard"
by its Height setting of 4,15 m. And change that to 4.28 later in one go, to satisfy the engineers
and the client.
Level's Flexibility.
The Default Level Setting currently does nothing more than prevent you from creating each Level
again from scratch when creating a new Story.
What I initially expected is, and even the term "Default Level" implies it, that when you change a Default
Level's height, all assignments in Stories will follow.
Like the Architect designs all Windows nicely from ceiling to floor, then client says, no, too expensive,
make balustrades, you will want to adjust your "Window Bottom Level" to +90 cm to comply clients wish
in one go.
And beside the tangling duplicates of Levels with identical names caused by the "auto create Layer"
feature. This will also happen when you want to use a Level Type having a different unique height setting
in a special Story. So there needs some recognizability, if it is still a (better linked) Default Level or
a unique Special Setting of Level, beside just the height entry and the need to remember which was your
default height.
And those duplicates will stay appearing in every Story's option - until the last used copy of it will finally
be found and eliminated manually.
And those "duplicates of Levels with identical names" only happen because you currently can can
(and maybe will) choose one single Level only into your PIO setting.
But such a Limit is not necessary by itself.
Of course there could be an option to choose more of these :
"Window Top Level Default" + "Window Top Level A= delta + 30 cm" + Window Top Level B= 1.36 m",
what ever Level applies to the Window in the current Story. The Window would still know what to do.
(Given that only one of these Levels can happen at each Story)
Generally I think it is simple, therefore better, that PIO's let you choose only one Level at a time, as they
currently do. So therefore such Level "Types" and their names have to be unique in each Story.
But there is a need for a clear UI in a Story Setting, which of those identical named Levels is which.
Where I propose to only show that one Default Layer + a checkbox to unlink from its default values
with an input field for the alternative height in that Story.
(So this way also allowing to re-link to default height binding, if needed)
And for as it is now, at least that Levels that have an additional Description Option that you can differentiate
clearly between a : "Window Top Level (Default)" and its "Window Top Level (Custom-A)" counterpart.
Coming Back to the "the auto creation of Layers"
I think it should happen in the Stories creation settings options, as a simple checkbox behind each Level
to avoid redundant Levels. Maybe set the Layer name Suffixes in the Levels Box.
I still don't get why there is
a) a need for a "Level Type" Box, instead of doing that in the Default Levels Box
and
b) if, why it is in the Layer's Tab of Organisation Toolbox and not in Stories Tab
"Stories : CANNOT be copied and pasted into a another file."
I think this is not nice at all and there is no need for that limit.
There could be (hidden or not) Default Story Settings included in any File.
So that VW is aware of what a an Elements Story information is (Like 4rd Floor above ground) and will
keep that information for later use.
So when I drag and drop a 3rd floor Window into another File without explicit user created Story Information,
VW will ask :
The Object you try to insert hast Story information, (looks your Files misses that), will you
a) discard that Story information and put it in using its height based on ground level
b) Keep that Objects Story Information and even copy all Story Information from the other file as you still
didn't create your own, as I told you
or
c) convert that Story Information of the Object to adapt to the Story Settings provided in your file
That Limit is especially irritating as there generally is no option in VW,
when transferring Elements from one Layer to the other, to decide wether to do make that possible jump in
height levels between these Layers or just, for organization/visibility purposes, keep the Objects "World"
height level over ground.
(Imagine you had the wrong 1st Story's Layer active when creating new objects in correct World Height
of 3rd Story, because snapping to the correct height level elements of the proposed Layer.
If it is a crowded drawing and you can't drag, you will need to open your calculator and start thinking about
what your delta height differences between your Stories may have been)
I've just spent a couple of hours finally trying to get my head around storeys, to decide whether I want to attempt using them on a drawing I'm currently setting up.
Everything @zoomer says above is absolutely spot on. He identifies all the things that are confusing when you start out trying to understand what's going on, and more stuff that I don't quite follow right now but I'm sure I would find out if/when I started using storeys for real, and I suspect it is all exactly right and will reflect the frustrations of many users. I expect most of this feedback will be ignored. Ho hum.
-
Thanks @zoomer, that all makes sense.
On using mm vs m - I prefer to use mm just because I "think" in mm. I think this is a UK convention, compared to some continental European countries where dimensions are shown in m or even cm.
I will always think of something as 200mm long rather than 20cm long, and 1450mm long rather than 1.45m long.
I have wondered the same as you though; does using mm instead of m mean that drawings start to show problems from getting too large (objects far away from origin) sooner.
Currently my biggest model is about 500m in its largest dimension but drawn in mm and it seems to be ok.
-
Actually, fiddling around with things, I see that in fact even with precision set to 1, if I draw something 10.5mm long (by typing 10.5 into the OIP) then although the OIP tells me its rounded to 11mm, in reality it *is* 10.5mm because if I duplicate it, snap the two things together and measure the total length, it is 21 not 22.
Same applies with a wall style for example - I set components at x.5 width and it looks like they've all been rounded up or down, but when I check the overall width of the wall it's correct.
This now makes me wonder why there's an option to display less precision than is available, because all it does is make small errors invisible to the user.
-
Although... I see that actually I can use these settings to draw to the nearest half millimetre:
(Changing "decimal rounding base")
Do the settings above, in theory, make it impossible for me to draw a line that isn't in a 0.5mm increment (unless I snap to something else)? If so, then it seems a good way of avoiding accidentally not-in-0.5mm-increment dimensions.
I guess my question is still whether there are any downsides of setting the precision higher.
If there aren't then it seems to make sense to do what zoomer suggests.
-
5 minutes ago, Tom W. said:
I have come up against the same issues. I always used to set decimal precision to 1mm then occasionally would need 0.5 of a millimetre (12.5mm plasterboard for example) + would change to precision accordingly, only to find that existing objects I assumed were sized to whole mm had in fact dims to fractions of a mm. Then I saw @zoomer's post below + have now set precision to 6 digits + works well:
(Thank you @zoomer)
Ah, thanks.
That other thread outlines the same worries that I have!
I've never fully understood what actually happens behind the scenes with accuracy and so on... probably some maths beyond my comprehension.
For example if I draw 2 lines at right angles, each length 1 unit and then a diagonal between them, I know that's going to be a number with an infinite number of decimals, so somewhere it must get rounded up or down, but if I then add lots of those diagonals together, don't all those rounding errors add up and cause problems.
Probably best just not to worry about it.
Going to try @zoomer's method on a new drawing and see if it presents any problems.
-
I tend to draw with millimetres as my unit, and with "decimal precision" set to 1.
That's because, for architectural work you don't generally need to be more precise than a millimetre.
However - there's one issue I run into repeatedly which is (at least in the UK) a standard brick is 102.5mm wide. Of course, no brick is actually exactly 102.5mm wide, but this is the dimension used for various co-ordinating dimensions, and the 0.5mm will add up over multiple bricks.
It comes up, for example where I am drawing a cavity wall which is 102.5mm brick, 100mm air gap, 102.5mm brick. The overall width of the wall should therefore be 305mm. But when I make that wall style, because I can't use half millimetres I have to make it as 103+99+103, or 102+101+102 or 102+100+103 which is annoying, especially when I come to dimension things.
So - my question is, is there any downside to me changing to drawing with "decimal precision" set to 0.1 instead? Somehow I worry that I'm going to start finding all sorts of things that measure 99.9mm and so on, but I'm not sure this is rational. When I come to dimension things, I can set the dimension precision to "1" (because I don't want to produce working drawings with dimensions like 104.6mm all over them) and then for any dimensions that I do want to show as eg. "102.5" I can change the precision individually. Is that going to work?
Final question: if I change an already existing drawing from precision of 1 to precision of 0.1, is anything bad going to happen? Or does nothing actually change 'behind the scenes" and all that changes is what is shown to me?
-
4 hours ago, Ramon PG said:
I believe so, too... 2020 and newer. Thanks for the note.
Can't take both the M1 AND VWs 2021 hit right now.
I was in the same position as you... decided to go for the M1 and as a consequence had to go for the VW upgrade. I was on 2018, now on 2021. VW2021 is better than VW2018, but not lots better, and I only did it because I had to in order to move to the new mac. In and of itself, the amount I had to pay for the VW upgrade was not worth the limited improvements (and all the most annoying bugs and problems still remaining). Because I bought with a VSS subscription, I will be able to get 2022 as well, and so I'm going to hope that whatever it brings makes what I spent seem worthwhile.
-
1
-
-
11 hours ago, zoomer said:
Normally the Wacom monitor reconnects after I switched it off and back on.
AFAIK I had rare cases where I had needed to pull the USB out and back in
or even a restart too.
Yes, that works for me most of the time, but sometimes it doesn't, and it seems to change when I come back to the computer when I've left it overnight.
-
Seems like problems related to things sleeping or not sleeping or not waking is a common them with the M1.
For me, it's a monitor that sometimes refuses to come to life when I wake the machine. The problem always happens after the M1 has been left alone overnight (ie when it's been asleep for some time).
I've found that I can largely prevent this from happening by (1) switch off the troublesome monitor then (2) put the M1 to sleep, at the end of each day. No idea why this should make any difference but it seems to save me from the situation where I can only get that monitor back by restarting the computer.
-
2 hours ago, dtheory said:
This was in a main window.. main monitor.
I just asked because I've realised that OpenGL can become jittery when I have a floating view pane open - this affects the main pane and the floating view pane. I think there are various problems with floating view panes...but this is a subject for another thread.
-
3 hours ago, dtheory said:
I initially noted some funny flickering doing rotations of a smallish residential project in Open GL, which seems to have gone away, and I can't reproduce the problem, so not sure what's up there...
This wasn't when you had a floating view pane open on a second monitor by any chance was it?
-
I expect we are shouting into the void and we'll never get an answer to that.
Units and rounding: downsides of excessive precision?
in General Discussion
Posted
My experience when I did a bit of building work myself was that it's not as consistent as this! I'd get timber from one source and then some more from another, and then the studs would be 2 or 3 or 5mm different in one or other dimension, which is a problem if you are using them to frame the same bit of wall or roof. I learnt to be very careful when ordering and check what their 'actual' rather than nominal size was.