[Kde-games-devel] Tabletop Stereo 3D boardgames tutorial for KDE Games

[Excite User]

At new year's eve I wrote an essay for K16 on how to keep KDE popular
with the rise of tablets and their sandbox environments. In extension of
this I wrote this more practical tutorial. It may give a new goal for
KDE games or raise some questions, and that's why I post it here first
and will hang out on irc for the next few evenings (CET). Although not
as straight forward as the learning Ruby tutorials I wrote on techbase I
hope that it will inspire coders and artists alike (for example to give
Knights some cool new graphics).

Dennis P

Tabletop Stereo 3D boardgames tutorial 

Morph movement 
Let's convert a chess game with prerendered pieces to stereo 3D, this
tutorial is not suited for card games or action games but still a nice
introduction to stereo 3D on KDE. 

First we choose between above surface or sub surface game pieces. 

Above surface graphics is the 3D we know from science fiction movies
often presented as a hologram. But a hologram is not needed for this;
you just need to know where the eyes of the observer are and project a
stereo image at them, like the 25 year old Time Traveler arcade game. In
KDE however we assume that the observer sits in a chair at a desk or
dinner table and that the stereo 3D display lies flat on the table in
front of them. We assume the observer has a static location. We also
keep the appearance height of all solid objects no more than 2 cm above
the surface, any non-compliant software must be distributed with
explicit health warnings and be listed separately from the default
software download list. 

Above surface graphics have the following design issues: 
- When a piece approaches the upper border of the display the top of the
piece appears to be missing. While the 2D graphics slide underneath the
border their 3D representation gets broken and the user is taken out of
their 3D illusion. Take special care to avoid this. The sides have
similar issues.
- Like a pop-up book above surface items can be made to look part of the
windowing environment. If you float nothing more then a few millimeters
above a window it may even look good when moving windows around and off
screen.

Sub surface graphics is much the same as above. Instead the graphics
appear to be under a glass pane, like a viewing cabinet at a museum.
Again we project images to appear no more than 2 cm below the surface. A
non-image like a black abyss is allowed but you must not have graphics
which accentuate the abyss appear to be below 2 cm. 

The 2 cm above or below limit keeps the focal point of the eye looking
at graphics close to actual location on the display, providing the brain
with full depth perception instead of, possibly unhealthy, fake depth
perception. 

Unlike above surface graphics when they approach any border the observer
expects them to move underneath them, this means that when all graphics
are sub surface you can have a play field larger then the screen size
and freely scroll it around. Because the glass pane is similar as
experienced in real life the sub surface graphics are easily adjusted to
touch screen interactions, well as easy as designing a normal touch
screen interaction would be. As the graphics appear to be under the
desktop it works best if the game field replaces the background when the
game can easily move stuff as task bars out of sight during game play or
simply be played full screen.

For stereo 3D games on KDE we don't assume that touch screens are
available, we assume the player can use a scroll-wheel mouse and / or
four arrow keys. 

Back to the chess board 
So let's pick sub surface graphics for being easier. For our floor depth
we should realize that the less depth is better. However Chess pieces
are rather tall, the tallest of all common board games, so it seems we
must put the board at minus 2 cm. But the squares are usually carved
round the edges so minus 1.9 cm it is and the edge gutters between all
the squares are minus 2 cm at their lowest. 

To make it even easier we carve and paint the board on a table so that
there is no edge on the board to be designed, the table surface
continues underneath the screen borders in all directions.

Our stereo view consists of two images of 1280 x 960 square pixels and
the distance between the center of one pixel to the center of the next
is 0.25 mm. So we render the board in a 3D environment like blender.org
and put the two camera's where the eyes would be. 

You start with a flat 8 by 8 square pattern. Notice that on your first
test rendering the bottom squares are partially obscured by the border
nearest to your chest as the image is sunk into the cabinet's viewing
window. Do we want this or not? Maybe we should shrink the size of the
game board a bit. 

Since it is such a simple wooden or marble plane why not look way beyond
the year 2012 and render the scene with the chessboard carving in the
middle, at 2560 x 1920. Take the center 1280 x 960 image and cut the
rest up into PNGs of 160x160 pixels. You could even use these images to
create a tiny 2D chessboard on a 2560 x 1920 display. Notice that a 1280
X 960 stereo display may have 2560 x 1920 pixels. So we could reuse a
single stereo image to make a hi-res 2D board. Now it's time to pick the
material of the board; a light wood, put a darker oil effect on every
other square and carve the gutters around the squares. The chess table
is looking good.

