Thread: "3D-only rotations in MHT633"

From: Roice Nelson <roice3@gmail.com>
Date: Tue, 2 Nov 2010 09:00:02 -0500
Subject: 3D-only rotations in MHT633



--001636c5b31f58b0cb049412574f
Content-Type: text/plain; charset=ISO-8859-1

I wanted to chime in that I liked Melinda's thoughts on this.

This email is going to make the argument that the Poincare ball model would
be the right place to offer 3D-only rotations. One would do the projection
to the ball model, then allow the user to manipulate that post-projection as
if it was a 3d object. Of course, you could also offer enhanced controls to
do pre-projection H3 movements, leading to all the fun warping. Here is my
reasoning for liking the ball model for this...

First of all, it is the closest H3 analogue we have to the projection that
MC4D uses.


MC4D is close to a stereographic projection of S3 objects. The vertices
live in S3 and are stereographically projected. The edges are then
connected up with straight Euclidean lines, living only slightly outside of
S3 (in R4). The ball model of H3 is also a stereographic projection of a
constant radius surface (see this
page),
so it is an analogous situation. One could even similarly connect up the
stereographically projected vertices with straight lines, and I wonder what
Euclidean dimensional space that original object might live in, if any...not
R4!


But analogy closeness aside, the crux of why I think 3D rotations would fit
in quite naturally with a ball model representation is the following:
Consider that in the ball model, spheres centered at the origin are
equidistant from the origin in both H3 space and projected space. So for a
puzzle representation with the POV (lookat position) always at the origin, *a
3D rotation is also an H3 rotation*. Things work well in MC4D for the same
reason, because the 3D rotations are also R4 rotations.

When this is not the case, I can see why offering 3D-only rotations would be
strange (either in the current "in space" view of MHT633 or if there was a
similar "S3 in space" view for MC4D). Due to the 3D rotations not also
being an H3 rotation, the user would be forced to mentally track two
different sets of vectors, the 3D camera position and the H3 camera
position. Here's an example of what I mean... Say you're at some location,
then you 3D rotate around 180 degrees, then you want to do another H3
movement, moving forward for example. It would be awkward to do so, unless
you snapped back to a canonical 3D position first (your original location
with no rotation). If you didn't snap back, the forward H3
movement would make you feel like you were moving backwards, as all the
pieces rushed away from you. It seems like it could be easy to get lost.

A final benefit of doing this with the ball model is that it is more overtly
a model, which also leads to a naturalness in zooming around and studying it
in the way Melinda describes. Hope I'm not being too off-topic or
persistent with the ball model focus (though I can say I would be happy to
help on such a feature, if Andrey ever desired that)...

All the best,
Roice



On Thu, Oct 28, 2010 at 6:50 PM, Melinda Green wrote:


> I am starting to better understand. I don't doubt that you have chosen
> your viewing controls to be the best analogues to the MC4D controls in
> flat space. They may also be ideal when attempting a solution. Still, I
> find myself frustrated with the interaction so I will describe my
> expectation and maybe you can convince me that my expectations need to
> change.
>
> It is immediately clear that there is a 3D space behind the computer
> screen and that the controls affect viewing parameters in some model
> space which are then transformed into the viewing space. My problem is
> that I constantly want to understand the geometry that I see in the
> simple view space but I have no ability to examine it directly. I want
> to be able to left-drag to tumble the current 3D geometry around and
> view it from all sides in view space. I know that allowing me to see
> "behind the curtain", that I may well see jagged boundaries where small
> cells are being culled, but that's fine with me. I want to be fully in
> charge of what happens in my 3D viewing space. To my eye, your left-drag
> is the equivalent to MC4D's controls for the 4D view (shift-drag)
> controls that map from model space to view space, even if your model
> space is a 3D hyperbolic one.
>
> Here is a simple analogy: I've seen many viewers for star charts and
> other full-sky astronomical images such as the cosmic microwave
> background. They tend to use a fish-eye panorama display where the
> user's viewpoint is at the center of the Earth because that makes the
> most logical or realistic sense. The user is then allowed to drag the
> sky around or use left/right/up/down/zoom controls to change their
> viewing parameters. Unfortunately I find myself frustrated with those
> views just like I feel with this one. I much prefer to see star maps and
> CMB images mapped onto a sphere that I can view from the outside. Even
> if those viewpoints don't relate to any physical orientation, they just
> make more sense to me. I can easily understand that I really live at the
> center of those spheres just as I understand that the central face in a
> MC4D view is the furthest from me in 4-space.
>
> I'm not asking that you change your default left-drag behavior because
> I'm sure that I'll never attempt a solution, but I suspect that other
> users will find it very helpful and comforting to have a view control
> like I'm describing. I bet it would also be a really helpful debugging
> aid for you when work on your face culling code.
>
>

