colour priorities

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

colour priorities

nophead
This: color([1,0,0]) color([0,0,1]) cube(10);

displays a blue cube (June release). I expected it to draw a red cube.

translate(...) rotate(...) cube() rotates first and then translates so I would expect it to first colour the cube blue and then make it red. What do other people think?
Reply | Threaded
Open this post in threaded view
|

Re: colour priorities

nophead
I should add the reason I noticed it is that if you have a part in a library that defines its own colour you can translate, rotate and scale it but you can't recolour it.

On 24 December 2011 18:23, nop head <[hidden email]> wrote:
This: color([1,0,0]) color([0,0,1]) cube(10);

displays a blue cube (June release). I expected it to draw a red cube.

translate(...) rotate(...) cube() rotates first and then translates so I would expect it to first colour the cube blue and then make it red. What do other people think?

Reply | Threaded
Open this post in threaded view
|

Re: colour priorities

Whosawhatsis
In reply to this post by nophead
I agree, that's how it should work.

On Saturday, December 24, 2011 at 10:23 AM, nop head wrote:

This: color([1,0,0]) color([0,0,1]) cube(10);

displays a blue cube (June release). I expected it to draw a red cube.

translate(...) rotate(...) cube() rotates first and then translates so I would expect it to first colour the cube blue and then make it red. What do other people think?
_______________________________________________
OpenSCAD mailing list

Reply | Threaded
Open this post in threaded view
|

Re: colour priorities

kintel
Administrator
In reply to this post by nophead
On Dec 24, 2011, at 19:27 PM, nop head wrote:

> I should add the reason I noticed it is that if you have a part in a library that defines its own colour you can translate, rotate and scale it but you can't recolour it.
>
A use-case for the opposite would be a library only coloring certain parts objects to be able to distinguish them. If color()  overrides all subtree colors, this would be lost.

An alternative to making color() always override is to keep the current behavior as default and add a parameter:
// This will be blue:
color([1,0,0]) color([0,0,1]) cube(10);

// This will be red:
color([1,0,0], override=true) color([0,0,1]) cube(10);

Comments?

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: colour priorities

Whosawhatsis
I would think that if you wanted to be able to distinguish parts based on the coloring provided by the library, you would not be setting a color. If you do set a color, you would expect it to override any color already applied, like layers of paint.

On Sunday, December 25, 2011 at 8:16 AM, Marius Kintel wrote:

On Dec 24, 2011, at 19:27 PM, nop head wrote:

I should add the reason I noticed it is that if you have a part in a library that defines its own colour you can translate, rotate and scale it but you can't recolour it.
A use-case for the opposite would be a library only coloring certain parts objects to be able to distinguish them. If color() overrides all subtree colors, this would be lost.

An alternative to making color() always override is to keep the current behavior as default and add a parameter:
// This will be blue:
color([1,0,0]) color([0,0,1]) cube(10);

// This will be red:
color([1,0,0], override=true) color([0,0,1]) cube(10);

Comments?

-Marius

_______________________________________________
OpenSCAD mailing list

Reply | Threaded
Open this post in threaded view
|

Re: colour priorities

Berend Dekens
In reply to this post by kintel
On 25-12-2011 17:16, Marius Kintel wrote:

> On Dec 24, 2011, at 19:27 PM, nop head wrote:
>
>> I should add the reason I noticed it is that if you have a part in a library that defines its own colour you can translate, rotate and scale it but you can't recolour it.
>>
> A use-case for the opposite would be a library only coloring certain parts objects to be able to distinguish them. If color()  overrides all subtree colors, this would be lost.
>
> An alternative to making color() always override is to keep the current behavior as default and add a parameter:
> // This will be blue:
> color([1,0,0]) color([0,0,1]) cube(10);
>
> // This will be red:
> color([1,0,0], override=true) color([0,0,1]) cube(10);
>
> Comments?
I agree with nop head: I'd expect the cube to be red as well. I think
the opposite makes more sense:

// Blue cube: inheriting colors is disabled
color([1,0,0]) color([0,0,1], inherit=false) cube(10);

Regards,
Berend

Reply | Threaded
Open this post in threaded view
|

Re: colour priorities

kintel
Administrator
In reply to this post by Whosawhatsis
On Dec 25, 2011, at 17:19 PM, Whosawhatsis wrote:

> I would think that if you wanted to be able to distinguish parts based on the coloring provided by the library, you would not be setting a color. If you do set a color, you would expect it to override any color already applied, like layers of paint.

Good point.

The reason I said what I said is that this is common behavior in scene-graph engines. Overriding is usually controller by the "caller", not relinquished by the "client". Of course, this is not a scene-graph engine, so we're free to use other strategies.

I'm good either way, so I'll defer to the wishes of people actually modeling stuff :)

The only real concern I have is backwards compatibility. The behavior in earlier releases has always been that color only overrides the default color, not any specifically set colors, which is opposite from what is currently being wished for.
Otoh, I guess nobody is really dependent on this functionality.

I'll give it a day or two to see what shows up here.

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: colour priorities

Steven Dick
Alternately,
   color([1,0,0]) color([0,0,1]) cube(10);

could be the same as
   color([1,0,1]) cube(10);
Reply | Threaded
Open this post in threaded view
|

Re: colour priorities

Whosawhatsis
If anything, that should be color([.5, 0, .5]), but I doubt that's what anyone will actually want.

On Sunday, December 25, 2011 at 9:09 AM, Steven Dick wrote:

Alternately,
   color([1,0,0]) color([0,0,1]) cube(10);

could be the same as
   color([1,0,1]) cube(10);
_______________________________________________
OpenSCAD mailing list

Reply | Threaded
Open this post in threaded view
|

Re: colour priorities

Berend Dekens
In reply to this post by Steven Dick
On 25-12-2011 18:09, Steven Dick wrote:
> Alternately,
>    color([1,0,0]) color([0,0,1]) cube(10);
>
> could be the same as
>    color([1,0,1]) cube(10);
But then getting a green cube would require:
color([-1,1,-1]) ....

And stacking multiple modules would result in a nightmare of possible
colors.

Reply | Threaded
Open this post in threaded view
|

Re: colour priorities

Triffid Hunter
> On 25-12-2011 18:09, Steven Dick wrote:
>> Alternately,
>>    color([1,0,0]) color([0,0,1]) cube(10);
>>
>> could be the same as
>>    color([1,0,1]) cube(10);

nono, color([1,0,0]) color([0,0,1]) should be the same as color([1,0,0])

HOWEVER

color([1, 0, 0, 0.5]) color([0, 0, 1, 1]) should be the same as
color([0.5, 0, 0.5, 1]) !

tl;dr: remember the alpha channel!

Reply | Threaded
Open this post in threaded view
|

Re: colour priorities

kintel
Administrator
On Dec 26, 2011, at 01:26 AM, Triffid Hunter wrote:
> HOWEVER
>
> color([1, 0, 0, 0.5]) color([0, 0, 1, 1]) should be the same as
> color([0.5, 0, 0.5, 1]) !
>
Phew..

Not sure about how to implement that in a coherent way.
E.g., wouldn't you in your example want the final object to be half-transparent?

 -Marius


Reply | Threaded
Open this post in threaded view
|

Re: colour priorities

Triffid Hunter
On Tue, Dec 27, 2011 at 7:49 AM, Marius Kintel <[hidden email]> wrote:
> Phew..
>
> Not sure about how to implement that in a coherent way.
> E.g., wouldn't you in your example want the final object to be half-transparent?

hm, you have a point there. Perhaps simply implement
http://en.wikipedia.org/wiki/Alpha_compositing#Alpha_blending ?