Re: [Pipmak-Users] Patch rotation proposal (was: Autocubic: my reply to C.Walther)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello Andrea, I've finally gotten around to have a look at your=20
proposal. Sorry for the delay, I've been busy with other stuff.

> Using normalized coordinates, the method that could permit to place a p=
atch
> in the 3D space would be something like:
>=20
>   patch {
>     nx=3Dnx
>     ny=3Dny
>     nz=3Dnz
>     nw=3Dnw
>     nh=3Dnh
>     thetax=3Dtx
>     thetaz=3Dtz
>     angle=3Dangle
>     image=3Dimage
>     [visible=3Dvisible]
>     ....
>     }

OK, sounds good.

> these angles are expressed in radiants

I'd rather specify angles in degrees, because that's the way it's done=20
everywhere else in Pipmak, and I guess it's what non-scientists are more =

familiar with. Any objection?

> so if nx0,ny0,nz0 is the point of the upper-left corner of the patch
> and nx1,ny1,nz1 is the point of lower-right corner of the patch:
>=20
> nx1=3Dnx0+nw*cos(thetaz)
> ny1=3Dny0+nw*sin(thetaz)-nh*sin(thetax)
> nz1=3Dnz0-nh*cos(thetax)

Are you sure about this? Unless I made a mistake, I think there's=20
something wrong. If you insert nw =3D nh =3D 1 and thetax =3D thetaz =3D =
pi/2,=20
you get (nx1, ny1, nz1) =3D (nx0, ny0, nz0), i.e. the patch is squished t=
o=20
zero length along its diagonal.

> some example:
> =20
> patch {
>        nx=3D-0.5,ny=3D0.5,nz=3D0.5,
>        nw=3D1,nh=3D1,
>        thetax=3D0,thetaz=3D0,
>        image=3Df.png
>       }
>=20
>   this put an image that fully cover face1
>   notice that nw=3D1 and nh=3D1 stretch the image to full cover the cub=
e face
>   nw=3D0.5 and nh=3D0.5 will put an image that cover just one quadrant =
of the face. =20
>=20
>   the lower-right corner is placed on nx=3D0.5,ny=3D0.5,nz=3D-0.5
>=20
> patch {
>        nx=3D0.5,ny=3D0.5,nz=3D-0.5,
>        nw=3D1,nh=3D1,
>        thetax=3D0,thetaz=3D0,
>        angle=3Dpi,
>        image=3Df.png
>       }
>=20
>   this put the same image turned upside down=20
>   notice that the upper-left corner of the patch is placed
>   on the lower-right corner of the face1=20

This doesn't match with how you described the axis directions before.=20
 From this example, I'd conclude x =3D east, y =3D north, z =3D up (x and=
 y=20
swapped).

> patch {
>        nx=3D-0.5,ny=3D1,nz=3D0.5,
>        nw=3D1,nh=3D1,
>        thetax=3D0,
>        thetaz=3D0,
>        image=3Df.png
>       }
>=20
>   this put an image centered in the middle of the face1
>   which is the projection of a square parallel to face1 but double dist=
ant.

OK.

> patch {
>        nx=3D-0.5,ny=3D-0.5,nz=3D0.5,
>        nw=3D1,nh=3D1,
>        thetax=3D0,thetaz=3Dpi/2,
>        image=3Df.png
>       }
>=20
>   this put an image that fully cover the face6=20

Can't follow this - if the axes are the same as in the previous examples =

(or even your original description), and the patch is rotated about the=20
point (nx, ny, nz), I'd say it now lies in the plane of face 3, 4, or 5=20
(depending on the definition of thetaz), not on face 6. If the z axis=20
now points down, OK (and then thetaz seems to describe a rotation around =

the -x axis).

In short, because of these contradictions, I'm unable to conclude how=20
exactly you define thetax and thetaz. Therefore, I'm going to describe=20
my own version of what I think you have in mind:

First, let me make some of the arbitrary choices you made differently,=20
in order to better match what's done internally (if you think that your=20
choices were not arbitrary, but have a reason behind them, please say so)=
:

- For normalizing the coordinates, I chose k =3D 2, not k =3D 1, i.e. the=
=20
cube faces are at +-1 (not +- 0.5).

- Coordinate axes:
   x in direction of face 2 (east), away from face 4
   y in direction of face 5 (up), away from face 6
   z in direction of face 3 (south), away from face 1

