line-weight

Taper face command is often useful for this kind of thing (NB the second taper face operation, where I just type in 25 degrees, in reality you might have to create a guide line to snap to, to get the 25 degrees from the true vertical). Screen Recording 2023-02-16 at 18.44.22.mov

Yes, @Tom W. pointed me towards a thread about that, above. There's another one too, which I've already successfully used.

If you are tidying up annotations on a sheet layer with multiple viewports, it's quite tedious to have to click into the annotations space, then out again, for every single viewport. It would be good to be able to select multiple viewports, go to "edit annotations" and then have access to the annotations in all of those viewports at the same time, or at least to be able to switch between them with a single click.

Yes, it doesn't solve the problem unless you don't want any textures on roof face objects in the design layer. So, if you were using solid fill colours only it wouldn't matter. But I usually want to use a mixture of both (or solid fill colours might change to textures as the design develops)

oh, looks like there is also another script here:

^^^ would be great to have a version of that script that would just work on the active sheet layer, or better still on selected viewports only.

Well: the opposite seems to apply to roof face objects. If you leave that "Texture" box unticked, then class overrides work. If you tick it, class overrides stop working. Fancy that! This kind of consistent and predictable behaviour is what we all love so much about VW of course.

Don't suppose you have found a way around this? Each time it has to be deleted manually from the annotations space, right?

