 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 13 Jan 2001 11:45:46 +0100, "Rune" <run### [at] iname com>
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 used to map a 2D texture onto a 3D mesh. I know POV
textures are 3D and one might want to take advantage of that, but tell
this to the image-map geek types who made up UV mapping ;)
Maybe you can use a matrix transform to map the 3D texture to the XY
plane and then use a UV vector on it... just a suggestion.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Peter Popov" wrote:
> "Rune" 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 used to map a 2D texture onto a 3D mesh. I
> know POV textures are 3D and one might want to take
> advantage of that, but tell this to the image-map geek
> types who made up UV mapping ;)
The mesh2 syntax could be changed to accept xyz vectors as well as uv
vectors. I see no reason not to do it.
> Maybe you can use a matrix transform to map the 3D texture
> to the XY plane and then use a UV vector on it... just a
> suggestion.
I originally did "UV-mapping" using matrixes to transform textures for the
individual triangles in a regular mesh, but this required me to remove the
mesh{} block around the triangles, which of course was a great disadvantage,
as the triangles were then not optimised anymore.
So I wanted to use mesh2 instead as it had internal UV-support. I didn't
know it accepted UV-vectors only. Now, if I have to use matrixes again to
get the desired result, I'm back where I started. I have to use a bunch of
unoptimised triangles. Which is not an acceptable solution for me. :(
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think this could be a good idea. It wouldn't break backwards
compatibility either (because povray automatically promotes 2D-vectors
to 3D-vectors with the z coordinate being 0 when needed).
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a6190cc@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> I originally did "UV-mapping" using matrixes to transform textures
> for the individual triangles in a regular mesh, but this required me
> to remove the mesh{} block around the triangles, which of course was
> a great disadvantage, as the triangles were then not optimised
> anymore.
I don't understand what you mean...as far as I know, there are no
problems using per-triangle textures in meshes.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" wrote:
> I think this could be a good idea. It wouldn't break
> backwards compatibility either (because povray automatically
> promotes 2D-vectors to 3D-vectors with the z coordinate
> being 0 when needed).
Exactly.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" wrote:
> "Rune" wrote:
>
> > I originally did "UV-mapping" using matrixes to transform
> > textures for the individual triangles in a regular mesh,
> > but this required me to remove the mesh{} block around the
> > triangles, which of course was a great disadvantage, as
> > the triangles were then not optimised anymore.
>
> I don't understand what you mean...as far as I know, there
> are no problems using per-triangle textures in meshes.
In a mesh the textures cannot be translated differently for the different
triangles. So to do UV mapping I have to either
A) Remove the mesh{} block around the triangles.
B) Predeclare a unique texture for every single triangle.
Neither of those are attractive solutions.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a61d04f@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> In a mesh the textures cannot be translated differently for the different
> triangles. So to do UV mapping I have to either
>
> A) Remove the mesh{} block around the triangles.
>
> B) Predeclare a unique texture for every single triangle.
>
> Neither of those are attractive solutions.
How about:
C) Declare an array of textures. Use the textures in the array instead
of individual textures.
Or:
D) Write a macro that declares a texture (transformed to fit) and then
uses it in a triangle. This *should* work...in fact, I think it has been
done.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> In a mesh the textures cannot be translated differently for the different
> triangles. So to do UV mapping I have to either
> A) Remove the mesh{} block around the triangles.
> B) Predeclare a unique texture for every single triangle.
For B) I suppose you suggest something like:
#declare t1=texture{... transform ...}
#declare t2=texture{... transform ...}
...
mesh{
triangle{ ... texture{t1} } // or smooth triangle
triangle{ ... texture{t2} }
...
}
which of course requires a lot of memory to declare both texture variables
and textures in the mesh. But what about the following syntax ?
mesh{
#declare t=texture{ ... transform ...} // #local is more elegant ?
triangle{ ... texture{t} }
#declare t=texture{ ... transform ...}
triangle{ ... texture{t} }
...
}
which might be only a little longer to parse... maybe not.
In case you were talking about this syntax, please ignore my post !
BTW declaring UV vectors with XYZ should change the mesh2 syntax ;-)
*** Nicolas Calimet
*** http://pov4grasp.free.fr
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" wrote:
> "Rune" wrote:
> > In a mesh the textures cannot be translated differently for
> > the different triangles. So to do UV mapping I have to either
> >
> > A) Remove the mesh{} block around the triangles.
> >
> > B) Predeclare a unique texture for every single triangle.
> >
> > Neither of those are attractive solutions.
>
> How about:
> C) Declare an array of textures. Use the textures in the array
> instead of individual textures.
That's what I meant in B) of course. But it's still individual textures no
matter if they're in an array or not.
> D) Write a macro that declares a texture (transformed to fit)
> and then uses it in a triangle. This *should* work...in fact,
> I think it has been done.
Now I'm completely confused.
Maybe you've misunderstood me. Coding the POV-script that does the
UV-mapping is not the problem at all. I've already done that, and it works.
The problem is the amount of memory required: One unique texture for every
single triangle.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nicolas Calimet" wrote:
> For B) I suppose you suggest something like:
>
> #declare t1=texture{... transform ...}
> #declare t2=texture{... transform ...}
> ...
> mesh{
> triangle{ ... texture{t1} } // or smooth triangle
> triangle{ ... texture{t2} }
> ...
> }
Yes basically, although I'd use an array.
> which of course requires a lot of memory to declare both
> texture variables and textures in the mesh.
Well, not texture variables, just the textures.
> But what about the following syntax ?
>
> mesh{
> #declare t=texture{ ... transform ...} // #local is more elegant ?
> triangle{ ... texture{t} }
> #declare t=texture{ ... transform ...}
> triangle{ ... texture{t} }
> ...
> }
>
> which might be only a little longer to parse... maybe not.
Interesting. I wonder if it changes anything. I'll try it out. Thanks!
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a6227e7@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> > D) Write a macro that declares a texture (transformed to fit)
> > and then uses it in a triangle. This *should* work...in fact,
> > I think it has been done.
>
> Now I'm completely confused.
#macro UVTri(PointA, PointB, PointC, UVA, UVB, UVC, Texture)
#local Tex = texture {Texture ...put your UV mapping transformations
here...}
triangle {PointA, PointB, PointC texture {Tex}}
#end
> Maybe you've misunderstood me. Coding the POV-script that does the
> UV-mapping is not the problem at all. I've already done that, and it
> works.
> The problem is the amount of memory required: One unique texture for
> every single triangle.
You said the problem was that you couldn't use an ordinary mesh...not
that the number of textures used up too much memory. You implied that
you did it using a union of triangles instead of a mesh, and that that
was the problem...
If you simply can't handle that number of textures, then the only
solution is to wait for the UV mapping to be fixed to allow 3D vectors,
or do figure out a way to do something similar with 2D vectors.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > which of course requires a lot of memory to declare both
> > texture variables and textures in the mesh.
>
> Well, not texture variables, just the textures.
What do you mean ?
When you #declare/#local a variable e.g. as a texture, the
memory allocated for this variable is the size of the texture. And
when you create a texture calling that variable, like 'texture{t1}',
it copies the data contained in the variable. So in this case you
need twice as much as memory:
#declare t=texture{ ... } // requires the size of the texture
// t is not a pointer, but a texture
triangle{ ... texture{t} } // makes a copy of the texture t
Now, with the second syntax I mentionned in my previous post:
you will re-declare the same variable 't', so it requires the memory
for only one texture variable ('t') plus for textures of every triangle.
With an array of textures, you would need twice the memory required for
the textures of your triangles: variables + copies.
That's why re-declaring the same variable for the next textures
of your mesh will work. If POV was not working this way, only the last
triangle of your mesh would have the correct texture, and all the previous
triangles would refer to this last. Not the expected result ;-)
> > which might be only a little longer to parse... maybe not.
Finally this syntax (declare the texture before each triangle
with the same variable) *might be* a little bit longer to parse since
you have to allocate/desallocate memory each time you declare the
texture when parsing the mesh. But memory requirements should be
definitely less for numerous triangles than using a texture array !
*** Nicolas Calimet
*** http://pov4grasp.free.fr
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" wrote:
> #macro UVTri(PointA, PointB, PointC, UVA, UVB, UVC, Texture)
> #local Tex = texture {Texture ...put your UV mapping transformations
> here...}
> triangle {PointA, PointB, PointC texture {Tex}}
> #end
That's basically what I'm doing.
> You said the problem was that you couldn't use an ordinary mesh
> ...not that the number of textures used up too much memory.
I mentioned two solutions, A) and B). Only A) was about not using the mesh
block.
B) was about the number of textures, although I didn't directly say that the
memory was the problem.
> If you simply can't handle that number of textures, then
> the only solution is to wait for the UV mapping to be
> fixed to allow 3D vectors
How much memory do textures consume (not a very simple texture, but an
average complicated one)? Would it be a lot if say 3000 unique textures were
needed? (3000 triangles in a mesh is not even very much, is it?)
> or do figure out a way to do something similar with 2D vectors.
I don't think that's possible.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nicolas Calimet" wrote:
> When you #declare/#local a variable e.g. as a texture, the
> memory allocated for this variable is the size of the texture.
> And when you create a texture calling that variable, like
> 'texture{t1}', it copies the data contained in the variable.
OK, that's probably true, but if the whole texture is copied anyway, why
can't I translate the texture inside the mesh triangles? What difference
would it make?
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a633131@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> I mentioned two solutions, A) and B). Only A) was about not using the
> mesh block.
> B) was about the number of textures, although I didn't directly say
> that the memory was the problem.
I thought B was about the number of identifiers...a misunderstanding on
my part. Sorry.
> How much memory do textures consume (not a very simple texture, but
> an average complicated one)?
No idea...it depends on so many things. Image maps, the pattern used,
warps, the size and contents of any blend maps used, the amount of data
shared with something else (I'm pretty sure image file data is shared,
for example)...an "average complexity" texture could vary from bytes to
megabytes.
> Would it be a lot if say 3000 unique textures were needed? (3000
> triangles in a mesh is not even very much, is it?)
It would probably total to quite a lot, but I think textures also share
data, similar to the way meshes work. I'm not sure if it works with
different transformed textures, it may make a new copy in that case.
> > or do figure out a way to do something similar with 2D vectors.
>
> I don't think that's possible.
You could probably do something with the displace warp...working around
that limitation in this way would probably be harder than coding support
for 3D vectors, though.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> OK, that's probably true, but if the whole texture is copied anyway, why
> can't I translate the texture inside the mesh triangles? What difference
> would it make?
Could you post in here a small script that shows your problem with
translate in this case ? (and maybe pics in p.b.i)
Normally you should be able to do any transform of your textures
inside the triangles. The TRIMAP.MCR macros from Chris Colefax do that all
the time. Chris Huff in this thread gave the idea about how it works, and
you know it for sure.
But if the problem is real, it reminds me of a discussion I had in
this group with Nathan several months ago about mesh2 and interpolated textures
inside triangles - as for different colors per vertex that are blended together.
Basically mesh2 is a mesh and textures are handled the same way. I think you
should not have problem to translate textures in your triangles. Please send
some code to show that I'm wrong !
*** Nicolas Calimet
*** http://pov4grasp.free.fr
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nicolas Calimet" wrote:
> Normally you should be able to do any transform of your textures
> inside the triangles. I think you should not have problem to
> translate textures in your triangles. Please send some code to
> show that I'm wrong !
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?
Also notice that when the mesh{} block is removed, it works fine:
#declare Tex = texture {pigment {color rgb 1}}
triangle {x, y, z texture {Tex translate x}}
It's only for optimized mesh triangles it doesn't 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a636876@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> 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?
It is probably a simple limitation of the syntax that nobody has fixed
yet...it should be quite possible to fix, and seems to be a rather
stupid limitation. The same goes for the inability to transform
individual triangles...they weren't expected to be hand-written, so
nobody ever thought about it.
It's on my list of things to look at, but there probably won't be a
fixed version of MegaPOV for a while (unless these make it into POV 3.5
as bug fixes). I will make sure the POV Team knows about it.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" <chr### [at] maccom> wrote...
>
> It would probably total to quite a lot, but I think textures also share
> data, similar to the way meshes work. I'm not sure if it works with
> different transformed textures, it may make a new copy in that case.
Actually, textures share very little data. This is done primarily for speed
reasons. Only image data is shared, AFIAK.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <run### [at] inamecom> 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
|
|
| |
| |
|
|
|
|
| |
|
|
