POV-Ray : Newsgroups : povray.binaries.images : workbench_train_02.png : Re: workbench_train_02.png Server Time
20 May 2024 06:31:42 EDT (-0400)
  Re: workbench_train_02.png  
From: William F Pokorny
Date: 14 Dec 2023 10:25:50
Message: <657b1e7e$1@news.povray.org>
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

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