Christopher James Huff <cja### [at] earthlinknet> wrote:
> In article <3eaeff00$1@news.povray.org>,
>  "Early Ehlinger" <ear### [at] respowercom> wrote:
>
> > You could do a bounding-sphere at the beginning of each element.  The parser
> > could then scan past the element quickly by checking open and close braces.
> > It would store the center and radius of the element.  Determining if the
> > element needs to be checked for ray collision is then simply a matter of
> > comparing the distance from the center of the bounding-sphere to the ray
> > with the radius of the bounding-sphere.  If it needs to be checked, the
> > parser would go back and read the entire element.
>
> This would require a bounding object to be specified for every object,
> and for the parser to save the entire text of each object associated
> with each bounds until it parses it, which will likely take more memory
> than the parsed object. This would just slow things down, eat up memory,
> and make things difficult for the user, as well as making the source
> code much more complex. And it adds yet another way for people to make
> mistakes, the manually specified bounding. POV originally used manual
> bounding, there's a reason it was automated.
>
> --
> Christopher James Huff <cja### [at] earthlinknet>
> http://home.earthlink.net/~cjameshuff/
> POV-Ray TAG: chr### [at] tagpovrayorg
> http://tag.povray.org/

Plus any side-effects (assignmets to global variables) would have to be
moved outside of objects.

OTOH it might be able to create an infinite number of objects:

#macro sph
union{
  bounded_by{sphere{0,0.9}}
  sphere{0,1 material{hollow_glass}}
  sph
  scale 0.9
}
#end sph

would be parsed as:
macro, aha... blah,blah,blah... ends here.
oh, we call it: union, bounded by a 0,0.9 sphere. Nice.
....
Oh, there's something unknown in this sphere, it is:
an union, let's see it.
It contains a sphere, it's made of thin glass.
Oh, there's another union here. I't bouded by a 0,0.81 sphere. We don't need
it now.
....

That might come in handy :-)
Maybe this could be activated selectively, e.g. by a
hold{container,containment} object. Rendering hold{c_er,c_ent} would mean:
if the ray hits the c_er it parses the c_ent. It effectively suppresses an
infinite (transfinite?) recursion. Until being hit it looks just like an
object lucky enough not to be hit yet. Easy to learn, hard to master.

BTW, the reality behaves just like that: a particle doesn't know its
position until you ask it (uncertainty principle) and it behaves
differently depending on when do you observe it (quantum interference).
The hold doesn't know its contents until you ask it (uncertainty principle)
and the time for it to be parsed(observed) may affect the results greatly.
This way you can e.g. make a ray sensor that only contains itself AND counts
the photons, possibly triggering something. You can even create multiple
detectors to store the ray position, even to a file.

I can see great possibilities in conditional parsing, especially transfinite
number of objects (fractals, lattices), with no fear of losing speed if used
well. The worst you can do is to create an infinite loop, which is already
simple to do.

Post a reply to this message