Kevin Wampler <wam### [at] cswashingtonedu> wrote:
> 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.

  With most primitives copying by reference (instead of making a deep copy)
wouldn't make sense because it would only consume more memory.
  For example a sphere has only a center and a radius as data (besides
everything common to all objects). If you want to copy that sphere the
most efficient way of doing that is to simply make another sphere with
the same center and radius.

  It's only with primitives which contain (potentially) lots of data which
benefit from reference-counting. Mesh is one such primitive because this
single object can contain even hundreds of megabytes of data. Certainly
copying by reference is enormously more efficient than making a deep copy.
  Blobs also use reference counting for their data, as one blob can
contain lots of components inside it. Lathe and sor reference-count the
spline data (ie when you make several instances of the same pre-declared
lathe or sor, the spline inside them is not copied, but they all point
to the same spline data).

  One primitive type which would benefit a lot from reference counting
would be the CSG objects becaue they also can potentially contain lots
of other objects inside them.

  Now, there are several reasons why CSG does not do this.
  Firstly, the internal structure of the POV-Ray core code makes it
currently quite difficult to do this. A serious redesign would be
necessary in order to support this (which is something planned for pov4).

  Secondly, transformation optimizations and reference counting are
mutually exclusive. Primitives which have transformation optimizations
could not reside inside a csg object which uses reference counting.
  The transformation optimizations minimize the need to create a
transformation matrix for the object. If an object has a transformation
matrix it's somewhat slower to trace: Each trace against the object
requires a matrix multiplication. If the object does not have a
transformation matrix then this multiplication can be skipped.

  In the case of CSG supporting reference counting would be as simple
as having a CSG-specific transformation matrix. When a CSG is traced,
the ray would be transformed with the matrix of the CSG and then traced
against the objects inside it. However, these objects can also be
CSG themselves, and if they have transformation matrices, additional
multiplications would have to be made for each one that has. In
addition, if any object inside these CSG had matrices, the ray would
have to be multiplied by those as well.
  If I'm not mistaken currently CSG does not cause additional matrix
multiplications to be done, even if you have CSG inside CSG inside CSG.

  So it's a question of deciding which is worse, additional memory usage
or perhaps a bit slower rendering.
  (And take into account that the transformation matrix itself takes
some meory, so unless the CSG is very big, it could take even more memory
than without one.)

  It's not a trivial issue.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message