 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
WINPOV 3.5 Beta 10
When including woodmaps.inc (or woods.inc) without including colors.inc
an error occurs in line 471. A color "Clear" defined in colors.inc is
used.
Either colors.inc should be included in woodmaps.inc or "Clear" should
be replaced by rgbf 1 imho.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Felix Wiemann wrote:
>
> WINPOV 3.5 Beta 10
> When including woodmaps.inc (or woods.inc) without including colors.inc
> an error occurs in line 471. A color "Clear" defined in colors.inc is
> used.
> Either colors.inc should be included in woodmaps.inc or "Clear" should
> be replaced by rgbf 1 imho.
There are other include files that are dependant upon colors.inc being
included to make the file work. It is a good idea to just get used to
including colors.inc if you will be using other texture related files.
--
Ken Tyler - POV-Ray Techinical Assistance Group
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> There are other include files that are dependant upon colors.inc
being
> included to make the file work. It is a good idea to just get used to
> including colors.inc if you will be using other texture related
files.
But why not including colors.inc in every include, which needs it? That
would be more logical and the parsing time would not be much longer.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Felix Wiemann" <Fel### [at] gmx net> schrieb im Newsbeitrag
news:3c5571df@news.povray.org...
> > There are other include files that are dependant upon colors.inc
> being
> > included to make the file work. It is a good idea to just get used to
> > including colors.inc if you will be using other texture related
> files.
>
> But why not including colors.inc in every include, which needs it? That
> would be more logical and the parsing time would not be much longer.
It actually would increase parse time. Besides, POV-Ray include files
always used to depend on a common subset of include files.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It actually would increase parse time. Besides, POV-Ray include files
> always used to depend on a common subset of include files.
But there's this section in colors.inc:
#ifdef(Colors_Inc_Temp)
// do nothing
#else
#declare Colors_Inc_Temp = version;
Does it take so much time to open the include and to skip reading if
Colors_Inc_Temp already exists? I think this isn't used in loops, so it's
not very important.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: It actually would increase parse time.
Then use a trick sometimes used in C/C++. Instead of:
#include "whatever"
do:
#ifndef _WHATEVER_INC_
#include "whatever"
#declare _WHATEVER_INC_ = yes;
#end
As this is done just inside a standard include, the user doesn't have to
worry about it.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:3c55a741@news.povray.org:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>: It actually would increase parse time.
>
> Then use a trick sometimes used in C/C++. Instead of:
Colors.inc already does this.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c55a741@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> : It actually would increase parse time.
>
> Then use a trick sometimes used in C/C++. Instead of:
Which is exactly what increases parse time! The POV-Ray parser still turns
everything into tokens, only to ignore it - keep in mind the parser and what
looks like a preprocessor is actually more or less *one* step, so it isn't
very fast.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns### [at] 204213191226> , che### [at] sympaticoca
(Coridon Henshaw) wrote:
> Warp <war### [at] tagpovrayorg> wrote in news:3c55a741@news.povray.org:
>
>> Thorsten Froehlich <tho### [at] trfde> wrote:
>>: It actually would increase parse time.
>>
>> Then use a trick sometimes used in C/C++. Instead of:
>
> Colors.inc already does this.
Precisely. Afaik a lot of include files do, or at least did this.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
:> Then use a trick sometimes used in C/C++. Instead of:
: Which is exactly what increases parse time!
Do you mean that povray reads the #included file even though it's inside
an #if block which is just being skipped?-o
--
#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 <3c55c4e9@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> Do you mean that povray reads the #included file even though it's inside
> an #if block which is just being skipped?-o
How could it know that the #if block ends at the end of the file without
looking through the whole file?
Or is there a user-mind-reading interface I missed? If so, I didn't
implement it! ;-)
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: How could it know that the #if block ends at the end of the file without
: looking through the whole file?
I think that it would be fair to _assume_ that block starts and ends are
always located in the same file. This probably will not break any logical
SDL script and is a very rational standard limitation to make.
The big advantage of this is, of course, speed. If we are skipping a block
of code, we don't need to read any possible #includes in this block because
the specs say that there can't be anything interesting in the include anyways.
I don't see any advantage of supporting the feature that, for example,
an #if starts in one file and the correspondent #end is in another file
(of course you could invent lots of artificial examples, but I don't think
there is any real useful example).
The C preprocessor makes this assumption and it works just fine.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in
news:3c55b94d@news.povray.org:
> In article <3c55a741@news.povray.org> , Warp <war### [at] tagpovrayorg>
> wrote:
>
>> : It actually would increase parse time.
>>
>> Then use a trick sometimes used in C/C++. Instead of:
>
> Which is exactly what increases parse time! The POV-Ray parser still
> turns everything into tokens, only to ignore it - keep in mind the
> parser and what looks like a preprocessor is actually more or less
> *one* step, so it isn't very fast.
The parser would probably do something a little more intellegent if the
standard include files were not included directly but by wrappers, e.g.
rename colors.inc to something else and create a new colors.inc with the
following code:
#ifndef(Colors_Inc_Temp)
#declare Colors_Inc_Temp = version;
#version 3.5;
#include "realColors.inc"
#version Colors_Inc_Temp;
#else
I doubt it's worth the effort to do this, however...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c55d9f1@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
> : How could it know that the #if block ends at the end of the file without
> : looking through the whole file?
>
> I think that it would be fair to _assume_ that block starts and ends are
> always located in the same file. This probably will not break any logical
> SDL script and is a very rational standard limitation to make.
As far as I know, the POV SDL *does* make this assumption. You missed
his point...there is no way of knowing the end of the block is at the
end of the file. It has to search to find the matching #end, and it has
to do this starting forward from the #if statement. You can't even
search backwards from the end of the file, you will mess up if you have
multiple #if statements in series, and you can't just stop at the first
#end, or you mess up nested statements.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote:
: As far as I know, the POV SDL *does* make this assumption. You missed
: his point...there is no way of knowing the end of the block is at the
: end of the file. It has to search to find the matching #end, and it has
: to do this starting forward from the #if statement.
Sorry, but I don't understand. What's the problem with this?
Of course it searches for the #end correspondent to the #if. So? If, when
it encounters the #include command, it does not actually include the given
file, I don't see any problem here. The behaviour is exactly what I meant.
Perhaps my point was not clear. Let me profundize:
The usual way of "speeding up" parsing and avoiding multiple declaration
of things is to put lines like these in the include file:
// Beginning of the file
#ifndef _INCLUDE_FILE_1_
#declare _INCLUDE_FILE_1_ = yes;
(contents of the include file)
#end
// End of the include file
Suppose that was "IncFile1.inc".
Also suppose that we have another include file named "IncFile2.inc" which
needs the above one and thus includes it.
Now, if "IncFile2.inc" does this in the usual way, ie:
#include "IncFile1.inc"
and "IncFile1.inc" was already read somewhere earlier, then this is slow, as
povray has to parse the entire "IncFile1.inc" file.
However, what we do in "IncFile2.inc" instead, is this:
#ifndef _INCLUDE_FILE_1_
#include "IncFile1.inc"
#end
If "IncFile1.inc" has already been included somewhere earlier and povray
just skips that #include command and doesn't actually read the contents
of "IncFile1.inc", then it's much faster.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sorry, I thought you were talking about what it does now. It doesn't
process the #includes any more than it has to in order to figure out it
isn't an #end. Modifying the actual #include statements would be
possible, of course, just messier looking.
I personally don't think the parse time is that much of a problem...my
scenes all spend more time in loops and macros than in parsing includes.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c560a2b@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
>
> #ifndef _INCLUDE_FILE_1_
> #include "IncFile1.inc"
> #end
But this isn't how you do it in C/C++ header files...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I think that it would be fair to _assume_ that block starts and ends are
> always located in the same file. This probably will not break any logical
> SDL script and is a very rational standard limitation to make.
> The big advantage of this is, of course, speed. If we are skipping a
block
> of code, we don't need to read any possible #includes in this block
because
> the specs say that there can't be anything interesting in the include
anyways.
>
> I don't see any advantage of supporting the feature that, for example,
> an #if starts in one file and the correspondent #end is in another file
> (of course you could invent lots of artificial examples, but I don't think
> there is any real useful example).
I have written such a script and it's very useful! It's not #if and #end,
but { and }. I think it's not a big difference.
#include "part1.inc" //Camera, lights etc. and...
//an union is started!
---Write your object---
#include "part2.inc" //The union is modified and ended
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
:> #ifndef _INCLUDE_FILE_1_
:> #include "IncFile1.inc"
:> #end
: But this isn't how you do it in C/C++ header files...
I know, but it's a (less) known way of speeding up parsing in C/C++.
It's not something significant in small and mid-sized projects, but I have
heard stories about *HUGE* projects, which take several days to just compile,
where using this trick speeded up the parsing greatly.
--
#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
|
|
| |
| |
|
|
|
|
| |
