 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degroot org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