The chess pieces
Unlike flat 2D graphics you can't animate one piece crossing over the
other, its would look like the where passing through each other. So we
design the pieces to be so narrow that an extra piece can stand between
two pieces standing each in the center of their own square without
anything touching, this also makes the pieces look taller. As each piece
has a different viewing angle at each position on the board we need to
have a rendering of each of the six types of pieces at each location in
two colors. We may want the game to pause a while before we kick another
piece from it's place so let's also render each piece standing in
between two pieces, not in front or back as that will be a piece in
motion, but only in between. That makes 8 x 8 plus 7 x 8 locations for
12 pieces 1440 renderings of pieces. Double that for our stereo vision
and we have 2880 PNGs of 1280 x 960 pixels, luckily we can limit the
colors down to 256 for mass distribution and for the most part the PNG's
pixels are empty and transparent. We can also stuff multiple PNGs
unchanged into a SVG, each as a layer. So the game could be distributed
with 24 SVGs.

Now we need just one more thing from our 3D artist and that is a spot
card. A single PNG which reveals all the locations of the bottom center
of pieces as seen through the lens used for the pictures. Kind of like
each actor's position having been clearly marked on the blue or green
floor of a film set with stickers.

We now have enough stereo images to make a 1.0 version of our chess
program. If we animate with two frames per second the pieces can jump
around the board quite naturally. Done! 

For a smoothly animated version 2.0 we can use the spot card and
morphing. First we open the spot card in a simple editor with
cross-hairs instead of a pointer arrow. We place the cross-hairs on the
center of each spot, one after another, and write down the x,y location.
Now we can formulate the code to move a piece a few percent towards the
position of a neighboring piece. The percentage depends on the speed of
the animation and the number of frames per second we need to generate to
create a smooth movement. But the perspective of this piece should
change slightly so we move the other piece to the same location (move
100 percent toward the location of the moving piece minus the percentage
the first piece moved). Now we have two pieces at the same location and
need to call in a morphing library.

We ask the morphing lib to detect the outlines of the two images. We
could ask it to morph the images in a single new combined image but that
would only give us a picture which resembles the image as it would look
when both images have moved 50 percent towards each others position. So
we tell it we may want a morphing animation consisting of multiple
images. The number of stages must be the same as the number of frames we
want rendered to move from the location of one piece to the neighbor.
Now instead of actually creating all stages of morphing we only want the
one that corresponds to the percentage with which the first piece moved.
We now have the first frame of the animation to show on screen. Will we
show it now and assume the computer is fast enough for real time PNG
shuffling and morph rendering or should we collect the images and show
them once we made a full animation filling up RAM? 

For chess I would suggest to build a full animation. Let the user click
to highlight a square which contains one of their pieces, then let them
use the mouse to move to other squares and only super highlight squares
to which a piece may be moved. When they clicked one you finish
rendering the animation and move the piece to there.

Anyway the next animation frame; we move both pieces to the second
position and ask for detection of the outlines and the rendering of the
second phase frame of the morph and continue until we have reached the
position of neighboring piece itself, we get that frame of the animation
for free. 

Now we move on to the next neighboring piece using the same technique
until we have reached the position we want to move the piece to. If
there is a piece there (in the game as seen by the user) we move that
one to the side and of the board in a straight line and skip some stages
to speed it up so that we don't notice that the piece didn't change
perspective when it moved to the edge of the board, alternatively we can
fade it out of existence before it reaches the border.

Notice that this technique also works diagonally. As the stereo 3D game
seems to be underneath the desktop plane we can easily slide the windows
related to the chess game in and out of view, over the stereo image,
without spoiling it. In fact as the display lies flat on the table the
windows have their own perspective in real life which matches the stereo
3D board game underneath. While we use the normal mouse pointer to
interact with the windows, we don't need to use a mouse pointer when the
board game is shown full screen all by itself, light up the square where
the mouse is by painting a simple SVG filter over the PNG of the board.

Now we have a game engine which does not require knowledge of 3D
animation techniques. If some artist had the time they could even use
the 3D perspective to manually recreate stereo SVG graphics by outlining
2880 images. And that is why we use large PNG with mostly empty space.
Users could replace the PNGs with different renderings they made. So
when designing the engine don't hardcode the positions you found in the
spot card, put them in a plain list next to the graphic resources. 

We could use the same engine to create any board game where one moves
pawns around. Most games would be easier; as many times they are not
white and have all the same shape, so for the pawns you need only as
much PNGs as you have positions on the board. The image of the pawn
would be gray-scale and you give them different colors as you use them.
You could decrease the depth of the board and the engine would not know
or care. You could also decrease the height of the pawns.

Perhaps we could even enhance the engine and make it touch screen
compatible: have the pawns stick up through the cabinet window pane if
the game does not use windows on top during play. Let the pawn be
squeezable so you can put your finger on top causing it to be squeezed
down and then let the player's finger move it around.

Recreating them in SVG is more realistic here as you only need as much
SVGs as there are positions. The artist could even start the other way
around: start with the most busy board (for example Chinese checkers),
redraw all the pawns as seen in a Stereo 3D rendering using SVG shapes
and its pong effects and then design a simpler board game which uses
less positions, reusing the pawns at their positions from the busy game,
by drawing a different but compatible game board. 

