Materials

[PVA - Admin]

So... Materials, or Building Materials.

This is a big one, and a concept/feature we are actively looking into developing. For me personally this is a more difficult feature to properly frame out, as I feel I may lack sufficient industry knowledge to detail what such a feature would include. To that end, I am requesting your comments, concerns and any other input regarding the scope of your needs and how we can best meet them.

Now, this is not to say that as of this post we BEGIN developing Materials, talk about this internally has been going on for a long time and many of our distributors (some of them accomplished architects and designers in their own right) have been providing us with wishes and other suggestions, but this thread will concentrate on specific user needs that I will curate and add to internal planning pages for use by engineering since I am sure there will be a great deal.

I won't merge the other existing threads since many of them have tangents to things I feel are a bit outside the scope of this feature, so this will be the new home for this discussion.

I have pulled input from many existing threads, (Special thanks to @digitalmechanics, @zoomer, @Chris D, @Dieter @ DWorks, @Christiaan and many others whose threads and posts I stole from) as well as from competitors feature lists. Feel free to link in any I may have missed that have missing key points to advance this initial list:

1) Materials must be assignable to any object, 2D or 3D, with the 3D aspects of the Material simply left out of 2D scenarios.

2) Users must be able to not only rely on an extensive default catalog of Materials, but be able to add new Materials themselves from scratch.

3) Materials must be a resource type available in the resource manager with all the current share-ability of current resources via workgroup folders.

4) Users must be able to update a source Material resource and have that push the update to all instances where a Material is used.

5) Materials must include Line Styles for both the 2D and 3D edges of geometry, separate control for section vs non-section views.

6) Materials must include Hatch settings for both the 2D and 3D faces of geometry, separate control for section vs non-section views.

7) Materials must include Tile settings for both the 2D and 3D faces of geometry, separate control for section vs non-section views.

8) Materials must include Textures.

9) It must be possible to generate reports on the volume, weight, density, cost, surface area, exposed surface area, and thermal properties.

10) The same Material needs to be applicable to wall, slab, roof components as well as solids. Duplicates should not need to be created for each type of object to inherit the Material's settings.

11) Materials need to (optionally) have the ability to determine the joins for wall, slab and roof components contextually. Each of these types of joins needs to be user definable.

12) What aspects a Material inherits from the resource should be controllable similarly to Door and Window Types, where users are able to select certain fields that use the Material resource and then allow for overrides for that particular object's particular field value.

If I have completely or partially missed the mark with this list, feel free to correct me.

[Pat Stanford]

I'm not doing a great job of coming up with a better explanation in my head, so I am just going to write this as a starting point:

Objects need AT LEAST three types of information to allow a user to specify

Layers are WHERE objects are: (position in space, different scale needed, etc)

Classes are WHAT an object is: (Wall, furniture, fixture, truss, lighting device, etc)

Materials are the PROPERTIES of an object (Material, density, fire resistance, cost, etc). These properties need to be unit smart, so if you have some prices in $ and some in € you can set up a worksheet and have them automagically converted to the unit you want them in with a user specified or static (for units of measure) conversion rate.

We need to be able to set visibilities of object by any combination of the three. For bonus points visibility by the individual FIELDS of Materials would be great.

And the ability to use any of the above as a kind of temporary GROUP/SELECTION to be able to easily modify multiple objects at once. And the ability to select a subset and change the information for that subgroup without changing all of the other objects in the drawing.

The ability to set the display attributes of an object by whichever type of information (Like By Class, but also for By Layer and By Material).

Materials need to be extensible. If I decide that I need an extra field I should be able to add it at any time. And easily transfer that field to other materials if needed. But not have it show on Materials where it makes no sense. I might want to know the coverage (Square feet / gallon) of paint, but I certainly don't want to see that field in lighting fixtures and roof shingles.

Material Properties need to be easily accessing in worksheets. They should not require special functions (like the current Wall, Roof, Curtain Wall and Component functions).

Materials COULD take the place most of the custom data field in objects like Door and Window. The trick there would be to keep the information that should not be changed but that is not an intrinsic part of the object geometry from being accidentally changed. It would be bad to have a material for a steel door that included a price for that door and have someone accidentally apply that material to a door that was twice as expensive or half as expensive.

Maybe a starting point for discussion.

[zoomer]

Ok implement it

Just kidding.
Why not start a Poll with these questions (by Multiple Choice Option)

