Am 28.01.2018 um 13:32 schrieb clipka:

Having looked at the code again, I must correct myself:

> Whenever an object instance is inserted into the scene, some additional
> instantiations may also happen. For instance, if a primitive does not
> have an explicit texture, a texture will be instantiated as a copy of
> either the containing CSG's texture or the default texture.

When a primitive inside a CSG has no texture, the parser will /not/
create a new texture instance. Rather, the contained primitive will
share the texture with the containing CSG.

>> 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
> 
> No change in memory consumption there: Even without the transformation
> of the texture a copy is currently created.

While this statement is technically true, that's only because the object
itself is translated, which constitutes an implicit translation of the
texture. If the texture is transformed anyway, that implict translation
is "fused" into the texture's transformation block.

Post a reply to this message

hi,

On 28/01/2018 12:32, clipka wrote:

thank you for the clear description of object instantiation and
life-time, and the rest.  invaluable.  it's the type of information that
would be good to have in the manual, perhaps a "the gory details" section?

regards, jr.

Post a reply to this message

Am 28.01.2018 um 14:43 schrieb jr:

> thank you for the clear description of object instantiation and
> life-time, and the rest.  invaluable.  it's the type of information that
> would be good to have in the manual, perhaps a "the gory details" section?

I'd prefer to avoid that for now, at least in that level of detail, as I
consider the current state of POV-Ray's internal architecture to still
be in transition between pure C code and neat C++ code.

Post a reply to this message

> Maybe it's worth first clearing up the term "evaluate".

Thanks for your detailed answer. I know it can't be easy to explain such an
'all-encompassing' question as mine-- particularly when I'm not being completely
clear with the proper terms to use (and I'm probably further confusing the issue
by discussing two different aspects of POV-ray as if they are one:
'instantiating' elements in a scene, and the operations performed during the
parse/render stages.) Honestly, I'm still 'groping my way through a fog' to
arrive at a proper set of intelligent questions ;-) And to fully understand some
of the details of your reply.

My use of the term 'evaluate' is probably a bit shabby and uninformed. What I
really mean is, 'where the hard time-consuming work is done.' For instance,
pre-#declaring an image_map for multiple use later: 'Evaluate' would mean,
'during the #declare step' (and the parse stage)... then it's simply
instantiated later, with no extra time-consuming work required during the parse
or render stages (a gross simplification of what really happens there.) In other
words, the greatest amount of time time is spent 'evaluating' that image_map
only once.

I obviously need a better phrase to describe that paradigm.

>
> Maybe what you mean is something I'd call "creating an instance" of, or
> just "instantiating", an object: Reserving a block of memory as required
> for a primitive of that particular type, and filling in the values
> required later during the render stage. This may include a few
> precomputed values, but for most primitives it is just the data
> specified in the SDL code.

Yes, that's basically it.

Post a reply to this message

On 28/01/2018 19:01, Kenneth wrote:
> Thanks for your detailed answer.

How nice this Newsgroup is compared to most open forums and newspapers.

{I just felt like saying.}


-- 

Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 26.01.2018 um 22:22 schrieb Kenneth:
> >
> > #declare C = 1;
> > #while(C <= 100000)
> > object{B texture TEX translate 1.1*C*x}
> > #declare C = C + 1;
> > #end
>
> (If I'm not mistaken you need curly braces around `TEX` when using it.)

I wasn't sure about that myself; you're right, it does need them.

Post a reply to this message

Le 18-01-28 à 14:01, Kenneth a écrit :
>> Maybe it's worth first clearing up the term "evaluate".
> 
> Thanks for your detailed answer. I know it can't be easy to explain such an
> 'all-encompassing' question as mine-- particularly when I'm not being completely
> clear with the proper terms to use (and I'm probably further confusing the issue
> by discussing two different aspects of POV-ray as if they are one:
> 'instantiating' elements in a scene, and the operations performed during the
> parse/render stages.) Honestly, I'm still 'groping my way through a fog' to
> arrive at a proper set of intelligent questions ;-) And to fully understand some
> of the details of your reply.
> 
> My use of the term 'evaluate' is probably a bit shabby and uninformed. What I
> really mean is, 'where the hard time-consuming work is done.' For instance,
> pre-#declaring an image_map for multiple use later: 'Evaluate' would mean,
> 'during the #declare step' (and the parse stage)... then it's simply
> instantiated later, with no extra time-consuming work required during the parse
> or render stages (a gross simplification of what really happens there.) In other
> words, the greatest amount of time time is spent 'evaluating' that image_map
> only once.
> 
> I obviously need a better phrase to describe that paradigm.
> 
>>
>> Maybe what you mean is something I'd call "creating an instance" of, or
>> just "instantiating", an object: Reserving a block of memory as required
>> for a primitive of that particular type, and filling in the values
>> required later during the render stage. This may include a few
>> precomputed values, but for most primitives it is just the data
>> specified in the SDL code.
> 
> Yes, that's basically it.
> 
> 
> 

In the case of an image_map, that image can be seen as a kind of 
constant. It's a container of many values that are each constants by 
themselves.
So, while the #declare don't actually evaluate anything in this case, 
but only assign a name and some work space, it can be evaluated later.
In this case, it's more loading the image file, and usually decoding it, 
that takes time. You can save a lot of time by attributing it to some 
identifier to be used later in several places.

Same goes for a mesh or a complex blob object.

Post a reply to this message

On 28-1-2018 20:25, Stephen wrote:
> On 28/01/2018 19:01, Kenneth wrote:
>> Thanks for your detailed answer.
> 
> How nice this Newsgroup is compared to most open forums and newspapers.
> 
> {I just felt like saying.}
> 
> 

I second that. I would have left long ago otherwise.

-- 
Thomas

Post a reply to this message

I just noticed that my original post's title has been changed here (in the
newsgroups' web interface, at least). What the...???   I had to look around to
find my own post!

When I look in 'Thread Digest', it has changed to "OT: How nice..." (!!) But if
I look in 'POV-Ray Topics/General', it has its original title of "parse vs.
render stages, and best use of memory."

Hmm. Some gremlins or leprechauns are having some fun somewhere...

Post a reply to this message

On 30/01/2018 20:31, Kenneth wrote:
> I just noticed that my original post's title has been changed here (in the
> newsgroups' web interface, at least). What the...???   I had to look around to
> find my own post!
> 
> When I look in 'Thread Digest', it has changed to "OT: How nice..." (!!) But if
> I look in 'POV-Ray Topics/General', it has its original title of "parse vs.
> render stages, and best use of memory."
> 
> Hmm. Some gremlins or leprechauns are having some fun somewhere...
> 
> 
> 


Oops! sorry. 'Twas I

If you look at the thread in a newsgroup reader. It is only a branch of 
the thread that has that title. Replies to any other posts will gave 
your original one.

I just wanted to commend the manners of the newsgroup.


-- 

Regards
     Stephen

Post a reply to this message