I've noticed that colors.inc will not reload if it finds evidence that it
has already been loaded (the following copied from colors.inc):

#ifdef(Colors_Inc_Temp)
     // do nothing
#else
     #declare Colors_Inc_Temp = someValue;
     // body of file is here
#end // last statement in file

However textures.inc doesn't use this approach while math.inc and shapes.inc
use slightly different logic with the #ifndef directive to do the same thing
(skip parsing the file if that has already been done once).

Am I correct in assuming that there are benefits in reduced overhead in
using this kind of approach in my own include files?

Also, would the following lines in myStuff.inc be worthwhile:

#ifdef(Colors_Inc_Temp)
    // do nothing, since colors.inc has already been called at least once
#else
    #include "colors.inc"
#end

I don't see anything like this in the standard includes I have looked at,
yet it looks like a simple extension of the idea (if POV isn't going to
parse the file anyway, why pay the even higher cost of loading it?)

--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

Will W <wil### [at] nospamwizzardsnet> wrote:
> Am I correct in assuming that there are benefits in reduced overhead in
> using this kind of approach in my own include files?

  Yes, there will be reduced overhead.
  For example, each time you #declare something in an include file, some
memory will be allocated and the memory block initialized with some data.
Depending on how many #declares (and other things) you do in the include
file, this can save more or less resources. Surrounding the include with
the multiple inclusion check avoids these allocations and other overhead.

> Also, would the following lines in myStuff.inc be worthwhile:

> #ifdef(Colors_Inc_Temp)
>     // do nothing, since colors.inc has already been called at least once
> #else
>     #include "colors.inc"
> #end

  This is the optimal way of reducing parsing overhead.
  If the #ifdef check is inside the include file, the include file will
still be opened and parsed through (POV-Ray must find the #end corresponding
to the #ifdef at the beginning and this is possible only by parsing the
whole file).
  However, doing it like you write above, the include file is not even
opened, much less parsed, which saves parsing time (specially if the include
file is large). Thus it's the optimal optimization.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Doesn't POV-Ray run through the file, in case it might
find the appropriate #end in the file? Thats what I thought,
and what, IIRC, someone has mentioned somewhere
some time ago on this very server.
Although I'm doing that anyways. Every include-file
of mine has a
#declare _filename_end_tnw = 1;
in its body. When I create scenes which depend on each
other, or include files which depend on still other include-files,
they will check for this value:
#ifndef (_filename_end_tnw) #include "filename.end" #end


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

Post a reply to this message

Tim Nikias <tim### [at] gmxde> wrote:
> Doesn't POV-Ray run through the file, in case it might
> find the appropriate #end in the file? Thats what I thought,
> and what, IIRC, someone has mentioned somewhere
> some time ago on this very server.

  No. POV-Ray does not open the include file if it's inside a block which
is not being executed.
  And yes, this means that an #if (or any other command terminating with #end)
cannot be located in one file and its corresponding #end in another.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <3e558acf@news.povray.org>,
 "Will W" <wil### [at] NOSPAMwizzardsnet> wrote:

> However textures.inc doesn't use this approach while math.inc and shapes.inc
> use slightly different logic with the #ifndef directive to do the same thing
> (skip parsing the file if that has already been done once).

They were written at different times by different people.


> Am I correct in assuming that there are benefits in reduced overhead in
> using this kind of approach in my own include files?

Yes, this way POV doesn't have to fully parse the file and recreate all 
the variables, just find the #end of the #ifndef or #ifdef directive.


> Also, would the following lines in myStuff.inc be worthwhile:
> 
> #ifdef(Colors_Inc_Temp)
>     // do nothing, since colors.inc has already been called at least once
> #else
>     #include "colors.inc"
> #end
> 
> I don't see anything like this in the standard includes I have looked at,
> yet it looks like a simple extension of the idea (if POV isn't going to
> parse the file anyway, why pay the even higher cost of loading it?)

#ifndef() would work better, you don't need the empty part. But the 
benefit is very small, I was unable to measure it even on my old 
machine, and it adds dependencies to the inside of one include file to 
the other includes which could be a nightmare to maintain. Not 
worthwhile: at best you save a few milliseconds per render.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Is there some kind of FAQ for this kind of thing
#if's here and #end's there somewhere, or is it
located somewhere in an advanced part of the
documentation? These kind of issues (like, I
don't know, parsing, macro vs functions etc) seem
to interest many people, once they get there. I doubt
that some newbie (unless with programming experience)
would ask these sort of questions, but some of those
that actually script more "plugins" than actually tracing
images seem to run into this every now and then in
order to optimize their plugins.

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

> > Doesn't POV-Ray run through the file, in case it might
> > find the appropriate #end in the file? Thats what I thought,
> > and what, IIRC, someone has mentioned somewhere
> > some time ago on this very server.
>
>   No. POV-Ray does not open the include file if it's inside a block which
> is not being executed.
>   And yes, this means that an #if (or any other command terminating with #end)
> cannot be located in one file and its corresponding #end in another.
>
> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> But the 
> benefit is very small, I was unable to measure it even on my old 
> machine

  Your include file probably wasn't a multi-megabyte mesh include or
something similar.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Thanks to all for your input! It has been a very useful discussion.

To summarize: use of conditional inclusions can significantly reduce parsing
overheads when there is a certainty that the internal cross-coupling will
always work.

Thus

#ifndef (myStuffIncUniqueID)
    include "myStuff.inc"
#end

is useful in avoiding an unnecessary repeated load/parse so long as there is
a guarrantee that myStuff.inc contains a declaration

#declare myStuffIncUniqueID = someValue


So at a minimum, this is good with the standard includes that have a unique
declaration (seems like they all do) and with include files developed in
house, where there is absolute version control. It is also interesting that
this technique will fail gracefully: if the unique declaration in the
include file is changed at a later time, the pov file will still function--
it just won't be as efficient as it once was.

Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

In article <3e563e91@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Your include file probably wasn't a multi-megabyte mesh include or
> something similar.

None of the standard includes are. Dealing with such files is quite rare 
for most people, it is the exception, not the rule.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

> None of the standard includes are. Dealing with such files is quite rare
> for most people, it is the exception, not the rule.

I wouldn't say that. Many of those who use external programs
like sPatch (though that one doesn't export triangles) export
to a lot of triangles once they are converted with sufficient
resolution. Heck, my "Gerberas" Image required some thousands
of triangles for the petals, the vase, the background...

Though POV's native objects are very fine to begin with, there
are a lot of abstract and less function-driven objects out there.
Thus, to model something near lifelike requires lots and lots
of triangles.

So I would say, those which like to fumble just within POV may
not necessarily need multi-megabyte files, but I'm fidding just
within POV and do so, and IMHO there seem to be a lot
(like Mick Hazelgrove or Gilles Tran) which make use of external
modellers and thus load huge meshes.

If you're just talking about plain POV-SDL, you're most
probably right (though my PartixGen requires some 250kb or
so), I doubt that hand-written POV-SDL will become larger
than at most 500kb (unless we've got some insane pure-POVer
on the loose) :-)


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

Post a reply to this message