1-3) Yes
4) Yes, a Material is parent, any change will update all parts where it is used.
5) ? why would we need Classes anymore ?
6-7) = same item ?  -  well big questionmark.
Currently don't overview if those things should be controlled by Classes, Materials or in Textures ....
8) I would say RW Textures are separate Group in RM, but you will assign one of the RW texture to your Material
9-10) Exactly
11) Well that is "priority based automatic joining", of course I would like to have that, but see it as an new feature
12) to keep it simple, for the beginning, no.
Like a Wall Style, when none of the existing doesn't fit needs, you duplicate the most nearest and adapt to fit ?

For the beginning I think it is even fine that there is such a system, collecting all data that we currently input in
things Wall/Slab Styles redundantly again.
So when I create a Wall Style Component from scratch, and chose a Building Material,
that Component automatically gets its name by the Material Name, its R-Values for Energos, The Material for IFC Tags,
Fire Withstand, ... you name it.
Similar to a common File and Project Info Container that will feed all sheet borders, IFC Project Tags, ....

 

Edited September 19, 2016 by zoomer

[PVA - Admin]

We do want to remove a lot of the burdens that are currently placed on the Class system. They are overworked and user's class lists are becoming extremely long and complex, however I don't feel that we would necessarily NEED to remove a lot of their functionality, some redundancy as long as users are given adequate control of overrides would be fine, Classes and Layers have many crossover abilities that users combine in unique ways to great effect.

I think treated Materials as extensible makes a lot of sense as well, letting users utilize them for something as simple as "Have this texture and this thermal conductivity" as a start, all the way up to eventual section appearance, cost, physical properties such as tensile and compressive strength, or even how much sand per cubic meter in a given type of concrete. Letting this be expandable by the user similarly to how Records are I think is a key element to their usability and to separate them dramatically from Classes.

[Pat Stanford]

My wish would be for the ability to easily change "Material Sets".  I am thinking some sort of spreadsheet format that would show the "groups" that have a certain material down the side and multiple columns for the material to be applied. There should then be a way to  create a new "column" based on an existing one and modify the material to be applied. Then a way to select the column (SET) to be currently used.

An example of this would be to have one Set showing a stucco exterior of a given color. An alternate Set could then have wood siding or shingles or ???

There would also need to be a way to take a modified Set and effectively apply it back to the original. So if you changed one side of a house to be a different material, the original Set would then show that side as a separate row, but with the original material.

This needs a lot more fleshing out, but I think the idea of Sets of materials is just as important as having materials by themselves. Especially if you want to use Materials to show different design options.

[zoomer]

OK, Hatches belong to Classes or Materials, not to Textures , as you can't see them in a RW render anyway ...
But I do too less VP or 2D to decide Class or Material.
I see Building Materials as a simple thing.
Shouldn't be more included in a file as RW Textures.

I see it as main Materials that are mostly used in Multi Component Plugin Objects, where they get added to
the final sandwich. I do not think about every little steam blocking foil.
Of course the final outer surface appearance should be visible.

If such details can be included, like Material Sets and Combinations, if that is possible from software side
and doesn't decrease users's usability - of course welcome ...

It needs a certain flexibility.
Like when you will need to add prices, some Materials will need cubic meters, other square meters or meters.
for other Materials that may not make any sense at all.
Physical qualities can be included, like weight, burning or not and those things, but maybe things like fire withstand
better belong to the plugin objects itself (Or VW will calculate that for us. I think that would need some AI)

But if there is already a Wood Materials for Walls, I would like to apply that to my doors, windows and maybe furniture
too.

[Matt Overton]

List looks good and I'm a big fan of materials (we use a class family dedicated to materials) and would welcome any change that makes them more common in usage but also makes them easier to resource. I think there should be a push to try and make the interface to materials more visual than purely by abstract settings like classes are now. If we could have a cube in space and see the cut section face with ability to click on part to edit that would be grand.

What I can't pick from this list is the relationship with classes. So would suggest:-

