> (I have been explained why it was done in megapov, and I believe it is not
> the correct solution to the problem, a second transformation matrix when
> a mesh is duplicated should have been enough with enough care done for the
> texture computation; at least, it would have been less memory intensive than
> the megapov duplication of the texture)


	Could you possibly develop that point further ? This duplication
of the mesh textures is a real problem for huge texture lists. It's actually
the only reason why I don't use megapov, and why I will have to patch
POV-Ray 3.5 as I did for 3.1g.
	So, if you know of a better solution involving a second matrix,
I'd like to see it  :o)

Post a reply to this message

Nicolas Calimet wrote:
> 
> > (I have been explained why it was done in megapov, and I believe it is not
> > the correct solution to the problem, a second transformation matrix when
> > a mesh is duplicated should have been enough with enough care done for the
> > texture computation; at least, it would have been less memory intensive than
> > the megapov duplication of the texture)
> 
>         Could you possibly develop that point further ? This duplication
> of the mesh textures is a real problem for huge texture lists. It's actually
> the only reason why I don't use megapov, and why I will have to patch
> POV-Ray 3.5 as I did for 3.1g.
>         So, if you know of a better solution involving a second matrix,
> I'd like to see it  :o)

I have no tested solution (i.e. no code), but from what I understood from
the explanation given on this server (See this group, answer from Nathan Kopp
dated 23 February 2002 to "Question regarding MegaPov").

There is potentially two different times (that I can think of, maybe
I missed some other and therefore my solution might then be bogus) when
an additional transformation (translate,rotate, scale, whatever) is applied
to an existing mesh with a collection of texture.
1. During the original declaration of the mesh (i.e. the mesh parsing is not
yet finished), and I believe the 3.1g handled this case well.
2. Whenever a mesh is reused (via its identifier) and then an additional
transformation
is performed. Traditionnal handling of this is to copy the object and update the
transform
matrix attached to the copy. This is where the 3.1g had problem with texture handling
in
mesh.

To sum up: an object has a transformation matrix and every texture has also a matrix.
First an object is created and get a matrix A (transformation before texture).
Then texture is applied and texture has its own matrix T.
Object is then transformed again and a new matrix B is used (transformation after
texture).
This later stage can be repeated with a new matrix Ci whenver an identifier is used.

Usually, A & B are combined in a single matrix (object level), 
while T & B are combined in a matrix (at texture level). (this is happening at parse
time!)

So far so good, but when adding Ci, the traditional approach with objects (not mesh)
is to
get a copy and then combined Ci at the object level (no problem with mesh, the top
level
is also
a copy which can be updated) as well as at the texture level (here mesh have a
problem,
because 
it is not allowed to update the data structure regarding the textures [in 3.1g, it's
not a
copy,
it's a reference to the first data]).

Instead of trying to combined the texture matrix with Ci, it could be possible to
store Ci
as 
a new matrix at the object level, because texture evaluation code for mesh is already
so
special,
it could as well apply an additional transform when evaluating the texture. It's
trading
memory
for speed but I believe that the real interest of mesh is really memory and the
additional
cost
to correct the initial bug is only paid when the mesh is hit, which I believe is a
small
price.

So: When parsing the initial mesh, the same behavior as 3.1g is kept;
When adding transformation to a copy of a mesh, the textures do not have to be copied,
but instead another matrix must also be updated at the object level of the mesh
structure,
which will be used by the texture evaluation code of the mesh. Of course the default
value
for this additional matrix should be Identity.

Allow me an analogy: transformation of textures in mesh are like a list of integers.
When you apply an additional transformation, you are adding a value to each integer of
the
list.
Rather than copying the list for each copy of the list that have a different (or
identical, you cannot
know) transform, it is simpler to keep a single list with various offset (one for each
copy).
It's trading memory for speed, because now each time you access a copy, you have to
perform
a calculation using the offset, but you have avoided to copy the whole list.

What is bigger: a transformation matrix or a texture list ?
I guess you know the answer...
-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message