line-weight

After extensive fiddling around, I realised it's the refraction setting in the glass transparency shader that affects this. Turning it down to only slightly over 1 has gotten me a little closer to what I want.

Trying that doesn't seem to make much difference - you may have misunderstood what I'm trying to reduce, which is the dark grey/black you can see along the 'edges' and facets of some the glassy elements. Here I have highlighted a couple of examples:

In a further unwelcome twist to this story ... it would appear that for some reason, re-rendering a viewport, without changing the crop or anything else about it, is liable to result in a new image that is just a few pixels different in size from the previous one. So, any workflow that relies on being able to replace the old render, with the new one, in exactly the same position, gets broken.

I've just had one of those mornings where I've basically been doing unpaid testing for vectorworks, because that's the only way I am going to get semi-predictable results using the heliodon tool. My conclusions at the moment: 1) Just don't even think about touching any settings in the visualisation pallete when dealing with viewports. The over-rides here, for switching lights on and off, just seem completely unreliable. 2) Instead from now on I'm going to control which heliodons are on and off by class and by class only (as @Matt Overton suggests above). 3) So the heliodons are "always on" where they are sitting on whatever design layer they live on (I have a dedicated "lighting" layer). Each has its own class, and it's that class that gets turned on or off per viewport. 4) There's another bug which I don't know if it's been noted before: if you change a heliodon's class in the OIP, it doesn't actually change its class. Look in the visualisation palette, against that particular heliodon, and you'll see in the "class" column that it is still in its previous class. This caused me much confusion until I realised this, because I'd put the heliodon in the class I want, turn that class on in the viewport where I want it, but the heliodon would not be active. So, if you want to change a heliodon's class, it seems you have to activate the class, then create a new heliodon with all the same settings. One of the biggest problems I have with heliodons is that I change the sun brightness, but it doesn't take effect, or causes unpredictable results, usually being brighter than expected. I now wonder if what has actually been happening is that there are actually duplicate heliodons active, even though the vis palette says there are not. Anyway, I'm now implementing a strict "by class only policy" and will see if this helps at all.

There are so many bugs with the Heliodon tool, it's hard to know which one is causing a problem at any one time.

Does anyone else have this problem all the time? It seems that if you change the "sun brightness" setting of a heliodon, whether that actually takes effect is highly unreliable. I can do a rendering with it set at 100%, then change it to 50%, redo the rendering, and sometimes I'll see a difference and sometimes I won't. I can't work out a consistent way of getting around it: making a new heliodon and changing the setting on that? Duplicating the heliodon and then changing the setting? Closing and opening the file? Quitting and reopening Vectorworks? Is there something somewhere I might be missing?

I'm not sure which setting you mean?

Yes. At the moment I'm doing something slightly complicated that involves exporting a large number of renders that need to be an exact pixel size for a website. All I need is to be able to right click on the viewport and extract what I know VW can produce (because it produces it if you do cmd-K on the veiwport). I can't really use the exact-size sheet method you describe because the number of viewports, and I want them on the same sheet so that I can transfer class settings and other stuff easily. Doing a copy-to-clipboard nearly works but it adds a white border, and something weird happens to the resolution which is then a big faff to sort out in an image editor. I did some experiments to see if there was a sheet resolution that would produce output from the marquee tool that was the same pixel dimensions as VW had actually rendered. It turns out it would have to be something like 92.26dpi, and the sheet settings only accept whole numbers. If I try with 92 or 93 dpi, the marquee tool gives me an image that is just a few pixels larger or smaller than the actual rendering, so it must resample it somehow and this must result in a loss of image quality. The saviour is the great script produced by @herbieherb which can be found here. That gives me something reliable and predictable (and also allows me to batch export a bunch of images, already named correctly if I give the viewports names). Unfortunately it doesn't export anything on an annotation layer though. So it looks like my workflow is going to have to be -Export from VW using that script -Open in an image editing programme, and do all my annotations on layers in there -Export from there to produce the final output The whole step of messing around in an image editor could be avoided if VW could just provide a very simple command, which we know would be technically possible to implement, and which was requested at least five years ago.

It's 1,000,000,000 mm3 = 1 m3!