So. In the course of working out how to make data vis work, I found I could actually fix the wall object, so that class override works on its components, by (1) Making sure the "texture" box is ticked, in the relevant class settings (it wasn't previously) as per screenshot below (2) Resetting the wall object using a 0,0 move. However, a similar fix does not seem to work for roof face objects. Moving on to data vis - I have basically got this to work. There's an additional bit of setup that has to happen though, where I have a container object with [container class] and then objects within it with [material class]. Using class overide, the attributes of the [material class] are determined by that class, not the [container class]. But using data vis, what happens to objects with [material class] is also determined by the [container class] of whatever container they are within. So I have to set the criteria to take account of both. Basically tell data vis to exclude any [container classes] where I want to fiddle with attributes of objects inside them. This is kind of ok for the particular use case I'm dealing with right now ... but I foresee potential to cause problems with other things in the future. Certainly, even without that issue, converting large numbers of viewports to work using data vis instead of class over-rides, is going to be a tedious task necessary in any files I want to move from VW2021 to 2023.

Eurghh. Various key workflows broken for me then. It wasn't a problem in VW2021. I'd have thought class overrides were a fundamental enough thing that it's something we shouldn't have to worry about losing without warning. Should I be able to replicate class texture overrides using data vis or do I have to start using Materials too?

It is - as is the wall face object.

Hastily cobbled together example file attached. Two things actually going on here: - The over-ride is not working properly on the wall object - but I notice, it is working on the ends/sides* - It's also not working on the "roof face" object. *gives a possible clue as to what could be going wrong...have to go out for a bit but will investigate later override.vwx

I am in a similar position. VW 2023 SP3. I want a (styled) wall to appear with a certain renderworks texture, in a renderworks viewport, via a class override The container class, and all the component classes, are given the over-ride for the relevant viewport. The wall changes colour but the texture is not there. I too suspect materials (which I don't currently use) are getting involved. Here's the wall object's OIP, note the "material" cube icon appearing there hence my suspicions Here's the relevant wall style: Here's the settings for the relevant component of that wall style: Note the "use material" checkbox is *not* ticked and texture is by class. So it should take the texture of my class " *materials-masonry-brick". And that class is over-ridden in the viewport with the texture I want. As is the overall "container class" for the wall object. Is there anything I can do here or is this another workflow broken?

I've been seeing what it takes to stress VW out on my system (16GB Mac mini, VW 2023 sp3). If anyone wants to try replicating: https://we.tl/t-qD6Jn6aVxQ 1. Download & unzip file at above wetransfer link (about 1.3GB in size) 2. Make three copies of it (so you have four in total). 3. Open one copy in VW. In my case, apple's activity monitor tells me VW is now using about 16GB of memory 4. Open the other three copies in VW so you now have four copies open. In my case VW now using about 36GB of memory 5. In one of the open copies, update all nine viewports. In my case memory use goes up to about 60GB at which point I start getting alerts about system memory and VW eventually beachballs indefinitely. So it would seem that maybe you want to have at least 10x as much RAM as the largest file you want to work on - in order to open the file without starting to rely on swap memory. That doesn't seem to scale linearly if you have multiple files open. In my case, 5GB of open files means about 7x as much RAM. Once you want to start working on those files though, the multiplier looks like it might start to be more than 10x. Is this normal/reasonable behaviour memory-wise? I have no idea!

But I get the impression that people with 16GB, 32GB, 64GB of RAM are reporting this kind of pressure on memory. Maybe even 96GB unless @Wesley Burrows is experiencing some other problem. So just how much more memory is warranted?

Yes it was a true cube (as far as I know) - drawn fresh in a new blank file in VW2023 SP3. I've been seeing this in many of my models in 2023. However - just tried quitting & restarting VW, then drawing a new one, and the behaviour did not repeat. Further investigation required...

The video below shows me attempting the same operation in VW2021 and then 2023. Using the "extrude face" mode of the push pull tool in 2021 simply gives me a larger cuboid. In 2023 it gives me the same shape - but with each of the extended faces somehow split into two coplanar faces. This then has consequences for further editing - as demonstrated. Is this an intentional change in the way it works? Am I now supposed to use the "move face" mode instead, when I don't want this result? (It's possible this change happened between VW2021 and 2022 - I skipped VW2022 altogether.) Screen Recording 2023-02-07 at 17.48.48.mov

Here are the notes I wrote to myself when I was last trying to puzzle out how the grid tool works..... Put grid line objects on dedicated “grid” layer Put them in class “none” (to make sure they’ll appear in all viewport annotations) Grid line objects can be styled. Grid line style has design layer grid line instances called “grid line definitions” (drawn on “grid” layer). Each design layer grid line definition has its own letter/number (label) Each definition has a real-world start and end point. Then each of those has multiple instances in viewport annotation spaces Changing “show bubble at” in a definition doesn’t change already-drawn VP instances Changing “shoulder length” in a definition does change already-drawn VP instances Changing start & end points in a definition does change already-drawn VP instances Changing “bubble scale factor” in a definition does change already-drawn VP instances To avoid confusion, when drawing grid line definitions in the grid layer, leave shoulder length and bubble scale as per style. Changing attributes in VP instances only applies to that VP instance. [for now] attributes of grid line “lines” and “shoulders” set within style and not by class, and take on class of object (none) A kind of default “Shoulder length at” and “show bubble at” can be set within grid line style, and will apply to any newly drawn definition, but can be overridden in any definition and in any VP instance (in the OIP) Grid lines should appear in any viewport: – where GRID layer and none class are visible - where they are perpendicular to the VP view direction - where they are within (or intersect with) the VP’s crop - where, in the grid line definition’s OIP, under “grid line instances”, the relevant viewport has a tick against it. NB therefore grid line visibility in viewports is controlled by the definition’s OIP, not within the viewports’ OIP. A GL instance’s start & end in a VP are determined by the crop box (unless real world start/ends as drawn on Grid layer are inside the crop box. But can then be overridden manually. Manual adjustment will be remembered if crop box subsequently changed.

I never use hidden line in design layers so am unfamiliar with how it works.... it seems the teapot is there for a while, then disappears, but it's not actually finished rendering yet, and there is then a green "Stopping Render" message in the bottom bar...and then at some point that eventually disappears and it's finished.

Hrm... I posted the screenshot above, went away and had my dinner and stuff, then came back to the computer to find it looking like this... so it had maybe not entirely finished doing its render.

Here's what I get on my mac mini

This has just reminded me I was going to give this app a try as recommended by @E|FA

I'm too lazy to use the space bar - I'd have to move my left hand several centimeters. Moving my right thumb a few millimeters is just about an acceptable amount of effort. Also - space bar is so commonly used for panning, in all sorts of applications, I'd be worried I'd confuse my brain/muscle memory if I started using it for something else in VW.

I mean this thing, (smart options display?) It works for me because I just press one button and all the options are there visually for me with icons my brain has already learnt to recognise.

I just use one of these https://www.logitech.com/en-gb/products/mice/m705-wireless-mouse.910-001949.html I like the weighted scroll wheel, the scrolling is smooth and you can scroll rapidly by sending it spinning. Only thing I don't like so much is the two buttons in the thumb position, they are a bit awkward because where my thumb naturally sits, it presses both of them at the same time. But I have the VW "quick actions" menu mapped to come up when I press those. I find there are only so many macros and mapped buttons that I can keep in my head at once so a mouse with a zillion buttons isn't that attractive to me.