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