13 (or 8 seeing it's a double)  Materials must be a usable way to define class attributes with optional 2D Attribute overrides.

 

Also meant to add as a stretch goal- some materials are linear in nature it would be great to be able to set different looks for when see in length vs short section.

 

 

Edited September 20, 2016 by Matt Overton

[digitalcarbon]

there seems to be some things that have a specific shape. such as plywood.  (is plywood a product or material?) if I'm working in plywood i don't want to model it THEN apply a material to it.  i would rather go to the resource manager, find 3/4" plywood and drag it in like a symbol. it would need to be locked in the thickness dimension but i can push/pull it in length and width.  so i guess that plywood would need to have a type of orientation to it so that it knows that the thickness does not change.

its about what needs to be ordered to build the project.  plywood is really wood & glue material, but no one is going to order that.  they will order plywood  

whatever is done i think it should be worked in with a type of "Product/Material" mindset.

below is a previous video posted, but it shows that a type of "Product/Material" object vs just Symbols only (& definitely way better than the parametric mindset)

 

[PVA - Admin]

56 minutes ago, digitalmechanics said:

there seems to be some things that have a specific shape. such as plywood.  (is plywood a product or material?) if I'm working in plywood i don't want to model it THEN apply a material to it.  i would rather go to the resource manager, find 3/4" plywood and drag it in like a symbol. it would need to be locked in the thickness dimension but i can push/pull it in length and width.  so i guess that plywood would need to have a type of orientation to it so that it knows that the thickness does not change.

its about what needs to be ordered to build the project.  plywood is really wood & glue material, but no one is going to order that.  they will order plywood  

whatever is done i think it should be worked in with a type of "Product/Material" mindset.

below is a previous video posted, but it shows that a type of "Product/Material" object vs just Symbols only (& definitely way better than the parametric mindset)

 

That I would see as a second or third phase, objects whose dimensions are actually controlled by what material they were made from, but since a Material in Vectorworks would most likely be a properties/attributes and currently we divide functionality by object type I think something like you describe would be an advanced version of the feature. Plywood, concrete blocks, rebar, prefab components for modular construction and a number of other things lend themselves to this concept well.

[rDesign]

14 hours ago, Matt Overton said:

Also meant to add as a stretch goal- some materials are linear in nature it would be great to be able to set different looks for when see in length vs short section.

This ties into the UV Mapping wish-list item in that materials with grain (e.g. wood) should be able to have different 2D textures for the short, long and face grains.

[PVA - Admin]

14 hours ago, Matt Overton said:

Also meant to add as a stretch goal- some materials are linear in nature it would be great to be able to set different looks for when see in length vs short section.

 

4 minutes ago, rDesign said:

This ties into the UV Mapping wish-list item in that materials with grain (e.g. wood) should be able to have different 2D textures for the short, long and face grains.

Correct, that would be separate from the scope of Materials specifically, but any future improvements to texture mapping would of course need to apply to the mapping of material textures as well.

[zoomer]

I see Building Materials more as a Data and Info Container only.
Don't know if 2D visual appearance should be included or stay in Calsses or both.
But for visual rendering appearance, I think that is still the job of Rendering Materials*.
(*Some call it RW Textures)

[PVA - Admin]

11 minutes ago, zoomer said:

I see Building Materials more as a Data and Info Container only.
Don't know if 2D visual appearance should be included or stay in Calsses or both.
But for visual rendering appearance, I think that is still the job of Rendering Materials*.
(*Some call it RW Textures)

Right, that would be Materials as they exist in C4D and other rendering apps, the focus for us is more Construction or Building Materials. 2D appearance control (ability to override class attributes optionally or vice versa depending how we go about it), as well as 3D edge and section attributes would be integral for Vectorworks' implementation of this idea. 

[zoomer]

Would that allow to get rid of the current class overrides in Components,
that I currently have to set each to "by class" each time I create a new component.
(If not, there should be a "set all to by class" checkbox)

And for Windows,
Would I set my Jamb Material in Jamb Options or in (beside) the Class list ?
Or does the Class list stay there to override or if no Materials assigned ?

 

In General, I think this won't be an easy task, as you have to modify each Plugin Object's
Setting Box and more. And finally check all bad influences in function and stability.
:)

[Tom Klaber]

21 hours ago, zoomer said:

Ok implement it

Just kidding.
Why not start a Poll with these questions (by Multiple Choice Option)

5) ? why would we need Classes anymore ?

 

 

Just because an object is made out of the same material does not eliminate the need to class the objects.  I could have a concrete stair, concrete fireplace, concrete slab, concrete structural wall component and I may want to be able to control the visibility of those objects separately.  Classes need to stay.

[PVA - Admin]

