Streamlined naming to go with the new UI

[Tom Klaber]

Liking the UI refresh. I think we should build on this cleaner aesthetic and use the momentum to rename some things:

 

Design Layers -> Layers

Sheet Layers -> Sheets

Renderworks Textures -> Textures

 

Let's Marie Kondo this thing!

 

[_James]

Absolutely!

 

This could be part of the remit of the "click reduction officer" which VW should employ (an idea I saw on here somewhere a while ago). Perhaps they should rename it to "Software Simplification Officer".

 

A couple of others:

 

Title Block Border -> Title Block

Renderworks Camera -> Camera (I would support just dropping the 'Renderworks' prefix for everything)

[Kevin Allen]

there are many places where clarity and brevity would be appreciated.

[Kevin McAllister]

18 hours ago, Tom Klaber said:

Design Layers -> Layers

Sheet Layers -> Sheets

Renderworks Textures -> Textures

Definitely needed. Renaming Renderworks Textures to Textures is way overdue. And being able to display the Tab Style as Text Only for things like the Navigation Palette is pointless with long names like Design Layers and Sheet Layers......

Kevin

 

[zoomer]

I only have a problem with Textures.

 

Coming half from the 3D App side, the term texture is always used for image textures.

While VW's RW Textures are commonly "Materials".

And Textures are a child part of Materials.

 

As we meanwhile also have Building Materials, I would rather name these BIM Materials.

 

I also have a great problems with VW Layers as anywhere else VW Classes are Layers.

But as Classes for classification makes some sense and Levels may not really fit to

VW Layers - I can live with it ....

[Tom Klaber]

2 minutes ago, zoomer said:

I only have a problem with Textures.

 

Coming half from the 3D App side, the term texture is always used for image textures.

While VW's RW Textures are commonly "Materials".

And Textures are a child part of Materials.

 

As we meanwhile also have Building Materials, I would rather name these BIM Materials.

 

I also have a great problems with VW Layers as anywhere else VW Classes are Layers.

But as Classes for classification makes some sense and Levels may not really fit to

VW Layers - I can live with it ....

The confusion with Layers and Classes as it applies to communication with AutoCad will exist regardless - no desire to make the internal VW nomenclature clunkier to somehow better fit with other programs termonology.

 

Not sure if I understand the hesitation around Textures vs Renderers Textures.   Materials are a broader concept that contain lots of information including textures.  To me - dropping the word Renderworks does not change anything. 

[zoomer]

Honestly I would rather like to combine VW's RW Textures and (Building) Materials

as they are basically the same.

The Visualization part (RW Textures) and the BIM Materials (Information) part,

Appearance and Data, belong together.

[zoomer]

1 minute ago, Tom Klaber said:

The confusion with Layers and Classes as it applies to communication with AutoCad

 

Not only Autocad, nearly any CAD.

Even Allplan that has a similar (pretty rare) double system like VW's Classes + Layers

names its "Classes" Layers.

 

I am no native speaker but for me a Layer represents something very thin.

Like Layers of foil or paint. But VW Layers have a strict 3D stacking order and usually

Z differences of many meters. That is why I tend more td "Level".

Just that the term "Level" only represents the "Layer height" issue but not the content

separation part, I am still looking for a better term.

[zoomer]

11 minutes ago, Tom Klaber said:

To me - dropping the word Renderworks does not change anything. 

 

No, for me either.

It doesn't make anything better either.

 

In Visualization a Material (RW Texture) is not just seen as a wallpaper.

It is a 3D Material experience.

If you cut a Beam in half in a 3D App, the cut faces will still show the

same Material appearance, and not a void.

(Although 3D App's geometry work with faces only and you have to actively

close the wholes. But it does not make much sense otherwise)

And there are procedural Textures, too which work 3D.

 

So a RW Texture in VW, which always had great Render options for a CAD,

(with the extra paid RW Plugin in the past) should/could have gone with the

Material term from the beginning.

[Tom W.]

12 minutes ago, zoomer said:

Honestly I would rather like to combine VW's RW Textures and (Building) Materials

as they are basically the same.

