gzz-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gzz] Abstract Colorable Vob


From: Tuomas Lukka
Subject: Re: [gzz] Abstract Colorable Vob
Date: Mon, 17 Mar 2003 07:42:56 +0200
User-agent: Mutt/1.4i

On Sun, Mar 16, 2003 at 07:50:36PM +0100, Benja Fallenstein wrote:
> >To make things clearest, the idea is that the cloneWithColors is the method
> >that creates the new vob with the right colors for this one thing.
> >The default bg color is already in the prototype vob.
> >
> >I can see that my points would make no sense without the above idea ;)
> >
> >Ok?
> 
> Hmm.
> 
> I think it usually makes sense to require that the prototype vob has no 
> solid colors: The common situation is,
> 
>     vob = prototype;
>     if(something)
>         vob = vob.cloneColorAdded(Color.yellow);
>     if(somethingElse)
>         vob = vob.cloneColorAdded(Color.blue);
> 
> If it is at all *possible* that the prototype includes solid colors of 
> its own, this would have to be something like,
> 
>     vob = prototype.cloneColorReplaced(new Color[0]);
>     if(something)
>         vob = vob.cloneColorAdded(Color.yellow);
>     if(somethingElse)
>         vob = vob.cloneColorAdded(Color.blue);
> 
> I.e., if we do not want *any* solid colors on the vob, we would still 
> have to create a new vob object(!).
>
> *If* we allow solid colors on the prototype--
> 
> May we want to do this: The prototype vob has a list of solid colors, 
> but we want to have *different* ones on the final vob?
> 
> May we want to do this: The prototype vob has a list of solid colors, 
> and we want to have *those and additional others* on the final vob?
> 
> I do not see a use case for the first, but can imagine one for the 
> second. 

Umm, actually I do see: if you want to change the default background
color, i.e. the one without any cursor/clone/... colors. That's a color
that needs to be replaced.

> Let's say we have lots of clones, shown as yellow, but few 
> accursed cells, shown as blue, in a scene. Now we could write:
> 
>     if(isClone)
>         vob = clonePrototype; // yellow solid
>     else
>         vob = normalPrototype; // no solids
> 
>     if(isAccursed)
>         vob = vob.cloneColorAdded(Color.blue);
> 
> I couldn't use cloneColorReplaced() now without overwriting the color 
> from the prototype.

I'd rather see this as 

        if(isClone) {
                replaceColors = false;
                vob = cloneProto;
        } else {
                replaceColors = true;
                vob = normalProto;
        }

        ...


> I see where you going, but I'm not yet sure that cloneColorReplaced() is 
> really a good idea-- so far, it seems to me that even with prototypes, 
> cloneColorAdded() works better.
> 
> You said that you think cloneColorAdded() is like addToX(float), but I 
> think that this is different because a) you know what 'x' you start with 
> ('no colors'-- or else you have strange behavior anyway, for the nodes 
> rendered without changing the colors), and b) the usual pattern actually 
> *does* make you 'add' things (if(a) add(A); if(b) add(B); etc.).

What color is the vob if there's no solid colors?

This would work if there were another attribute for the color
if there's no solid colors...

I still do want both functions; if for nothing else, for plain *control*
of the attribute.

        Tuomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]