Hello, just me and my wild ideas here.
I have been working a lot with macro's and creating lot's of objects(See
my fireworks posts)
While doing this, I have to check lightsourses and fog settings, and
since the fireworks are lightsources I need to wait for parse every
time.
Now I wondered, is there a possibility to add something of a expander to
pov?

By storing the parsed data in a new file, ex. example.pov ->example.par
->example.tga

This could be specified with a command line argument, or a setting in
global_settings {
  write_parse true
  load_parse false
}

This is only an idea, I'm not sure if it'd work, or if it is implemented
somewhere already, but I think it might come in hadny in several cases.

//Spider

Post a reply to this message

Spider wrote:
> 
> Hello, just me and my wild ideas here.
> I have been working a lot with macro's and creating lot's of objects(See
> my fireworks posts)
> While doing this, I have to check lightsourses and fog settings, and
> since the fireworks are lightsources I need to wait for parse every
> time.
> Now I wondered, is there a possibility to add something of a expander to
> pov?
> 
> By storing the parsed data in a new file, ex. example.pov ->example.par
> ->example.tga
> 
> This could be specified with a command line argument, or a setting in
> global_settings {
>   write_parse true
>   load_parse false
> }
> 
> This is only an idea, I'm not sure if it'd work, or if it is implemented
> somewhere already, but I think it might come in hadny in several cases.
> 
> //Spider

Sounds like a good idea. On the other hand, this would be most profitable in
scenes with long parsing-time and I think in those cases the *.PAR-files are
going to be huge.

Remco

Post a reply to this message

In article <36B4901A.5D252934@bahnhof.se> , Spider <spi### [at] bahnhofse>  wrote:

> I have been working a lot with macro's and creating lot's of objects(See
> my fireworks posts)
> While doing this, I have to check lightsourses and fog settings, and
> since the fireworks are lightsources I need to wait for parse every
> time.
> Now I wondered, is there a possibility to add something of a expander to
> pov?
>
> By storing the parsed data in a new file, ex. example.pov ->example.par
> ->example.tga
>
> This could be specified with a command line argument, or a setting in
> global_settings {
>   write_parse true
>   load_parse false
> }
>
> This is only an idea, I'm not sure if it'd work, or if it is implemented
> somewhere already, but I think it might come in hadny in several cases.

Where is the difference between a binary file and your idea? :-)


    Thorsten

Post a reply to this message

I'll reply to both answeres here...

As for a binary file, totally ok, if it only "mark" the code in some way
and make it re-doable, trhe point is to make the parsing take less time,
by exchanging the whole 30000 object creator loops while you work on
getting the fog and light to shimmer through it in a nice way, without
having to wait for a 15 minute parse time.

As for filesize, I don't think it will really matter in some cases, of
course, a built-in LZW or Huffman compression would fit nicely.

The main problem as I see it, is how to get the parser/storer7loader to
recognise if I have changed in a macro while parsing. But then, I don't
think that will be necessary, since the user can then simply reparse the
whole lot. 

I am also afraid that this would ultimately kill my tree include
creator. ;-)

Well, I'm just thinking it could make life easier for us. If you dislike
the hugefile-size, lean back and wait each time you do a pre-render.
*grinning*

I know that ther reason I did the tree creator, was to have the trees in
a .inc so I didn't have to bother with waiting for a LOOONG LOONG time
for each parse of three or four trees while I tried to position them
"just right" for the scene.

//Spider

Post a reply to this message

Spider <spi### [at] bahnhofse> wrote:
: The main problem as I see it, is how to get the parser/storer7loader to
: recognise if I have changed in a macro while parsing. But then, I don't
: think that will be necessary, since the user can then simply reparse the
: whole lot. 

  Perhaps a program similar to 'make' in UNIX could be used to reparse only
the modified files.

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Nieminen Mika schrieb in Nachricht <36b6c5c3.0@news.povray.org>...
>Spider <spi### [at] bahnhofse> wrote:
>: The main problem as I see it, is how to get the parser/storer7loader to
>: recognise if I have changed in a macro while parsing. But then, I don't
>: think that will be necessary, since the user can then simply reparse the
>: whole lot.
>
>  Perhaps a program similar to 'make' in UNIX could be used to reparse only
>the modified files.


But then you'd have to have a "compiler" (to parse the files and turn them
into binary or whatever) and a "linker" (to connect the parsed files into
one scene). This is of course a totally different approach from the current
one.

