POV-Ray : Newsgroups : povray.binaries.images : workbench_train_02.png : Re: workbench_train_02.png Server Time
20 May 2024 05:48:49 EDT (-0400)
  Re: workbench_train_02.png  
From: Thomas de Groot
Date: 11 Dec 2023 02:15:16
Message: <6576b704$1@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.