2024 - Viewport Styles

[Matt Overton]

6 hours ago, Dave Donley said:

 

Lighting Options can be controlled by the viewport style, so your viewport style can indeed set ambient light and ambient occlusion.

Are we finally getting time of day control in viewports?

[M5d]

2 hours ago, line-weight said:

I don't quite see how control of class or layer visibility could be part of a viewport style. Because styles are independent of individual files, but two files can have entirely different sets of classes.

 

Been wondering the same . . . 

 

I think the problem with the eyedropper has been, it just treated classes and layers like numerical lists between files. Hopefully, this identifies like for like naming and notes the differences . . . ?  

[Matt Overton]

On 9/8/2023 at 6:36 AM, line-weight said:

I don't quite see how control of class or layer visibility could be part of a viewport style. Because styles are independent of individual files, but two files can have entirely different sets of classes.

 

 

Then the question if it doesn't control classes, both visibility and overrides, is what issues does it solve over render styles to warrant being a tentpole feature of the release?

[line-weight]

5 hours ago, Matt Overton said:

Then the question if it doesn't control classes, both visibility and overrides, is what issues does it solve over render styles to warrant being a tentpole feature of the release?

I guess we have to wait and see!

 

There are quite a lot of settings for section viewports, things like how the cut plane is dealt with for example, that are outside of what render styles can control.

 

Being able to control that stuff by viewport style would be very useful, but as you imply, class visibilities & over-rides are an important part of getting viewports to show what you want, and are also some of the most tedious things to keep a handle on. So whether or not they are included in what viewport styles can do will determine whether or not it's really a game-changer.

Edited September 12, 2023 by line-weight

[Tom W.]

5 minutes ago, line-weight said:

I guess we have to wait and see!

 

There are quite a lot of settings for section viewports, things like how the cut plane is dealt with for example, that are outside of what render styles can control.

 

Being able to control that stuff by viewport style would be very useful, but as you imply, class visibilities & over-rides are an important part of getting viewports to show what you want, and are also some of the most tedious things to keep a handle on. So whether or not they are included in what viewport styles can do will determine whether or not it's really a game-changer.

 

I agree. It was weird to not see any dialog boxes in the video which would have shined a light on all this, hence my earlier post.

[Tom Klaber]

On 9/7/2023 at 4:36 PM, line-weight said:

I don't quite see how control of class or layer visibility could be part of a viewport style. Because styles are independent of individual files, but two files can have entirely different sets of classes.

 

 

Class settings are part of most styles.  Custom classes and definitions for doors/windows/tables styles - and they work - I think they just default to <Door Class> if the class in the new file is not present. 

 

It could be that the layer and class settings aspect of the style is localized to the file that the style resource is.

[line-weight]

1 hour ago, Tom Klaber said:

Class settings are part of most styles.  Custom classes and definitions for doors/windows/tables styles - and they work - I think they just default to <Door Class> if the class in the new file is not present.

 

Yes I see, you are right of course.

 

I guess I have not previously paid a lot of attention to what happens when I bring in a style resource to a different file - whether classes that are part of it (but not present in the destination file) get imported or default to something - and whether the behaviour is consistent between different types of styles.

 

I just tried importing a structural member style to an empty file, and I see that the class that is attributed to the SM comes in with it and is added to the classes already in the file.

 

But a set of (possibly hundreds of) class visibilities/over-rides for a viewport style - that's slightly different because it's not objects in the classes themselves you'd be bringing in but a set of rules about how they appear, which is all rather more complicated to co-ordinate. For example if it has a rule about a particular class, which isn't in the drawing that I am bringing it into... then does that rule just disappear or does it get remembered if I later add that class to the drawing?

 

But we will find out in due course.

Edited September 12, 2023 by line-weight

[Tom Klaber]

19 minutes ago, line-weight said:

 

Yes I see, you are right of course.

 

I guess I have not previously paid a lot of attention to what happens when I bring in a style resource to a different file - whether classes that are part of it (but not present in the destination file) get imported or default to something - and whether the behaviour is consistent between different types of styles.

 

I just tried importing a structural member style to an empty file, and I see that the class that is attributed to the SM comes in with it and is added to the classes already in the file.

 

