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!

 

[Tom W.]

16 minutes ago, zoomer said:

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, ......

 

So out of interest are you using VW Materials in this way at the moment? i.e. when you assign a stainless steel texture to an object are you doing it with a VW Material - which includes all the data you mention - or are you doing it with a Renderworks Texture? I'm interested in whether the primary issue is the way that textures are named or whether it's genuinely about improving functionality. I personally don't mind what things are called too much - it's just a language + you learn it + that's that - but I do care about functionality + I think the current arrangement whereby attributes (textures + fills) are separate resources which are assigned to Materials - alongside everything else - works really well + would need to see a stronger argument for changing it.

[bcd]

On 9/14/2023 at 4:37 PM, Kevin Allen said:

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

with unlimited scratchabillity

[bcd]

56 minutes ago, Tom Klaber said:

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 agree with this and that while Textures represent the look of the exposed surfaces of an object Materials represent its full materiality of an object, it's texture, mass, thermal properties, tensile strength etc....  I like the current setup, and have no objection to reducing Sheet Layer to Sheet. Design Layer to Layer loses something in its meaning I think, so my vote would be, conservative as it is, to leave things as they are and just make more use of Materials & Material Textures (oops)

[Mark Aceto]

20 hours ago, Jeff Prince said:

Maybe just copy Blender's terms as an example 🙂

 

This comment shouldn't be overlooked. The fact that Blender is open source certainly democratizes the choices they make together as a team. Blender users, like many VW users, come from all industries, backgrounds, other 3D design software... Blender's excellent documentation reflects common language, like a Rosetta Stone, across that Tower of Babel user base.

 

I think we can all agree that what would benefit VW users, as Tom proposed in the OP, is streamlining the language / workflows / procedures (or lack of them) and so on... throughout the VW UI. We can start with the lowest hanging fruit, and iterate from there (please no more overhauling). Also +1 for PBR textures and procedural everything.

Carry on, my wayward sons
There'll be peace when we are done
 

*guitar solo*

[E|FA]

Some (most?) of us only use VW, so changing naming conventions to more closely resemble other programs that we’ll never use would be a total useless nightmare. 

[zoomer]

44 minutes ago, Tom Klaber said:

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

 

The only reason I would like to is because it is quasi standard anywhere else

and it is an extra unnecessary hurdle for switchers or just in collaboration and

communication with the world outside.

(I personally am capable to simultaneous translate my VW Classes as "Layers"

when I talk to other CAD users ....)

 

From a pure VW walled garden standpoint I am totally OK with Classes + Layers.

I said that I can live with all VW terms.

 

I am also aware that it highly unlikely that RW Textures will ever get renamed

to Materials or Render Materials or that both VW Materials get ever combined.

I just won't ever agree that RW Textures is an appropriate term for a complete

Material Setup.

[zoomer]

52 minutes ago, Tom W. said:

So out of interest are you using VW Materials in this way at the moment? i.e. when you assign a stainless steel texture to an object are you doing it with a VW Material - which includes all the data you mention - or are you doing it with a Renderworks Texture?

 

 

At the time it was released I was in already running projects so I did not test

and I heard a few users having issues with their SLVP (class) overriding.

 

I was the first one who asked for a global Material System

(after watching me re-creating the same concrete definition in my Wall/Slab/Column

Style Components ....)

I thought I would have invented that idea but found it already in Bricscad ....

 

 

In the last project I tried to switch to VW Building Material Setup.

So far my conclusion is that VW Material System is more complicated and tedious

than I thought, especially when creating own Materials or trying to put them into

my office standard folders or naming. Less default Materials than expected.

(Importing a Material will also pollute your RM File's Folder structure with new Folders,

RW Textures, Hatches ... you name it)

So for VW, I am not sure about recommending Materials.

Maybe if I had my own standard complete VW Material Library and such, but so

far I think it is overall easier for me to work like in the past.

 

 

But I use the Building Material System in Bricscad extensively.

But I think it is mandatory for BIM "Compositions" anyway ...

(Basically = VW Wall/Slab/Roof/... Multi Component Setups)

 

And yes, Bricscad also has separated Materials.

The older Render Materials and the newer Building Materials.

So like in VW, Render Materials are added as a child item inside the Building Material

Setup Dialog.

(Could be that I already filed a Feature Request to unite both there but am not sure)

 

 

 

 

[zoomer]

33 minutes ago, E|FA said:

Some (most?) of us only use VW, so changing naming conventions to more closely resemble other programs that we’ll never use would be a total useless nightmare. 

 

A totally agree.

 

I do not insist at all in trying to force VW to change that.

(It is too late)

But I do not give up to state that some those terms are wrong, do not fit, are unlucky, ....

and repeat myself in case I feel some simple misunderstandings.

 

I think this is what makes @Pat Stanford fearing to escalate or get more ugly, tedious and

finally personal. But I do not have any problem with thread starter Tom or really read

that he has with me.

 

[Jeff Prince]

 

4 hours ago, Tom Klaber said:

