line-weight

I've found the previous thread on this subject (see below). In fact what you describe is supposed to be possible, but is not, due to a bug identified last year. Has anything been done about it?

This is something that's been discussed/requested before I think. It's very tedious as it is - it seems there are few situations where you would want to adjust the crop and also have the viewport shift on the sheet layer (as currently is the behaviour). There's also the question of what happens to the annotations. Some annotations you might want to stay in place relative to the design layer, but some - for example, things like drawing labels, northpoints and scale bars, that you want to stay in place relative to the sheet layout.

I would rather see Renderworks improved, or replaced with some other integrated renderer, than removed. For me, it's a big benefit of VW that I can do everything within one file. I hate workflows that involve constant importing/exporting between applications. As it is, I can make a minor update to the model in VW and it is then present both in my main drawings, and any renders that I want to generate. I don't want to be making decisions about whether it's best to make changes to the 3d model within VW and then export, or in an external application, then have to duplicate it in VW. I often have drawing sheets that contain sections, elevations and renders. I like being able to simply update all the viewports instead of messing about importing images and so on. It's fine if whatever is integrated/included with VW is not a fully powered renderer - for producing high quality presentation images it's ok to use an external renderer and invest extra time in those images. But a lot of the time I want to do OK-quality renders quickly and efficiently. Speed and efficiency is important.

You draw the ten objects... then you have to select them all. If you're lucky you can draw a window around them all - but if they are scattered around the place it's some scrolling around and shift-clicking to get them all selected. And if some of them are in groups... or on different layers....

I quite often work with a "guidelines" class active (especially in 3d). This is a class I use for setting-out geometry that I can switch off when I don't want it visible. It means I can quite quickly do a load of generating geometry, then draw the "real" objects and class them into whatever I want them. Because I can switch this guideline class on and off, I don't need to worry too much about cleaning up behind me. Sometimes I want that geometry left for future reference anyway. This wouldn't work for me if I stuck with "none" as the active class. Just my workflow of course.

Still ten extra clicks! And if they are scattered in different locations, not so handy.

Sure, you can do it either way, but there are certain situations where using the "active class" method seems the most obvious, for example when I want to draw ten objects in the same class. It would be rather tedious to draw them all in "none" and then change them each individually. Much quicker to set the "active class" to what you want and then just draw them all. You might say it's user error to then forget to switch the "active class" back to none, but my experience is that this happens a lot. It seems I'm not the only one. Sometimes there might not be anything wrong with the programmer's intention but it turns out that when it comes to real life use, the system created tends to make errors likely. For me, direct visual feedback is a reliable way of keeping track of what class I'm drawing in. If that's also how others work, then I think it's legitimate to criticise the way the extrude classing works.

