Walking animations including camera turn to correct orientation upon hotspot click

[GoogleCodeExporter]

Rather than moving from one viewpoint to the next instantly, I would like to 
create a more in-depth experience by showing the player walking from point to 
point.

The technical aspects of this would be as follows:

a) Each hotspot would contain orientation information for the camera
b) Upon clicking a hotspot, if the current orientation differs from the hotspot 
data, the engine moves the camera over 500 milliseconds to the correct 
orientation, then the walking animation is played.  At the end of the movie, 
the destination viewpoint is loaded.

Information that would need to be provided to the project lead would be the 
resolution (width & height) and focal length of the camera (35mm etc).  This 
would need to be experimented with until the settings are found.

Video example:

http://www.youtube.com/watch?v=DFRcl8tIA8k&feature=related (00:07-00:10) mouse 
pointer changes to arrow to indicate that walking can be performed.  Upon 
clicking, the camera orients to match the first frame of video, the walking 
animation is played and the game cursor returns.

Original issue reported on code.google.com by AndrewCu...@gmail.com on 22 Jun 2012 at 7:10

[GoogleCodeExporter]

This can be done with one caveat.  Here's how I would approach it:

1) Aware-Engine needs to know the X,Y,Z coordinate of the blender-camera for 
each viewpoint.
2) When the user clicks a hotspot the camera will be panned to face the X,Y,Z 
of the target viewpoint.
3) Rendering mode switches to full screen video and plays the walking video
4) Rendering mode switches back to pano mode (retaining the same camera heading)

To generate the video you will need to animate the movement of the 
blender-camera from the source X,Y,Z to the target X,Y,Z.

Here's the catch.  Since the walking video is pre-rendered you must decide upon 
an aspect ratio for the video ahead of time.  Let's say you chose 16:9 
widescreen.  The implication is that folks with screens of a different aspect 
ratio cannot see the video as intended.  (My laptop for instance has an aspect 
ratio of 8:5).  This gives you two options for showing the video:

  1) Show the original width of the video but display black bars above and below.  (I think this is what happens when you play a widescreen DVD on a non-widscreen TV).

  2) Show the original height of the video but clip off the screen edges.  (I think this is what happens when studios convert a widescreen DVD to "fullscreen").

Now, in the current implementation, Aware-Engine locks the vertical FOV angle 
(field-of-view) to 65 degrees and varies the horizontal FOV depending upon the 
screen aspect ratio.  So, if you're screen is not 16:9 the transition from pano 
rendering mode to video mode will not be seamless.

The youtube video you show does not suffer from this problem because the walk 
animations are rendered in realtime (as best I can tell) and thus there's no 
change in aspect ratio.

So we are left with a choice: tolerate non-seamless transitions to fullscreen 
video or force the pano rendering mode to render using the same FOV as the 
videos and have black bars or clipped width on non 16:9 screens.

Original comment by cru...@gmail.com on 22 Jun 2012 at 10:59

[GoogleCodeExporter]

A few thoughts about this.

1)  Would the switch from viewpoint - video - new viewpoint occur without 
screen flickering?  I would like to achieve the result while trying to limit 
anything that could detract from the immersion.

The Youtube video from JMP3 is not rendered in realtime; they used Quicktime VR 
viewpoints and quicktime video for the walk animations - everything was 
pre-rendered.

I would say that locking the panos and the video to the same FOV would be the 
best option; the best way would be to lock the video to the FOV as this can be 
achieved very easily in Blender.

Original comment by AndrewCu...@gmail.com on 25 Jun 2012 at 7:16

[GoogleCodeExporter]

I watched the JMP3 video again.  It looks like the viewport is roughly 16:9 and 
both panos and videos are rendered to this aspect ratio.  They have chosen to 
show the entire width of the 16:9 viewport and make use of the screen space 
above and below to show a HUD.  The lack of fullscreen seems like it would be 
less immersive but then, I haven't played the game.

So the question for you is, do you want to ditch fullscreen panoramas so that 
we can do walk animations seamlessly?  If so I think the transition from pano 
to video could be mostly flicker free.  The only noticeable change would be the 
switch from hi-res pano to lower resolution compressed video.

Original comment by cru...@gmail.com on 27 Jun 2012 at 5:28

[GoogleCodeExporter]

The idea with the borders at the top and bottom was that the "suit" you were 
wearing had a helmet with a heads-up display showing your world outside; the 
texture at the top and bottom were to reinforce that idea.

JMP1 was rendered in a smaller windows as the "eyepiece" being worn by the 
player, so again the view was constrained by this.

I think that we should go with the tried-and-tested method from the originals 
and go with the locked 16:9 ratio, making switching more seamless.  I realise 
that this moves away from the fullscreen HD, but I also appreciate that a 
compromise was almost inevitable in this area with these requirements.

If there was any other way to do it I'd jump at it, but I don't believe there 
is.  However, any thoughts on this would be appreciated.

Original comment by AndrewCu...@gmail.com on 27 Jun 2012 at 6:19

[GoogleCodeExporter]

I agree - given the requirements this is the best choice.  I'll put it on my 
todo list.

Original comment by cru...@gmail.com on 28 Jun 2012 at 7:34