Do you take your Vectorworks models into physics engines? 

 

Blender... It's the answer to most questions on this forum 🙂

 

 

 

3 hours ago, zoomer said:

 

Absolutely right.

Poligon sells image "Textures" (sets)

 

Check this out LOL....  I guess they changed with the times and adopted "textures", but forgot to update their website's html 🙂

 

 

 

 

2 hours ago, E|FA said:

Some (most?) of us only use VW, so changing naming conventions to more closely resemble other programs that we’ll never use would be a total useless nightmare. 

 

This would be consistent with what the company is already doing by changing the UI on us or removing important features like color wheels 🙂

Really, bringing the software into "compliance" with the design language of the rest of the industry makes it easier to convert people to customers.  I mean they changed the program's icon shape to match Apple's new conventions, so clearly some things matter to them 🙄.

We've all heard new people in our offices or here on the forums moan about how archaic or foreign the software is, and thusly difficult to learn.

Old dogs here tell these young dogs to learn new tricks, instead, the young dogs go looking for treats from other masters.

Soon, there will only be old dogs here and it will look like a Form Z forum.

 

 

Edited September 26, 2023 by Jeff Prince

[Kevin Allen]

3 hours ago, bcd said:

I agree with this and that while Textures represent the look of the exposed surfaces of an object Materials represent its full materiality of an object, it's texture, mass, thermal properties, tensile strength etc.... 

I've experimented with materials, but haven't, as yet, found them applicable to show business. I might have several different uses for plywood and/or MDF. Each with a different finish. That said, It would be nice to be able count sheets of plywood/MDF/laminate, as well as calculate paint.

[Mark Aceto]

6 hours ago, E|FA said:

Some (most?) of us only use VW, so changing naming conventions to more closely resemble other programs that we’ll never use would be a total useless nightmare. 

 

Changing "OpenGL" to "Shaded" made sense (especially since VW uses DirectX on Windows) and is consistent with other software.

 

Changing VW "Layers" and "Classes" to something else would not make sense (regardless of what other software names things: groups, scenes, containers, trees... ).

 

The discussion about Materials / Textures is a little more nuanced... 

[Mark Aceto]

3 hours ago, Kevin Allen said:

I've experimented with materials, but haven't, as yet, found them applicable to show business. I might have several different uses for plywood and/or MDF. Each with a different finish. That said, It would be nice to be able count sheets of plywood/MDF/laminate, as well as calculate paint.

 

Today I was asked to provide all materials for an (mostly) corporate show, so I added a "Material" field to my custom Record Format that I full expect to report in my Instrument Schedule as:

• Aluminum
• NA
• NA
• NA
• NA
• NA
• NA
• NA
• NA
• NA
• NA

I'm not sure the reason why I have to do this but more and more production companies are mindful of producing sustainable events. Some of my clients are certified according to this:

 

https://www.iso.org/iso-20121-sustainable-events.html

 

That said, the discussion of Materials / Textures in regards to DCC / CAD / CAM software carries a whole other meaning that gets conflated quickly... I used Blender as an example because I think when it comes to wrangling all of the variables, they're a good example of mostly getting it right. Not a hill I'm willing to die on though.

[Mark Aceto]

Does everyone remember when Renderworks was a separate add-on that we had to pay for before it was baked (pun intended) into VW at no additional cost?

 

And how about all the redundant RW Textures that end in "RT"? Still.

 

Or how about a year or two ago when the Render tab in the OIP got some love, mostly for the better but then... crickets. Where's the iterative development? Nope, time to change all the icons... 

 

The whole "RW" quagmire could use a little love. Not rearranging vegetables on the plate instead of eating them. Not overhauling it with something polarizing. Just lose the legacy artifacts, and streamline it... 

[Tom W.]

3 hours ago, Mark Aceto said:

And how about all the redundant RW Textures that end in "RT"? Still.

 

Why is a texture redundant if it ends in RT...?

[Tom W.]

11 hours ago, zoomer said:

(after watching me re-creating the same concrete definition in my Wall/Slab/Column

Style Components ....)

 

Exactly. I even created a Wishlist item for the ability to save/import/export components because it was such a bad, inefficient, error-prone system. Until I tried Materials + realised this is precisely what they are designed to do. So for me Materials are almost exclusively a function of wall/slab/roof/etc components + now an utterly essential part of that workflow. I am surprised they don't get more love as for me they are one thing that work really really well + are a pleasure to use!

[Mark Aceto]

4 hours ago, Tom W. said:

 

Why is a texture redundant if it ends in RT...?

 

RT = Renderworks Texture, so in the Renderworks Textures folder are Renderworks Textures RT... it's like The Department of Redundancy Department.

 

I believe this is a result of a years-long housekeeping exercise, and any texture with the RT suffix was somehow modernized. So now most of the textures end in RT.

 

To the point of the OP, they're just textures! We don't need all of this friction, especially for new users that are like, "Why do most of these end in RT but some don't?"

 

