Message #1240

From: Roice Nelson <>
Subject: Re: [MC4D] Re: 3D-only rotations in MHT633
Date: Tue, 02 Nov 2010 19:14:41 -0500

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

> 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…