Hi all there !

	Yes, again another message related to the mesh2 object
using texture_list definitions...

	I've noticed in the mesh.c code that all textures are
copied when the initial mesh2 object is duplicated, as for
instance:

/* will use 3 times the required memory for the textures */
#declare surface = mesh2{...}
object {surface transform ...}
object {surface rotate ...}

This is IMHO a little bit in contradiction with the original
mesh features. Needless to say that it requires much more
memory when using big meshes with a lot of textures...
	I suppose it could be possible to use a Reference
system as designed for the Data structure of the object. I did
something like this for my patch (colors only, not full textures).
Maybe I missed some critical thing concerning the mesh2 object,
and I wanted to know it before changing the related code.

	Thanx ;-)

*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote...
> I've noticed in the mesh.c code that all textures are
> copied when the initial mesh2 object is duplicated

Yes.  The original mesh implementation did not do this, but that caused a
BUG.

> This is IMHO a little bit in contradiction with the original
> mesh features. Needless to say that it requires much more
> memory when using big meshes with a lot of textures...
> I suppose it could be possible to use a Reference
> system as designed for the Data structure of the object. I did
> something like this for my patch (colors only, not full textures).
> Maybe I missed some critical thing concerning the mesh2 object,
> and I wanted to know it before changing the related code.

The problem is not just with mesh2, but with the way POV handles textures on
all objects.  The issue is that the textures are computed in texture space,
which is stored in a separate matrix from object space.  For texture space
and object space to be the same, the textures must be translate with the
object.  Object transformations are applied to textures prior to rendering
the scene, not on the fly.

All of this is done for a variety of speed opminization reasons.  It is a
matter of sacraficing memory for speed. And, because it is built into the
core of POV, it is NOT AT ALL EASY to change it.  It might be changed during
the complete rerwite that is planned for POV 4.0, though.

The bottom line is that if references are used for textures, the textures
will not move when the object is moved.  Or, if they are moved, moving one
object will affect the textures for all copies of that object (which would
be very bad).  Check out POV 3.1 for an example of this problem.  Note that
this affects the per-triangle textures, and not the per-object texture.

-Nathan

Post a reply to this message

Nathan Kopp wrote:

> The problem is not just with mesh2, but with the way POV handles textures on
> all objects.  The issue is that the textures are computed in texture space,
> which is stored in a separate matrix from object space.  For texture space
> and object space to be the same, the textures must be translate with the
> object.  Object transformations are applied to textures prior to rendering
> the scene, not on the fly.

	I understand this for any object but mesh2 using texture_list (and
presumably uv mapping also). In this object the textures are always related
to the mesh vertices (and interpolated within mesh triangles). Hence texture
space always equals mesh space. Since the ray is transformed into mesh space,
it must be transformed as well for the textures (that's precisely the fix you
posted when I pointed the related bug a few weeks ago).

> All of this is done for a variety of speed opminization reasons.  It is a
> matter of sacraficing memory for speed. And, because it is built into the
> core of POV, it is NOT AT ALL EASY to change it.  It might be changed during
> the complete rerwite that is planned for POV 4.0, though.

	Sacrifiying memory when it requires a lot (as in textures) is a real
problem. I'm using a DEC device with 2 GBytes of physical memory and have
troubles to get a picture for two copies of a mesh2 object (~ 800,000 triangles).

> The bottom line is that if references are used for textures, the textures
> will not move when the object is moved.  Or, if they are moved, moving one
> object will affect the textures for all copies of that object (which would
> be very bad).  Check out POV 3.1 for an example of this problem.  Note that
> this affects the per-triangle textures, and not the per-object texture.

	Again the textures from texture_list don't have to move.
	I simply removed the Copy_Textures things in Copy_Mesh code and replaced
it by simple pointer assignment. It gives expected results for me, I don't see
any problem when applying seperate transforms to the object copies. And of course
it saves quite alot of memory.
	Only to mention that the program crashes at the end when the memory is
free'd since it needs some Reference handling as I mentionned before. Also there's
a weird problem related to Mesh->Blend_Map (do_texture_map) only when the display
is on (+d). I'm going to investigate this particular issue.

	Anyway I don't want to show myself as an expert in POV/MegaPOV programming
because it's simply not the case. I only hope to push *real* experts such as
Nathan to improve as much as possible the good work they're doing ;-)


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote...

> Again the textures from texture_list don't have to move.
> I simply removed the Copy_Textures things in Copy_Mesh code and replaced
> it by simple pointer assignment. It gives expected results for me, I don't
see
> any problem when applying seperate transforms to the object copies. And of
course
> it saves quite alot of memory.

If you use uv_mapping, then you won't notice the problem.

Here is where you'll notice the problem:

#declare MyMesh = mesh2 { ... }

object{
  MyMesh
  translate 10*x
}

object{
  MyMesh
  scale 1000*y
}

The textures on both objects will be stretched in the y direction, even
though the transformation was only applied to the second object.  If you use
uv_mapping, you won't see it because object transformations are not applied
to uv_mapped objects.

> Sacrifiying memory when it requires a lot (as in textures) is a real
> problem. I'm using a DEC device with 2 GBytes of physical memory and have
> troubles to get a picture for two copies of a mesh2 object (~ 800,000
triangles).

How many textures are you using?  Usually, a mesh will only have one or two
textures.  Now that I think about it, if you are trying to use this the same
way you would have used the color interpolation, you may be using a
different texture for each vertex, which would definately drain memory.  For
this, the transformations would not be important (solid red is red no matter
where you look at it).  Currently, I don't have a good solution.  The only
thing I can say is that it wouldn't be a good idea to have a specialized
texturing system for meshes that differs drastically from the texturing
system for the rest of POV.  The old texture vertex color interpolation
texturing scheme, for example, contradicted the rest of POV's texturing
system, which is why it was changed into the current form.