Textures, records, layers, clases, sheets (or plates if you're nasty)... 

 

[zoomer]

2 hours ago, Tom W. said:

So for me Materials are almost exclusively a function of wall/slab/roof/etc components + now an utterly essential part of that workflow.

 

I would like to use them too of course.

But for me they looked quite tedious to organize so far.

 

Another issue for me is multi or combined Materials.

Hard to visually differentiate and I always run into naming issues.

 

I think for you the UK material library is a good start.

If I had the localized VW version, I think it would be quite ok too.

But fighting against VW's default naming and folders so that I can

organize and find my stuff again was no fun so far.

 

BTW,

in Bricscad there are no Container Materials.

There is only one level of Material.

So a Concrete + Rebars is just a reinforced Concrete single Material.

 

Combinations only happen in Composition's (VW PIO Styles) by Plies

(VW PIO Components)

That makes it easier for me.

 

 

[zoomer]

10 minutes ago, Mark Aceto said:

RT = Renderworks Texture, so in the Renderworks Textures folder are Renderworks Textures RT... it's like The Department of Redundancy Department.

 

I always thought that RT would stand for Raytracing (?)

And I thought there is some redundancy by keeping their older copies - without a RT.

(For supporting legacy files ?)

 

I thought the RT "Texture" versions were updated versions, optimized for the newer

Material capabilities.

When also C4D Material import was added

(At the time when ancient simplified RW Textures got the upgrade to full C4D Material

feature support. (Means VW can render these but the RW Texture Material Editor does

not offer the interface to use these features from within VW)

 

(?)

Edited September 27, 2023 by zoomer

[Mark Aceto]

2 minutes ago, zoomer said:

I always thought that RT would stand for Raytracing (?)

 

Another one of my favorites: RT also means Ray Tracing aaaaaaaaand Real Time... so someday we can have realtime raytracing rendtrworks textures: RT RT RT!

[line-weight]

Naming doesn't just need to be streamlined, terminology needs to be carefully rethought in many areas. Just recently I've been fighting with this dialogue box.

 

 

We've ended up with scenarios where I can be choosing a dotted line for dashed hidden line display for hidden objects above the cut plane. And a dashed line for hidden line display within dashed hidden line display of hidden objects. And this is a different setting from where I can set a dashed line for non-hidden objects in hidden line display. I can see why everything has ended up with these names but I get migraines and this is the sort of thing that triggers them.

 

Where it's not possible to clarify things via carefully chosen terminology, there should be visual previews of exactly what everything refers to. Human brains don't work like computers.

Edited September 27, 2023 by line-weight

[Tom W.]

1 hour ago, Mark Aceto said:

 

RT = Renderworks Texture, so in the Renderworks Textures folder are Renderworks Textures RT... it's like The Department of Redundancy Department.

 

I believe this is a result of a years-long housekeeping exercise, and any texture with the RT suffix was somehow modernized. So now most of the textures end in RT.

 

To the point of the OP, they're just textures! We don't need all of this friction, especially for new users that are like, "Why do most of these end in RT but some don't?"

 

Textures, records, layers, clases, sheets (or plates if you're nasty)... 

 

 

I use all my own textures rather than the ones in the VW libraries but I still include a RT suffix to avoid naming conflicts i.e. I can have a 'Concrete RT' texture + a 'Concrete HF' hatch.... Also makes it easier (for me) to tell resources apart in RM

[Tom W.]

1 hour ago, zoomer said:

 

I think for you the UK material library is a good start.

If I had the localized VW version, I think it would be quite ok too.

But fighting against VW's default naming and folders so that I can

organize and find my stuff again was no fun so far.

 

I created all my own Materials. Same with every other resource. Don't think I've ever used anything straight off the shelf...

 

1 hour ago, zoomer said:

 

BTW,

in Bricscad there are no Container Materials.

There is only one level of Material.

So a Concrete + Rebars is just a reinforced Concrete single Material.

 

I think VW Compound Materials work fine. It is more about how quantities are reported + R value rather than appearance.

[zoomer]

2 minutes ago, Tom W. said:

I created all my own Materials. Same with every other resource. Don't think I've ever used anything straight off the shelf...

 

Respect.

Cool.

 

I usually do that too.

But only adding a VW resource like a Solar Panel will instantly contaminate your File Resource order.

(If we would finally get a table like GUI, similar to for VW localization, where we could rename all VW terms,

default folder locations, .... VW could be so pleasant and comfortable)

[Kevin Allen]

13 hours ago, Mark Aceto said:

The whole "RW" quagmire could use a little love. Not rearranging vegetables on the plate instead of eating them. Not overhauling it with something polarizing. Just lose the legacy artifacts, and streamline it... 

Can we crowd source a task document? There are a number of ideas in this thread (and others) about workflows and simplification. @markdd that probably need task documents created to communicate the right paths to the engineers.

Serious Question, I think the users need to define their own needs.

[Kevin Allen]

5 hours ago, Tom W. said:

I use all my own textures

I sometimes start with a stock texture, but always modify.