Maybe some more consistency would help... > If you change the class of a group, then it doesn't change the class of the objects inside it (unless you ask it to). > If you change the class of an extrude, it does change the class of the profile inside it. > If you change the class of a solid addition, it does change the class of both solids inside it. In these cases extrudes & solids behave similarly, and groups do something else. > If you group an object, the group takes the "active class" > If you extrude a profile, the extrude takes the "active class" > If you perform a solid addition, it takes on the class of one (which one?) of the solids you've added. In these cases groups and extrudes behave similarly, and solids do something else. (I had to go and try doing each of these things to remember what happens. Because there's no easily discernible consistency, it's very hard for the user to remember what's going to happen in each case. Hence mis-classed objects galore)

If your standard workflow is to always have 'none' as the active class then I guess it doesn't affect you. However I don't think that's everyone's workflow, and it's clearly not intended in the design of VW that the software should/must be used that way.

Here is one of the ways things end up in the wrong class - I create the profile polygon in the "right" class. I know if I'm drawing it in the wrong class because it'll be the wrong colour. (I use colour as my visual cue to how things are classed, at least at a "materials" level. I know that not everyone uses classes in the same way.) Then I extrude it - and I extrude it in the "wrong" class, because I happen to have some other class active at that point, but there's no visual cue, because it continues to be displayed in the polygon's class. So it stays like that until I notice it's not showing up in views where it should be. And then I have to go and sort it out. Confusingly, if I draw the polygon in the "wrong class", then generate the extrude in the "right class", the polygon stays in the "wrong class" and the extrude displays in the wrong class colours. But if I then change the class of the extrude, the polygon inside it changes too. This does not seem intuitive. Are the polygon and extrude classes independent of each other or aren't they? I'm not sure your use case of two polygons inside an extrude, each of them a different class, is something that's commonly needed. If it is, then it'll be messed up whenever the class of the extrude is changed, for the reason I describe above.

I'm bumping this thread as it's something that causes me constant irritation. I note that it was "considered a bug" six years ago but nothing's changed. I'm forever going back into extrudes to change the class of the generating polygon, or changing the class of the extrude itself, because objects that I expect to be visible based on their class aren't.

vectorworks was initially designed to work in 2d (as I understand it) with the 3d element gradually being added. As far as I have worked out there's not actually any "official" way to deal with what you describe - drawing the basic geometry in 3d then adding detail in 2d. They pretend you can draw it all in 3d (at least, up to a certain level of detail) - using things like the wall and roof tools, but as you will have found, that really only works for quite straightforward and rectilinear stuff. As soon as you get into drawing things like lofts and dormers you've really no hope of building it with the standard tools and producing something with useful constructional detail (in my opinion, anyway). I can tell you where I have ended up, which may or may not be of use to you. Recent projects I have tried drawing in quite a bit of detail in 3d - to the extent that I can almost take 1:20 or 1:10 constructional sections straight off the model. This involves modelling a lot of stuff directly, abandoning things like the wall tool in certain instances and building the individual layers of construction (and things like timber studs) individually. This probably sounds rather laborious - it is, but I've found it's not as laborious as you might think, and probably still saves time compared to previous workflows where all that stuff was drawn in 2d (but had to be copied/redrawn between multiple details). Once you get your head around it you can be a bit strategic - for example, you don't have necessarily have to model the internal detail of each wall for its entire extent, you can model it to the extent that is necessary to produce your GAs, and then certain portions in more detail, where you are taking a section. But you kind of have to keep a consistent level of external facade detail, for example, so that elevations look OK. I'm still trying to find the right balance of detail in the model vs detail added in 2d annotations - the right balance is probably different for each project. I do add detail in annotations but try and keep it fairly minimal. One of the weaknesses of annotations, as you've alluded to, is that it's not really attached to the underlying model at all. So if the underlying geometry shifts, you have to go and shift all that annotation stuff manually to match. Something else to know about annotations - VW does not do a great job, when it comes to producing the final drawings as PDF or whatever, of integrating the linework of the 3d and annotation parts of the viewport, with slight misalignments sometimes being visible. This is most noticeable if you try and "blank out" errant lines generated by the section - you can try and do it by drawing white objects on top but the result is always slightly messy. I've complained about this on here many times, and asked if VW has any recommended way of doing this, but have only been met with silence. This is one of the bits where VW just doesn't really work well, and I think there's a denial of the reality of how people want/need to produce working drawings.

Is there a reason why you don't want to use annotations?

Good work @Benson Shaw! Is it just an artefact of the rendering that it appears the 'fabric' has a bit of an undulation in the middle of this section?

That's great to hear that these issues are being looked at. I hope some progress will be made. But they aren't new. This is no criticism of you: but how has this mess been allowed to exist for so long? Here's a thread from 2007 with someone confused by pretty much the same thing. That's 13 years ago. 13 years! Will we be coming back to this in 2033?

Yes I agree. To add to the confusion, I think the shortcuts will rotate planar objects in 3d views, but it rotates them relative to the screen plane or something, so you don't get the result you want. Therefore I just don't touch them unless I'm in top-plan.

The excellent analysis by @Andy Broomell of the multiple ways in which these particular elements are confusing is illustrative of a common theme across the whole of VW. There are so many tools that have similar problems. Many instances of two tools that do nearly the same thing, inconsistent naming of functions, and much of it not properly documented, so that the only way you can figure out how things actually work is to spend a large chunk of your own time untangling it. I wonder if the notes I've written for myself on how VW functions work may soon be more extensive than VW's own help pages. Occasionally I do what @Andy Broomell has done above - write out a detailed explanation of why something's ultra-confusing. And then several releases later - nothing has changed. I feel sorry for anyone trying to learn VW from scratch.

Do you mean rotate left/right by 90 degrees via the menu command or shortcuts? While these don't work, you can still use the rotate tool in 3d views.

Are they actual mesh objects (rather than groups of 3d polygons)? Also, have you tried fiddling with the OpenGL options (crease angle can be adjusted here as well as in document preferences)?

@rseybert my recent experience trying to use NURBS curves has led to me the conclusion that VW simply isn't much good at them, if you want accuracy. You might find some of this thread (perhaps more towards the end) of interest.

It seems to defeat the purpose of offering the 'user origin', if stuff like this starts happening though. It seems like a bug to me - unless there is some good reason for it to work this way.

Hm - it seems that the internal origin and user origin are not aligned, and it looks like this is the cause (judging by the offset). I had not changed the user origin myself - but something must have happened when I imported a DWG file. Thinking about it - in another file where I've been having similar problems, I had set the user origin myself (I think). Is this therefore a bug?

Ok... thanks for the reply. For me it's been happening in 3d space. Might see if I can post the relevant file here if I get time.

I'm aware there are various issues with symbols (and other containers) and internal origins and so on. But I'd like to know if the following is something that's not working properly, or the error is mine. I thought that if I (a) create a symbol (b) leave the original instance in place (b) specify the insertion point of that symbol as the drawing origin 0,0,0 Then (a) that instance of the symbol should have its internal origin in the same location as the drawing origin. (b) therefore copying something from outside of the symbol container, then doing a paste-in-place within the symbol, should result in that object staying in the same location Is all of that correct? Because sometimes the paste-in-place ends up with the object somewhere else, and I can't work out why.

Do I need to update the title of the thread linked below to read 'VW2021' instead of 'VW2020'? (I've not used 2020 yet myself)