--001636c5b31f58b0cb049412574f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I wanted to chime in that I liked Melinda's thoughts on this.=A0div>

This email is going to make the argument that the P=
oincare ball model=A0would be=A0the right place to offer 3D-only rotations.=
=A0 One would do the projection to the ball model, then allow the user to m=
anipulate that post-projection as if it was a 3d object.=A0 Of course, you =
could also offer enhanced controls to do pre-projection H3 movements, leadi=
ng to all the fun warping.=A0 Here is my reasoning for liking the ball mode=
l for this...




=A0
First of all, it is the closest H3 analogue we have=A0to the =
projection that MC4D uses.=A0


<digression as to why>

MC4D is close to a stereographic projection of S3 objects.=A0 The vert=
ices live in S3 and are stereographically projected. =A0The edges are then =
connected up with straight Euclidean lines, living=A0only slightly outside =
of S3 (in R4).=A0 The ball model of H3=A0is also a stereographic projection=
of a constant radius surface=A0(see g/HyperbolicGames/" target=3D"_blank">this page), so it=A0is an analogo=
us situation.=A0 One could even similarly connect up the stereographically =
projected vertices with straight lines, and I wonder what Euclidean dimensi=
onal space that original object might live in, if any...not R4!=A0



</digression as to why>

But analogy closeness aside, the crux of why I think 3D rotations woul=
d fit in quite naturally with a ball model representation is the following:=
=A0 Consider that in the ball model, spheres centered at the origin are equ=
idistant from the origin in both H3 space and projected space.=A0 So for a =
puzzle representation with the POV (lookat position) always at the origin, =
a 3D rotation is also an H3 rotation.=A0 Things work well =
in MC4D for the same reason, because the 3D rotations are also R4 rotations=
.



=A0

When this is not the case, I can see why offering 3D-only rotations wo=
uld be strange (either in the current "in space" view of MHT633 o=
r if there was a similar "S3 in space" view for MC4D).=A0 Due to =
the 3D rotations not also being an H3=A0rotation, the user would be forced =
to mentally track two different sets of vectors, the 3D camera position and=
the H3 camera position.=A0 Here's an example of what I mean...=A0 Say =
you're at some location, then=A0you 3D rotate around 180 degrees, then =
you want to do another H3 movement, moving forward for example.=A0 It=A0wou=
ld be awkward=A0to do so,=A0unless you=A0snapped back to a canonical 3D pos=
ition first (your original location with no rotation).=A0 If you didn't=
snap back,=A0the forward H3 movement=A0would=A0make you feel like you were=
moving backwards, as all the pieces rushed away from you.=A0=A0=A0It seems=
like=A0it could be easy to get lost.



=A0

A final benefit of doing this with the ball model is that it is more o=
vertly a model, which also leads to a naturalness in zooming around and stu=
dying it in the way Melinda describes.=A0 Hope I'm not being=A0too off-=
topic or persistent with the ball model focus (though I can say I would be =
happy to help on such a feature, if Andrey ever desired that)...



=A0

All the best,

Roice

=A0


=A0

=A0

On Thu, Oct 28, 2010 at 6:50 PM, Melinda Green <=
span dir=3D"ltr"><_blank">melinda@superliminal.com> wrote:=20
=A0

dding-left:1ex" class=3D"gmail_quote">

I am starting to better understand. I don't doubt that you have ch=
osen

your viewing controls to be the best analogues to the MC4D controls in=

flat space. They may also be ideal when attempting a solution. Still, =
I

find myself frustrated with the interaction so I will describe my>
expectation and maybe you can convince me that my expectations need to=

change.

=A0

It is immediately clear that there is a 3D space behind the computerdiv>
screen and that the controls affect viewing parameters in some modeldiv>
space which are then transformed into the viewing space. My problem is=

that I constantly want to understand the geometry that I see in theiv>
simple view space but I have no ability to examine it directly. I want=

to be able to left-drag to tumble the current 3D geometry around anddiv>
view it from all sides in view space. I know that allowing me to seediv>
"behind the curtain", that I may well see jagged boundaries =
where small

cells are being culled, but that's fine with me. I want to be full=
y in

charge of what happens in my 3D viewing space. To my eye, your left-dr=
ag

is the equivalent to MC4D's controls for the 4D view (shift-drag)<=
/div>
controls that map from model space to view space, even if your modeldiv>
space is a 3D hyperbolic one.

=A0

Here is a simple analogy: I've seen many viewers for star charts a=
nd

other full-sky astronomical images such as the cosmic microwave

background. They tend to use a fish-eye panorama display where thev>
user's viewpoint is at the center of the Earth because that makes =
the

most logical or realistic sense. The user is then allowed to drag the<=
/div>
sky around or use left/right/up/down/zoom controls to change theirv>
viewing parameters. Unfortunately I find myself frustrated with those<=
/div>
views just like I feel with this one. I much prefer to see star maps a=
nd

CMB images mapped onto a sphere that I can view from the outside. Even=

if those viewpoints don't relate to any physical orientation, they=
just

make more sense to me. I can easily understand that I really live at t=
he

center of those spheres just as I understand that the central face in =
a

MC4D view is the furthest from me in 4-space.

=A0

I'm not asking that you change your default left-drag behavior bec=
ause

I'm sure that I'll never attempt a solution, but I suspect tha=
t other

users will find it very helpful and comforting to have a view control<=
/div>
like I'm describing. I bet it would also be a really helpful debug=
ging

aid for you when work on your face culling code.

=A0


--001636c5b31f58b0cb049412574f--




From: "Andrey" <andreyastrelin@yahoo.com>
Date: Tue, 02 Nov 2010 23:15:34 -0000
Subject: Re: 3D-only rotations in MHT633



Roice,
I'm not sure what you mean by "3D-only rotations". I see that navigation =
in S3 (in MC4D) and in H3 uses only one camera with 6 position/orientation =
parameters (+ some zoom parameters) like normal 3D navigation. For example,=
in MC4D you can't freely navigate in projection space (look from center ou=
tside etc.) like you can, say, in MC7D.
In MC4D we talk about "3D projection" because there are problems with rea=
l view in sphere: all rays from camera meet in opposite point of sphere and=
you can't see farther than that point. It can be solved by a nonrealistic =
optics: say, rays are going by circles tangent to camera axis - or by inter=
mediate projection, as done in MC4D.
Yes, it's easy to convert view in MHT from real-view to Poincare ball (ce=
ntered in POV). The only problem will be with the situation when camera is =
outside of the space. In that case we'll need to recalculate "shift-left dr=
ag" operation (twist of camera or x-y pan): it will become sliding along so=
me straight line. But I think that it's not very difficult.
I'll think about introducing of this view model in the program.

