i can't argue with the use of this, but it is not exactly what I had in
mind when making the post..

the reason I came with the idea, was that I was using the tree-macro to
create a few(4) trees for a scene. But, once I had created the trees I
wanted, I got a problem with placing lights and textures. A big one
actually, so, I had to re-render some 15 times before getting the trees
and lights placed ok. This wouldn't be much of a problem, if the trees
hadn't taken so darn long to parse, I used a fairly recursive macro for
it. But the rendering was fast. And since I always got the same output
from the macro, I just wanted to get rid of the parse time. So I made an
eternal program(pascal) to create a .inc with my trees in it. Then I
included it, and, there it was, parsing was suddently fast again.

It is to avoid this that I have come with the idea of storing parsed
macro's and loops in a file, to reuse when there isn't a change.

I've thought some more now, and it would be easier to use a macro test,
for each macro do a comparsion of in-data and other variables used
between the parsing file, and the file stored since previous parse. That
way, it would be easy to compare and load the ready parsed scene
calling. I know there is a problem with detecting if the macro itself
was changed between the parsed data's store and the new parse, but this
can be solved by setting a global_settings{ always_reparse true} as
default. or add the line in the macro... I'm uncertain of this point,
so  I can't be of much help here.

//Spider

Axel Hecht wrote:
> 
> 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
> 
> Hi,
> I don't exactly know where to put my reply as it comments on some parts
> of the thread. So it just goes here.
> 
> Reading the thread it comes to my mind, that the major problem is
> creating a set of similar objects.
> 
> I am mostly doing Matlab-programming, which is in a way quite similar to
> PovRay. It is a interpreter. Well, that quite all, but in fact, Matlab
> is darn slow on loops. Loops are hell, to be honest, and they usually
> even kill the memory management. Being specialised on chunks of data,
> Matlab is vecotrizing a lot of operations. This could possibly be done
> in Povray just as well. So instead of doing some
> #while
>   sphere{}
> #end
> 
> thing one could just define an array
> #define hallo= array[3][3]{{1,0,0},{2,0,0},{3,0,0}}
> and generate three spheres by
> sphere{hallo,1}
> 
> It's a bit tricky and you possibly have to restrict this feature on some
> specific variant of the syntax, but it generally speeds up quite a lot.
> 
> Axel

Post a reply to this message