But it would be great. The .par files would be something like the
precompiled headers many C/C++ compilers provide for, or the symbol files
many compilers can produce to speed up compiling.

But as the POV-team already mentioned somewhere, most time is not wasted in
parsing, but in allocating objects during this process. If this is true (I
can't verify it), the pre-compile wouldn't do a lot of good.

--
Rudy Velthuis

Post a reply to this message

Nieminen Mika wrote:
> 
<snip> 
>   Perhaps a program similar to 'make' in UNIX could be used to reparse only
> the modified files.
Yes, perhaps.
Or, brutal approach, comment out the #while and include a text .inc of
the result.... :-)

//Spider

Post a reply to this message

Rudy Velthuis wrote:
> 
> But then you'd have to have a "compiler" (to parse the files and turn them
> into binary or whatever) and a "linker" (to connect the parsed files into
> one scene). This is of course a totally different approach from the current
> one.
Yes, it would be far different. Perhaps better, perhaps worse.
The main thing I have a problem with the current model, is that there is
no syntax checking performed before a parse is done. This irritates me a
bit, since I have a bad habit of foretting a ; or doing a pigment{WHite}
style approach when I type.

Tehn, all of sudden, POV parses, all is ok, allocates lots of memory for
my five recursive cakks that make 50000 objects each, and hangs on the
plane afterwards, with a wrong pigment and then I have to wait for my
windows to stop swaping as hell so I can get back to work..

Solution to this? Add more RAM:-)
But, a pre-check of syntax might improve, this could also choose a
parser after the version or something.. (please don't flame me because I
haven't read the source and don't have any idea of what I am talking
about, please don't. )

> But it would be great. The .par files would be something like the
> precompiled headers many C/C++ compilers provide for, or the symbol files
> many compilers can produce to speed up compiling.
Yes. It would probably increase the file-size a bit, but it is a
trade-off to do...
 
> But as the POV-team already mentioned somewhere, most time is not wasted in
> parsing, but in allocating objects during this process. If this is true (I
> can't verify it), the pre-compile wouldn't do a lot of good.
It depends on the scene, as far as I know. in some cases, I've spent a
lot of time waiting for a parse to finish. (take a look at the recursive
tree creation algorithms. Those are very long parsing, but not long if
declared as a .inc. (try the WinTrees if you like:-) it is from this
experience that I came with the idea.

//Spider

Post a reply to this message

What I got out of this and seems like a good idea is a pre-parse syntax.check. 
Like compilers do. Not a bad thought at all...
(I've been playing with trees too)

Remco

Spider wrote:
> 
> Rudy Velthuis wrote:
> >
> > But then you'd have to have a "compiler" (to parse the files and turn them
> > into binary or whatever) and a "linker" (to connect the parsed files into
> > one scene). This is of course a totally different approach from the current
> > one.
> Yes, it would be far different. Perhaps better, perhaps worse.
> The main thing I have a problem with the current model, is that there is
> no syntax checking performed before a parse is done. This irritates me a
> bit, since I have a bad habit of foretting a ; or doing a pigment{WHite}
> style approach when I type.
> 
> Tehn, all of sudden, POV parses, all is ok, allocates lots of memory for
> my five recursive cakks that make 50000 objects each, and hangs on the
> plane afterwards, with a wrong pigment and then I have to wait for my
> windows to stop swaping as hell so I can get back to work..
> 
> Solution to this? Add more RAM:-)
> But, a pre-check of syntax might improve, this could also choose a
> parser after the version or something.. (please don't flame me because I
> haven't read the source and don't have any idea of what I am talking
> about, please don't. )
> 
> > But it would be great. The .par files would be something like the
> > precompiled headers many C/C++ compilers provide for, or the symbol files
> > many compilers can produce to speed up compiling.
> Yes. It would probably increase the file-size a bit, but it is a
> trade-off to do...
> 
> > But as the POV-team already mentioned somewhere, most time is not wasted in
> > parsing, but in allocating objects during this process. If this is true (I
> > can't verify it), the pre-compile wouldn't do a lot of good.
> It depends on the scene, as far as I know. in some cases, I've spent a
> lot of time waiting for a parse to finish. (take a look at the recursive
> tree creation algorithms. Those are very long parsing, but not long if
> declared as a .inc. (try the WinTrees if you like:-) it is from this
> experience that I came with the idea.
> 
> //Spider

Post a reply to this message

Remco used his keyboard to communicate :
> (I've been playing with trees too)
Wintrees? You like???

//Spider

Post a reply to this message