Andrey

--- In 4D_Cubing@yahoogroups.com, Roice Nelson wrote:
>
> I wanted to chime in that I liked Melinda's thoughts on this.
>=20
> This email is going to make the argument that the Poincare ball model wou=
ld
> be the right place to offer 3D-only rotations. One would do the projecti=
on
> to the ball model, then allow the user to manipulate that post-projection=
as
> if it was a 3d object. Of course, you could also offer enhanced controls=
to
> do pre-projection H3 movements, leading to all the fun warping. Here is =
my
> reasoning for liking the ball model for this...
>=20
> First of all, it is the closest H3 analogue we have to the projection tha=
t
> MC4D uses.
>=20
>
> MC4D is close to a stereographic projection of S3 objects. The vertices
> live in S3 and are stereographically projected. The edges are then
> connected up with straight Euclidean lines, living only slightly outside =
of
> S3 (in R4). The ball model of H3 is also a stereographic projection of a
> constant radius surface (see this
> page),
> so it is an analogous situation. One could even similarly connect up the
> stereographically projected vertices with straight lines, and I wonder wh=
at
> Euclidean dimensional space that original object might live in, if any...=
not
> R4!
>

>=20
> But analogy closeness aside, the crux of why I think 3D rotations would f=
it
> in quite naturally with a ball model representation is the following:
> Consider that in the ball model, spheres centered at the origin are
> equidistant from the origin in both H3 space and projected space. So for=
a
> puzzle representation with the POV (lookat position) always at the origin=
, *a
> 3D rotation is also an H3 rotation*. Things work well in MC4D for the sa=
me
> reason, because the 3D rotations are also R4 rotations.
>=20
> When this is not the case, I can see why offering 3D-only rotations would=
be
> strange (either in the current "in space" view of MHT633 or if there was =
a
> similar "S3 in space" view for MC4D). Due to the 3D rotations not also
> being an H3 rotation, the user would be forced to mentally track two
> different sets of vectors, the 3D camera position and the H3 camera
> position. Here's an example of what I mean... Say you're at some locati=
on,
> then you 3D rotate around 180 degrees, then you want to do another H3
> movement, moving forward for example. It would be awkward to do so, unle=
ss
> you snapped back to a canonical 3D position first (your original location
> with no rotation). If you didn't snap back, the forward H3
> movement would make you feel like you were moving backwards, as all the
> pieces rushed away from you. It seems like it could be easy to get lost=
.
>=20
> A final benefit of doing this with the ball model is that it is more over=
tly
> a model, which also leads to a naturalness in zooming around and studying=
it
> in the way Melinda describes. Hope I'm not being too off-topic or
> persistent with the ball model focus (though I can say I would be happy t=
o
> help on such a feature, if Andrey ever desired that)...
>=20
> All the best,
> Roice
>=20
>=20