Remember the stereo image consists of two images of 1280 x 960 pixels
and each pixel is a 0.25 x 0.25 mm square. This can be previewed on any
1080p Stereo 3D TV by laying it flat. On industry standard 2560 x 1920,
0.125 mm pixel pitch displays with a custom stereo layer added, the
image uses the first pixel 1,1 for the left eye and the pixel next to it
(x,y: 2,1) for the right eye. The next line of the pixels (x,y: 1,2 2,2
3,2 etc.) are left blank. 

A second instance of your application can be used to allow a second
player to sit opposite of the table to play the game in competition with
each other, the same as in a chess competition. This instance of the
game is shown rotated 180 degrees on the previously blanked out lines.

The primary player is allowed full control over the orientation of the
display. 
Tilt detection should alert your application if the display is being
tilted toward the normal standing position. When looked straight on, at
a perpendicular angle, the custom stereo layer looks normal and
transparent, your application should switch to showing only one of the
two stereo images of 1280 x 960 pixels to all 2560 x 1920 pixels.


Stereo 3D layer technical specification 
A KDE compliant Stereo 3D display has a highly detailed light refraction
layer and should allow two children or thin adults on one side of the
table to both see stereo 3D using the refraction pattern: 
L L R L R L R R 
Near a perpendicular angle the refraction pattern guides light from all
2560 x 1920 pixels straight on (upwards when it lies flat). 
For the other side of the table each second scan line is used, the
refraction pattern is reversed to also give the pattern: 
L L R L R L R R 
when viewed from the other side. 

The pattern allows 4 players to each view 4 different 1280 x 960 pixel
images when sitting on two opposite sides of the table. By moving closer
to the center of the display each side can see one stereo image unique
to that side. Two players can sit opposite of each other centered in
front of the display to view each a unique stereo image. When the
display is tilted toward the upright position and the view is near
perpendicular a single user can see a single high resolution image or
all stereo images garbled together when the software has not switched
the view. 

When the user rotates the display at the near perpendicular viewing
angle a 1:1 A4 page plus some navigation icons can be viewed at about
204 dpi. That is double the resolution of common displays today. These
types of displays have already entered mass production for usage in
laptops and for example last decade's iPod Nanos. 

Non integrated Stereo 3D layer 
An aftermarket stereo 3D layer can be custom ordered from a toy factory,
the plastic plate may not offer all the refraction patterns of a tightly
integrated layer. Expect at most a single stereo view per side plus a
full resolution perpendicular view. 

An even simpler pattern would be straight stereo gutters as common in
toddler toys. The simple pattern creates stereo view at all times an all
tilt angles for one user only. However in software we can simply show
the same image to both eyes for the 2D view by showing a 1280 x 960
pixel image scaled to the 2560 x 1920 pixel display. This increases your
viewing angle quite a bit. However it lowers your effective viewing
resolution to the 0.25 mm pixel pitch as common today in 2D mode, so
you'll be losing money and not resolution when compared to 15 inch
displays sold today. However you can increase the vertical resolution to
a 0.125 mm pixel pitch by not viewing images of 1280 x 960 but stretched
images of 1280 x 1920. 

The plastic plate should come with a foil on the back which covers a
sticky removable (3M like) glue. Unfold a cm or so on the left side and
place the panel on your cleaned (2560 x 1920 pixels 0.125 pixel pitch)
screen. Confirm that the plate is located correctly, maybe look through
on eye, compared to a stereo image. Press down the plate so it sticks,
keep your thumbs on it and look from a distance, did you get the top and
bottom correct? Okay, now keep your thumbs on it and ask someone else to
pull back the cover, you may need to have supplied them with two
manicure plyers, but it should be possible without. Let them rub down
the the plate from between your thumbs just over half way through
uncovering the plate. The cover now comes out the other end and they can
pull the rest of if from underneath. If the plate is not a plate but
rather a thick plastic layer you'll need a metal or plastic spatula, as
wide as your screen height, as wide as the thick plastic layer. Bend the
spatula so that it gives enough down force by itself to prevent bubbles
from forming. If you do it by hand then you'll likely stretch the layer
and mess up the stereo vision on the right side of the screen. 

This tutorial is a candidate for the K16 project :

In 2016 we hope that anyone who wants to buy some A4 metric math
notebook paper / A4 grid paper / A4 school paper will buy an A4+ sized
high resolution KDE tablet instead.

(and has not yet been selected by the KDE community as a common goal)

To achieve this goal we target a stereo 3D hardware reference platform
to be promoted at the end of 1012 which has these same metric display
qualities, is as fast or faster then game consoles available in 2011,
and allows families to play all the good old tabletop boardgames in
stereo 3D at the dinner table.

Now let's create more stereo 3D games so that after 2012 stereo 3D
laptops with this resolution are sold everywhere! Thanks for reading
this tutorial, and good luck. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-games-devel/attachments/20110113/c667572a/attachment-0001.htm