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