On Fri, 22 Feb 2002 14:43:54 +0000, Grey Knight wrote:
> My question; how far ahead does this look-ahead work? I have an idea for
> a version of POVRay which will pass the scenefile to the parser in small
> chunks (I'll explain why later), and I'd like to know how small I can
> make those chunks without running into problems with look-ahead.

If you explain why now, we might be able to help you avoid povlegal pitfalls.

The parser does not work as you think it does, but the general answer to your
question is probably "a token's worth."  However, the parser expects to be
able to go back and reread data it's already seen, and it expects to be able
to do so by opening a file and doing a seek.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

Ron Parker wrote:
> 
> On Fri, 22 Feb 2002 14:43:54 +0000, Grey Knight wrote:
> > My question; how far ahead does this look-ahead work? I have an idea for
> > a version of POVRay which will pass the scenefile to the parser in small
> > chunks (I'll explain why later), and I'd like to know how small I can
> > make those chunks without running into problems with look-ahead.
> 
> If you explain why now, we might be able to help you avoid povlegal pitfalls.

Well, I wanted to sort out some algorithims first so that Warp wouldn't
complain (j/k)
Basically, I wanted to see if I could store a .pov file as binary data
(with eg 0x10 representing the "sphere" keyword, 0x0C for "blob" or
whatever), and then compress that data into a file (I was thinking .pbz
for POV-Ray Binary Zipfile; also look what happens when you ROT13 it ;)
The idea is that the .pbz file will be much smaller than the .pov file,
so we can keep only the pbz data in memory, and translate it to text
when required by the editor or parser.

> The parser does not work as you think it does, but the general answer to your
> question is probably "a token's worth."  However, the parser expects to be
> able to go back and reread data it's already seen, and it expects to be able
> to do so by opening a file and doing a seek.
Hmm, perhaps we could just uncompress the data again if it wants to look
at old stuff?

These are all just ideas off the top of my head, I wanted to try and
realise it a bit more before I posted any detail.

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message

On Tue, 26 Feb 2002 12:09:18 +0000, Grey Knight wrote:
> The idea is that the .pbz file will be much smaller than the .pov file,
> so we can keep only the pbz data in memory, and translate it to text
> when required by the editor or parser.

Well, you could always use a version of POV that doesn't need to keep the
.pov file in memory. :)

I don't think the editor would take too well to this sort of thing, actually.
The parser might be okay with it with some small modifications, though.

However, most .pov files that you would actually load into the editor are
fairly small in size anyway, and files that are just being rendered (but not
edited) are never actually in memory, so I can't see that you'd see much 
improvement with these changes.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

Ho hum. Can you think of anything in POV that *would* benefit from some
sort of compression? I'm just looking for something to experiment with
now...

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message

Oh, actually I just thought of one; sigfiles ;)
I'll just finish my *2* IRTC entries first...

Grey Knight wrote:
> Ho hum. Can you think of anything in POV that *would* benefit from some
> sort of compression? I'm just looking for something to experiment with
> now...

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message

I can get you a few hundred povscript .inc files containing huge mesh2 data.
Maybe compressing those?

Post a reply to this message

I forgot. The folks of the 'Internet Movie Project' have a povray 3.1
version that can use zipped file systems or something IIRC.
http://www.imp.org/



Apache
http://geitenkaas.dns2go.com/experiments/

Post a reply to this message

Ron Parker wrote:
>
> However, the parser expects to be
> able to go back and reread data it's already seen, and it expects to be
> able to do so by opening a file and doing a seek.

I'm a little bit surprised by this, because - according to the docs 
Section 6.2.2.5 - you can pipe a scene to povray. Is the complete scene
buffered internally?

Anyway, you can of course uncompress a scene file on the fly using zcat.
This would at least save hard disc space, but you probably know all this.

Thomas

Post a reply to this message

On Wed, 06 Mar 2002 08:38:07 +0100, Thomas Willhalm
<wil### [at] fmiuni-konstanzde> wrote:
> I'm a little bit surprised by this, because - according to the docs 
> Section 6.2.2.5 - you can pipe a scene to povray.

(in new 3.5 documentation standard input is mentioned in 5.2.3.2)

ABX

Post a reply to this message

How are they formatted? Could you send me a couple of example files plz?

Apache wrote:
> 
> I can get you a few hundred povscript .inc files containing huge mesh2 data.
> Maybe compressing those?

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message