Wall styles: use of class attributes

[Petri]

An annoyed user has drawn my attention to a fundamental flaw in styled walls.

If a wall style has been defined NOT to use class attributes, he thinks (and I agree) that he should be able to give each wall an individual colour.

At present, if a wall style is defined as above, walls using it won't even get rendered (ie. does not have a fill). At the same time, the attribute palette choices are greyed.

No-one can have a wall style for each colour they might want to use.

"What," asks my irate correspondent, "is the point, the b-dy point, of having all these paint colours if I can't use them in walls?"

So, here's how this should be:

- Use Class Attributes: as is

- Not Use Class Attributes: pop-up to have

--- none

--- object attributes

--- solid etc

Hope this is clear. And fixed at least partially (to enable object attributes) ASAP. Yesterday would be fine.

EDIT

Use Surface Components' Attributes (class OR colour) would be good, too.

Edited December 6, 2007 by Petri

[Dieter @ DWorks]

you can have a wall style for every color?

[Petri]

Of course you CAN, but...

[brudgers]

The heirarchy of inhertance is class-->style--->wall.

Unstyled walls can be given individual graphic properties.

Those having a style are assigned properties by the style.

Those having a class are assigned properties by the class.

Style is the praxis of the conflict between the individual and the class system.

The alternative is anarchy.

Viva la Revolucion!

[Petri]

Is that so? Well, then the implementation of textures in VW is anarchy.

Now, tell me how does one deal with even 4320 paint colours and some 20 mandatory conceptual classes for walls?

If the alternative to 86400 wall styles is anarchy, I'll take anarchy.

[Pat Stanford]

Petri,

I am sure you know this, but for those who don't you can convert a styled wall to Unstyled in the OIP. It will keep the cavities and structure, but then can be altered with the attributes palette.

The down side is that the wall no longer is linked to the style, so if you change something the wall won't change.

But you can change an unstyled wall to any style you desire in the OIP, but then you lose the individual graphic attributes.

Maybe we need a script that saved the attributes of a wall, lets the user select a style for the wall, makes it styled, makes it unstyled and reapplies the attributes?

Pat

[Petri]

Yes, but that would entirely defeat the purpose of wall styles!

I paint a wall red - now, I no longer know its thermal or STC performance. Well, too bad!

While a Divine Guru & Operating Theta like yours truly might be able to script something like what you suggest (not sure, but the idea has passed my mind), it would rely on 7 or 8 large libraries and, according to the Creed of VectorWorks (as revealed to & witnessed by the Most Reverend Robert Anderson), could not be made publicly available.

[Guest]

The textures do not have to be handled by the wall style nor by the class. The wall textures can be set using the Render tab of the Obj Info palette.

[Petri]

Textures, maybe. They are of no use in the real world.

[brudgers]

Is that so? Well, then the implementation of textures in VW is anarchy.

Now, tell me how does one deal with even 4320 paint colours and some 20 mandatory conceptual classes for walls?

If the alternative to 86400 wall styles is anarchy, I'll take anarchy.

I think you're half right.

Each side of the wall could be a differnt color.

So it looks like you'ld need quite a bit more anarchy....86400!

[brudgers]

Of course the best way to assign a feature to individual walls might be via the data record.

Though that won't translate into a graphic representation.

[Petri]

Actually, it should go the other way around: when a user assigns a colour to an object (or part thereof), it becomes (if required) data in an alphanumeric database.

"Explicit" alphanumeric data is the last resort, since it usually has no relevance to the user and needs to be separately entered. One of the many advantages of VW is its rich vocabulary of "implied" data which can be queried and developed further by inference, often in conjunction of explicit & inherited data. (The term "inherit" used somewhat freely here.)

[brudgers]

Well, there's the data for graphic representation and the data for building modeling.

For BIM, the building model determines the graphic representation not vice versa. In other words, the graphic representation expresses the data properties of the underlying model.

The primary BIM Data vehicle is the data record. Classes and Styles are simply provided to simplify graphic management. An unstyled wall can still carry any desired data.

For me the simplicity is a benefit.

[Petri]

It's still the other way around... Classes and styles ARE data and either represent or can be used to control properties of objects.

[brudgers]

Like layers, classes are categories of objects which share common features.

The shared features of layers and classes may be graphic, spatial, or informational...this is to say that, different types of objects can be of the same class and/or same layer.

Styles are different. Only walls can have a wall style. And only walls of similar construction can(should?) share a style.

If there is a need to differentiate walls within a style; layers, classes or data records are the options.

If the differentiation is graphic, then it's got to be layers or classes...or using unstyled walls.