Alain CULOS <ZAl### [at] bigfootcom> wrote:
: Besides their to do list is probably big enough not to add this low priority
: item - given the small ratio benefit/cost.

  This is a very good point. Often people forget this fact.

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

Spider schrieb in Nachricht <36B7317E.4D09F18E@bahnhof.se>...
>
>
>Rudy Velthuis wrote:


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


I'll have to take a look at the parser, but if this is true, then it's
definitely not the allocation, which takes time, as obviously the result
(the number of objects) would be exactly the same, so the number of
allocations would be the same too.

Only difference is the fact, that WinTree does the recursion once (in Visual
Basic), producing an include file with all objects already spelled out, and
the recursive parser does this while parsing. So parsing is definitely the
culprit here, not allocation.

I have read somewhere, for #while loops, at the #end, the parser must
re-read the source to find the #while, like old BASIC dialects did. If this
is true, propably an improved parser would have some importance (I know, I
know, the POV-team is busy enough), esp. for scenes which use a lot of
grass, trees, leaves, flowers, fur, etc. And these scenes are becoming more
common, as machines are getting more powerful, and memory is getting cheaper
and POV-artist are getting more "courageous" to tackle huge numbers of
objects.

Perhaps there would be demand for a small program, which unravels #while
loops and macros and creates (huge) include files out of them, taking a bit
out of the parsing POV-Ray does. This could work like WinTree, but perhaps a
bit more generalized. So the program would turn a:

  #declare Count = 0;
  #while (Count <= 40)
    sphere { <-1, Count, -1>, 1 }
    #declare Count = Count + 1;
  #end

into:
  // #declare Count = 0;
  // #while (Count <= 40)
  sphere { <-1, 0, -1>, 1 }
  sphere { <-1, 1, -1>, 1 }
  sphere { <-1, 2, -1>, 1 }
  ...
  // #declare Count = Count + 1;
  // #end
  #declare Count = 40;

etc. (40 sphere definitions instead of one simple loop, and Count = 40, we
might perhaps need this later on).

--
Rudy Velthuis

Post a reply to this message

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

Uhm, most of the time I just play with my own thing...

Remco

Post a reply to this message

On Wed, 3 Feb 1999 14:10:20 +0100, Rudy Velthuis <rve### [at] gmxnet> wrote:
>I have read somewhere, for #while loops, at the #end, the parser must
>re-read the source to find the #while, like old BASIC dialects did. 

Not true, fortunately.  It stores the offset within the file where the 
#while appears and jumps directly to it upon hitting the #end.  

>Perhaps there would be demand for a small program, which unravels #while
>loops and macros and creates (huge) include files out of them, taking a bit
>out of the parsing POV-Ray does. 