From: Roice Nelson <roice3@gmail.com>
Date: Tue, 2 Nov 2010 19:14:41 -0500
Subject: Re: [MC4D] Re: 3D-only rotations in MHT633



--001485f772aa84d8c504941aedc9
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 2, 2010 at 6:15 PM, Andrey wrote:

> Roice,
> I'm not sure what you mean by "3D-only rotations". I see that navigation
> in S3 (in MC4D) and in H3 uses only one camera with 6 position/orientation
> parameters (+ some zoom parameters) like normal 3D navigation. For example,
> in MC4D you can't freely navigate in projection space (look from center
> outside etc.) like you can, say, in MC7D.
>

Sorry that wasn't clear. By "3D-only rotations", I meant rotations which
are done after the H3 -> R3 projection, not before it. They are Euclidean
3D rotations of the projected (3D) object, and are what Melinda was asking
for. These rotations would preserve the shape of 3D objects, unlike the
left-click dragging currently in MHT633. Does that help clarify?

If you implement the ball model with the POV at the origin, your left-click
dragging should automatically result in the types of rotations I was
intending to describe.


> In MC4D we talk about "3D projection" because there are problems with real
> view in sphere: all rays from camera meet in opposite point of sphere and
> you can't see farther than that point. It can be solved by a nonrealistic
> optics: say, rays are going by circles tangent to camera axis - or by
> intermediate projection, as done in MC4D.
>

I think an "in sphere" view could work well for the 3^4. The image of the
furthest cube would cover the entire background and would be "inverted".
Depending on face/sticker shrink values, you wouldn't be able to see past it
like you describe, but you could still see the entire puzzle and work with
it.


> Yes, it's easy to convert view in MHT from real-view to Poincare ball
> (centered in POV). The only problem will be with the situation when camera
> is outside of the space. In that case we'll need to recalculate "shift-left
> drag" operation (twist of camera or x-y pan): it will become sliding along
> some straight line. But I think that it's not very difficult.
>

Don's tessellation applet
had to deal with the
same problem of hyperbolic panning outside the model
boundary, so you might check out what he did there...

seeya,
Roice

--001485f772aa84d8c504941aedc9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

=A0

On Tue, Nov 2, 2010 at 6:15 PM, Andrey =3D"ltr"><andreyastrelin@yah=
oo.com
>
wrote:

; PADDING-LEFT: 1ex" class=3D"gmail_quote">Roice,
=A0I'm not sure wh=
at you mean by "3D-only rotations". I see that navigation in S3 (=
in MC4D) and in H3 uses only one camera with 6 position/orientation paramet=
ers (+ some zoom parameters) like normal 3D navigation. For example, in MC4=
D you can't freely navigate in projection space (look from center outsi=
de etc.) like you can, say, in MC7D.