-Nathan

Post a reply to this message

Nathan Kopp wrote:

> How many textures are you using?  Usually, a mesh will only have one or two
> textures.  Now that I think about it, if you are trying to use this the same
> way you would have used the color interpolation, you may be using a
> different texture for each vertex, which would definately drain memory.

	Yes precisely. I forgot to mention that I was talking only about mesh2
object which carries a different texture at each vertex. This obviously is quite
memory expensive. And in this case the exemple you give works well since again
the texture are interpolated within triangles only.

> For
> this, the transformations would not be important (solid red is red no matter
> where you look at it).  Currently, I don't have a good solution.  The only
> thing I can say is that it wouldn't be a good idea to have a specialized
> texturing system for meshes that differs drastically from the texturing
> system for the rest of POV.  The old texture vertex color interpolation
> texturing scheme, for example, contradicted the rest of POV's texturing
> system, which is why it was changed into the current form.

	I agree. More than two years ago when I started to do color-interpolation
within triangles, I chose a more general method than the one implemented later by
Ansgar Philippsen. I created a new pattern texture ("vertexcolor") which works for
any (smooth_)triangle, inside mesh or not. Of course it works differently than
other patterns. Also I suppose my code to be faster and without side-effect (like
the message in MegaPOV: "all determinants too small"). Still it was designed only
for colors, not full textures as you do.

	Well, after more trials in this particular situation of mesh2 object (with
as many textures as vertices for example), it seems possible to drastically reduce
the memory cost when copying the object. I was expecting to do better as I was
saying in my previous post, but it crashed in some common situations. At least the
following seems to work even with complex textures.

	Replace this line in Copy_Mesh:
New->Textures[i] = Copy_Textures(((MESH *)Object)->Textures[i]);
	by:
New->Textures[i] = Copy_Texture_Pointer(((MESH *)Object)->Textures[i]);

No need of another Textures->References since it's already handled this way. In my
test-case of 800,000 triangles it may save a few hundred megabytes ;-)

	Maybe not the end of this story ?

	- Nicolas


*** Nicolas Calimet
*** http://pov4grasp.free.fr

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote...
> Well, after more trials in this particular situation of mesh2 object (with
> as many textures as vertices for example), it seems possible to
drastically reduce
> the memory cost when copying the object. I was expecting to do better as I
was
> saying in my previous post, but it crashed in some common situations. At
least the
> following seems to work even with complex textures.
>
> Replace this line in Copy_Mesh:
> New->Textures[i] = Copy_Textures(((MESH *)Object)->Textures[i]);
> by:
> New->Textures[i] = Copy_Texture_Pointer(((MESH *)Object)->Textures[i]);
>
> No need of another Textures->References since it's already handled this
way. In my
> test-case of 800,000 triangles it may save a few hundred megabytes ;-)
>
> Maybe not the end of this story ?

Unfortunately, no.  While this does work for solid colors, it will not work
for any other kinds of textures, because of transformation problems.
(  More extensive changes would be necessary to make it work.  I had been
working on that (in a more general sense for all objects, not just meshes),
but it was taking too much effort so I moved on to "more important" things.
Feel free to keep working on it, though  :-)  One quick-hack solution would
be to check and see if the texture is a solid color with no normal, and if
so, just copy the texture pointer.  That should work correctly in all
situations and will save you much memory for your particular use.

-Nathan

Post a reply to this message

Nathan Kopp wrote:
> Unfortunately, no.  While this does work for solid colors, it will not work
> for any other kinds of textures, because of transformation problems.

	Yes. Finally It splashed in my eyes after I decided to put on my
screen two pictures with translated/rotated mesh2 objects with complex
textures as those given in texture_list demo. I was too stupid to look a
little bit longer than 1 nanosecond to see the textures were definitely
not oriented as they were when copying the textures. Sorry for all.

> (  More extensive changes would be necessary to make it work.  I had been
> working on that (in a more general sense for all objects, not just meshes),
> but it was taking too much effort so I moved on to "more important" things.

	Of course if you decided to copy the textures it was for a good
reason. #$%&^@* I really feel my fault >:(
	Unfortunately textures/memory are one of the major issue of the next
release of POV-Ray I think. I understand you're probably willing to work more
on photon mapping and all the new great features. I'm sure the Chris Huff's
particule system will be also integrated soon in all MegaPOV versions :-)

> Feel free to keep working on it, though  :-)

	Not too much time I'm afraid, and the worst is that I'm not enough
understanding the POV-Ray code as this story prooved to me. In my own patch
(which is extremely specific, hence in contradiction with POV philosophy)
I only focused on meshes and its related code...

> One quick-hack solution would
> be to check and see if the texture is a solid color with no normal, and if
> so, just copy the texture pointer.  That should work correctly in all
> situations and will save you much memory for your particular use.

	Yes, now I completely agree. This is what I'm going to do in what
I will call a "custom MegaPOV 0.5a" for my benchmarks until you release the
next version if you decide to make such changes. I will continue to test
as much as possible the mesh2 object since this is mainly what I currently
need in MegaPOV, and if required to report bugs if they're real ones ;-)

	Thanks again for your patience !

	- Nicolas


PS: as a UNIX/Linux user I compiled MegaPOV on several architectures. If
someone is interested I can provide compiles for DEC, SGI, Linux (but M.G.
is here for that), and possibly SUN (but Warp does it AFAIK). Last time I
reported a 'transform id' bug that occurs only on DEC, so I think I should
follow the development on these devices.

Post a reply to this message