POV-Ray : Newsgroups : povray.general : parse vs. render stages, and best use of memory : Re: parse vs. render stages, and best use of memory Server Time
3 May 2024 19:53:46 EDT (-0400)
  Re: parse vs. render stages, and best use of memory  
From: Alain
Date: 28 Jan 2018 18:46:49
Message: <5a6e60e9$1@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.