line-weight

The other thing that has bugged me about multiple views since they arrived - and I think it was discussed at the time - is that it's too easy to do stuff and have it happen in the wrong view pane. For example, zooming in or out or changing visibilities. I think normally expected behaviour would be that if your cursor is over a view, then that's the view which is going to be affected if you do something. In VW, you often have to click on the pane to be quite sure that's the 'active' one. The title should turn blue as soon as the cursor is over the pane. This is particularly the case with floating panes on other monitors.

@Josh Loy if you are the multiple view pane expert, can you offer anything on the question I asked here - https://forum.vectorworks.net/index.php?/topic/80100-macos-how-to-keep-vw-floating-pane-alive/ This aspect of the floating view pane's behaviour is quite frustrating.

Has anyone tried running VW2018 or 2019 on it? (Or are they completely out?)

This might be useful for anyone who, like me, is interested in the M1 mini but wants to run more than 2 displays. Here he has 2 extra running: And here with 6:

I'm not sure if this is something that's under the control of Vectorworks, or macOS. I'm using Mojave, and VW2018 at the moment. I have three monitors and I often want to have things arranged like this: Monitor 1: Vectorworks main window Monitor 2: Vectorworks floating view pane Monitor 3: Other things (eg web browser, image viewer, etc) The problem is that I can get this set up, but when I then go to monitor 3 and start doing something in, say, Firefox, the VW floating view pane on monitor 2 disappears. To make it appear again, I have to go to Monitor 1 and make VW active, and then it re-appears. Is there any way of stopping this happening?

My feeling is that while all these ideas for automatically framing around windows and that sort of thing would be really great if it could be made to work.... it's way down the line of things that need to be urgently fixed. Make the windows themselves work properly first, for example. Because if the windows are essentially unusable at a construction detail level, then there's not much point trying to make the walls able to frame around them. And while it would be great for VW to automatically create correct corner junction details in timber frame... can we first get it to work properly with basic monolithic materials like masonry, please. As pointed out above, timber frame corners are not usually mitred in real world construction.... but neither are brick wall corners, whatever VW thinks.

Is the "structural member" tool now reliable and free of bugs? Last time I tried using it, it certainly wasn't. I currently draw all my structural members, and any wall studs, manually from scratch as extrudes.

That's certainly interesting to hear ... it seems I could be confident that it would outperform my refurbed 5,1 classic Mac Pro, where I'm trying to decide if it's worth upgrading the GPU to make it last another year or so before becoming entirely obsolete. The price of a new M1 mini does not make the price of buying a new video card for the Mac Pro look like very good value.

Does this mean you are getting better performance overall from a base-specification M1 mini, than you were from a trash-can mac-pro?

This really, really should not be necessary though. 4 different stair tools, all of which have different problems or limitations. Sort it out, VW!

Thanks - did not know that! For whatever reason that tool is not in my workspace but I've just added it. Having just had a look at it I can see that yes it does produce extrudes, which is loads more useful than the other stair tool. Looks like it can't do winders... but better than nothing.

There are ways but my experience of doing it to stairs objects is that it's immensely time consuming because you have to do a lot of ungrouping and then repetitive stuff like you have to do each step independently (as far as I recall). I hardly ever use VW stairs now, for these reasons. Unless you are doing a really bog standard stair, it's quicker to model the whole thing directly from scratch. Why the stair tool outputs something made up of polygons instead of solids I really don't know. I though VW was supposed to be a solids modelling programme. Why design it like that?

The X Y and Z could, alternatively, be colour coded in the dialogue box to match the axes on screen. I'd like this for the "move" command as well. I'm forever doing that by trial and error.

Not very easily though, because it gives you a bunch of meshes and 3d polygons rather than solid objects.

Hm. Let's hope that these issues can be fixed, then. It'll be interesting to see whether the higher spec mac minis when they announce them (later this year?) offer anything different in terms of peripherals.

Do you just use 1 monitor @zoomer? I am quite interested in the new mini but I like to run 3 monitors. I know it's not supposed to manage more than 2 but it seems some people have got 3 working by various means.

I name all my classes with a * prefix - this way, all of VW's auto created classes go to the bottom of the list and I try and just ignore them. At some point I decided that's easier than trying to track them all down, and it doesn't generally seem to cause problems.

I generally find that once a slab starts refusing to be edited, it is likely to do a disappearing act some time soon. My solution - only use slabs when there's a major benefit over other more reliable objects - if one starts being troublesome or disappears... go back through backups, find a version where it still seems to be ok, copy and paste that back into the file. Alongside the automatic backups, I tend to make a separate "safe save" of any important VW projects I'm working on every day or two... these are often useful to go in and retrieve non-corrupted earlier versions of objects. Not ideal. But maybe they'll get around to fixing it within our lifetimes - we'll see.

