![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a6227e7@news.povray.org>, "Rune" <run### [at] iname com>
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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> > 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a633131@news.povray.org>, "Rune" <run### [at] iname com>
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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a636876@news.povray.org>, "Rune" <run### [at] iname com>
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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Chris Huff" <chr### [at] mac com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |