Op 11/12/2023 om 03:29 schreef William F Pokorny:
> On 12/7/23 03:37, Thomas de Groot wrote:
>> ovus { 1.00, 0.65
>>    pigment {rgb <0.4, 0.9, 0.4>}
>>    pigment {rgbt <0.9, 0.1, 0.1, 0.99>} //varnish coating!
> 
> This syntax makes use of the shorthand 'texture-aspect' update method 
> mentioned not too long ago as aside(1) here:
> 
>
https://news.povray.org/povray.pov4.discussion.general/thread/%3C65518d6d%241%40news.povray.org%3E/
> 
> The first pigment{} updates the default texture's pigment, the second 
> updates the modified texture again.
> 
> As also mentioned in that aside(1) in povray.pov4.discussion.general, 
> when the interior_texture{} capability got added years ago this 
> texture-aspect update method didn't get extended to the 
> interior_teture{} too as should have been done. In other words, the 
> shorthand update trick, ignores any defined interior_texture{} without a 
> peep.
> 
> Well, on digging into the code recently with the idea of fixing that 
> long-standing oversight in yuqk, I found there are additional criteria 
> related to the type of pattern / special patterns in play too as to 
> whether the short hand texture aspect updates work - even for texture{}.
> 
> So... I'm now toying with the idea of making all shorthand updates, 
> parse errors in yuqk and suggesting this for v4.0 too. Essentially, yuqk 
> would be forcing the texture{} block specification(s), always, as a path 
> to consistent overall behavior.
> 
> This idea is easier for me to swallow because I tend to assign finish{}, 
> normal{}, pigment{} (and interior{}) blocks to IDs before using them in 
> texture{} or material{} blocks - also assigned to IDs - prior to use 
> with objects. In other words, I already often code in this style. I do 
> it because it makes modifications easier - but, it also avoids some of 
> the subtle shifts / inconsistencies in parsing behavior which happen 
> today with the texture shorthand / aspect update methods.
> 
> Aside: As an additional plus, forcing texture{} block(s) would enable 
> eventual simplifications in the parsing code. This, rather than 
> extending already complicated code to support interior_texture{} 
> shorthand / aspect updates.
> 
> Thoughts / comments?
> 
You are the expert here ;-) but I am very much in favour of your 
suggestion/intention. The problem with the shorthand is very much that 
it allows for inconsistencies in the coding. I certainly fell into that 
trap here, which probably would not have happened otherwise. So yes, 
please do. Thanks for your great work over the years btw.

-- 
Thomas

Post a reply to this message

On 2023-12-10 22:29 (-4), William F Pokorny wrote:
> 
> So... I'm now toying with the idea of making all shorthand updates,
> parse errors in yuqk and suggesting this for v4.0 too. Essentially, yuqk
> would be forcing the texture{} block specification(s), always, as a path
> to consistent overall behavior.
> 
> This idea is easier for me to swallow because I tend to assign finish{},
> normal{}, pigment{} (and interior{}) blocks to IDs before using them in
> texture{} or material{} blocks - also assigned to IDs - prior to use
> with objects. In other words, I already often code in this style. I do
> it because it makes modifications easier - but, it also avoids some of
> the subtle shifts / inconsistencies in parsing behavior which happen
> today with the texture shorthand / aspect update methods.

When I was developing RC3Wood v2.0, I found unblocked textures, normals,
etc. so difficult to shoehorn through the parser that I just made the
macros return blocks.  While this was not a shorthand update issue, the
resolution was the same: work with enclosed blocks.

> [snip]
> 
> Thoughts / comments?

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.

Post a reply to this message

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

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 11/12/2023 om 03:29 schreef William F Pokorny:
> >
> > So... I'm now toying with the idea of making all shorthand updates,
> > parse errors in yuqk and suggesting this for v4.0 too. Essentially, yuqk
> > would be forcing the texture{} block specification(s), always, as a path
> > to consistent overall behavior.
> >
> > This idea is easier for me to swallow because I tend to assign finish{},
> > normal{}, pigment{} (and interior{}) blocks to IDs before using them in
> > texture{} or material{} blocks - also assigned to IDs - prior to use
> > with objects. In other words, I already often code in this style. I do
> > it because it makes modifications easier - but, it also avoids some of
> > the subtle shifts / inconsistencies in parsing behavior which happen
> > today with the texture shorthand / aspect update methods.
> >
> > Aside: As an additional plus, forcing texture{} block(s) would enable
> > eventual simplifications in the parsing code. This, rather than
> > extending already complicated code to support interior_texture{}
> > shorthand / aspect updates.
> >

