The new feature I am describing here might not be of much use for
regular scenes, but I think, it comes handy for testing purposes.

Let me give an example.

I want to test a complex scene, because I had added some new parts to
it. I copy parts of the complex scene into a new file, and simplify the
requested textures of the original file (textures with large images,
complicated functions, or multiple textures) like this:

#declare TSimplified = texture
{
 pigment { rgb < 0.50, 0.50, 0.50 > }
}

#declare TA = texture { HullGray50 }
#declare TB = texture { HullGray50 }
#declare TC = texture { HullGray50 }
#declare TD = texture { HullGray50 }
#declare TE = texture { HullGray50 }
#declare TF = texture { HullGray50 }
#declare TG = texture { HullGray50 }
#declare TH = texture { HullGray50 }
#declare TI = texture { HullGray50 }
#declare TJ = texture { HullGray50 }
#declare TK = texture { HullGray50 }
#declare TL = texture { HullGray50 }
...

This way, I avoid loading a number of large pictures, or calling
functions that slow down the test renders of the test scene. But as you
see, I have to declare for each texture again and again.

-------------------------------------------

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 > }
}

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 > }
}

-------------------------------------------

Knowing that many scene developers use describing names for their
various texture declarations, maybe we could even think about a feature
that applies the simplified test texture for all textures containing the
one or another word, here again an example:

#declare TSimplified aka(all("gray","Hull")) = texture
{
pigment { rgb < 0.50, 0.50, 0.50 > }
}

This last example would apply the simplified test texture only to all
those textures, that contain the string "gray" and/or the string "Hull".
The number of strings to be added to the keyword "all" in brackets can
range from one to x strings (any amount or so, if that would make sense).

The strength of this new proposed feature ("all") is, that it can
replace with only one line all existing requested textures. Or, just a
number of them (something the "Quality" command line feature does not
give to you). So you achieve a partial simplification while you can keep
high details on other areas.

Post a reply to this message

On 20-12-2015 7:17, Sven Littkowski wrote:
> The new feature I am describing here might not be of much use for
> regular scenes, but I think, it comes handy for testing purposes.
>

I think there is no need for this as it can be probably be achieved with 
a macro using parse_string() and concat() within a #for loop. I hope to 
give an example after I try this out.

-- 
Thomas

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 20/12/2015 07:17, Sven Littkowski a écrit :
> The new feature I am describing here might not be of much use for 
> regular scenes, but I think, it comes handy for testing purposes.
> 
> Let me give an example.
> 
> I want to test a complex scene, because I had added some new parts
> to it. I copy parts of the complex scene into a new file, and
> simplify the requested textures of the original file (textures with
> large images, complicated functions, or multiple textures) like
> this:
> 
> #declare TSimplified = texture { pigment { rgb < 0.50, 0.50, 0.50 >
> } }
> 
> #declare TA = texture { HullGray50 } #declare TB = texture {
> HullGray50 } #declare TC = texture { HullGray50 } #declare TD =
> texture { HullGray50 } #declare TE = texture { HullGray50 } 
> #declare TF = texture { HullGray50 } #declare TG = texture {
> HullGray50 } #declare TH = texture { HullGray50 } #declare TI =
> texture { HullGray50 } #declare TJ = texture { HullGray50 } 
> #declare TK = texture { HullGray50 } #declare TL = texture {
> HullGray50 } ...
> 
> This way, I avoid loading a number of large pictures, or calling 
> functions that slow down the test renders of the test scene. But as
> you see, I have to declare for each texture again and again.
> 

you can declare all your complex pigments with a quick_color , and use
+Q5 as quality value for your testing renders.