=A0

=A0Sorry that wasn't clear.=A0 By "3D-only rotations", I=
meant rotations which are done after the H3 -> R3 projection, not befor=
e it.=A0 They are Euclidean 3D rotations of the=A0projected (3D) object, an=
d are what Melinda was asking for.=A0 These rotations would preserve the sh=
ape of 3D objects, unlike the left-click dragging currently in MHT633.=A0 D=
oes that help clarify?=20
=A0

If you implement the ball model with the POV at the origin, your left-=
click dragging=A0should automatically=A0result in the types of rotations I =
was intending to describe.

=A0

; PADDING-LEFT: 1ex" class=3D"gmail_quote">=A0In MC4D we talk about "3=
D projection" because there are problems with real view in sphere: all=
rays from camera meet in opposite point of sphere and you can't see fa=
rther than that point. It can be solved by a nonrealistic optics: say, rays=
are going by circles tangent to camera axis - or by intermediate projectio=
n, as done in MC4D.


=A0

I think an "in sphere" view could work well for the 3^4.=A0 =
The image of the furthest cube would cover the entire=A0background and woul=
d be "inverted".=A0 Depending on face/sticker shrink values, you =
wouldn't be able to see past it like you describe, but you could still =
see the entire puzzle and work with it.


=A0

; PADDING-LEFT: 1ex" class=3D"gmail_quote">=A0Yes, it's easy to convert=
view in MHT from real-view to Poincare ball (centered in POV). The only pr=
oblem will be with the situation when camera is outside of the space. In th=
at case we'll need to recalculate "shift-left drag" operation=
(twist of camera or x-y pan): it will become sliding along some straight l=
ine. But I think that it's not very difficult.


=A0

Don's te=
ssellation applet
had to deal with the same problem of hyperbolic panni=
ng outside the model boundary, so you might check out what he did there...<=
/div>

=A0

seeya,

Roice


--001485f772aa84d8c504941aedc9--




From: Roice Nelson <roice3@gmail.com>
Date: Tue, 2 Nov 2010 19:39:54 -0500
Subject: Re: [MC4D] Re: 3D-only rotations in MHT633



--0016368e240baec60404941b4735
Content-Type: text/plain; charset=ISO-8859-1

I realized that for a 3^4 "in sphere view", the 1C sticker would always
block seeing further than the location that is antipodal to the camera in
S3, regardless of shrink settings. So you could never see beyond that. You
potentially could see beyond the antipode for the 4^4 though, assuming the
camera is invisible anyway :) I still think an "in sphere" view might work
well and would be interesting to play with...

Roice

On Tue, Nov 2, 2010 at 7:14 PM, Roice Nelson wrote:

>
> On Tue, Nov 2, 2010 at 6:15 PM, Andrey wrote:
>
>> Roice,
>> I'm not sure what you mean by "3D-only rotations". I see that navigation
>> in S3 (in MC4D) and in H3 uses only one camera with 6 position/orientation
>> parameters (+ some zoom parameters) like normal 3D navigation. For example,
>> in MC4D you can't freely navigate in projection space (look from center
>> outside etc.) like you can, say, in MC7D.
>>
>
> Sorry that wasn't clear. By "3D-only rotations", I meant rotations which
> are done after the H3 -> R3 projection, not before it. They are Euclidean
> 3D rotations of the projected (3D) object, and are what Melinda was asking
> for. These rotations would preserve the shape of 3D objects, unlike the
> left-click dragging currently in MHT633. Does that help clarify?
>
> If you implement the ball model with the POV at the origin, your left-click
> dragging should automatically result in the types of rotations I was
> intending to describe.
>
>
>> In MC4D we talk about "3D projection" because there are problems with
>> real view in sphere: all rays from camera meet in opposite point of sphere
>> and you can't see farther than that point. It can be solved by a
>> nonrealistic optics: say, rays are going by circles tangent to camera axis -
>> or by intermediate projection, as done in MC4D.
>>
>
> I think an "in sphere" view could work well for the 3^4. The image of the
> furthest cube would cover the entire background and would be "inverted".
> Depending on face/sticker shrink values, you wouldn't be able to see past it
> like you describe, but you could still see the entire puzzle and work with
> it.
>
>
>> Yes, it's easy to convert view in MHT from real-view to Poincare ball
>> (centered in POV). The only problem will be with the situation when camera
>> is outside of the space. In that case we'll need to recalculate "shift-left
>> drag" operation (twist of camera or x-y pan): it will become sliding along
>> some straight line. But I think that it's not very difficult.
>>
>
> Don's tessellation applet had to deal with the same problem of hyperbolic panning outside the model
> boundary, so you might check out what he did there...
>
> seeya,
> Roice
>