But a set of (possibly hundreds of) class visibilities/over-rides for a viewport style - that's slightly different because it's not objects in the classes themselves you'd be bringing in but a set of rules about how they appear, which is all rather more complicated to co-ordinate. For example if it has a rule about a particular class, which isn't in the drawing that I am bringing it into... then does that rule just disappear or does it get remembered if I later add that class to the drawing?

 

But we will find out in due course.

 

Our internal desire  - is to have the same or mostly the same classes across all of our projects / files.  Every project usually gets a couple of special classes to sort something out - but the majority of it is standardized.  Additionally - we have template files with the starting official office standard classes built in - so the viewport styles could be predefined and contained in your template.  So ideally you would not be starting from nothing.

 

Speculation here - but my guess would be that the style would simply try and translate as best it could at the time of being imported.  If there is a class definition that does not exist - then it is simply ignored and new classes are defaulted to off. I would not imagine that if you added a class later that it would default to on - even if that style in some previous version of its life in a previous document had it on.  You would simply need to redefine the style if you add classes after the style is imported.

 

Without class support - the viewport style is not of very much use to me...

 

 

[line-weight]

Yes I too try and have mostly the same classes across all projects files. Although, this always feels like a moving target, because files can remain in use through several versions of VW and my system continually evolves somewhat, partly as a result of changes in VW itself.

 

For example, VW2024 might be the one where I start trying to use VW "materials" and if I do, then part of my classing strategy may become redundant.

 

If Viewport Styles do include control of class visibility that'll certainly be a strong incentive to further standardise/rationalise my class naming though.

[Hugues]

Viewport Styles control visibility and attribute overrides for Classes and Layers. 
You can try to copy a viewport from one file to another to see how the class overrides work. That should give you an idea of how this would work for Viewport Styles.

[Matt Overton]

6 hours ago, Hugues said:

Viewport Styles control visibility and attribute overrides for Classes and Layers. 
You can try to copy a viewport from one file to another to see how the class overrides work. That should give you an idea of how this would work for Viewport Styles.

 

Thank you.

Now I have more reasons to get people to use the standard names. 

 

[line-weight]

Have just been looking at VW2024.

 

The Viewport Style dialogue box does look promising.

 

One thing I note though; the opportunity does not seem to have been taken to fix the confusing "Lighting Options" button in the OIP for a renderworks viewport. This is the button that (if you are dealing with a renderworks viewport) actually takes you to a dialogue called "Edit Renderworks Style" which, if you are not paying attention, can lead you to make changes to a renderworks style that applies multiple renderings and not just the one in the viewport. I have been complaining about this for years.

 

I think this is also going to cause confusion when dealing with Viewport Styles for Renderworks viewports. Because in the settings for that Viewport Style I can choose "Lighting Options" to be "by style". And yet, a viewport with that style will have its "Lighting Options" button ungreyed. Because actually that button shouldn't be called "Lighting Options" it should be called "Edit Renderworks Style" or arguably not there at all.

 

[edit] Oh, actually it adds a further inconsistency. If I have a styled viewport, where I have "Lighting Options" by style, then that button is not greyed out but when I press it, it takes me to a "lighting options" dialogue with everything greyed out (why not just grey out the button?)

 

So this means that for a styled Renderworks viewport, this button does something different from what it does for an unstyled Renderworks viewport.

Edited September 13, 2023 by line-weight

[line-weight]

Another thing...

 

If I set up my own customised Renderworks style I can choose "apply lighting options" for this style. And let's say I choose, under Indirect Lighting, 16 bounces.

 

I'll expect those settings to apply to any Viewport that uses that Renderworks style.

 

Then I can make a Viewport style, where I set "Renderworks style" to be "by style" and I can choose the customised Renderworks style I've just made.

 

But it seems that, within the settings for this Viewport style I can still press the "lighting options" button, and choose, under Indirect Lighting, say, 4 bounces.

 

So what then applies to Viewports that use that Viewport style? Is it the 16 bounces I've specified in the Renderworks style or is it the 4 bounces I've specified in the Viewport style?

[Jeff Prince]

must resist switching to 2024....

 

I just experienced this great update today while coordinating a set of plans with 6 different enlargements used across 24 sheets.  Salvage, Hardscape, Planting, and Irrigation.

Nicely done Vectorworks!  I look forward to doing more with this tool.