 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <run### [at] iname com> wrote...
> This works:
>
> #declare Tex = texture {pigment {color rgb 1} translate x}
> mesh {triangle {x, y, z texture {Tex}}}
>
> But this doesn't work:
>
> #declare Tex = texture {pigment {color rgb 1}}
> mesh {triangle {x, y, z texture {Tex translate x}}}
>
> My point is that if the whole texture is copied anyway, then why does it
> make a difference if the texture is transformed before or after it is
> applied to the triangle?
BUT - the texture is only copied ONCE for the WHOLE mesh. If you use that
same texture 100000000 times in the mesh, you will get only one single copy
with many pointers pointing to it. This is a HUGE memory saving
optimization. But as soon as you translate the texture, you can't re-use
it, because that basically creates a new texture because the translation
becomes an integral part of the texture definition.
This is also why you have to declare the textures before the mesh instead of
within the mesh. The issue is consolidating textures. Let's say you have a
mesh with 1000 triangles (a small mesh). 500 use texture{pigment{ color rgb
<1,0,0>}} and the other 500 use texture{pigment{color rgb <0,0,1>}}. Now,
you wouldn't want 500 copies of each of those textures, would you? Of
course not. But, how in the world is POV supposed to know that those
textures are identical and that it should merge them into one of each?
Instead, you declare two textures before starting the mesh, then you assign
those two textures to the 1000 triangles. This tells POV exactly what you
want: you want 2 textures assigned to 1000 triangles, not 1000 triangles
each with its own unique textures.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <run### [at] inamecom> wrote...
> Why do the UV vectors in mesh2 only accept UV vectors?
> It may sound like a stupid question put like that, but I really see no
> reason whatsoever why I can't define my UV-triangles in 3D space. I think
> it's a great and very annoying limitation.
UV mapping is also known as "surface mapping." A surface is a 2D property
of an object. Therefore, surface coordinates are, by definition, 2D. The
reason it's called u/v mapping is that it uses two coordinates, named "u"
and "v", instead of the traditional three ("x", "y", and "z").
Generally speaking, u/v mapping is used to "paint" an 2D image map onto the
2D surface of an object.
Basically, what you're asking for is not u/v mapping, but rather some type
of texture coordinate interpolation, where each vertex of a mesh is mapped
to a point in 3D texture space, and interpolation is used to find the other
texture coordinates on the surface. This could work for meshes, but it is
not really u/v mapping and it probably wouldn't work well for many other
objects.
Of course, this does NOT mean that it is a bad idea. I can see how it could
be rather useful, but it's not really u/v mapping. I'd like it if there'd
be a way to make it work for all objects, and not just meshes, though.
Although texture interpolation currently only works for meshes, so we're
already setting a trend for extra texture features for meshes.
As you say, it would be relatively easy to implement.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nathan Kopp" wrote:
> BUT - the texture is only copied ONCE for the WHOLE mesh.
Aha! I first thought there was a good reason like that, but then I got
confused, as I got the impression that others participants in this thread
thought otherwise...
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nathan Kopp" wrote:
> Basically, what you're asking for is not u/v mapping,
> but rather some type of texture coordinate interpolation,
> where each vertex of a mesh is mapped to a point in 3D
> texture space, and interpolation is used to find the other
> texture coordinates on the surface.
Yes. I don't really care what it would be called, but found it easier to
explain my thoughts if I just called it "UV-mapping". :)
> it probably wouldn't work well for many other objects.
> I'd like it if there'd be a way to make it work for all
> objects, and not just meshes.
What is the problem? That other objects have not 3 but 4 UV coordinates and
having those specified in 3D might cause them sometimes not to be co-planar?
If so, then couldn't it just be required that they're co-planar, and if not,
an error could be made, or the texture could be ignored, or something like
that. Like polygons currently work...
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmmm, I think there are misunderstanding somewhere.
Okay, let's try to give a summary:
1) At first a reminder (for Rune):
#declare Tex = texture {pigment {color rgb 1} translate x}
mesh {triangle {x, y, z texture {Tex}}}
this is of course valid as you said, and
#declare Tex = texture {pigment {color rgb 1}}
mesh {triangle {x, y, z texture {Tex translate x}}}
is not valid because the texture wants only the 'Tex' identifier when
defined in meshes. POV docs say that only an identifier is allowed due
to optimisation purposes (I didn't check the exact words).
2) General case:
#declare t = texture{... tranform{...}}
mesh{
triangle{...} // No texture explicitely defined.
triangle{...}
triangle{... texture{t} } // Will copy the texture from 't'.
// Only an identifier is allowed, not
// anything else like 'transform'.
triangle{...}
triangle{...}
...
texture{...} // Anything allowed in this global texture.
// If not defined, you get a 'no pigment
// given' for your mesh; say it's black:
// the 2 last triangle will be black too.
}
Here the global texture is affecting all but the third triangle
which carries its own texture. This global texture acts like a
reference but is actually not promoted to each triangle. Those
triangles have no texture at all, only the mesh object has one
and this is the one you see. The third triangle has its own texture
which supersedes the global one of the mesh. This is a copy of the
texture data contained in the variable t, this is not a pointer to t.
So the following exemple will work.
3) What you can do to save memory:
// Don't declare here thousands of textures, even in an array,
// because it would require "lots" of memory for almost nothing.
// Maybe the mesh parsing is then a little bit longer.
mesh{
#declare Tex = texture{ whatever translate x }
triangle{... texture{Tex}} // Copy of Tex is used.
// now we overwrite Tex
#declare Tex = texture{ whatever2 rotate z }
triangle{... texture{Tex}} // Another copy of the new Tex;
// the triangles have different textures.
triangle{...} // No texture.
triangle{...} // No texture.
texture{...} // Global texture that will affect the
// two last triangle (but no copied nor
// referenced).
}
The general form for the required memory is then:
o n + m triangles (explicitly textured + not textured)
o 1 global texture for the whole mesh
and
o n + 1 textures (triangles + Tex variable)
while with declared textures outside the mesh, you would have
o 2n textures (#declare'd variables + copies for the triangles)
hence twice the memory required for the explicitely textured triangles.
Believe me, it's BAD for hundreds of thousands of triangles.
4) The last point is related to mesh2 in MegaPOV 0.6a for now:
When you copy a mesh2 object, you also copy every textures carried by
individual triangles. So if every triangle has its own texture, as this
is the case with UV vectors maps, you do have huge memory requirements;
mesh2 variable + every of its copies have almost the same size because
of the copied textures (the mesh geometry is almost nothing compared to
the memory used by textures in most cases).
Sorry for this long post, I hope it is clear enough.
Maybe it's even not useful to anybody :_(
*** Nicolas Calimet
*** http://pov4grasp.free.fr
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Correction for this point (I'm pretty sure for the others)
> 4) The last point is related to mesh2 in MegaPOV 0.6a for now:
>
> When you copy a mesh2 object, you also copy every textures carried by
> individual triangles. So if every triangle has its own texture, as this
> is the case with UV vectors maps, you do have huge memory requirements;
> mesh2 variable + every of its copies have almost the same size because
> of the copied textures (the mesh geometry is almost nothing compared to
> the memory used by textures in most cases).
UV vectors was not a good example since I never used them,
and in this case what I say is most probably wrong. So please instead
consider the example where every triangle as a different texture given
by a texture_list.
*** Nicolas Calimet
*** http://pov4grasp.free.fr
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thinking a little bit more about it:
> #declare Tex = texture {pigment {color rgb 1}}
> mesh {triangle {x, y, z texture {Tex translate x}}}
> is not valid because the texture wants only the 'Tex' identifier when
> defined in meshes. POV docs say that only an identifier is allowed due
> to optimisation purposes (I didn't check the exact words).
Of course the "optimisation" mentionned would be exactly *not*
to copy the whole texture when it's exactly the same. This is what does
the Mesh_Hash_Texture() function... So what Nathan said previously is
quite logical, and I agree with that. I may have been confused by the
fact that the syntax I wrote actually give different textures while the
texture name is the same:
mesh{
#declare Tex = texture{ whatever translate x }
triangle{... texture{Tex}}
#declare Tex = texture{ whatever2 rotate z }
triangle{... texture{Tex}}
}
This is probably due to the fact that the Tex variable has a
different memory adress when it is reallocated; then the hashing code
consider that Tex and new Tex are really not the same. Then I wonder
what would happen if, when parsing a lot of triangles using this script,
exactly the same adress is given "by chance" to the Tex variable as for
a previous triangle... this would mess up the stuff.
Anyway POV really rocks... not like me :_(
Okay, now I stop my monologue, I promise.
*** Nicolas Calimet
*** http://pov4grasp.free.fr
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks you Nicolas for your contributions in this thread. If it works right
(I think it will) it will save the memory needed for textures by about 50%.
It's still a lot of memory required, but 50% less sure isn't bad!
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 6)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