Hi William!

I am wondering how your idea would affect an explicitly-specified
         #default [texture/pigment/etc].

When I want to quickly get an idea for a scene into POV-ray, I usually use a
#default{...something...} at the start, whether a full texture of just a finish,
etc...which I understand to be a full behind-the-scenes 'default' texture that I
am just updating there with a shorthand change. Then I can additionally use more
shorthand updates for the objects I make, while still getting the #default stuff
that I originally specified:

sphere{0,1 pigment{rgb <.2,.4,.6>}} // already including my #default stuff

It's a nice quick method to sketch-out the basics of a scene.

But if I understand your proposed fix-- of making all shorthand updates into
parse errors-- it seems that I would have to pre-#declare even a #default
texture with an ID, then specify the ID in an object (with another shorthand
update if desired.) That would seem to negate the easy usefulness of the
#default{...} feature as-is.

Am I mistaken?

[As you can tell, I LIKE POV-ray's 'shorthand' ability ;-)  ]

Post a reply to this message

On 12/13/23 10:48, Kenneth wrote:
> i William!
> 
> I am wondering how your idea would affect an explicitly-specified
>           #default [texture/pigment/etc].
> 
> When I want to quickly get an idea for a scene into POV-ray, I usually use a
> #default{...something...} at the start, whether a full texture of just a finish,
> etc...which I understand to be a full behind-the-scenes 'default' texture that I
> am just updating there with a shorthand change. Then I can additionally use more
> shorthand updates for the objects I make, while still getting the #default stuff
> that I originally specified:
> 
> sphere{0,1 pigment{rgb <.2,.4,.6>}} // already including my #default stuff
> 
> It's a nice quick method to sketch-out the basics of a scene.
> 
> But if I understand your proposed fix-- of making all shorthand updates into
> parse errors-- it seems that I would have to pre-#declare even a #default
> texture with an ID, then specify the ID in an object (with another shorthand
> update if desired.) That would seem to negate the easy usefulness of the
> #default{...} feature as-is.
> 
> Am I mistaken?
> 
> [As you can tell, I LIKE POV-ray's 'shorthand' ability 😉  ]
> 
Hi.

In the no shorthand, texture aspect, update(a) approach you'd tweak the 
default texture by specifying no initial texture ID.

     object { My_Object
         texture { pigment { color <1,0,0> } }
         interior_texture { pigment { color <1,1,0> } }
     }

Specifying the texture{} or interior_texture{} with or without a initial 
texture ID will, I believe, always behave in a consistent and simple to 
understand way, but yes, the short methods are handy.

(a) - Internally POV-Ray considers many of the shorthand forms to be 
object modifiers where they directly follow an 'object' definition or 
reference. FWIW.

---

One of a few confusing things with the short form updates is you have to 
know whether 'My_Object' already has a non-default texture - and what it 
is - to know what you get for a final complete texture.

     #declare Sph00  = sphere { 0, 0.7 }
     #declare Sph00p = sphere { 0, 0.7 pigment { color Green } }
...
     object { Sph00 normal { granite } }  // White with granite normal 	
     object { Sph00p normal {granite } }  // Green with granite normal

Where as the texture{}, internal_texture{} wrap always starts with the 
default texture and updates one to all the texture aspects.

---

In a related and FWIW category, how many know the following is a valid 
way to specify a texture?

#declare Sph00 = sphere { 0, 0.7 }

#declare P = pigment { rgb <1,0.6,0.3> }
#declare N = normal { quilted 0.5 scale 1/3 }
#declare F = finish { emission 1/3 }

object { Sph00 texture { P N F  }  } // Aspect updates by ID type!

Bill P.

Post a reply to this message

On 2023-12-13 20:16(-4), William F Pokorny wrote:
> 
> In a related and FWIW category, how many know the following is a valid
> way to specify a texture?
> 
> #declare Sph00 = sphere { 0, 0.7 }
> 
> #declare P = pigment { rgb <1,0.6,0.3> }
> #declare N = normal { quilted 0.5 scale 1/3 }
> #declare F = finish { emission 1/3 }
> 
> object { Sph00 texture { P N F  }  } // Aspect updates by ID type!

I'm not even going to touch that!  Why tempt fate--or the parser?

Post a reply to this message

Op 14/12/2023 om 01:16 schreef William F Pokorny:
> In a related and FWIW category, how many know the following is a valid 
> way to specify a texture?
> 
> #declare Sph00 = sphere { 0, 0.7 }
> 
> #declare P = pigment { rgb <1,0.6,0.3> }
> #declare N = normal { quilted 0.5 scale 1/3 }
> #declare F = finish { emission 1/3 }
> 
> object { Sph00 texture { P N F  }  } // Aspect updates by ID type!
> 
> 

<shudder>  I didn't, but I don't like it.

-- 
Thomas

Post a reply to this message

On 12/13/23 19:16, William F Pokorny wrote:
> Specifying the texture{} or interior_texture{} with or without a initial 
> texture ID will, I believe, always behave in a consistent and simple to 
> understand way, but yes, the short methods are handy.

Simple to understand... Something worth mentioning with respect to 
default textures though perhaps obvious. The default texture changes - 
and can change any number of times while SDL is parsed.

//...
// Here there is a POV-Ray default (which itself changed v3.7 to v3.8)
default { pigment { Green } }  // Pigment aspect of texture to Green
#declare Sph00 = sphere { 0, 0.7 }

object { Sph00 texture { normal { N } } translate -x } // Green
default { pigment { Red } }
object { Sph00 texture { normal { N } } } // Red
#include "defaultPigToBlue.inc" // defaults not scoped; Always global
object { Sph00 texture { normal { N } } translate +x } // Blue

The exposure with default{} statements and include files is we might not 
know they've been used therein and the previous default state is not 
restored when we leave the include. (Yes, default statements in macros 
can cause similar confusion)

Bill P.

Post a reply to this message

On 12/13/23 20:31, Cousin Ricky wrote:
> On 2023-12-13 20:16(-4), William F Pokorny wrote:
>>
>> In a related and FWIW category, how many know the following is a valid
>> way to specify a texture?
>>
>> #declare Sph00 = sphere { 0, 0.7 }
>>
>> #declare P = pigment { rgb <1,0.6,0.3> }
>> #declare N = normal { quilted 0.5 scale 1/3 }
>> #declare F = finish { emission 1/3 }
>>
>> object { Sph00 texture { P N F  }  } // Aspect updates by ID type!
> 
> I'm not even going to touch that!  Why tempt fate--or the parser?
> 

:-) The method was news to me too. A detail which popped out while 
looking at making interior_texture{} support more consistent with 
texture{}.

Though it rang an old bell. I think this form is something I'd seen in 
some SDL years ago where I didn't understand how what was coded worked.

I expect this method of update has been used as much by accident as by 
intent. Use by someone forgetting - or accidentally deleting - a 
pigment{}, normal{} or finish{} wrap of an ID. It is a short way to 
specify texture aspects I guess - especially if you don't want to pick 
up any part of the 'current' default texture.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> It is a short way to
> specify texture aspects I guess - especially if you don't want to pick
> up any part of the 'current' default texture.
>
> Bill P.

I think that most people completely miss this, because although it _is_ stated
in the documentation, it's not stated in a way that really highlights the fact
that you're _always_ starting out with a default texture and then _modifying_
it.

I think most people operate on the (obvious in hindsight) faulty assumption that
they are _creating_ a texture with those statements.

Maybe just start the documentation section off with a bold, unambiguous
statement that when an object is created, it is assigned a default texture, and
then only when the parser hits a texture component assignment is the default
texture modified.

https://wiki.povray.org/content/Reference:Texture

I have noticed that my quickie scenes that I use to puzzle out various things
look a lot dimmer and grayer compared to the way they used to, and I need to
change my default finish to diffuse 1.

There are definitely lots of shortcuts that I use and enjoy, but I realize that
yuqk is an arrow pointing toward 4.0, and we need to "do the work" to get there,
and may have to abandon certain conveniences to get there.    Then, once we
establish a firm foundation, certain convenbience tools might then be able to be
reimplemented, albeit in a different way.

Post a reply to this message