How the patch is rotated:

- The upper left corner of the patch is located at (nx, ny, nz).

- The patch starts out oriented parallel to face 1, with its upper right =

corner in direction +x and lower left corner in direction -y from the=20
upper left corner (nx, ny, nz). The "inward-pointing" normal of the=20
patch points in direction +z.

- First, it is rotated by <thetax> around its top edge (oriented=20
rightward, i.e. positive angles move the center of the patch in=20
direction -z).

- Then, it is rotated by <thetay> around its (already rotated) left edge =

(oriented upward, i.e. positive angles move the center of the patch in=20
opposite direction to its normal).

- Lastly, it is rotated by <angle> around its normal at the top left corn=
er.

Reproducing your examples (and a few more) with this:

- patch that covers face 1:

patch {
	nx =3D -1, ny =3D 1, nz =3D -1,
	nw =3D 2, nh =3D 2,
	thetax =3D 0, thetay =3D 0, angle =3D 0,
	...
}

- patch that covers face 1, upside down:

patch {
	nx =3D 1, ny =3D -1, nz =3D -1,
	nw =3D 2, nh =3D 2,
	thetax =3D 0, thetay =3D 0, angle =3D 180,
	...
}

- patch that covers face 6, in the "natural" orientation of this face:

patch {
	nx =3D -1, ny =3D -1, nz =3D -1,
	nw =3D 2, nh =3D 2,
	thetax =3D -90, thetay =3D 0, angle =3D 0,
	...
}

- patch that lies in the plane of face 6, but moved northwards so that=20
it appears as a trapezium at the bottom of face 1:

patch {
	nx =3D -1, ny =3D -1, nz =3D -3,
	nw =3D 2, nh =3D 2,
	thetax =3D -90, thetay =3D 0, angle =3D 0,
	...
}

- patch that covers face 4 (in its natural orientation):

patch {
	nx =3D -1, ny =3D 1, nz =3D 1,
	nw =3D 2, nh =3D 2,
	thetax =3D 0, thetay =3D 90, angle =3D 0,
	...
}

- two versions of a patch that covers face 2, rotated 90=B0 clockwise fro=
m=20
its natural orientation:

patch {
	nx =3D 1, ny =3D 1, nz =3D 1,
	nw =3D 2, nh =3D 2,
	thetax =3D 90, thetay =3D -90, angle =3D 0,
	...
}
patch {
	nx =3D 1, ny =3D 1, nz =3D 1,
	nw =3D 2, nh =3D 2,
	thetax =3D 0, thetay =3D -90, angle =3D -90,
	...
}

Is this about what you had in mind?

> if you want rotate a patch placed on face1 respect his center,
> I have to rotate and translate the patch
>=20
> patch:moveto(0,0,-nh,0,0,pi/2).

Are you sure it's that easy? In fact that's the main point I'm unsure=20
about how to solve in a user-friendly way.

In the system I proposed above, rotating a patch on face 1 whose=20
unrotated top left corner lies at (nx, ny, -1) by angle theta=20
(counterclockwise) around its center would look like

patch:moveto(nx + nw/2 - nw/2*cos(theta) - nh/2*sin(theta),
	ny - nh/2 - nw/2*sin(theta) + nh/2*cos(theta),
	-1,
	0, 0, theta).

Substituting nx =3D ny =3D 0 and theta =3D 90=B0 as in your example, that=
's still

patch:moveto(nw/2 - nh/2, -nh/2 - nw/2, -1, 0, 0, 90).

Somehow I'm not quite happy with this.

> I'm little perplexed about
> normalization of w and h, but we could use original size (in pixels) of=

> the patch if we don't know the dimension in pixel of the cube
> (which could be whichever value because it's a projection)

I think offering an "nw" and "nh" property for normalized width/height,=20
as you did, is a good idea. After all, you don't need to use it, you can =

still specify width and height in pixels using the existing "w" and "h"=20
properties if you want. (The only question is, how big is a pixel in=20
normalized units if the cube faces have different pixel sizes? Maybe=20
just take the value from face 1.)

Another question that we haven't touched yet is, what do we do on=20
slides? At least the "angle" property should work there too. Using=20
normalized coordinates is probably not that good an idea, as they are=20
non-uniform if the slide is not a square.

Thanks for your input!

  -Christian