Im thinking @Pat Stanford's view on having Layers, Classes and then the new Materials as described is the way to go. This gives another means of customization and control without impacting existing methods, but one that could still be simply ignored if the user was not interested in it, OR used instead of the other two for more focused workflows like raw 3D modeling and rendering.

[Tom Klaber]

Its true - if Materials is a "Style" like control - if you wanted to in @zoomer's direction - you could set a material's class settings to By Material Style so all instances of that material are classed the same - or if you want the objects to have the ability to be classed separately, the class would be a by instance setting.  

[zoomer]

4 minutes ago, Tom Klaber said:

Just because an object is made out of the same material does not eliminate the need to class the objects.  I could have a concrete stair, concrete fireplace, concrete slab, concrete structural wall component and I may want to be able to control the visibility of those objects separately.  Classes need to stay.

I have a similar setup.
We currently don't have Building Materials, but I have 3 Concrete Tecture Materials already 
So if one Concrete will be fabricated, other parts CIP, than I will also have to Building Materials,
I think these will differ in Price or timeframe anyway.

I don't want to let Classes die, I'm just not sure which Controls will belong to which.

 

6 minutes ago, JimW said:

Im thinking @Pat Stanford's view on having Layers, Classes and then the new Materials as described is the way to go. This gives another means of customization and control without impacting existing methods, but one that could still be simply ignored if the user was not interested in it, OR used instead of the other two for more focused workflows like raw 3D modeling and rendering.

 

Absolutely.
i didn't meant at all that Classes should go or be replaced.
There was just one proposal, don't remember, which seem to make Materials direct competition of essential Class Functionality.
 

[Pat Stanford]

Right now, Classes are used for too many things.

    What type of object it is

    What kind of attributes the object has

    What the visibility of the object is

    Viewport Overrides of visibility and attributes

Some of those "things" need to be broken out separately so you don't end up with redundant classes that have the same attributes but to allow separate visibility.

Actually, it would be really great to make this "infinitely" expandable. Rather than have a single "material" that is applied to an object, what about the ability to "attach" multiple "properties" to an object. Sort of like Records are now, but with the ability to use them to "easily" control both visibility and display attributes.

So you could have a wall object that could have a composite "Material" that would be the summary of all the components that make up the wall. Then later in the design you could replace the generic wall type with a detail wall type that would include all the components, each having individual materials (and perhaps labor hours are well) that would then sum up to be used for the overall wall.

So perhaps instead of thinking of this as Materials, we should think of this as Properties. Properties of different components would sum to get costs, insulation values, fire resistance, etc.

I'm glad I'm not the one who has to implement this, but I think that limiting individual Objects or individual Components to a single "Material" rather than having the ability to attach multiple "Properties" may not be the right way to go. More flexibility is always better than less. Except when it adds so much complexity that it is not better.

 

[Tom Klaber]

The power of the concept of Materials is that is mirror real world construction - which is the right direction to go.  Materials come with properties associated with that material - and I think that is a useful conceptual tool.  Now that we can style by record with the data visualization, it has taken some pressure off of classes.  (ThoughI have not played with this - I think it would be good to be able to do both at the same time - style by class for all objects EXPECT for those that have the following record. - I hope that is the way it works).  

[Matt Overton]

16 minutes ago, Pat Stanford said:

Right now, Classes are used for too many things.

    What type of object it is

    What kind of attributes the object has

    What the visibility of the object is

    Viewport Overrides of visibility and attributes

Some of those "things" need to be broken out separately so you don't end up with redundant classes that have the same attributes but to allow separate visibility.

 

 

These things aren't different or separate they are all tasks on the same path. They are all part of the storyline needed to get buildings built. 

What type of object is it

How do I want it seen generally 

When do I want to hide it so other objects can be highlighted

When do I want to tone up/down that object to tell details of the story. 

 

But that comes back to the core question do we need materials or just better classes?

[zoomer]

Classes for visibility control.
Clases for 2D appearance overrides, or for all those many Elements like 2D that can't have Materials
(aham why ?)

Currently I use large part of my classes as materials as I need this pre-2017 for C4D Export.
Another part is Building Elements just for Visibility control and some few 2D Classes.

Although this will no more needed with 2017, I can use my classes as I want now,
and Materials could even hold the whole former Material Classes,
I will keep this system as it works also well for me for visibility control and VP's

 

