Hi!
I just downloaded beta 8, and wanted to try out some scenes I did in beta 1.
One of the things I tried out then was uv_mapping, but it behaves completely
different now.. On the image you can see what I mean.
The first box has no uv_mapping.
The second box is how the uv_mapping works now.
The third box is how uv_mapping worked before. (I faked it with three image
maps).
Why has this changed? If I understand the docs right it's supposed to behave
like box #3 (and it did before :)

The source code:
box {-1,1 pigment {image_map {png "test.png"}}} // box #1
box {-1,1 pigment {uv_mapping image_map {png "test.png"}}} // box #2

I haven't read the news groups much lately, my humble apologies if this
question already has been asked and answered..
Did I post to the right group, or is povray.beta-test.binaries the place?

-Peter

Post a reply to this message

Attachments:
Download 'uv_mapping.jpg' (18 KB)

Preview of image 'uv_mapping.jpg'

povray.beta-test.binaries is the proper place.  Nice presentation picture.
Plenty has changed since then, and uv mapping is one of those things.  Have
a read of the revision.txt file in the POV-Ray folder.
Change 1187 and 1123 are two of the things relating to it I see there,
number 1123 is about bicubic patches though.
--
text{ttf"arial","bob h",.1,0pigment{rgb 9}translate<-1,-.2,3>}


"Peter Hertel" <NOS### [at] hertelno> wrote in message
news:3c0f8f2e@news.povray.org...
> I just downloaded beta 8, and wanted to try out some scenes I did in beta
1.
> One of the things I tried out then was uv_mapping, but it behaves
completely
> different now.. On the image you can see what I mean.
>
> I haven't read the news groups much lately, my humble apologies if this
> question already has been asked and answered..
> Did I post to the right group, or is povray.beta-test.binaries the place?

Post a reply to this message

Hi Peter Hertel, you recently wrote in povray.binaries.images:

> I just downloaded beta 8, and wanted to try out some scenes I did in beta 1.
> One of the things I tried out then was uv_mapping, but it behaves completely
> different now.. On the image you can see what I mean.
Yes, the uv mapping for boxes was changed to use environment cube
mapping the way that most 3D packages use it. Doing it this way allows
you to map different parts onto each face, whereas the previous
version placed the same image on all six faces. Now it projects the
image like this (ASCII monospaced art alert!):

 1   . . . +-----+ . . . . . .
V    .  X  ^  4  |     X     .
     .     z     |           .
 .6  +-----+--x>-#--z>-+-<x--+
     |     ^     |     |     |
     |  1  y  5  |  2  |  6  |
     |     |     |     |     |
 .3  +-----O--x>-+-----+-----+
     .     |     |           .
     .  X  |  3  |     X     .
 0   . . . +-----+ . . . . . .
 
     0    .25    .5   .75    1
                          U

The places marked X are ignored.

The effect is that this will allow a seperate part of an
imagemap on each face instead of placing the entire imagemap on each
face.

Regards,

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

Hi
Thanks for your explanation!
What would a image_map look like if you wanted to place the same image on
all six faces? Frankly, I prefer the old method, maybe because I don't
understand the new mapping system completely =)
What about a way to select which method you want to use?

-Peter

> Yes, the uv mapping for boxes was changed to use environment cube
> mapping the way that most 3D packages use it. Doing it this way allows
> you to map different parts onto each face, whereas the previous
> version placed the same image on all six faces. Now it projects the
> image like this (ASCII monospaced art alert!):

Post a reply to this message

Hi Peter Hertel, you recently wrote in povray.binaries.images:

> What would a image_map look like if you wanted to place the same image on
> all six faces? 
You would make an imagemap and place the image six times on this
image. The numbers 1-6 in my drawing represent the cubes faces.

> Frankly, I prefer the old method, maybe because I don't
> understand the new mapping system completely =)
Ahhh, afraid of change, are we :-)

The old system did not allow you to put different images on each face
of the cube. The new one does.

