POV-Ray : Newsgroups : povray.binaries.images : workbench_train_02.png Server Time
10 Dec 2024 04:19:54 EST (-0500)
  workbench_train_02.png (Message 13 to 22 of 22)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: William F Pokorny
Subject: Re: workbench_train_02.png
Date: 12 Dec 2023 11:59:02
Message: <65789156$1@news.povray.org>
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

From: Kenneth
Subject: Re: workbench_train_02.png
Date: 13 Dec 2023 10:50:00
Message: <web.6579d26b6e5f46b99b4924336e066e29@news.povray.org>
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

From: William F Pokorny
Subject: Re: workbench_train_02.png
Date: 13 Dec 2023 19:16:16
Message: <657a4950@news.povray.org>
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

From: Cousin Ricky
Subject: Re: workbench_train_02.png
Date: 13 Dec 2023 20:31:53
Message: <657a5b09$1@news.povray.org>
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

From: Thomas de Groot
Subject: Re: workbench_train_02.png
Date: 14 Dec 2023 02:05:01
Message: <657aa91d$1@news.povray.org>
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

From: William F Pokorny
Subject: Re: workbench_train_02.png
Date: 14 Dec 2023 02:36:27
Message: <657ab07b$1@news.povray.org>
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

From: William F Pokorny
Subject: Re: workbench_train_02.png
Date: 14 Dec 2023 02:39:34
Message: <657ab136$1@news.povray.org>
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

From: Bald Eagle
Subject: Re: workbench_train_02.png
Date: 14 Dec 2023 06:40:00
Message: <web.657ae8e86e5f46b91f9dae3025979125@news.povray.org>
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

From: William F Pokorny
Subject: Re: workbench_train_02.png
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

From: William F Pokorny
Subject: Re: workbench_train_02.png
Date: 14 Dec 2023 10:30:20
Message: <657b1f8c$1@news.povray.org>
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

<<< Previous 10 Messages Goto Initial 10 Messages

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