> Quite interesting -- I was not aware of that.  Out of curiosity does
> anyone know why all objects can't use references for multiple copies?  I
> understand that it's some detail oin the implementation of POV-Ray, but
> I don't think I've ever heard what it was.

I actually very recently attempted to make an "object reference" patch which
does just that. I had a sort of working implementation, but at that point I
began to more fully understand the limitations which make it very difficult.

What it comes down to is this: all transforms are handled ahead of time. For
instance, when you transform a union, that transformation is applied right
then to every object within the union, and to their textures, interiors,
etc. Later, when an intersection is calculated, there is one intersection
point. This is the point in 3D space where the lighting is calculated from,
the normal of the object is calculated from, the texture is evaluated at,
etc.

Now say you have a reference to an object which is defined at the origin,
and the reference is translated to x = 10. (Internally, the actual object is
still at the origin, but the "object reference" wrapper has the
transformation applied.) When a ray intersects this object, where should the
intersection point be? Should it be near x=0 (relative to the original
object) or near x=10 (relative to the reference object)?

If it's near x=0, then the lighting will be calculated from that point,
which produces incorrect lighting. Other calculations may also go wrong,
since the intersection point is not really where the intersection happened
in 3D space.

But if it's near x=10, then the texture will be evaluated at that point,
which is wrong since the texture should be evaluated near x=0. Also, the
normal has to be calculated relative to x=0. Other calculations may also go
wrong.

And this is just the difficulty that transformations bring up. What if
no_shadow is applied to the object reference? It can't be copied to the
actual object since that would affect other references to the same object.
So we need both information about the actual object (its texture, no_shadow
and other flags, etc) and about the reference (additional texture, no_shadow
and other flags, all which should override the actual object's settings).
But we can't keep track of both at once.

The only practical way to avoid these problems is to prevent the user from
doing anything at all with object references; this then makes them useless.

One possible solution would be to find all the places where data from an
intersection is looked at, and determine which intersection point should be
considered, or which texture should be evaluated, etc. But there are so many
places in the code where these things happen that it would be easy to miss a
few, and have a buggy patch. Assumptions are made all throughout the source
code that an intersection happens in one place; those assumptions can't
practically be changed without a rewrite.

If POV-Ray were written in C++ (I believe/hope this is one of the changes
planned for 4.0?), then this wouldn't be so hard to solve. The Intersection
object would have functions like getNormal(), evaluateLighting(),
evaluateTexture(), and those could be rewritten to handle the special case
of object references.

I may continue to look for solutions to this problem with the restraint that
only transformations may be applied to an object reference, but I don't have
high hopes for it.

(The reason that none of these problems apply to mesh data or other
referenced data is that the only areas of code that deal with those data are
the respective objects that use them. Change the implementation of mesh data
and you only have to change the mesh object methods, not the entire source
code.)

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message