Regards,

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

"Lutz Kretzschmar" <lut### [at] stmuccom> wrote...
>
> The old system did not allow you to put different images on each face
> of the cube. The new one does.

Now, that can't be true.  The whole purpose of the original method was to
allow separate images on each face of the cube.  Each face mapped to a 1x1
square of texture space.  So the entire texture space was 4x3 pov units.
The new method uses a total texture space of 1x1 (1/4 x 1/3 for each face)
instead of a 4x3 rectangle.

-Nathan

Post a reply to this message

Hi Nathan Kopp, you recently wrote in povray.binaries.images:

> "Lutz Kretzschmar" <lut### [at] stmuccom> wrote...
> >
> > The old system did not allow you to put different images on each face
> > of the cube. The new one does.
> 
> Now, that can't be true.  
Well, it was :-) Try it.

> Each face mapped to a 1x1 square of texture space.  So the entire 
> texture space was 4x3 pov units.
Yes, and then when reading the pixels from the imagemap it was read
modulo 1, resulting in a repetition on all six faces.


- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

"Lutz Kretzschmar" <lut### [at] stmuccom> wrote...
> Hi Nathan Kopp, you recently wrote in povray.binaries.images:
>
> > "Lutz Kretzschmar" <lut### [at] stmuccom> wrote...
> > >
> > > The old system did not allow you to put different images on each face
> > > of the cube. The new one does.
> >
> > Now, that can't be true.
> Well, it was :-) Try it.
>
> > Each face mapped to a 1x1 square of texture space.  So the entire
> > texture space was 4x3 pov units.
> Yes, and then when reading the pixels from the imagemap it was read
> modulo 1, resulting in a repetition on all six faces.

So... you would simply just need to scale the image to 4x3.  Ever since
UV-POV, uv textures have worked in the z-plane of texture space, not image
space.  Texture space is infinite (well, within the limits of floating point
math)... it is not clipped to [0..1].  So, it would be perfectly fine to
scale your image map to 4x3 and then apply it as a uv-mapped texture.

-Nathan

Post a reply to this message

Hi Nathan Kopp, you recently wrote in povray.binaries.images:

> So... you would simply just need to scale the image to 4x3.  
Whoops, looks like I spoke too soon. I stand corrected. It did indeed
work if I put 
  
    scale <4 , -3, 1 >
    translate <-1, 2 , 0>

in the material block (the signs may be due to right-handedness :-). 

So, the question is, do we revert the change or leave it. I guess it
comes down to a question of what the default UV mapping should be. 
If we have legacy scenes, I guess the previous version would be
better.

Since I've always expected UV coodinates in the 0..1 range I assumed
that my version was the desired mapping, but then I think right-handed
coordinates are easier to understand :-) (please, no flames, it was
meant in jest).

Regards,

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

"Lutz Kretzschmar" <lut### [at] stmuccom> wrote...
> So, the question is, do we revert the change or leave it. I guess it
> comes down to a question of what the default UV mapping should be.
> If we have legacy scenes, I guess the previous version would be
> better.
>
> Since I've always expected UV coodinates in the 0..1 range I assumed
> that my version was the desired mapping, but then I think right-handed
> coordinates are easier to understand :-) (please, no flames, it was
> meant in jest).

It really doesn't matter to me.  I think that the new 0..1 range is more
consistent with the rest of uv mapping in POV.  Regarding handedness, again
we should probably go for consistency with the rest of POV.

Different users will want different things.  Fortunately, they can easily
scale & translate their image however they want to and it will work.  I
really don't think backwards compatibility is a really big issue here, since
we won't have many legacy scenes, and MegaPov was an unofficial version.
Therefore, I would lean towards the mapping is most consistent with the rest
of POV, and put in the FAQ a few transformations (like what you wrote in
your message) that will convert MegaPov scenes to work with POV 3.5's
mapping.

-Nathan

Post a reply to this message