--0016368e240baec60404941b4735
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I realized that for a 3^4 "in sphere view", the 1C sticker w=
ould always block seeing further than the location that is antipodal to the=
camera in S3, regardless of shrink settings.=A0 So you could never=A0see b=
eyond that.=A0 You potentially could see beyond the=A0antipode for the 4^4 =
though, assuming the camera is invisible anyway :)=A0 I still think an=A0&q=
uot;in sphere"=A0view might work well and would be interesting to play=
with...


=A0

Roice


On Tue, Nov 2, 2010 at 7:14 PM, Roice Nelson an dir=3D"ltr"><roice3@gmail.com=
> wrote:

; PADDING-LEFT: 1ex" class=3D"gmail_quote">
=A0


On Tue, Nov 2, 2010 at 6:15 PM, Andrey =
<andreyast=
relin@yahoo.com
>
wrote:

; PADDING-LEFT: 1ex" class=3D"gmail_quote">Roice,
=A0I'm not sure wh=
at you mean by "3D-only rotations". I see that navigation in S3 (=
in MC4D) and in H3 uses only one camera with 6 position/orientation paramet=
ers (+ some zoom parameters) like normal 3D navigation. For example, in MC4=
D you can't freely navigate in projection space (look from center outsi=
de etc.) like you can, say, in MC7D.


=A0

=A0Sorry that wasn't clear.=A0 By "3D-only rotations", I=
meant rotations which are done after the H3 -> R3 projection, not befor=
e it.=A0 They are Euclidean 3D rotations of the=A0projected (3D) object, an=
d are what Melinda was asking for.=A0 These rotations would preserve the sh=
ape of 3D objects, unlike the left-click dragging currently in MHT633.=A0 D=
oes that help clarify?=20
=A0

If you implement the ball model with the POV at the origin, your left-=
click dragging=A0should automatically=A0result in the types of rotations I =
was intending to describe.


=A0

; PADDING-LEFT: 1ex" class=3D"gmail_quote">=A0In MC4D we talk about "3=
D projection" because there are problems with real view in sphere: all=
rays from camera meet in opposite point of sphere and you can't see fa=
rther than that point. It can be solved by a nonrealistic optics: say, rays=
are going by circles tangent to camera axis - or by intermediate projectio=
n, as done in MC4D.


=A0

I think an "in sphere" view could work well for the 3^4.=A0 =
The image of the furthest cube would cover the entire=A0background and woul=
d be "inverted".=A0 Depending on face/sticker shrink values, you =
wouldn't be able to see past it like you describe, but you could still =
see the entire puzzle and work with it.



=A0

; PADDING-LEFT: 1ex" class=3D"gmail_quote">=A0Yes, it's easy to convert=
view in MHT from real-view to Poincare ball (centered in POV). The only pr=
oblem will be with the situation when camera is outside of the space. In th=
at case we'll need to recalculate "shift-left drag" operation=
(twist of camera or x-y pan): it will become sliding along some straight l=
ine. But I think that it's not very difficult.


=A0

Don's rget=3D"_blank">tessellation applet had to deal with the same problem o=
f hyperbolic panning outside the model boundary, so you might check out wha=
t he did there...


=A0

seeya,

Roice



--0016368e240baec60404941b4735--




From: Roice Nelson <roice3@gmail.com>
Date: Tue, 2 Nov 2010 20:11:39 -0500
Subject: Re: [MC4D] Re: 3D-only rotations in MHT633



--001636c5b31f35f2cc04941bb999
Content-Type: text/plain; charset=ISO-8859-1

Argh! Scratch the "assuming the camera is invisible" comment. I was
letting my rays get ahead of themselves and wrap back around to the viewer.
And profuse apologies for the extra spam.

