POV-Ray : Newsgroups : povray.binaries.images : workbench_train_02.png : Re: workbench_train_02.png Server Time
19 May 2024 22:10:33 EDT (-0400)
  Re: workbench_train_02.png  
From: William F Pokorny
Date: 10 Dec 2023 21:29:06
Message: <657673f2$1@news.povray.org>
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:


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 

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?

Bill P.

Post a reply to this message

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