You have some good points here and as I said this isn't all 100% thought
out.

Ron Parker wrote in message <35bf2617.0@news.povray.org>...
...
>Surely you didn't mean to scale your spheres by zero in two dimensions.
>There is a big difference between saying "scale the object by 2" and "set
the
>scale of the object to 2," and that difference isn't apparent in this
syntax.
>
>Also, you're slipping in a new function (intersects) that would be a
>tremendous chore to write, object oriented or not.  Collision detection
with
>the kind of primitives POV-Ray provides is not easy at all.


You're right I made a mistake on that scale it should have been:

mySphere.Scale = <2, 1, 1>;

or even:

mySphere.Scale( <2, 1, 1> );

Regarding the intersects function, I realize this is a non trivial matter
especially for other more complex shapes than the sphere. This is why I
propose the functionality be put into the parser instead of the render
engine.

>Actually, as you see, it's not hard to translate what you wrote into POV
code,
>but the result probably takes a lot longer to parse.


In some cases I agree completely. Some other objects, however, would be much
harder to translate accurately. Blobs, interior effects, and some of the
higher order mathematical functions come to mind.

>When you put the ability to know about an object into POV-Ray, you're not
>putting it into the render engine.  You're putting it into the parser.  For
>example, my object bounds patch at http://www2.fwi.com/~parkerr/traces.html
>is mostly a patch to express.c, the part of the parser that deals with
>expressions.  The only difference between the way it is now and the way it
>would be if the parser were split off is one of compile time and (I hate to
>say it) run time.  Yes, splitting off the parser would actually SLOW POV
>DOWN as it writes the sometimes-massive binary representation to disk and
>then reads it back.


    I don't fully agree with this. If the parser saved the scene as a well
constructed binary format scene then I believe POV could parse that file
much more quickly than it can the current file. In order to acheive this
speed-up, though, I think some other rewriting of POV would be necessary. I
haven't looked at the code buy I remember I created a scene once that had
about 30,000 objects and required about 30MB of RAM to render (regardless of
the resolution). This meant that POV was allocating an average of 1k per
object. When I considered the actual information POV should have to remember
about each object I thought that there must be a lot of waste in there
somewhere.
    Part of that scene was 4 trees. Each tree contained about 5000 objects
but each tree was also identical (just rotated and positioned differently).
I think there should probably be some way for POV to handle objects that are
the same in a more memory effecient manner.
    Again, I haven't looked at the code but I think some vast improvements
in parsing could be accomplished.

Post a reply to this message