To try to make this correction a useful post, let me mention that this
particular lapse came from me recalling portions of a very nice discussion
of this exact topic in Thurston's "Three-Dimensional Geometry and Topology".
See "Example 1.4.2 (the three sphere from the inside)", starting on page
32. The short two page discussion is visible in google
books,
and very readable :) I'll make myself scarce now...

Cheers,
Roice


On Tue, Nov 2, 2010 at 7:39 PM, Roice Nelson wrote:

> I realized that for a 3^4 "in sphere view", the 1C sticker would always
> block seeing further than the location that is antipodal to the camera in
> S3, regardless of shrink settings. So you could never see beyond that. You
> potentially could see beyond the antipode for the 4^4 though, assuming the
> camera is invisible anyway :) I still think an "in sphere" view might work
> well and would be interesting to play with...
>
> Roice
>
> On Tue, Nov 2, 2010 at 7:14 PM, Roice Nelson wrote:
>
>>
>> On Tue, Nov 2, 2010 at 6:15 PM, Andrey wrote:
>>
>>> Roice,
>>> I'm not sure what you mean by "3D-only rotations". I see that navigation
>>> in S3 (in MC4D) and in H3 uses only one camera with 6 position/orientation
>>> parameters (+ some zoom parameters) like normal 3D navigation. For example,
>>> in MC4D you can't freely navigate in projection space (look from center
>>> outside etc.) like you can, say, in MC7D.
>>>
>>
>> Sorry that wasn't clear. By "3D-only rotations", I meant rotations which
>> are done after the H3 -> R3 projection, not before it. They are Euclidean
>> 3D rotations of the projected (3D) object, and are what Melinda was asking
>> for. These rotations would preserve the shape of 3D objects, unlike the
>> left-click dragging currently in MHT633. Does that help clarify?
>>
>> If you implement the ball model with the POV at the origin, your
>> left-click dragging should automatically result in the types of rotations I
>> was intending to describe.
>>
>>
>>> In MC4D we talk about "3D projection" because there are problems with
>>> real view in sphere: all rays from camera meet in opposite point of sphere
>>> and you can't see farther than that point. It can be solved by a
>>> nonrealistic optics: say, rays are going by circles tangent to camera axis -
>>> or by intermediate projection, as done in MC4D.
>>>
>>
>> I think an "in sphere" view could work well for the 3^4. The image of the
>> furthest cube would cover the entire background and would be "inverted".
>> Depending on face/sticker shrink values, you wouldn't be able to see past it
>> like you describe, but you could still see the entire puzzle and work with
>> it.
>>
>>
>>> Yes, it's easy to convert view in MHT from real-view to Poincare ball
>>> (centered in POV). The only problem will be with the situation when camera
>>> is outside of the space. In that case we'll need to recalculate "shift-left
>>> drag" operation (twist of camera or x-y pan): it will become sliding along
>>> some straight line. But I think that it's not very difficult.
>>>
>>
>> Don's tessellation applet had to deal with the same problem of hyperbolic panning outside the model
>> boundary, so you might check out what he did there...
>>
>> seeya,
>> Roice
>>
>
>

--001636c5b31f35f2cc04941bb999
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Argh! =A0Scratch the "assuming the camera is invisible" comment. =
=A0I was letting my rays get ahead of themselves and wrap back around to th=
e viewer. =A0And profuse apologies for the extra spam.


T=
o try to make this correction a useful post, let me mention that this parti=
cular lapse came from me recalling portions of a very nice discussion of th=
is exact topic in Thurston's "Three-Dimensional Geometry and Topol=
ogy". =A0See "Example 1.4.2 (the three sphere from the inside)&qu=
ot;, starting on page 32. =A0The short two page discussion is visible in href=3D"http://books.google.com/books?id=3D9kkuP3lsEFQC&printsec=3Dfro=
ntcover&dq=3DThree+dimensional+geometry+and+topology&hl=3Den&ei=
=3DBbTQTKT2C8WAlAe2q529Bg&sa=3DX&oi=3Dbook_result&ct=3Dresult&a=
mp;resnum=3D1&ved=3D0CDIQ6AEwAA#v=3Donepage&q&f=3Dfalse">google=
books, and very readable :) =A0I'll make myself scarce now...>

Cheers,
Roice


mail_quote">On Tue, Nov 2, 2010 at 7:39 PM, Roice Nelson =
<roice3@gmail.com>
wro=
te:

