"Kenneth" <kdw### [at] gmailcom> wrote:

> In POV-Ray's current structure, there are two 'stages' to any render: the
> parsing, and the rendering.

POV-Ray needs to read the instructions you give for creating the scene (parsing)
before it then shoots the rays and does the calculations for the color value of
each pixel in the image (render).


>( Although, I don't know if those are called the
> 'front end' and 'back end', in the current use of those words.)

Front end would be the POV-Ray editor and the render window.  Back end would be
all the stuff that goes on "behind the scenes".

> It's still not truly clear to me which aspects of the program are 'evaluated'
> during those particular stages, in regards to parsing times *and* the best use
> of RAM memory-- particularly for *duplicated* elements in a scene (objects,
> textures, etc. etc.) For example, I do know that image_maps, height_fields and
> triangle meshes can be -pre#declared before their (repeated) use, to save memory
> -- they are then 'instantiated' in the scene repeatedly, with very little if any
> additional memory overhead.

Well the image_map just gets read in, and then used as a pigment pattern where
needed.
The height field is sorta the same thing - just geometric coordinates instead of
color values.
I believe the mesh geometry data takes up a block of memory once, and then each
instantiation carries whatever texture overhead you add to it.

> But some objects are not-- I think isosurfaces and
> parametric objects would be examples. They are evaluated during the rendering
> stage(?)  For other elements like typical textures/pigments/finishes, I don't
> know the answer, nor do I have a clear idea as to what other kinds of elements
> might fall into the parsing vs. rendering category... or which can be
> instantiated and which cannot.

I _think_ the isosurface and parametric objects can be declared as objects,
which get evaluated at parse time, and then you can just use them like anything
else.

Your timing is interesting with this, as I was thinking about some of this over
the last few days with regard to include files.
I think that the texture info takes up a block of memory, and then each object
you attach it to needs whatever reference information, but I believe the only
time you use up another memory block is when you declare a new texture
identifier.
So I think if you do object {Whatever texture {Texture1 rotate x*90}}, that's
better on memory than #declare Texture2 = texture {Texture1 rotate x*90} then
object {Whatever texture {Texture2}}


>
> A simple example would be...
>
> // the elements are pre-#declared here...
> #declare TEX = texture{pigment{gradient y} finish{ambient .1 diffuse .7}}
> #declare B = box{0,1}
>
> #declare C = 1;
> #while(C <= 100000)
> object{B texture TEX translate 1.1*C*x}
> #declare C = C + 1;
> #end
>
> // ...versus NO pre-#declared elements
> #declare C = 1;
> #while(C <= 100000)
> box{0,1
>     texture{pigment{gradient y} finish{ambient .1 diffuse .7}}
>     translate 1.1*C*x
>    }
> #declare C = C + 1;
> #end
>
> Is there a difference (of any kind) between using one vs. the other?

AFAIK, not with regard to memory usage.

> To 'muddy the waters' a bit (or  maybe not?), add something simple like a random
> scale to the texture, in the first-example #while loop (just a typical
> 'conceptual' example of a change.) Does this cause the texture itself to be
> re-evaluated every time, and/or to require more memory?
>
> #declare S = seed(123);
> #declare C = 1;
> #while(C <= 100000)
> object{B texture (TEX scale .5 + .5*rand(S)} translate 1.1*C*x}
> #declare C = C + 1;
> #end

I think so due to the way it gets "attached" to the object...

Post a reply to this message