Lukas Winter <web### [at] geloeschtremovethisandthedotbeforenet> wrote:
> Am Mon, 13 Apr 2009 18:55:22 -0400 schrieb clipka:
>
> > I think however that the function-based approach is better, because it
> > would define transformations as basically property-less. So nobody tries
> > to do things like:
> >
> >   sphere {
> >     rotate { axis: <1,0,0>; angle: 30 deg; } as myRotate; translate {
> >     vector: <1,2,3>; };
> >   }
> >   myRotate.angle = 60 deg;
> >
> > Otherwise, POV-Ray would need to keep track of a stack of
> > transformations applied to the object (and similarly all the texture
> > patterns and such as well), just in case someone would want to modify
> > one of the steps later.
>
> Well, I think the point here is: Do we store references in variables or
> actual copies of the data? If we store references, then yes, POV-Ray
> would need to keep track of them in its internal state. If we don't then
> "myRotate.angle = 60 deg" would do nothing until we use myRotate in an
> object modification block. Thats the same problem as cloning vs.
> modifying objects in the scene.

You'd want a transformation for each container, which doesn't prevent references
being used. Those that seem to be a list of transformations interleaved with
effects would be processed into a nested structure, each having the
transformations and effects before the container is closed.

I think we can use the usual (simple) language constructs to create references,
and new declarations for copies.

Generally, we could go for partial OO implementation for the scene objects,
which means that we don't carry per-instance methods, but instead just have the
instances (with a single pointer) locate the methods for the class, along with
the enumerated properties. The parser would be version-matched to the engine,
which removes any opaque enumeration from the SDL source scripts.

Post a reply to this message