On 12/13/23 10:48, Kenneth wrote:
> I am wondering how your idea would affect an explicitly-specified
>           #default [texture/pigment/etc].

While we are discussing short hand texture aspect updates, I'll mention 
another awkward bit we have today with default{}. Suppose someone does 
this in their default statement:

default { normal { quilted 0.5 scale 1/3 } }
...

And later they want a sphere without that default normal?

The following of course uses the default normal:

     object { Sph00 pigment { Red } }

Maybe this ? :

     object { Sph00 pigment { Red } normal {} }
or
     object { Sph00 texture { pigment { Red } normal {} } }

No, those empty normal{} blocks also evaluate to the default quilted 
normal(a).

(a) - And should the current default texture's normal be a null pointer, 
those empty normal{} blocks cause the parser to fail with a 'no normal 
type/pattern message'. I guess the thinking was if a user specified a 
normal{} block they probably wanted the texture's normal set to 
something valid...



The only way I know to get back to an initial, normal 'nullptr', POV-Ray 
default is to capture the default texture before any 'default updates' with:

     #declare InitDfltTxtID = texture{}

So we can later code:

     object { Sph00 texture { InitDfltTxtID pigment { Red } } }

But that initial default texture capture is iffy where we don't 
completely control whether or when 'default{}' might be used.

Aside 1 : I've had the thought of perhaps adding a 'nnoop' (normal 
no-op), normal{} block perturbation pattern. Unlike texture's pigment 
and finish which always end up set to a color or finish prior to 
rendering, normal starts as a nullptr (null pointer) and can remain that 
way through the render phase - and it being a null pointer is how we get 
no normal{} perturbation in any texture{}. A 'nnoop' normal{} method 
could be used too when users want to 'null' a texture ID's normal{} 
setting.

Aside 2 : Where we can be sure of capturing the initial inbuilt 
default{} texture as an ID, the initial default texture can be restored 
with:

     default { texture { InitDfltTxtID } }

at any point later in the SDL for the scene.


What I suspect is most folks are not using default{} to set up a 
defaulted normal, but maybe I'm missing something and there is some way 
a default{normal{}} works well?

Bill P.

Post a reply to this message

On 12/14/23 06:37, Bald Eagle wrote:
> 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.

The dimmer bit is probably that the finish default for ambient was 
changed from 0.1 to 0.0 relatively late during v3.8 development. With 
assumed_gamma 1.0 the older default ambient of 0.1 was far too large. It 
should be something like 0.006 - if you want results as affected by the 
ambient finish default to act similar to the 0.1 at the old 
assumed_gamma of 2.2.

The greyer could be a lot of things including a little of the ambient 
default change above. The _maps with respect to color blend somewhat 
differently at an assumed_gamma of 1.0 than 2.2 - this a reason clipka 
added the blend_mode and blend_gamma options.

Bill P.

Post a reply to this message