When I had the first idea of a Material System, I was again in a situation where I had set tediously
my first Concrete Wall Component including R-Value dropdown, afterwards had to do exactly the
same procedure for my first Concrete Slab Component.
That was the time when I thought that would be a bit easier to do that one time only.
If a Building Material Setup can do this one time, I will be happy.
If Plugin Tools get so intelligent to also use that information to better feed their IFC data automatically,
the better. If it can do even much more - welcome.

Edited September 20, 2016 by zoomer

[Thomas Wagensommerer]

Classes already do almost everything we expect from materials. I suspect most users already use classes as materials. I think we need a solution that does not create redundant information and is compatible to the way most users already have organized their classes.

I would like to suggest to separate classes into 2 types.

1.) "Material Classes"

Those can do everything our classes can do now. Additionally they would recieve the ability determine the joins for wall, slab and roof components and all the other already suggested abilities for materials.

2.) "Organizational Classes"

These would be used only for visibility control and 2D appearance.

Every object would be able to reside in one Material and one Organizational class.

The advantage of that system would be, that we dont get even more dialog boxes, dropdown menus palettes and so on. Users, that use classes as material would not be forced to reorganize everything. The change to the user interface would be a inside the class definition dialog to determine the type, a divider line in the class list and a additional materials popup in the object info.

 

 

16 hours ago, zoomer said:

Classes for visibility control.
Clases for 2D appearance overrides, or for all those many Elements like 2D that can't have Materials
(aham why ?)

Currently I use large part of my classes as materials as I need this pre-2017 for C4D Export.
Another part is Building Elements just for Visibility control and some few 2D Classes.

Although this will no more needed with 2017, I can use my classes as I want now,
and Materials could even hold the whole former Material Classes,
I will keep this system as it works also well for me for visibility control and VP's

 

When I had the first idea of a Material System, I was again in a situation where I had set tediously
my first Concrete Wall Component including R-Value dropdown, afterwards had to do exactly the
same procedure for my first Concrete Slab Component.
That was the time when I thought that would be a bit easier to do that one time only.
If a Building Material Setup can do this one time, I will be happy.
If Plugin Tools get so intelligent to also use that information to better feed their IFC data automatically,
the better. If it can do even much more - welcome.

 

 

Edited September 21, 2016 by Thomas Wagensommerer

[Tom Klaber]

1 hour ago, Thomas Wagensommerer said:

Classes already do almost everything we expect from materials. I suspect most users already use classes as materials. I think we need a solution that does not create redundant information and is compatible to the way most users already have organized their classes.

I would like to suggest separate classes into 2 types.

1.) "Material Classes"

Those can do everything our classes can do now. Additionally they would recieve the ability determine the joins for wall, slab and roof components and all the other already suggested abilities for materials.

2.) "Organizational Classes"

These would be used only for visibility control and 2D appearance.

Every object would be able to reside in one Material and one Organizational class.

The advantage of that system would be, that we dont get even more dialog boxes, dropdown menus palettes and so on. Users, that use classes as material would not be forced to reorganize everything. The change to the user interface would be a inside the class definition dialog to determine the type, a divider line in the class list and a additional materials popup in the object info.

 

 

 

 

 

Naming them both classes will be super confusing, but the 1 dialog is not bad.  You could set the class - which would have lost some power - and you can set the material which will give some added information to the object.  

I think I still prefer the "Style" method (Though please do not call it 'Material Styles') where the user can decide how much control a Material definition has.  Certain materials might take total control over visibility and class definitions, other materials might only give an R-Value or allow quantitative calculations leaving the class, visisbility, and attribute stuff up to the instance.

[Thomas Wagensommerer]

51 minutes ago, Tom Klaber said:

Naming them both classes will be super confusing.

True. I would call the dialog box "Classes and Materials". "Material Classes" would be called "Materials" and "Organizational Classes" would be called "Classes".

[zoomer]

I would Call them :

Classes => Classes (you remember I would call these Layers)
RW Textures => Render Materials
Materials => Building Materials

Classes are needed and still have to do a lot of jobs.
Visibilities, Editabilities, Transparencies, Attribute Overwriting, 2D Appearance, ... (Lock Freeze, Render, C4D/FBX Export, ...)

Building Materials, beside their Data and Information, 3D Appearance, Render Material assignment, ...
may also overwrite Classes Settings, if needed.