The Visualization part (RW Textures) and the BIM Materials (Information) part,

Appearance and Data, belong together.

 

I don't agree. Plenty of textures have nothing to do with building materials. Plenty of textures don't need + would never need to have loads of data attached to them. Plenty of people are quite happy just using textures + have no need for Materials.

 

Plus is a Material the right place to include all the texture (shader) settings, alongside the physical properties + cost/manufacturer/supplier/etc info for the product/material that the texture is being used to represent? 

 

Also, section fills (Tiles/Hatches/Solid Fills) are just as important as the texture in a Material so would the combine-into-one argument extend to them as well...?

[zoomer]

5 minutes ago, Tom W. said:

Plus is a Material the right place to include all the texture (shader) settings, alongside the physical properties + cost/manufacturer/supplier/etc info for the product/material that the texture is being used to represent? 

 

 

Hmmh, I personally think yes.

In my other CAD I also have "render" materials and "BIM" materials that include

a child render material.

Not a big issue for me but I think it would be ok to combine them.

Not sure if anyone ever needs to replace the render material of its BIM materials (?)

 

 

9 minutes ago, Tom W. said:

Plenty of textures have nothing to do with building materials. Plenty of textures don't need + would never need to have loads of data attached to them.

 

So for me, they will just not get enriched by that unnecessary data,

just like I may ignore adding values to some objects or deeper IFC tagging.

But I personally see no problem if a e.g. Blender Material of a Wood would also

know its specific weight or fire resistance ....

[Tom W.]

What about plant textures for Image Props, Decals, glow textures, colours, etc. Wouldn't it just be weird/unhelpful/confusing to have multiple tabs of settings dedicated to 'product model no.', 'product cost', 'manufacturer', 'embodied carbon', 'lambda', 'density', etc for these? And why would you ever need to attach a custom record to such a texture?

 

For me Materials are a very specific tool for use almost exclusively with Wall/Slab/Roof/Hardscape/Landscape Area components. It works well for me to keep my wider library of textures + my product-specific library of Materials separate. For example, in my textures libraries I perhaps have 20 different insulation textures that I've collected over time but for my Materials I probably only use 3 or 4 of them but have 20-30 different insulation Materials because of all the different products (different manufacturers, different thickness, etc) I'm using in my models i.e. the same texture might be used by 6 or 7 different Materials.

 

I get where you're coming from but for me, Materials + textures are distinct from each other + there's a benefit to keeping them separate. And I believe this is how VW Materials were designed to be used (hence the fact it took 3 years before they brought them in for Doors/Windows).

[Kevin Allen]

3 minutes ago, Tom W. said:

For me Materials are a very specific tool for use almost exclusively with Wall/Slab/Roof/Hardscape/Landscape Area components.

Materials COULD be useful in entertainment, I have not yet figured out how.

[Kevin Allen]

1 hour ago, zoomer said:

I am no native speaker but for me a Layer represents something very thin.

 

to me, A VWX Design Layer is like a sheet of vellum.

[zoomer]

24 minutes ago, Tom W. said:

I get where you're coming from but for me, Materials + textures are distinct from each other + there's a benefit to keeping them separate.

 

I personally would think it is logical for Render Materials and Building Materials to be combined,

but I have no problem if they stay separated  for organizational reasons.

 

I just still think RW Textures should not be called Textures but Materials as everywhere else.

And as VW meanwhile got "Materials", I see a need to differentiate both naming.

 

I agree with the initial wish of simplification to Sheets and Layers (SVP and LVP ?)

but not so much with "Textures"

 

But I am not a standardization authority and scale for everyone, I just put it in.

Basically I got used and can live with Classes, Layers, RW Textures, Jambs and Sashes, ...

Edited September 14, 2023 by zoomer

[E|FA]

23 hours ago, Tom Klaber said:

Design Layers -> Layers

Sheet Layers -> Sheets

Renderworks Textures -> Textures

14 hours ago, _James said:

Title Block Border -> Title Block

Renderworks Camera -> Camera (I would support just dropping the 'Renderworks' prefix for everything)

 

