Am 20.12.2015 um 07:17 schrieb Sven Littkowski:

> Here my suggestion. Please have a look to the declaration:
> 
> #declare TSimplified aka(TA,TB,TC,TD,TE,TF,TG,TH,TI,TJ,TK,TL) = texture
> {
>  pigment { rgb < 0.50, 0.50, 0.50 > }
> }

Here's a fun language construct for you:

    #declare TSimplified = texture { ... }
    #declare (TA,TB,TC,TD,TE,TF,TG,TH,TI,TJ,TK,TL,) = (
      #for (I,1,12) TSimplified, #end
    );

(The extra comma at the end of the identifier list is intentional.)

Needs POV-Ray 3.7.1-alpha.8141620 or later.


> Or, using the keyword "all" inside the brackets, this texture becomes
> placeholder for all used textures within that scene:
> 
> #declare TSimplified aka(all) = texture
> {
>  pigment { rgb < 0.50, 0.50, 0.50 > }
> }
...
> 
> #declare TSimplified aka(all("gray","Hull")) = texture
> {
> pigment { rgb < 0.50, 0.50, 0.50 > }
> }

These would be overly complicated to implement, as it wouldn't be a
matter of just declaring additional identifiers; instead, the
implementation of identifier lookup would have to be modified,
potentially at the cost of general parsing speed. Also, it would open up
a can of worms regarding the handling of conflicting rules, global vs.
local variables, and possibly a lot more.

Therefore: No, this won't happen.

If you think you need this, then my advice would be to proceed as follows:

- Firstly, use a global variable to govern whether you want the full
textures or the simplified ones, like so:

    #define FullTextures = yes;

- Make sure that all your full textures reside in a separate include
file. This way, you can easily prevent any textures from being parsed if
you don't need them, like so:

    #if(FullTextures)
      #include "MyTextures.inc"
    #end

- Wherever you use a pre-defined texture, use a macro call instead,
passing the texture name as a string; thus, instead of this:

    texture { MyTexture }

you would now use:

    Texture("MyTexture")

- In the macro, define whatever rules you deem fit to select your
texture, possibly making use of the Parse_String macro from strings.inc,
like so:

    #include "strings.inc"
    #macro(TextureName)
      #if(FullTextures)
        texture { Parse_String(TextureName) }
      #elseif(substr(TextureName,1,4) = "gray")
        texture { ... }
      #else
        // nothing; don't apply any texture at all
      #end
    #end


Note how this approach, even though using only existing features, can
provide far more flexibility than your suggested mechanism could ever be
designed to provide.


Some general advice on feature suggestions:

Feature requests custom-tailored to one particular use case are seldom
useful enough in general to be honored. To the contrary, they may
actually brush the developers the wrong way(*).

As a matter of fact, POV-Ray is such a feature-rich tool that more often
than not it turns out that the use case in question can already be
solved by smart use of existing features.

Therefore, if you have something that bothers you about POV-Ray, and you
think that there should be a less cumbersome way of doing things, the
first step should be to ask your fellow users whether they know any
smart way to solve that problem.

If the ensuing discussion concludes that there's no smart way (with the
absence of any discussion over several days serving the same purpose),
then you are in a much better position to post a feature suggestion:

(1) You know that you're not requesting something that's already there.

(2) The discussion may already have demonstrated that you are not the
only one experiencing the issue.

(3) During the discussion you may have learned about related issues,
potentially allowing you to propose a much more general feature to solve
a much broader range of problems.

(4) The discussion may already have gained the attention of some members
of the dev team, preparing them for the feature request to come. (As a
matter of fact, there have been cases where the feature request was met
with a friendly "already working on it".)

(5) Members of the dev team may already have participated in the
discussion, in which case you'll have a clearer picture of whether
they'll respond favorably to a feature request.


(* We all know that in an ideal world this shouldn't be the case;
software developers should be open minded to, and embrace, each and
every suggestion to their piece of software. Thus, for many years I had
made it a habit to try and suppress any such emotions and be
"professional". However, by now I've found that this is simply not
possible: Even as a developer I'm still human; I love my baby, and deep
in my heart I will always be biased to think that there's nothing wrong
with its nose, and that even its missing pinkie toe only makes it more
adorable. Certain types of user feedback /will/ have an impact on my
attitude towards, and interaction with, that user, and trying to fight
this effect may actually add to my frustration. Therefore, I have come
to the conclusion that the best way to deal with this effect is to allow
it to happen, while being open about it.)

Post a reply to this message