Just dropping by, FIVE YEARS LATER to note that this bug is still not fixed, in VW2018 or 2019. I don't have 2020 yet. Don't know if anyone can confirm whether it's still an issue there? I'll put my money on it not being fixed.

Thanks. It's already set to zero on that texture (the top one of my images), though.

Thanks! Yes, I have tried playing with these settings a bit, but without full understanding of what they each do. I was hoping someone might be able to point me to the specific things that will affect what I'm trying to change ... otherwise it is quite a long and tedious process of trial and error.

Here are some test renderings for quite a complicated model. You can see that there is a bunch of stuff that I am rendering as if it's glass - the idea being that the parts that I've highlighted in a kind of beige colour are visible through it. In the top image, I've used the "glass frosted 01 RT" default texture. It sort of looks how I want it, but I'd like to reduce the very dark portions that mostly appear along edges, but also on some angled faces. What's the setting that I should be fiddling with to reduce this? Are they reflections? If so, I can't work out what they are reflecting, because I've got a pure white background. The bottom image is the same model but using "plastic transparent polythene RT" instead. This has no dark edges, and makes the highlighted elements more visible, but I don't like the look of it so much - it doesn't really look like a real material. So I guess I'm aiming for something that is in between these two materials. Any tips?

It's scientific notation (E notation) https://www.calculatorsoup.com/calculators/math/scientific-notation-converter.php 7.59e+006 means 7.59 x 10^6 (10 to the power of 6 which means 10 with 6 zeros after it) So, 7.59 x 10,000,000 = 7,590,000mm3 Then you can use a converter to change it to cubic meters or whatever unit you need. eg https://www.digitaldutch.com/unitconverter/volume Somewhere in vectorworks there is a setting that will make you give these volumes in, say cubic metres rather than cubic millimetres, if that's more useful to you. I think.

A quick test suggests that it does pick up light overrides if the "render properties" box is ticked. That's potentially handy - although, could also be problematic where I want to copy render settings between viewports without changing the lighting setup. In that case, I guess I could use your class based system for switching lights - but then I'd have problems where I want to copy class visibilities but leave the lighting alone. A typical use case for me is when I do sunlight studies - I'll have maybe an option A and an option B design, and for each one I'll have a few viewports showing sunlight at different times of day/year, which I do by having multiple Heliodons, each for a different time, and each viewport will have one of these switched on.

That's me not looking carefully enough! Does that copy lighting settings too (ie which lights are switched on or off)?

I've a feeling I've seen this as a wishlist item at some point ... but it would be useful if the eyedropper tool could copy render and lighting settings between viewports too.

Ah! I never noticed it had these settings! This will make quite a few things easier. Thanks.

Is there any way to copy class visibilities only from one viewport to the other?

I've realised there's a problem: a saved view can have the "don't change" option for class visibilities, whereas a viewport can't. This means that the method described above doesn't work for any saved views where I have some classes set as "don't change" - that setting gets over-written.

Yes, that's pretty much what I mean.

I've had a thought though, maybe this can be a multi step process: 1) Edit viewport>display using viewport visibilities 2) Save that as a temporary saved view.... but save the class visibilities only. 3) Go to the saved view that I want to change (with layers and other stuff set up) 4) Then go to the temporary saved view, which will switch the classes but leave everything else alone 5) Then save that on top of the old saved view, effectively changing it to the new class visibilities setup. A bit tedious but less tedious than manually changing lots of class visibilities. Not sure if something similar can work in the opposite direction.

Thanks. Yes, this would allow me to save a new saved view, with the right classes activated. However, ideally I want to be able to copy the class visibilities to saved views that I already have set up with specific viewpoints, render modes, layer visibilities etc. Class overrides (which i do use in the viewports) would not be a problem, because I don't need the overrides in the saved views.

I have some viewports set up with a rather complex bunch of class visibilities - and I also have some saved views set up with similarly complex bunches of class visibilities. Is there any way I can copy the class visibilities (and the class visibilities only - not anything else) from a viewport to a saved view, and/or vice versa? Ideally a way that doesn't melt my brain in the process?

Totally agree with you. Have lost any hope that these kind of things will be addressed any time soon though. Instead they'll introduce another kind of marker with yet another slightly different way of setting the parameters. Most of those marker objects are also a nightmare to edit graphically, partly due to inconsistencies in behaviour between outwardly similar objects.