It won't save you the parsing time, but you do not have to edit the
whole scene when switching to the final rendering.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iJwEAQEIAAYFAlZ2a+AACgkQhKAm8mTpkW2EFwP/VwSN6XWg8Lw90uml/JyICts5
b7FzudjKazkF1QvZdSQ/qibjn2QYaMDOCzdUykElB56lCixebZyaW7bSKctZykQ+
6JJKJ1i5nLwKqpoJxhP7ux2K70EdanrWl6+pmenXuD8FvyTtuPGEf1vFmRau0aj3
BFPc9yVwrYk5rbMdVko=
=uoZ1
-----END PGP SIGNATURE-----

Post a reply to this message

On 20-12-2015 8:57, Thomas de Groot wrote:
> On 20-12-2015 7:17, Sven Littkowski wrote:
>> The new feature I am describing here might not be of much use for
>> regular scenes, but I think, it comes handy for testing purposes.
>>
>
> I think there is no need for this as it can be probably be achieved with
> a macro using parse_string() and concat() within a #for loop. I hope to
> give an example after I try this out.
>

OK. My idea was a bit too complicated and didn't work. However, you can 
use arrays instead:

#declare T_array = array[10]

#for (I,0,9,1)
   #declare T_array[I] = texture {pigment {rgb < 0.50, 0.50, 0.50 >}}
#end

You have now 10 identical textures named T_array[0] to T_array[9].

Adapt this to your needs.

-- 
Thomas

Post a reply to this message

Well, the parsing is one of the reasons: at the current level, parsing
alone takes 11 minutes.

The textures have already all being named, and since i use over 30
textures, i don't want to work on all of them. I somehow still think,
being able to mention their name i one single line and apply a
simplified texture 8based on the test needs) to all of them, is an
advantage.

Post a reply to this message

On 12/20/2015 01:17 AM, Sven Littkowski wrote:
> The new feature I am describing here might not be of much use for
> regular scenes, but I think, it comes handy for testing purposes.
>
>
Hi Sven,

My scenes tend to be small, but what I've noticed when reviewing code 
from others is they plan ahead for switching to simpler versions of 
textures or shapes knowing they'll need to do it to speed development.

As they create code, they add conditionals based upon switches that let 
them swap in simpler/faster versions of things peripheral to the portion 
of the scene they are currently developing. They might also swap in and 
out simpler lighting, for example.

What is necessary to speed up development changes scene to scene and 
with development style. A person who uses a great many large meshes 
might need to swap in simpler ones or CSG shapes to speed parsing times. 
Another user with complex lighting might need to develop mostly with 
simpler lighting.

For you, I'd guess from the enormous size of the images you have posted, 
it is probably loading and using very large images maps in textures that 
most slows you down.

Is so, an option is to have large and small versions of your image maps 
where you use the smaller versions for scene elements peripheral to 
those on which you are currently working. For example, a 
UseSimpleHullTexture switch for conditional code around the loading of 
the image(s) and defining your texture(s). Such a switch would allow you 
to define simpler versions of your hull textures if you were, say, 
working on media for the engine.

I'll add that in addition to the quick color mechanism previously 
mentioned, there is also the SDL #default directive for textures though 
it would too require some switch and conditional set up.

Bill P.

Post a reply to this message

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