x #ccc solid;padding-left:1ex;">
I realized that for a 3^4 "in sph=
ere view", the 1C sticker would always block seeing further than the l=
ocation that is antipodal to the camera in S3, regardless of shrink setting=
s.=A0 So you could never=A0see beyond that.=A0 You potentially could see be=
yond the=A0antipode for the 4^4 though, assuming the camera is invisible an=
yway :)=A0 I still think an=A0"in sphere"=A0view might work well =
and would be interesting to play with...



=A0

Roice


On Tue, Nov 2, 2010 at 7:14 PM, Roice Nelson an dir=3D"ltr"><ro=
ice3@gmail.com
> wrote:

dding-left:1ex" class=3D"gmail_quote">
=A0


On Tue, Nov 2, 2010 at 6:15 PM, Andrey <=3D"mailto:andreyastrelin@yahoo.com" target=3D"_blank">andreyastrelin@yahoo=
.com
>
wrote:

dding-left:1ex" class=3D"gmail_quote">Roice,
=A0I'm not sure what yo=
u mean by "3D-only rotations". I see that navigation in S3 (in MC=
4D) and in H3 uses only one camera with 6 position/orientation parameters (=
+ some zoom parameters) like normal 3D navigation. For example, in MC4D you=
can't freely navigate in projection space (look from center outside et=
c.) like you can, say, in MC7D.



=A0

=A0Sorry that wasn't clear.=A0 By "3D-only rotations", I=
meant rotations which are done after the H3 -> R3 projection, not befor=
e it.=A0 They are Euclidean 3D rotations of the=A0projected (3D) object, an=
d are what Melinda was asking for.=A0 These rotations would preserve the sh=
ape of 3D objects, unlike the left-click dragging currently in MHT633.=A0 D=
oes that help clarify?=20
=A0

If you implement the ball model with the POV at the origin, your left-=
click dragging=A0should automatically=A0result in the types of rotations I =
was intending to describe.


=A0

dding-left:1ex" class=3D"gmail_quote">=A0In MC4D we talk about "3D pro=
jection" because there are problems with real view in sphere: all rays=
from camera meet in opposite point of sphere and you can't see farther=
than that point. It can be solved by a nonrealistic optics: say, rays are =
going by circles tangent to camera axis - or by intermediate projection, as=
done in MC4D.



=A0

I think an "in sphere" view could work well for the 3^4.=A0 =
The image of the furthest cube would cover the entire=A0background and woul=
d be "inverted".=A0 Depending on face/sticker shrink values, you =
wouldn't be able to see past it like you describe, but you could still =
see the entire puzzle and work with it.




=A0

dding-left:1ex" class=3D"gmail_quote">=A0Yes, it's easy to convert view=
in MHT from real-view to Poincare ball (centered in POV). The only problem=
will be with the situation when camera is outside of the space. In that ca=
se we'll need to recalculate "shift-left drag" operation (twi=
st of camera or x-y pan): it will become sliding along some straight line. =
But I think that it's not very difficult.



=A0

Don's rget=3D"_blank">tessellation applet had to deal with the same problem o=
f hyperbolic panning outside the model boundary, so you might check out wha=
t he did there...



=A0

seeya,

Roice





--001636c5b31f35f2cc04941bb999--




From: "Andrey" <andreyastrelin@yahoo.com>
Date: Wed, 03 Nov 2010 06:53:40 -0000
Subject: [MC4D] Re: 3D-only rotations in MHT633





--- In 4D_Cubing@yahoogroups.com, Roice Nelson wrote:
>
> I realized that for a 3^4 "in sphere view", the 1C sticker would always
> block seeing further than the location that is antipodal to the camera in
> S3, regardless of shrink settings. So you could never see beyond that. =
You
> potentially could see beyond the antipode for the 4^4 though, assuming th=
e
> camera is invisible anyway :) I still think an "in sphere" view might wo=
rk
> well and would be interesting to play with...
>=20
> Roice
>=20

It's correct only for face-centered camera position. Once you shift center =
from stickers you will see through antipode point, but objects around this =
point will be very large and distorted, and objects behind it will be inver=
ted in some sense. So it may be interesting, but not fit for the puzzle.

Andrey





Return to MagicCube4D main page
Return to the Superliminal home page