Material, Layer, Color, Alpha

TIG

A Material has a Color, it also has an alpha setting - this transparency applies to the material itself - its Color's alpha setting is ignored.

A Color can have an alpha setting, but this is only used when a color is used in the 'draw' commands for the temporary graphics used by a Tool - such a faces and rubber-banding lines. Also note that this color and alpha setting only works in newer versions of SketchUp - the older versions can have colored lines, but have 'black' faces and fully opaque temporary-graphics irrespective of their color's alpha.

Only recently have you able to change a layer.color in the API.
The Color associated with a layer can have an alpha, BUT it is academic as this is currently ignored.
And there is currently no equivalent layer.material...

MSP_Greg

Note to self – don’t compose messages when reorganizing code object structures.

Rephrasing my original post

The following returns a correct value –

Material.alpha

The following DO NOT return the correct value –

Material.color.alpha
Material.color.to_a[3]

Layer.color.alpha
Layer.color.to_a[3]

The following do not return correct value for the ‘A’ string

Material.color.to_s
Layer.color.to_s

I think it would be helpful the three color properties that return alpha information worked with both material and layer, returning the opacity...

Thanks,

Greg

tt_su

Yea, it would have been good if the two alpha values where linked. I ran into that confusion myself before my time as a Trimbler. Wrote up an article on it: http://www.thomthom.net/thoughts/2012/03/the-secrets-of-sketchups-materials/
We have an issue filed for that.

Dan Rathbun

Not so fast.

material.color does not return a property. It returns a reference to a separate Ruby object, which can be shared across multiple Sketchup::Drawingelement subclass instances.

If changing the alpha upon a material object, changed every object that also referenced that color object, there would be some really ticked off people (both users and programmers alike.)