Le 15-12-20 01:17, Sven Littkowski a écrit :
> The new feature I am describing here might not be of much use for
> regular scenes, but I think, it comes handy for testing purposes.
>
> Let me give an example.
>
> I want to test a complex scene, because I had added some new parts to
> it. I copy parts of the complex scene into a new file, and simplify the
> requested textures of the original file (textures with large images,
> complicated functions, or multiple textures) like this:
>
> #declare TSimplified = texture
> {
>   pigment { rgb < 0.50, 0.50, 0.50 > }
> }
>
> #declare TA = texture { HullGray50 }
> #declare TB = texture { HullGray50 }
> #declare TC = texture { HullGray50 }
> #declare TD = texture { HullGray50 }
> #declare TE = texture { HullGray50 }
> #declare TF = texture { HullGray50 }
> #declare TG = texture { HullGray50 }
> #declare TH = texture { HullGray50 }
> #declare TI = texture { HullGray50 }
> #declare TJ = texture { HullGray50 }
> #declare TK = texture { HullGray50 }
> #declare TL = texture { HullGray50 }
> ...
>
> This way, I avoid loading a number of large pictures, or calling
> functions that slow down the test renders of the test scene. But as you
> see, I have to declare for each texture again and again.
>
> -------------------------------------------
>
> 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 > }
> }
>
> 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 > }
> }
>
> -------------------------------------------
>
> Knowing that many scene developers use describing names for their
> various texture declarations, maybe we could even think about a feature
> that applies the simplified test texture for all textures containing the
> one or another word, here again an example:
>
> #declare TSimplified aka(all("gray","Hull")) = texture
> {
> pigment { rgb < 0.50, 0.50, 0.50 > }
> }
>
> This last example would apply the simplified test texture only to all
> those textures, that contain the string "gray" and/or the string "Hull".
> The number of strings to be added to the keyword "all" in brackets can
> range from one to x strings (any amount or so, if that would make sense).
>
> The strength of this new proposed feature ("all") is, that it can
> replace with only one line all existing requested textures. Or, just a
> number of them (something the "Quality" command line feature does not
> give to you). So you achieve a partial simplification while you can keep
> high details on other areas.
>

A common practice for that is to have a controll variable declared early 
in the scene, and use some #if()...#else...#end constructs.

For example:
#declare Final = 0;
...
#if(Final)
	#declare My_Texture texture{Some_Complicated_Texture}
#else
	#declare My_Texture texture{pigment{rgb<1,0,1>}}
#end

or

#declare Test = 1;
...
#if(Test)
	#declare My_Texture texture{pigment{rgb<1,0,1>}}
#else
	#declare My_Texture texture{Some_Complicated_Texture}
#end


When you construct your scene, you set the controll variable to sellect 
the simplified textures, and set it to use the advanced textures when 
you are finished with constructing the geometry.

You may also try the quick_colour feature and use +q1 on the command 
line. That cause most advanced, and some not so advanced, features to be 
turned off, such as area_light, radiosity, photons, shadow computation, 
reflection and transparance,...


Alain

Post a reply to this message

I forgot to mention that this can also be used to substitute some place 
holders for some complex object, or not parcing and render whole objects.
Say, you are working on the hull, you don't need to have the wormhole 
generator showing. So, a controll variable can switch it off or replace 
it by a much simplified version, like a simple box or cylinder using a 
plain pigment.


Le 15-12-20 14:12, Alain a écrit :

>
> A common practice for that is to have a controll variable declared early
> in the scene, and use some #if()...#else...#end constructs.
>
> For example:
> #declare Final = 0;
> ...
> #if(Final)
>      #declare My_Texture texture{Some_Complicated_Texture}
> #else
>      #declare My_Texture texture{pigment{rgb<1,0,1>}}
> #end
>
> or
>
> #declare Test = 1;
> ...
> #if(Test)
>      #declare My_Texture texture{pigment{rgb<1,0,1>}}
> #else
>      #declare My_Texture texture{Some_Complicated_Texture}
> #end
>
>
> When you construct your scene, you set the controll variable to sellect
> the simplified textures, and set it to use the advanced textures when
> you are finished with constructing the geometry.
>
> You may also try the quick_colour feature and use +q1 on the command
> line. That cause most advanced, and some not so advanced, features to be
> turned off, such as area_light, radiosity, photons, shadow computation,
> reflection and transparance,...
>
>
> Alain

Post a reply to this message

This is a long and good answer. I like the style, too.

Besides if my suggestion is useful or not, it would be nice to have one
newsgroup forum just for new ideas and their discussion: "Feature-Requests".

Well, I thought, my suggestion (aka) was good. But the way I suggested
its implementation, is not mandatory. besides, if the AKA makes not much
sense, no problem.

The macro option is something that can be done, too. Right now, i work
with plenty macros in my scene. And yes, all textures are already in an
own file.   :-)

Post a reply to this message