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

In article <3e56bb6b@news.povray.org>, "Tim Nikias" <tim### [at] gmxde> 
wrote:

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

But that is the exception, not the rule. The vast majority of include 
files would have no significant benefit from an inclusion guard outside 
the include.

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

> But that is the exception, not the rule. The vast majority of include
> files would have no significant benefit from an inclusion guard outside
> the include.

I'm still not so sure about that, but it depends if you're talking
about SDL-Includes, like Rune's Particle System, Colefax's files
etc, or about objects, so if you're talking about the first kind
of files, then you're right, and I would agree.
But for the more professional users (talking of guys who are likely
to make money off of their images), I think that multi-megabyte
files aren't the exception, but rather the rule.
So I guess it depends on the situtation and perspective, like
if we talk about general POV Users (which I think you are) or
about those that try to accompany POVs capabilities with
the flexibility of modelling with other tools (which I am).

Would that be fine for us both to agree on? I like to have
settled and calm endings to different points of view, that's why
I'm asking...

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

>
> > > 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...
>
> But that is the exception, not the rule. The vast majority of include
> files would have no significant benefit from an inclusion guard outside
> the include.
>
> --
> 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