On 12/11/23 07:59, Cousin Ricky wrote:
> I'm fine with yanking shorthand updates.  I never use the technique
> anyway, so I would not miss them; and since it uses a seemingly
> ambiguous syntax to merely duplicate functionality of less confusing
> code, I would discourage other people from using it.
> 
> On the other hand, I would not require all finish{}, normal{} and
> pigment{} blocks to be enclosed in a texture{} block.  This is too
> useful and too often used in existing code to be discontinued.  I don't
> know if you had this in mind, but I'm just trying to keep my position clear.

Thanks both for the feedback. I'll need to think about all this some 
more and play with more varieties of code.


-------- Thinking aloud

Our current documentation for pigment has this:


---
A pigment statement is part of a texture specification. However it can 
be tedious to use a texture statement just to add a color to an object. 
Therefore you may attach a pigment directly to an object without 
explicitly specifying that it as part of a texture. For example instead 
of this:

object { My_Object texture {pigment { color Red } } }

you may shorten it to:

object { My_Object pigment {color Red } }

Doing so creates an entire texture structure with default normal and 
finish statements just as if you had explicitly typed the full texture 
{...} around it.

Note: an explicit texture statement is required, if you want to layer 
pigments.
---


It looks to me from the code that the documentation is lying some. That 
second shorter form is doing a shorthand update (albeit by another path 
through code for complicated reasons...).

In other words, when we write:

     object { My_Object texture {pigment { color Red } } }

what happens is the default texture is copied as the starting texture 
and then the pigment{} aspect is updated to "color Red".

When we write the 'supposedly compatible' shorter form:

     object { My_Object pigment {color Red } }

We are updating the pigment aspect of the texture already attached to 
My_Object. This might be the default texture - if no explicit texture 
has been specified for My_Object - or it might be updating the pigment 
aspect of whatever explicit texture was most recently attached to 
My_Object(a)

(a) - I'm ignoring some complicating factors for the sake of a simpler 
description.

We can update aspects of a texture ID for both texture{} and 
interior_texture{} with the form:

     #declare Txtr00 = texture { pigment { color rgb <1,1,1> } }
     object { My_Object
         texture { Txtr00 pigment { color <1,0,0> } }
         interior_texture { Txtr00 pigment { color <1,1,0> } }
     }

and this what I was toying with for consistency.

I'm understanding you to be saying you'd like to keep the shorter form. 
I do see it in some of the code you've written. I use the short form 
myself often enough too - and no doubt a great deal of exiting SDL makes 
use of this shorter form...

I'll look again at making interior_texture{} behavior consistent with 
texture{}. This wouldn't fix the consistency issue we are talking about 
here with dual pigment{} updates, but it's probably the most compatible 
way to go.

Bill P.

Post a reply to this message