Let's not get impatient... they've only had 5 years to fix it.

This applies if I use the "true curve" rather than the faceted version for the path, right? Because, once it's been converted to a segmented version, the end profiles are no longer perpendicular to the end segments of the path. This started me thinking... is there a way to facet the path such that the end profiles *are* perpendicular to the end segments? If there is, could this mean that each section of the wall/viaduct could be constructed from an EAP rather than a lofted object? The advantage of this would be that having constructed your wall/viaduct, you could make alterations to the profile without having to rebuild everything including the path. As far as faceting the curve is concerned, I am thinking along these lines: I have just shown a circle quadrant rather than a NURBS curve, for simplicity, but I think the principle would be the same (?) Black is original "true" curve, green is the method of faceting used by the current script, blue is an alternative, which means that the end facets would be at right angles to the true curve at its endpoints. I expect there is some reason this wouldn't work!

It seems to me that what you have come up with works as well as is possible within VW's limits and is a method that will be very useful to anyone trying to deal with this kind of geometry. I hope that some people at VW will take the time to go through it and understand it fully, most crucially understanding the problems that it solves. I think the principle of making things "exactly correct" at the control profile locations is sound. And then what happens in between them is 99.9% correct but most importantly does not create the horrible buckled, messy geometry that you highlight in your examples of why the seemingly most obvious approaches don't work. In my particular use case for this... the biggest test would be using it to try and create a junction between two converging viaducts. When they are only curving in plan, it's quite straightforward to see how to do this, but my brain starts to hurt when I try and think about the geometry if there are also curves in elevation. I'd be interested to see if you've managed to do something along those lines...but that perhaps should be a separate discussion. In any case thanks very much for your work on this!

My next question is about drawing a NURBS path where it needs to transition from a straight line (or even a radiused curve). For example, let's say this is plan view, and the grey rectangles represent straight sections of wall, or viaduct, or whatever. I want to create a curved connecting section using a NURBS path. Drawing it in "interpolation point mode" doesn't work because (I think) there's no way to ensure that the ends of the NURBS curve are exactly square to the ends of the straight sections: However it can be done in "control point mode": If I then place a profile at each end of that NURBS curve ... how do I then find all the "parallel" curves? Because I have to draw them in interpolation mode. I'm not going to get the correct result by trying to draw an interpolated curve between two points. So I can split the curve and introduce a third profile in the middle somewhere. Will that give me a correct curve? Or is it a case of the "parallel curves" becoming more and more correct, the more intermediate profiles I introduce? I have been too lazy to try this for myself out before typing this post... but suspect it's something you've already gone into.

Thanks. I guess that's what I'd 'intuitively' expect - that the more control profiles, the more accuracy. Do you feel you understand sufficiently the maths behind the way NURBS curves are constructed, to say that in theory (assuming all the profiles are perpendicular etc) the NURBS should all be exactly parallel?

There's a question that this method raises for me: - I draw a NURBS path, through each of the control points I want - assume the profile, set perpendicular to the path, at each control, is exactly the same at each of those points - then I draw all of my other NURBS paths, using the vertices of the control profiles along the way - am I right in saying that all of those NURBS parts I've drawn are not necessarily exactly parallel? To test this I've made a very simple example... the profile is exactly square, 690 by 690. There's just a start profile, an end profile and a mid profile. It's curved in plan only. I've constructed the 'wall' using the method described. If I measure the width of that wall at each of the profiles, it's 690 as expected. But if I measure its width between each of the segment vertices (which ought to be at positions exactly on the 'generating' NURBS curves) then it varies very slightly... in this example between 687 and 691. Is that just an inevitable result of the way VW produces the NURBS curves? I expect that this is something which in practice usually wouldn't matter... but it might in certain use cases, and maybe it would become more marked with more complicated curves. I can see that maybe you could try generating the extra NURBS curves by doing them as a parallel offset from the originating one...would that work? I think it might when they are on a 2d plane but then things would get complicated in 3d. parallel-test.vwx

In the meantime though - I've successfully built one of the sections and it looks good - nice clean geometry. Going to mess with things a bit now and try it on some different profiles. Your step 6 can be simplified a little, I think. Instead of creating 7 individual lofts - it seems to work to select all 7 lines as 'rails' in sequence - and then tick the "ruled" box as well as the others (this makes it join them with straight lines instead of a crazy loopy one) and then you can do the whole lot on one go. Unfortunately, it doesn't make a solid with end caps on - you still have to add these as you describe.