Interesting idea, but I'm not sure you'll save much time, as that's 
practically the same as what POV already does.  By seeking backward
in the file, it essentially duplicates the code as many times as 
needed.  The only thing you'd save is a few seeks (nearly instantaneous 
anyway except when it's a macro defined in another file), a few 
expression evaluations (these could potentially be slow, but usually 
aren't), and a few symbol lookups on your index variable (very fast.)  

I do wonder, though, if POV could be coaxed to output a .pov file
in canonical form as it parses a set of .pov and .inc files - with 
commas inserted where necessary and looping and conditionals and 
symbols and includes (all the #-stuff) and comments removed.  I 
think this goes a bit further than you were proposing.  It'd be 
less readable to humans, but it would be oh-so-easy for third-party 
parsers to read, and perhaps slightly faster for POV as well.  Some 
files, like the mandelbrot set made of spheres, would run much more 
quickly.

Post a reply to this message

Remco de Korte schrieb in Nachricht <36B7BEC9.C59DA130@xs4all.nl>...
>Spider wrote:
>> 
>> Remco used his keyboard to communicate :
>> > (I've been playing with trees too)
>> Wintrees? You like???
>> 
>> //Spider
>
>Uhm, most of the time I just play with my own thing...


Don't let your mother catch you! 

;-))
-- 
Rudy

Post a reply to this message

Ron Parker schrieb in Nachricht <36b8526e.0@news.povray.org>...
>On Wed, 3 Feb 1999 14:10:20 +0100, Rudy Velthuis <rve### [at] gmxnet> wrote:
>>I have read somewhere, for #while loops, at the #end, the parser must
>>re-read the source to find the #while, like old BASIC dialects did.
>
>Not true, fortunately.  It stores the offset within the file where the
>#while appears and jumps directly to it upon hitting the #end.


Fortunately, yes.

>>Perhaps there would be demand for a small program, which unravels #while
>>loops and macros and creates (huge) include files out of them, taking a
bit
>>out of the parsing POV-Ray does.
>
>Interesting idea, but I'm not sure you'll save much time, as that's
>practically the same as what POV already does.  By seeking backward
>in the file, it essentially duplicates the code as many times as
>needed.  The only thing you'd save is a few seeks (nearly instantaneous
>anyway except when it's a macro defined in another file), a few
>expression evaluations (these could potentially be slow, but usually
>aren't), and a few symbol lookups on your index variable (very fast.)


Still, the parser is an interpreter. Even if the allocation of objects takes
much time, the interpreter also uses time, which Spider's example with the
pre-computed trees proves. A pre-compiler (generating some kind of p-code,
optimized for the language, perhaps) would be a nice feature IMHO. A good
one could even look ahead and optimize (optimise) the allocations (yes I'm
dreaming again).

I myself am used to a very fast compiler (Delphi), so waiting for a parse is
really annoying (first time I made a longer parse, I thought the program was
hanging). You (MSVC) C++ guys are propably used to longer compile times <g>.

But I agree with the POV-team, that normally the render time is much more of
a problem, so they should propably optimize (optimise) that first.

>I do wonder, though, if POV could be coaxed to output a .pov file
>in canonical form as it parses a set of .pov and .inc files - with
>commas inserted where necessary and looping and conditionals and
>symbols and includes (all the #-stuff) and comments removed.  I
>think this goes a bit further than you were proposing.  It'd be
>less readable to humans, but it would be oh-so-easy for third-party
>parsers to read, and perhaps slightly faster for POV as well.  Some
>files, like the mandelbrot set made of spheres, would run much more
>quickly.

It would propably allow for a .pov to <add your favorite modeller here>
converter, if that's what you mean. You would have some kind of .dxf file in
.pov format <g> (afaik, .dxf are plain text files, and they can be huge).

But you'll propably have to write a rather extensive parser for this. Once
you've done that, the rest won't be hard to implement anymore.

--
Rudy Velthuis

Post a reply to this message

On Wed, 3 Feb 1999 21:39:08 +0100, Rudy Velthuis <rve### [at] gmxnet> wrote:
>But you'll propably have to write a rather extensive parser for this. Once
>you've done that, the rest won't be hard to implement anymore.

But if you use POV's built-in parser, and get the code added to the 
official release somehow...  This is how POB format works, but it's
not official.  All of the issues with binary files go away if you 
use a text file in a known format instead.  The result is something
that's a little slower parsing than a binary file but not as slow
as a procedural scene description, more cross-platform than a binary
file, and backward compatible with existing versions of POV.  It's
like the C preprocessor: it outputs C code, but it's not C code mere
mortals would want to read.  In fact, many compilers even have an 
option for "preprocess only."  This is the sort of option I'm 
proposing.

Post a reply to this message

Nieminen Mika wrote:
> 
> Alain CULOS <ZAl### [at] bigfootcom> wrote:
> : Besides their to do list is probably big enough not to add this low priority
> : item - given the small ratio benefit/cost.
> 
>   This is a very good point. Often people forget this fact.
I actually agree. It was only an idea from my side.

//Spider

Post a reply to this message

Alain CULOS wrote:
> 
> Hi,
> 
> What you want is typically called a binary format in programming jargon.
> This binary format exists in custom versions of POV, i.e. POB. Don't ask me
> for a URL I did not store any and my memory ain't that good - but I did see
> it, I'm sure you can find it.
> My understanding is the POV team does not want to implement such a binary
> format because it involves difficult questions when you come to
> cross-platform portability. As well as that they claim it would not be a
> major advantage in terms of performance (parse+render time) in most cases.
> Besides their to do list is probably big enough not to add this low priority
> item - given the small ratio benefit/cost.
> 
Hey !
Who said I wanted a binary format? (quiz)
No, I'd be glad with a ascii/ansi/unicode text file, why? because then I
could move one or two of the objects afterwards, as well as looking at
the results, searchin(ahem, ok, maybe not) for a way to improve.

As for performance, it depends on the scene, doesn't it ?

Well, out .

//Spider

Post a reply to this message

Lets start commenting on the discussion.


Rudy Velthuis wrote:
> 
> Spider schrieb in Nachricht <36B7317E.4D09F18E@bahnhof.se>...
> >
> >
> >Rudy Velthuis wrote:
> 
> >> 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.
> 
> I'll have to take a look at the parser, but if this is true, then it's
> definitely not the allocation, which takes time, as obviously the result
> (the number of objects) would be exactly the same, so the number of
> allocations would be the same too.
Yes.
 
> Only difference is the fact, that WinTree does the recursion once (in Visual
> Basic), 
*GASP*
Whatta heck are you accusing me of?
It is Delphi, admittedly using a very sloppy design, and rxlib, and
dElphi 3, but... "VISUAL BASIC" ????! *gasp* *choke*

> producing an include file with all objects already spelled out, and
> the recursive parser does this while parsing. So parsing is definitely the
> culprit here, not allocation.
Yes, it is. That's why I made the prog. the allocation takes around 4-8
seconds, depending on the size of the tree.
 
<snip>
> 
> Perhaps there would be demand for a small program, which unravels #while
> loops and macros and creates (huge) include files out of them, taking a bit
> out of the parsing POV-Ray does. This could work like WinTree, but perhaps a
> bit more generalized. So the program would turn a:
> 
>   #declare Count = 0;
>   #while (Count <= 40)
>     sphere { <-1, Count, -1>, 1 }
>     #declare Count = Count + 1;
>   #end
> 
> into:
>   // #declare Count = 0;
>   // #while (Count <= 40)
>   sphere { <-1, 0, -1>, 1 }
>   sphere { <-1, 1, -1>, 1 }
>   sphere { <-1, 2, -1>, 1 }
>   ...
>   // #declare Count = Count + 1;
>   // #end
>   #declare Count = 40;
yes, this might be helpful, but perhaps not good enough. This is a thing
too look deper into.

> etc. (40 sphere definitions instead of one simple loop, and Count = 40, we
> might perhaps need this later on).
yes.

I'll go on commenting now :-)

//Spider

Post a reply to this message