This is why the transparency property is implemented upon the Sketchup::Material class, and not the Sketchup::Color class. (As TIG noted, the color's alpha is only implemented for viewport drawing of screen elements, not model entities.)

You paint objects with Materials not Colors. It's like the concept that paint is mixed with chemicals, and pigments (which are the colors,) and perhaps metal flake, etc. The color(s) are only part of the ingredients.

Example. Think about creating a set of glass materials.
The set can all reference one color object as their base color.
Each material in the set can have a differing transparency setting, without changing the shared base color.
Any or all of this set can be painted upon faces in a model.
Adjustments to one material should not effect elements painted with other materials.

ccaponigro

@tt_su said:

Yea, it would have been good if the two alpha values where linked. I ran into that confusion myself before my time as a Trimbler. Wrote up an article on it: http://www.thomthom.net/thoughts/2012/03/the-secrets-of-sketchups-materials/
We have an issue filed for that.

Totally unrelated but just have to say bitching cool avitar picture.

Dan Rathbun

@msp_greg said:

The following DO NOT return the correct value –

Material.color.alpha
Material.color.to_a[3]

Layer.color.alpha
Layer.color.to_a[3]

The following do not return correct value for the ‘A’ string

Material.color.to_s
Layer.color.to_s

Yes they DO.
They are returning the correct properties of the returned Sketchup::Color instance object.
Ruby does exactly what you ask it to do (unless you ask incorrectly.)

There is an issue with the Sketchup::Layer class. The color and color= methods were implemented hastily late in a cycle. The problem is that layers actually have material references, but because the GUI feature is called "Color By Layer", it seems that someone thought this feature is display only, and there fore color only.
But although it is display only, the reference should be to a material with it's alpha property.
So the added methods, should have actually been layer.material and layer.material=, instead of color and color= methods.
If it were just a naming issue, we could live with it or alias the method names. But although there is a implicit conversion of color to material in many API methods, the opposite is not true.

Also.. weirdly materials assigned to layers via the GUI, do not appear in the "In Model" materials list.

MSP_Greg

@dan rathbun said:

Not so fast.

material.color does not return a property. It returns a reference to a separate Ruby object, which can be shared across multiple Sketchup::Drawingelement subclass instances.

Hmmm. Sorry if I confused you. I don't believe I said that anything returned a property. Color is a property of the material object.

@dan rathbun said:

If changing the alpha upon a material object, changed every object that also referenced that color object, there would be some really ticked off people (both users and programmers alike.)

Ticked off. I hate that.

First of all, the color property returns a color object, but it is not a reference to it; it is a new color object loaded with the values of the material's 'internal' color object. As such, color objects behave more like values, hence, when setting a color property to a color object, a reference is not created, the color object's values are just copied. Nothing changes with the following code --

` amMats = Sketchup.active_model.materials
oColor = amMats["Audience"].color
oColor.blue = 255

below also does nothing

amMats["Audience"].color.blue = 255`

Hence, your example...

Greg

Dan Rathbun

@msp_greg said:

` amMats = Sketchup.active_model.materials
oColor = amMats["Audience"].color
oColor.blue = 255

below also does nothing

amMats["Audience"].color.blue = 255`

Firtsly:
oColor.blue = 255
... does do something. It sets the blue component of the oColor object.

Why don't you see any change?

Because this proves my point that there are no properties in Ruby.
To see a change, you'd have to reassign the material's color like:
oColor = amMats["Audience"].color oColor.blue = 255 amMats["Audience"].color=oColor

If this seems weird, then it's just the way Ruby is. Most methods return new objects (unless their names end in ! or are true, false, nil, or one of the ordinal integers.)

Now you could file a feature request for some "immediate" methods, that would refer directly to the internal C++ properties. In Ruby, these methods have names that end with an exclamation point, as in:
sort! (which acts upon the enumerable collection itself, instead of returning a sorted copy.)

So if you wanted to set the blue of a material's color, without going through the unneeded assignment of a new color instance reference, it would look like:
amMats["Audience"].color!.blue= 255
or maybe closer to this:
amMats["Audience"].color![:blue]= 255

Yea, the second example is likely it, because other places in the API, internal C++ properties are accessed via a hash-like protocol. See the RenderingOptions and ShadowInfo classes.

But the API Team would have to implement these methods, and they can't unless a API Feature Request is filed.

Dan Rathbun

My quick reply is that Ruby does NOT have "properties".

.color() is a method call, that returns a reference to a Sketchup::Color instance object.

All I'm saying is that changes to the API need to be sure not to confound Apples and Oranges.

tt_su

@dan rathbun said:

Not so fast.

material.color does not return a property. It returns a reference to a separate Ruby object, which can be shared across multiple Sketchup::Drawingelement subclass instances.

Under the hood Material would convert that to an C++ color structure. The accessor recreate a new Ruby object when it returns it.

Dan Rathbun

Ok (we understand this,) but what do think about directly changing the C++ properties like:
matl.color![:blue]= 255
etc.

MSP_Greg

Dan,

Your first post started with 'Not so fast', then mentioned referenced objects, 'really ticked off people', and a few other interesting phrases like 'Ruby does exactly what you ask it to do (unless you ask incorrectly.)'

Now you've taken a different tack.

Your subsequent posts state –
My quick reply is that Ruby does NOT have "properties".
Why don't you see any change?
Because this proves my point that there are no properties in Ruby.
If this seems weird, then it's just the way Ruby is.

Regarding properties, methods, etc, I suggest you Google “properties vs methods”, as the distinction you're making is pointless and in error. Also, 'by reference' and 'by value' can apply to properties or methods.

You're mixing together the Ruby programming language and the SU API. Much of what you've said about Ruby is incorrect (or really applies only to the SU API), and your programming terminology is, at a minimum, odd. If you feel I'm mistaken, I'd suggest you read a few books on API / class design and OOP programming. You might also study other API's like the javascript DOM API, or the .NET API.

As an example, you've mentioned 'instance.' 'Instance' is applicable to programmers and designers of classes and API's, as is the term class (or static.) Users of API's rarely would use the term, as they are restricted to whatever the API allows, and aren't concerned with its internal implementation.

Regarding all of your 'ideas' about the color object (especially 'amMats["Audience"].color!.blue= 255'), they are strange. Plain and simple, color is a property of the material object, and AFAIK, no ruby properties use the “!” symbol, which is always used with methods that change an object. Big difference. The “!” symbol is used as a shortcut to self re-assignment, which is common in many languages, and can also be used in Ruby. IOW, the following are identical –

someArray.sort!
someArray = someArray.sort

It can also used when 'method chaining', but many programmers would prefer separate statements.

You've contributed a lot to this forum, but IMHO, many of your posts are argumentative, condescending and off topic. Please try to improve your signal to noise ratio...

Finally, API's are messy. Once something is added to one, it needs to be supported essentially forever. There have been many times where I wish the SU API was laid out differently (more like the DOM or .NET API's), but we and the SU dev team are stuck with it. Additionally, the SU API is designed with an eye towards being used by people who are not hardcore programmers. That shouldn't prevent discussions about how it might change or be improved. Let's just try to have good, on topic discussions.

Greg

Dan Rathbun

Greg you have been "ignored" because you are a troll. You have a total of 23 posts here. I have near 5000! You are both incorrect and insignificant.

MSP_Greg

Dan,

@dan rathbun said:

Greg you have been "ignored" because you are a troll. You have a total of 23 posts here. I have near 5000! You are both incorrect and insignificant.

As I stated, condescending.

The fact that I choose to spend my free time away from computers doesn't really have any bearing on what I know or what I've said.

I don't recall there being a relationship between quantity and quality regarding forum posts. Most forums always have a few people who feel their (often newfound) knowledge is so unique and authoritative that they post to almost every thread...

Please enlighten me and post a link to anywhere on the Internet that says something similar to your statement 'there are no properties in Ruby.'

Same thing goes for the statement 'Most methods return new objects.' By the way, you use the word 'new.' Since you've mixed it up before, are you referring to a new object like material.color, or a reference to a child object like Sketchup.active_model.entities?

You've misused many programming terms that have relatively standard definitions, and, as I've stated previously, you conflate Ruby and the SU API. I'd suggest you do some reading and join some other programming forums/lists.

BTW, my 'Design Patterns' book by the 'Gang of Four' is 2nd printing. I think it's currently at the 40th (or more) printing. Do you have a copy?

Greg