line-weight

I'd be interested to see how you decide to resolve the dormers. Can the roof objects and/or EAPs (is that extrude-along-paths?) be made to understand how to intersect with them?

Completely agree with all this. Another problem with the current stair tool is that what it produces in 3d is made up of polygons rather than solids. So it's not even possible to get it to build you a "nearly right" version, convert to solids and edit manually.

- how would you draw the dormer cheeks? - how to make the dormer cheeks join properly with the roof and wall elements? - would VW know to cut the dormer cheeks at the right height? - can the slab you use for the ceiling have angled edges to meet the roof neatly? My view is that making all the above work (especially if wall/roof components are to be shown), if it's even possible, would probably be more time consuming and less easily editable than just doing it all as directly modelled solids.

I also feel that it has gotten worse, although it's hard to be sure, because maybe I am also using VW in different ways. But at the moment 2018 does feel very glitchy in general. I'm half considering going back to 2017.

Yes, I have discovered this has been causing some (but not all) of my problems.

I've tried copying the symbol into a new file; the problem remains. Attached with this message if anyone wants to see if they can replicate. Go to saved view called "perspective view" You'll get an OpenGL view of a 3 panel sliding window, consisting of some grouped elements, some of which are symbols. Go into the group and double click on either the middle or right hand window panel to edit the 3d component of those symbols. For me, this throws me into an orthogonal/wireframe view. (I've not yet been able to replicate the problem I was having with objects disappearing in a top/plan view multi pane.) vwsymbol.vwx

Ok: I think I may have found where the problem is - I use saved views quite a lot, to switch viewpoints and visibilities. In some of these, the "restore unified view" checkbox is ticked. It seems that a couple of these restore unified view to "off". I've checked opening the same file in VW2017; the same applies but it doesn't seem to cause problems when there are no multiple view panes. For now I've unchecked the "restore unified view" boxes and will see how things go.

Turning on unified view improved things for a bit. However, it seems that it keeps getting turned off without me doing anything. For now I think i'm going to have to come to the conclusion that multiple view panes is unusable, at least with this file.

And going in to edit the 3d component of some symbols, but not all, I am inexplicably thrown into a different render mode and projection (I am working in openGL/perspective, double click to edit a symbol, and suddenly I am in orthogonal/wireframe) What a mess.

Additionally, I seem to have a situation where an object (a symbol within a group) does the "invisible" thing when in a top/plan pane, with unified view *on*. Turning UV off makes it appear, but then the other pane gets messed up.

@JimW I've realised that turning off UV doesn't solve this side issue ^

I've send you the file by private message. Thanks.

Ah - turning on unified view sorts it. I'm not sure I understand why. Maybe I need to do some homework. In light of unified view having seemingly solved things - would you still like me to post a file?

That doesn't seem to make any difference.

See the attached screen recording. When I attempt to enter a 3d symbol to edit it - all the components become invisible. They are still "there" as they highlight under the cursor. Those components which are extrudes: editing the extrude renders the polygon visible. If I edit the same symbol via the resource browser, the same does not seem to happen. Also: the symbol's name does not appear in the OIP as I think it ought to. (These problems are arising in a file which has been converted from 2017) vw3dsymbol.mov

Have just tried this and I see that disabling colour: - does remove colour - does remove the image maps associated with the textures (whereas you might expect that it would make them greyscale) - doesn't remove the transparency associated with the textures As ever with VW not exactly intuitive but useful to know. The reason I like to have the colours on is that I find it makes models more legible whilst working on them - provides distinction between materials (or whatever you use your classes to control) without the distraction of the tiled image maps, which can make edges hard to see.

Ah, ok. Cheers.

So, what does that "fill opacity" slider actually do?

For editing and for early-stage models, when working in OpenGL perspective views, I like to turn textures off (under "OpenGL Options"), because I find them distracting when working on the basic geometry. However, this makes any material that should be transparent, like glass in windows, appear solid, which is not what I want most of the time. Also, it means I can't really use this mode for creating quick presentation images and so on. One workaround is to give the objects that I want to appear transparent "no fill". That works in the basic OpenGL view but it then means that textures aren't applied if I switch them on or do a rendering. I control materials by class. When I edit a class, in the "Graphic Attributes" dialogue, under the "fill" options I can adjust opacity. This ought to so what I want, but it doesn't seem to have any effect in OpenGL view. Am I missing something?

I've got a drawing that I've converted from VW2017 to 2018 (this drawing started life several versions ago) When I enable multiple view panes, create a floating pane, make that one top/plan view and the main one perspective OpenGL view, the navigation in the OpenGL pane goes completely haywire. Any adjustment of the view using a 3dconnextion device or via the zoom scroll wheel on the mouse sends everything off into the far distance (I think - the result is in any case, it's impossible to see or navigate the model). I've tried making a new blank file, drawing some simple objects, and doing the same thing, and I don't get the same problem. Any suggestions as to what is happening / how to fix it?

You'd probably also end up with objects in complicated nested groups of some kind, especially if (as I do) you use class to control material as well. I already use class to, for example have an "open" and "closed" door - the door is a symbol made up of various parts each which are classed according to their material. Then there are two instances of that symbol, one in open position and one in closed position. Each instance in turn is in a different class, called something like "visibility_door01_open" and "visibility_door01_closed". This does tend to lead to a large list of classes, although it can be kept in check to some extent using the submenu method. If there were then also to be LOD visibility classes, they would have to be somehow applied within the symbol but at a higher level than my "material" classes. I've wondered in the past whether things would work if objects could be placed in multiple classes. This would avoid the need for nesting type strategies. Something could be simultaneously in a material class and a LOD class, for example. It would only be visible if both of those classes were activated. I've not thought it through fully whether this would work!

My current approach: Draw the basic model as accurately as possible, but don't expect to be able to use it for drawings any more detailed than 1:50, and possibly not even showing things like wall and roof components at that scale, because it's just too much faff to persuade them all to join correctly (certainly for anything to be used as construction drawings). So, for scales larger than that, revert to the old 2D drawing methods, but use the basic model in the background as a reference to keep things co-ordinated, and as a quick way to get the right section geometry - in other words, trace off section viewports. This at least saves the time it takes to project section geometry manually. But of course, updating the 3d model won't automatically update all your large scale, traced, detail drawings. I should say that the projects I've currently got at construction stage are ones drawn with the "old" method - all 2D. The ones I've got drawn up in 3D have only got as far as planning stage, so I haven't yet really tested the method I describe above, for progressing beyond 1:50 scale, on a "live" project. I've seen from your other threads in the past, that you've done pretty well at generating construction sections showing wall/floor buildups and so on (in fact I watched your presentation at the VW BIM day in London a year or so ago). However I've noted that those designs are all fairly rectilinear. Things really start to get tricky when you get involved in pitched roofs, split levels and so on. There's a reason the example that the VW people presented at that same BIM day was called something like "cube house" or similar.

Christiaan This is a problem I am continually wrestling with as I have recently been doing several projects that involve loft conversions and/or other work on existing buildings that are complicated in 3d, with split levels, intersecting pitched roofs and so on. As I linked to on the other discussion, here is a thread I made when I first started trying to work out how to do things using a 3d model (up until then I'd effectively been doing everything manually in 2D): https://forum.vectorworks.net/index.php?/topic/42959-generating-usable-floorplans-for-roof-spaces/ That was a couple of years back; in the meantime, I have developed a method of sorts but it's far from tidy. You might be interested in looking at this screen recording where I try and show how a more recent drawing is structured. You can see that at both of the floor levels I show, I've got a combination of a horizontal section and a top/plan view. Each cropped to odd shapes to the fit together into the final drawing. There is a certain amount of patching-up (hiding lines that shouldn't be there, and so on) that I do in annotation space. This drawing makes use of auto-hybrids to an extent. (NB towards the end for example that this is how I've created the party walls at loft level where they have to follow the profile of the roof, and incorporate chimneybreasts - trying to draw these using the wall tool was just too much hassle and unstable). However, I've since stopped using autohybrids because I have found they create too many new problems. Mainly to do with ease of editing, because it's difficult to move elements in and out of them due to the fact they have their own internal XYZ system. So elements that in this drawing example were autohybrids, visible in the top/plan portion of my composite drawing, I'm now more inclined to simply model directly and include in the horizontal section portion. This means that when I get to loft level, hardly any of the final plan is generated using top/plan - in fact it might literally be cropped right down to just a couple of doors and part of a partition wall. Top/plan is also not much good at showing things that have been directly modelled, on lower stories, in top view. In this drawing an example is the roof of an existing victorian ground floor bay window, which I want to see in my first floor plan. This had to be directly modelled as there's no hope of using the standard VW window, wall and roof tools to create something that sufficiently resembles the reality. So the top view of this is included in my horizontal section viewport crop. I'd certainly like to find a less labour-intensive way of dealing with these kinds of situations. It perhaps helps explain why I think we urgently need a rethink of how plans are generated. We need an "intelligent" horizontal section method. One that can section through solid modelling elements as well as parametric elements like doors and walls and produce a sensible and reasonably customisable result. Anyway here is the screen recording. Don't know if any of this makes sense to anyone else. Happy to answer any questions. vw_example_roofspace.mov

See also this thread: https://forum.vectorworks.net/index.php?/topic/42959-generating-usable-floorplans-for-roof-spaces/

The most basic example of where it fails is the generation of a plan within a pitched roofspace. I don't think that buildings with pitched roofs are exactly outside the area that an architectural drawing package should be expected to be capable in. I've not found it possible to build a 3d model of a roof space, and then have top/plan generate a proper floor plan from that, where the cutting plane understands what's going on. If you have examples where you think you've managed to do this I'd be interested to see them. Yes you can get some of the way with autohybrids - but they cause so many subsidiary problems that I've given up using them. And top/plan isn't even intelligent enough to know that a join between an autohybrid and, say, a wall is continuous and that you don't want to see a line there.