It seems like this thread is overcomplicating the simplification. I don't believe that VW will do a drastic change of naming protocols because it will be way to confusing for the existing user base and will void most of the existing support content. @Tom Klaber & @_James offered small improvements that should be feasible to implement.  There's another thread somewhere on the forum that has a discussion of major change proposals.  Can we keep this Wishlist thread focused on things VW might actually implement in the near future?

Edited September 14, 2023 by E|FA

[Mark Aceto]

Record Format -> Record

 

I'll never understand why the word "format" was ever a part of that resource, and if anyone tries to defend that choice, I'll beat them with a stick format.

[Tom Klaber]

On 9/14/2023 at 4:54 PM, zoomer said:

 

I personally would think it is logical for Render Materials and Building Materials to be combined,

but I have no problem if they stay separated  for organizational reasons.

 

I just still think RW Textures should not be called Textures but Materials as everywhere else.

And as VW meanwhile got "Materials", I see a need to differentiate both naming.

 

I agree with the initial wish of simplification to Sheets and Layers (SVP and LVP ?)

but not so much with "Textures"

 

But I am not a standardization authority and scale for everyone, I just put it in.

Basically I got used and can live with Classes, Layers, RW Textures, Jambs and Sashes, ...

Right now Textures and Materials are not the same thing. A texture is a rendering term about how something looks - the idea of a material is broader and that it comes with more data. You need those concepts to be different.  

[zoomer]

From a rendering term,

a VW RW Texture is a "Material",

which can have applied procedural or image "Textures" inside

the "Material" channels like Diffuse, Reflection, Bump, .....

 

And a Render Material does describe the rendered appearance

of a Material basically in the same way as BIM Material data

does for a Building Material.

 

E.g. if you have a 3D App and go to dynamics, you may want to

have additional drag coefficient information for that Material too.

No matter if, for organizational reasons, this is stored by material

or by object, it is additional information data.

Just like VW building materials may include additional "RW Texture"

definitions for the render appearance.

 

And the whole reason I always asked VW to bring  a "Building Material"

System was to avoid to need to manually re-enter the same concrete

every time again whenever you create a new concrete component

in a style.

Nevertheless such a Building Material should obviously also contain

the render related definition.

 

So from a VW-only perspective, it may be ok to agree to VW Materials

and stay with separate RW "Textures".

 

 

But from my global 3D and CAD experience those VW terms don't make

any sense. Literally.

 

 

To avoid Babel Tower problems, there are trends to explicitly standardize

terms and there is a quasi standardization that comes simply from common

usage and collaboration.

 

And this is where VW, in the past just failed.

It is just VW that brought the term "RW texture" for instead of Material

for whatever reason or just arbitrarily or pure ignorance.

Same as calling their Layers "Classes".

While any else CAD, even when having a similar double order system like VW,

