> 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