uses the term "Layer" (which makes as much sense as VW's classification).

And really everywhere in Computer Graphics,

a VW RW "Texture" used the term "Material" but "Texture" for a surface description.

 

Every other 3D or CAD App or anything in between I have used or seen so far,

uses the term "Material" for the grouping overall description of render properties.

 

So I think it it is definitely the same, Render Material vs Building Material,

physical values like k-value, weight, .... vs light absorption, fresnell, color, ....

it is just about prioritization of which data is relevant in which kind of App.

 

Beside all 3D Apps, even any other CAD Apps that I know call

"VW RW Textures" Materials ....

Microstation, Allplan, Autocad, Bricscad, Freecad, Archicad, .....

maybe even chief architect (?)

 

 

From a VW-only point of view that may be all impossible to change and somehow ok,

from my point of view that is all unnecessary and deeply wrong.

 

I see and help with some ACAD to VW switchers posts on these forums having

problems with VW Classes. Which is not really necessary.

 

 

As said, I can live with this VW nomenclature pretty ok.

(RW Textures, Materials, Classes+Layers, Stories, Jambs+Sashes, ....)

It is just that I still think that my arguments are valid and that I will not change

my mind that some is completely wrong and making many peoples life more

complicated than necessary.

 

 

 

 

 

 

 

 

Edited September 25, 2023 by zoomer

[Jeff Prince]

3 hours ago, zoomer said:

From a rendering term,

a VW RW Texture is a "Material",

which can have applied procedural or image "Textures" inside

the "Material" channels like Diffuse, Reflection, Bump, .....

 

And a Render Material does describe the rendered appearance

of a Material basically in the same way as BIM Material data

does for a Building Material.

 

E.g. if you have a 3D App and go to dynamics, you may want to

have additional drag coefficient information for that Material too.

No matter if, for organizational reasons, this is stored by material

or by object, it is additional information data.

Just like VW building materials may include additional "RW Texture"

definitions for the render appearance.

 

And the whole reason I always asked VW to bring  a "Building Material"

System was to avoid to need to manually re-enter the same concrete

every time again whenever you create a new concrete component

in a style.

Nevertheless such a Building Material should obviously also contain

the render related definition.

 

So from a VW-only perspective, it may be ok to agree to VW Materials

and stay with separate RW "Textures".

 

 

But from my global 3D and CAD experience those VW terms don't make

any sense. Literally.

 

 

To avoid Babel Tower problems, there are trends to explicitly standardize

terms and there is a quasi standardization that comes simply from common

usage and collaboration.

 

And this is where VW, in the past just failed.

It is just VW that brought the term "RW texture" for instead of Material

for whatever reason or just arbitrarily or pure ignorance.

Same as calling their Layers "Classes".

While any else CAD, even when having a similar double order system like VW,

uses the term "Layer" (which makes as much sense as VW's classification).

And really everywhere in Computer Graphics,

a VW RW "Texture" used the term "Material" but "Texture" for a surface description.

 

Every other 3D or CAD App or anything in between I have used or seen so far,

uses the term "Material" for the grouping overall description of render properties.

 

So I think it it is definitely the same, Render Material vs Building Material,

physical values like k-value, weight, .... vs light absorption, fresnell, color, ....

it is just about prioritization of which data is relevant in which kind of App.

 

Beside all 3D Apps, even any other CAD Apps that I know call

"VW RW Textures" Materials ....

Microstation, Allplan, Autocad, Bricscad, Freecad, Archicad, .....

maybe even chief architect (?)

 

 

From a VW-only point of view that may be all impossible to change and somehow ok,

from my point of view that is all unnecessary and deeply wrong.

 

I see and help with some ACAD to VW switchers posts on these forums having

problems with VW Classes. Which is not really necessary.

 

 

As said, I can live with this VW nomenclature pretty ok.

(RW Textures, Materials, Classes+Layers, Stories, Jambs+Sashes, ....)

It is just that I still think that my arguments are valid and that I will not change

my mind that some is completely wrong and making many peoples life more

complicated than necessary.

 

 

 

 

 

 

 

 

 

100% agree.

Vectorworks nomenclature causes more problems than it solves.

Instead of updating UIs all the time, maybe bringing the software in compliance with industry "standards" for identifying things would be more useful, especially for those potential new customers coming from one of the other platforms.  Maybe just copy Blender's terms as an example 🙂

 

[Tom Klaber]

20 hours ago, zoomer said:

From a rendering term,

a VW RW Texture is a "Material",

which can have applied procedural or image "Textures" inside

the "Material" channels like Diffuse, Reflection, Bump, .....

 

And a Render Material does describe the rendered appearance

of a Material basically in the same way as BIM Material data

does for a Building Material.

 

E.g. if you have a 3D App and go to dynamics, you may want to

have additional drag coefficient information for that Material too.

No matter if, for organizational reasons, this is stored by material

or by object, it is additional information data.

Just like VW building materials may include additional "RW Texture"

definitions for the render appearance.

 

And the whole reason I always asked VW to bring  a "Building Material"

System was to avoid to need to manually re-enter the same concrete

every time again whenever you create a new concrete component

in a style.

Nevertheless such a Building Material should obviously also contain

the render related definition.

 

So from a VW-only perspective, it may be ok to agree to VW Materials

and stay with separate RW "Textures".

 

 

But from my global 3D and CAD experience those VW terms don't make

any sense. Literally.

 

 

To avoid Babel Tower problems, there are trends to explicitly standardize

terms and there is a quasi standardization that comes simply from common

usage and collaboration.

 

And this is where VW, in the past just failed.

It is just VW that brought the term "RW texture" for instead of Material

for whatever reason or just arbitrarily or pure ignorance.

Same as calling their Layers "Classes".

While any else CAD, even when having a similar double order system like VW,

uses the term "Layer" (which makes as much sense as VW's classification).

And really everywhere in Computer Graphics,

a VW RW "Texture" used the term "Material" but "Texture" for a surface description.

 

Every other 3D or CAD App or anything in between I have used or seen so far,

uses the term "Material" for the grouping overall description of render properties.

 

So I think it it is definitely the same, Render Material vs Building Material,

physical values like k-value, weight, .... vs light absorption, fresnell, color, ....

it is just about prioritization of which data is relevant in which kind of App.

 

Beside all 3D Apps, even any other CAD Apps that I know call

"VW RW Textures" Materials ....

Microstation, Allplan, Autocad, Bricscad, Freecad, Archicad, .....

maybe even chief architect (?)

 

 

From a VW-only point of view that may be all impossible to change and somehow ok,

from my point of view that is all unnecessary and deeply wrong.

 

I see and help with some ACAD to VW switchers posts on these forums having

problems with VW Classes. Which is not really necessary.

 

 

As said, I can live with this VW nomenclature pretty ok.

(RW Textures, Materials, Classes+Layers, Stories, Jambs+Sashes, ....)

It is just that I still think that my arguments are valid and that I will not change

my mind that some is completely wrong and making many peoples life more

complicated than necessary.

 

 

 

 

 

 

 

 

Oh Zoomer - we have never been so opposed before.  While industry standards are all fine and good - doing something just because that is the way AutoCad does it is not good enough.

 

Autocad "Layers" is a bad name for that that is. The term "Classes" is more accurate to what they are. The fact that VW has this dual organizational system is one of the most profound advantages it has over AutoCad. Classes are classifications - layers - like a cake - can have Z relationships.  You are dead wrong about wanting to follow AutoCad there - even if others have. 

 

"Textures" has always been the industry standard for a map that gets applied to an object for rendering.  WWW.TEXTURES.COM - formally CGTEXTURES - is one of the best resources.  If you go to Poliigon - they have "Textures, Modesl, and HDRIs" - nobody calls the image maps you apply to objects "Materials."  "Materials" is more of a BIM term meant to classify objects with material-specific data and attributes. What if you wanted to change the look of the concrete in your model?  You would not say that you wanted to change the material - you want to change the texture that represents the material.  They are different.  Vectorworks has materials too - I do not use them - but if you make a material you can assign a texture to represent that material - have no idea why you would want name both those concepts the same thing. 

[Jeff Prince]

6 minutes ago, Tom Klaber said:

Oh Zoomer - we have never been so opposed before.  While industry standards are all fine and good - doing something just because that is the way AutoCad does it is not good enough.

 

Autocad "Layers" is a bad name for that that is. The term "Classes" is more accurate to what they are. The fact that VW has this dual organizational system is one of the most profound advantages it has over AutoCad. Classes are classifications - layers - like a cake - can have Z relationships.  You are dead wrong about wanting to follow AutoCad there - even if others have. 

 

"Textures" has always been the industry standard for a map that gets applied to an object for rendering.  WWW.TEXTURES.COM - formally CGTEXTURES - is one of the best resources.  If you go to Poliigon - they have "Textures, Modesl, and HDRIs" - nobody calls the image maps you apply to objects "Materials."  "Materials" is more of a BIM term meant to classify objects with material-specific data and attributes. What if you wanted to change the look of the concrete in your model?  You would not say that you wanted to change the material - you want to change the texture that represents the material.  They are different.  Vectorworks has materials too - I do not use them - but if you make a material you can assign a texture to represent that material - have no idea why you would want name both those concepts the same thing. 

as a former long time AutoCAD user, we use(d) xrefs in the same capacity as Vectorworks Layers.  I prefer Vectorworks obviously, but the VWX naming convention does conflict with most major softwares, hence confusion.

 

@Tom Klaber For rendering, Materials is a term that is inclusive of a Texture map, but encompasses much more such as how the material behaves in different lighting, rendering, and physics engines.  A Texture is a small, but very visible, portion of the definition that defines the look of a Material, regardless of what people name their websites 🙂   Look at technical education and most books published on rendering prior to YouTube hacks ruining technical language… Materials is the correct term…

[Tom Klaber]

47 minutes ago, Jeff Prince said:

as a former long time AutoCAD user, we use(d) xrefs in the same capacity as Vectorworks Layers.  I prefer Vectorworks obviously, but the VWX naming convention does conflict with most major softwares, hence confusion.

 

@Tom Klaber For rendering, Materials is a term that is inclusive of a Texture map, but encompasses much more such as how the material behaves in different lighting, rendering, and physics engines.   A Texture is a small, but very visible, portion of the definition that defines the look of a Material, regardless of what people name their websites 🙂   Look at technical education and most books published on rendering prior to YouTube hacks ruining technical language… Materials is the correct term…

 

XREFS are not quite the same as layers - but I hear you. Convention aside - I really do think that Vectorworks - despite being in the minority - is actually using the correct terminology in the grand layers/classes debate.  I say we stand our ground - righteous win out. 

 

I am so baffled by this.  Vectorworks has Materials.  Just not sure how renaming "Renderworks Textures" to "Materials" is a step in the right direction.   I never hear people say they have to go "re-material the model" - they have to go "re-texture the model."   Do you take your Vectorworks models into physics engines? 

 

We use Lumion - and they - as you say - call these resources Materials.  Maybe I am just used to it - but have not run into this as a sticking point.   Each own. 

[zoomer]

1 hour ago, Tom Klaber said:

nobody calls the image maps you apply to objects "Materials." 

 

Absolutely right.

Poligon sells image "Textures" (sets)

 

But that what VW calls RW Texture, is the usual whole Material setup.

Which can contain image "textures". AFAIK called images in VW (?)

 

 

 

 

1 hour ago, Tom Klaber said:

"Materials" is more of a BIM term meant to classify objects with material-specific data and attributes.

 

And when I think of a Material, I think of a matter.

E.g. a brushed stainless Steel.

And to describe that Material for any kind of purpose, it has some data

- physical data like density, e-module, melting point, atomic structure, ......

- a price, cleaning instructions, fire resistance, ......

and

- rendering data for a visual representation like, anisotrophy, IOR, albedo, ....

 

Why do some want to separate all that information.

For me a Material dialog should be able to define and setup just all information.

 

 

1 hour ago, Tom Klaber said:

You are dead wrong about wanting to follow AutoCad there

 

Was Autocad the first CAD in the world ?

 

It is nearly any CAD beside VW that uses the term Layer.

Like Layers of transparent foils that some architects used to "switch visibilities" in real drawings.

 

Layers makes a much sense as "Classification" in VW.

In real world, not all of my VW Classes are strictly used to "classify"

And not all of my VW Layers have a Layer and Wall Height.

 

 

I still think my analysis is ok.

[Pat Stanford]

OK.  Word from the moderator here.

 

I can tell you all have strong opinions on this. And it doesn't appear that any of you are going to change your mind.

 

As long as it stays civil and fun, we will let this conversation go on.  As soon as it gets ugly or personal the thread will be locked.

 

Have fun.

[Tom Klaber]

I clearly do not want to work today...

@zoomer
The reason the other programs misuse the term "layer" - is because of Autocad - not because of anything innate.

 

Layers - are analogous to layers of vellum - the place where objects are drawn.  They can be stacked (or not) but can - if you wish to have a stacked relationship with each other. 

 

What do you do with classes but to classify the objects?  Either at an object type or an option a or option b... ?  Honestly curious to understand how else classes can be utilized.

 

While you might have some outliers - classes do classify objects - and are analogous to your pen set - as they define the visual appearance of the objects.   Your layers do not need to have a layered wall height to take advantage of their stackability.

 

Would you really advise switching their meanings? Do you really think that makes more sense? Do not believe it.