Developing an app with the Visual Studio 3D Starter Kit, part 1 of 3

As we promised a few weeks ago, welcome to the first post in a series where we’ll explore a full end-to-end app developed with the Visual Studio 3D Starter Kit. During this series we’ll develop a 3D dice roller that allows you to roll a 6-sided die by tapping or clicking it. In the process of rolling a number, the die will jump and flip in the air. This app will also work on Windows 8’s snap view, so that users can still roll dice while working on other apps. Finally, we’ll show you how to make this app compatible with Windows RT devices and port it to Windows Phone.

This first post will cover the basics of creating the app to the point where we can render the die to the screen and apply a texture.  We’ll also review the Visual Studio Graphics tools, which are included in Visual Studio Professional or greater.  If you only have Visual Studio Express 2012 for Windows 8, don’t worry, you’ll still be able to use this walkthrough.

The hardest part about learning Direct3D development is the need to learn many new concepts, such as coding HLSL shaders and how to convert meshes into runtime formats. There are many Visual Studio tools make this process much easier, letting you focus on your app logic instead of dealing with all those new concepts. And whenever you’re ready you can add more advanced features to your app without having to start over. Throughout this series, we’ve provided a number of links to additional documentation about DirectX features that we use, so you may want to follow these links to explore more about DirectX and graphics programming.

Let’s stop talking and start designing our app!

The demo app: a dice roller

Dice are used for a variety of board games and gambling. Making a simple dice roller app is an easy task in any programming language - a random number generator is only one line of code in many languages. But how can we make this app more interesting?

Starting with a clean slate

The first step to use the Visual Studio 3D Starter Kit is to download and open it. You can get the full Starter Kit from http://aka.ms/vs3dkit. We have also prepared a special version of the Starter Kit (Windows Store only) for this tutorial that starts with a completely blank screen with no 3D models, so we can explore how to create our own assets. You can get that version on CodePlex (direct download link on the tile below). This changeset also shows what has to be changed to remove all the content from the Starter Kit.

Note for Visual Studio Express users: You can download the assets used in this project by clicking the tile below. Just add them to your project at the appropriate points in the walkthrough below.

If you run this app, you’ll see the Starter Kit’s teapot splash screen, followed by an empty gray screen. Don’t worry, we’ll fill it up soon…

...

Developing an app with the Visual Studio 3D Starter Kit, part 2 of 3

...

Let it roll, baby, roll

In order to make anything move in a graphics application, the steps are always the same:

1. Set some state (e.g. a Boolean flag) to indicate that an animation should be running. This is also a good time to save the starting position and time of the animation if needed.
2. In the Update method (called on every frame before rendering), calculate the object’s position/rotation/scaling (in 3D speak, transforms) using the time between the beginning of the animation and the current frame time. You must also make sure that when the animation ends the state is correctly updated to stop the animation.
3. In the Render method, make sure that the transforms are correctly applied to each object.

In our case we will add a new method called RollDie() that will set the state and save the starting time. We will use this method to calculate each die roll result, but for now let’s just execute an animation that rotates the die from 1 to 6.

To create this animation we will need a set of variables to keep track of the cube’s transforms, as well as the animation time. We will create one Boolean value to signal that animation is running, one float to store the animation time, and three vectors to store the initial, final and current rotations of the cube. These vectors should be of type XMFLOAT3, to store the Yaw, Pitch and Roll rotations (see figure below).

...

So this completes our app functionality. It’s definitely a more useful and interesting version of the classic random number generator. You can download this version on CodePlex (direct download link on the tile below).

We only have a few more steps to finish in order to make this app run on Windows RT and Windows Phone as well!  We’ll cover these steps in our third and last blog post. Stay tuned!

Keep an eye on the Visual C++ Team Blog for the final part...

• [0:34] Announcing Release of Windows Azure Media Services (Scott Guthrie)
• [1:42] Broadcast push notifications to millions of mobile devices using Windows Azure Notification Hubs (Scott Guthrie)
• [2:33] Now Available: Windows Phone SDK Update for 7.8 (Cliff Simpkins )
• [3:25] Fall Fury: Part 1 - Introduction (Den Delimarsky, Brian Peek, Clint Rutkas, Dan Fernandez, Rick Barraza )
• [5:16] Tile design guidelines for Windows Phone 8 (Shubhan Chemburkar)
• [6:08] Building the Bing apps for Windows 8 (Jigar Thakkar)
• [7:18] Building HTML5 Games for the Atari Arcade
• [8:36] Introducing SvcPerf - An End-to-End trace Analysis tool for WCF (Sajay Antony), http://svcperf.codeplex.com/
• [9:36] CODEMINE: Building a Software Analytics Platform for Collecting and Analyzing Engineering Process Data at Microsoft (Jacek Czerwonka, Nachi Nagappan, and Wolfram Schulte)
• [10:40] GoingNative 13: Visual Studio 3D Starter Kit, Meet Roberto Sonnino

Picks of the Week!

• Clint's Pick of the Week:[11:43] Everything you need to know about the Lumia 820 and 3D printing (Joel Willans)
• Dan's Pick of the Week:[13:00] Visual Studio ​Achievement​s; they're not Xbox live right? (Cheevos!)

The countdown has begun  [04:08]

It's good to be popular  [13:22]

Presenting in 3D  [17:35]

Control it with your EYES  [07:48]

Prior to DirectX 11.1, stereoscopic 3D required specific hardware and a custom API written for that hardware.  With DX11.1, stereoscopic 3D has been "democratized."  Any GPU that supports DirectX 11.1 can be connected to any device which supports stereoscopic 3D, be it a projector, an LCD TV, or anything else.  Plug it in and DirectX does the rest.

From the software side of things, any DX11.1 application can determine if the connected display supports stereoscopic 3D, and choose to render itself separately for the player's left and right eye.

To showcase this feature, we decided to build a very simple game that would give the illusion of depth, but be easy to explain and play.  What's easier than Pong?  So, we built the world's most over-engineered game of 3D Pong named Maelstrom.

Software

Each player setup consists of two applications: the DirectX 11.1 game written in C++, and the touch-screen controller written in C#/XAML.  Both are Windows Store applications.  Since this is a two player game, there are two instances of each application running, one per player.  All for applications are networked together using StreamSockets from the Windows Runtime.  The two controllers and player two's DirectX game connect to player one's DirectX game, which acts as the "master".  Controller input is sent here, and, once the ball and paddle positions are calculated, the data is drawn for player one and sent to player two which draws the world from the other player's perspective.

Direct3D Application

Getting Started with stereoscopic DirectX11, C++, and XAML

If you have never worked with DirectX before, it can be a little overwhelming at first. And even if you have worked with it some in the past, targeting the new Windows 8 ecosystem, along with C++ and XAML have added some additional changes in how you may have designed your solution previously.

Fortunately, the Windows Dev Center for Windows Store Apps has some great samples to get you started, and we took full advantage of them to get to speed. For a great, simple example of how to leverage the new stereoscopic feature in Direct3D 11.1, we started with Direct3D Stereoscopic Sample which shows the basic adjustments to the Render loop for toggling your virtual cameras. However, to see a great example of a simple game structure that also leverages stereoscopic rendering where available, the tutorial found at Walkthrough: a simple Windows Store game with DirectX is invaluable. Further in this article, we will dive deeper into the specifics of stereoscopic rendering in our game.

One thing to note, if you follow the link in the above Walkthrough to the original project, it will take you to a C++ only implementation of the game. Now, of course, all the DirectX game objects such as the paddle, puck and walls are all rendered using D3D. However, for HUD (Heads up Display) elements, this C++ only sample also uses DirectX exclusively. If you are coming from a managed code background, this will definitely seem like unnecessary overhead. That is because this C++ only sample was created after last year's BUILD conference in 2011 and C++ and DirectX still did not play well with XAML.

However, a few months later, the ability to nest DirectX content in a XAML project became available for true hybrid style solutions (see the article DirectX and XAML interop - Windows Store apps using C++ and DirectX for more information). After this feature was added, the simple Shooter Game referenced above had its HUD logic rewritten in XAML and posted up to Dev Center as XAML DirectX 3D shooting game sample, which shows both stereoscopic support, a simple Game Engine structure in C++ and XAML integration. At this point, we had all the starter code we needed to start writing our own game.

Game Engine

We modified the base sample to accommodate our needs.  We created specific GameObjects, such as Paddle, Puck, etc. to add the behaviors we needed.  We also added an Update and Render method to the base GameObject so that, for every frame, we could do any calculations required, and then draw the object to the screen.  This is very similar to how XNA sets up its game engine.

Game Constants

Because we were tweaking a variety of values like colors, sizes, camera locations, etc., we created a GameConstants.h header file which contains nothing but these types of values in a single location.  This made it very easy for us to quickly try out various tweaks and see the results on the next run.  Using namespaces helped keep the code a bit more manageable here as well.  Here’s a quick snippet of that file:

namespace GameConstants
{
    // bounds of the arena
    static const DirectX::XMFLOAT3 MinBound    = DirectX::XMFLOAT3( 0.0f,  0.0f,  0.0f);
    static const DirectX::XMFLOAT3 MaxBound    = DirectX::XMFLOAT3(19.0f, 10.0f, 90.0f);

    // game camera "look at" points
    static const DirectX::XMFLOAT3 LookAtP1    = DirectX::XMFLOAT3(9.5f, 5.0f, 90.0f);
    static const DirectX::XMFLOAT3 LookAtP2    = DirectX::XMFLOAT3(9.5f, 5.0f,  0.0f);

    // Waiting Room camera positions
    static const DirectX::XMFLOAT3 WaitingEyeP1                = DirectX::XMFLOAT3(GameConstants::MaxBound.x/2, GameConstants::MaxBound.y/2, GameConstants::MaxBound.z - 12.0f);
    static const DirectX::XMFLOAT3 WaitingEyeP2                = DirectX::XMFLOAT3(GameConstants::MaxBound.x/2, GameConstants::MaxBound.y/2, GameConstants::MinBound.z + 12.0f);
    static const DirectX::XMFLOAT3 WaitingEyeMjpegStation    = DirectX::XMFLOAT3(GameConstants::MaxBound.x/2, GameConstants::MaxBound.y/2, GameConstants::MinBound.z + 9.6f);

    // game camera eye position
    static const DirectX::XMFLOAT3 EyeP1        = DirectX::XMFLOAT3(GameConstants::MaxBound.x/2, GameConstants::MaxBound.y/2, GameConstants::MinBound.z - 6.0f);
    static const DirectX::XMFLOAT3 EyeP2        = DirectX::XMFLOAT3(GameConstants::MaxBound.x/2, GameConstants::MaxBound.y/2, GameConstants::MaxBound.z + 6.0f);

    static const float Paddle2Position    = MaxBound.z - 5.0f;

    namespace PaddlePower
    {
        // power level to light paddle at maximum color
        static const float Max                    = 9.0f;

        // max paddle power color...each component will be multiplied by power factor
        static const DirectX::XMFLOAT4 Color    = DirectX::XMFLOAT4(0.2f, 0.4f, 0.7f, 0.5f);
    
        // factor to multiply mesh percentage based on power
        static const float MeshPercent            = 1.2f;
    };
    
    // time to cycle powerups
    namespace Powerup
    {
        namespace Split
        {
            static const float Time                        = 10.0f;
            static const float NumTiles                    = 4;
            static const DirectX::XMFLOAT4 TileColor    = DirectX::XMFLOAT4(0.1f, 0.4f, 1.0f, 1.0f);
            static const float TileFadeUp                = 0.20f;
            static const float TileDuration                = 2.10f;
            static const float TileFadeDown                = 0.20f;
            static const float TileMeshPercent            = 2.0f;
            static const float TileDiffusePercent        = 2.0f;
        };
    };
}

Stereoscopic 3D

Direct3D must be initialized properly to support stereoscopic displays.  When the swap chains are created, an additional render target is required, such that one render target is for the left eye, and one render target is for the right eye.  Direct3D will let you know if a stereoscopic display is available, so you can create the swap chain and render targets appropriately.

With those in place, it’s simply a matter of rendering your scene twice, once per eye…that is, once per render target.

For our game this was very simple.  Our in-game camera contains two projection matrices, one representing the view from the left eye, and one from the right eye.  These are calculated when the projection parameters are set.

void Camera::SetProjParams(
    _In_ float fieldOfView,
    _In_ float aspectRatio,
    _In_ float nearPlane,
    _In_ float farPlane
    )
{
    // Set attributes for the projection matrix.
    m_fieldOfView = fieldOfView;
    m_aspectRatio = aspectRatio;
    m_nearPlane = nearPlane;
    m_farPlane = farPlane;
    XMStoreFloat4x4(
        &m_projectionMatrix,
        XMMatrixPerspectiveFovLH(
            m_fieldOfView,
            m_aspectRatio,
            m_nearPlane,
            m_farPlane
            )
        );

    STEREO_PARAMETERS* stereoParams = nullptr;
    // Update the projection matrix.
    XMStoreFloat4x4(
        &m_projectionMatrixLeft,
        MatrixStereoProjectionFovLH(
            stereoParams,
            STEREO_CHANNEL::LEFT,
            m_fieldOfView,
            m_aspectRatio,
            m_nearPlane,
            m_farPlane,
            STEREO_MODE::NORMAL
            )
        );

    XMStoreFloat4x4(
        &m_projectionMatrixRight,
        MatrixStereoProjectionFovLH(
            stereoParams,
            STEREO_CHANNEL::RIGHT,
            m_fieldOfView,
            m_aspectRatio,
            m_nearPlane,
            m_farPlane,
            STEREO_MODE::NORMAL
            )
        );
}

Depending on which eye we are rendering, we grab the appropriate projection matrix and pass it down to the vertex shader, so the final scene is rendered offset for the proper eye.

Collision Detection

If you are just starting to move into 3D modeling and programming, one of the trickier aspects of your game can be collision detection and response. Maelstrom uses primitives for all of the game elements, so our collision code was able to be a bit more straightforward compared to complex mesh collisions, but understanding a few core math concepts is still critical to grasp what the code is doing.

Fortunately, DirectX provides us with an DirectX Math Library that is able to do the serious heavy lifting, so the main complexity comes from framing the problem and learning how to apply the library.

For example, In our situation we had up to three very fast moving spheres and needed to check for wall collisions and then handle to appropriate bounce, since some of the walls would also be angled. In a 2D game, a collision detection between a sphere and an axis line is very easy. If the distance between a circle and the line is less than or equal to the radius of the sphere, they are touching. On every frame, you move your circle based on its velocity and do your collision test again. But even here, your solution may not be that easy for two reasons.

First, what if the line is angled and not lying flat on the X or Y axis? You have to find the point on the line based on the line's angle that is closest to the sphere to do your distance calculations. And if you then want it to bounce, you have to rotate the velocity of the circle by the line's angle, calculate your bounce, and then rotate back. And that's just rotated walls in 2D. When you move up to 3D, you have to take into account the surface normal  (which way the 3D plane is facing) in your calculations.

The second complexity that we needed to account for and which pops up in either 2D or 3D collision detection is travel between frames. In other words, if your ball is travelling very fast, it may have completely travelled through your collision boundary in between frames and you wouldn't notice it if you are only doing a distance / overlap check as outlined above. In our case, the pucks had the ability of travelling very fast with a speed boost, so we needed a more robust solution. Therefore, instead of implementing a simple sphere plane intersection test, we needed to create a line of motion that represented where the ball ended on the previous frame and where it currently is after it's new velocity is added to it's position. That line then needs to first be tested to see if it crosses a WallTile. If it does cross, then we know an collision has occurred between frames. We then solve for the time (t) between frames the Sphere would have first made contact to know the exact point of impact and calculate the appropriate "bounce off" direction.

The final code for a puck (or moving sphere) and wallTile collision test looks like this:

bool GameEngine::CheckWallCollision(Puck^ puck)
{
    bool isIntersect = false;
    bool wallCollision = false;

    for(unsigned int i = 0; i < m_environmentCollisionWalls.size(); i++)
    {
        WallTile^ wall = m_environmentCollisionWalls[i];
        float radius = puck->Radius();
        float signedRadius = puck->Radius();
        float contactTime = 0.0f;
        XMVECTOR contactPlanePoint = XMVectorSet(0.0f, 0.0f, 0.0f, 0.0f);
        XMVECTOR contactPuckPosition = XMVectorSet(0.0f, 0.0f, 0.0f, 0.0f);

        bool intersectsPlane = false;

        // Determine the velocity of this tick by subtracting the previous position from the proposed current position.
        // in the previous update() cycle, puck->Position() = puck->OldPosition() + ( puck->velocity * timerDelta ).
        // Therefore, this calculated velocity for the current frame movement differs from the stored velocity
        // since the stored velocity is independent of each game tick's timerDelta.
        XMVECTOR puckVectorVelocity = puck->VectorPosition() - puck->OldVectorPosition();
        float D = XMVectorGetX( XMVector3Dot( wall->VectorNormal(), wall->VectorPosition() ) );

        // Determine the distance of the puck to the plane of the wall.
        float dist = XMVectorGetX( XMVector3Dot(wall->VectorNormal(), puck->OldVectorPosition() )) - D;
        signedRadius = dist > 0 ? radius : -radius;

        // if the distance of the puck to the plane is already less than the radius, the oldPosition() was intersecting already
        if ( fabs(dist) < radius )
        {
            // The sphere is touching the plane.
            intersectsPlane = true;
            contactTime = 0.0f;
            contactPuckPosition = puck->OldVectorPosition();
            contactPlanePoint = puck->OldVectorPosition() + wall->VectorNormal()*XMVectorSet(signedRadius,signedRadius,signedRadius,1.0f);
        }
        else
        {
            // See if the time it would take to cross the plane from the oldPosition() with the current velocity falls within this game tick.
            // puckVelocityNormal is the amount of force from the velocity exerted directly toward the plane.
            float puckVelocityNormal = XMVectorGetX(XMVector3Dot(wall->VectorNormal(), puckVectorVelocity ));
            // if the puckvVelocityNormal times the distance is less than zero, a plane intersection will occur
            if ( puckVelocityNormal * dist < 0.0f )
            {
                // determine the contactTime, taking into account the shell of the sphere ( position() + radius )
                // is what will make contact, not the position alone.
                contactTime =  (signedRadius - dist) / puckVelocityNormal;
                // if the contact time is bewteen zero and one, the intersection has occured bewteen oldPosition() and position()
                if ( contactTime > 0.0f && contactTime < 1.0f )
                {
                    intersectsPlane = true;
                    // this is the position of the puck when its shell makes contact on the plane
                    contactPuckPosition = puck->OldVectorPosition() + XMVectorScale(puckVectorVelocity, contactTime);
                    // this is the position on the plane where the shell touches.
                    contactPlanePoint = contactPuckPosition - XMVectorScale(wall->VectorNormal(), signedRadius);
                }
            }
        }

        // If the puck has contacted the wall plane, determine if the point of contact falls within the wall boundary for true contact.
        if (intersectsPlane)
        {
            float Kr = 1.0f; // Kr is the coefficient of restitution. At 1.0, we have a totally elastic bounce with no dampening. At Kr = 0.0, the ball would stop at the wall.

            // Make sure the puck velocity and wall normal are facing each other
            float impact = XMVectorGetX ( XMVector3Dot ( wall->VectorNormal(), puck->VectorVelocity()) );
            if (impact < 0.0f)
            {
                wallCollision = true;

                //// bounce the vector off the plane
                XMVECTOR VectorNormal = XMVector3Dot(wall->VectorNormal(), puck->VectorVelocity())*wall->VectorNormal();
                XMVECTOR VectorTangent = puck->VectorVelocity() - VectorNormal;

                puck->Velocity(VectorTangent - (XMVectorScale(VectorNormal, Kr)));
                puck->Position(contactPuckPosition);

                int segment = (int)(puck->Position().z / GameConstants::WallSegmentDepth);
                segment = max(min(segment, GameConstants::NumWallSegments-1), 0);

                auto tiles = m_wallTiles[segment];
                WallTile^ tile = tiles[i];
                if(tile->GetPowerup() == Powerup::Split)
                    SplitPucks();

                break;
            }
        }
    }

    return wallCollision;
}

Drawing Maelstrom

To draw the game, we wanted to use some advanced techniques. We decided to go with a light pre-pass deferred rendering pipeline with normal mapping. That’s a lot of jargon but it isn’t all that complicated once you know what the jargon means, so let’s break it down.

When you draw something in 3D, there are three things that come together to determine the final color of each pixel on the screen: meshes, materials, and lights. A mesh is a collection of triangles that make up a game object (such as a wall tile in Maelstrom). On its own, a mesh is just a bunch of dots and lines. A material makes a mesh look like something. It could be as simple as a solid color but usually it’s a texture and sometimes it’s more (the wall tiles in Maelstrom use both a texture and a normal map to define their material properties). Lastly, lights transform materials by determining how bright they should appear and what sort of tint, if any, they should have. Without lights you would either have complete darkness or you would have flat lighting (where everything has a uniform brightness and adding a tint color would uniformly tint everything on the screen).

Forward Rendering vs. Deferred Rendering vs. Light Pre-Pass Rendering

The simplest approach to drawing 3D graphics is something called forward rendering. With forward rendering, drawing consists of rendering the mesh and calculating its material and all the lights that affect the material all at the same time. The more lights you add, the more complicated your shaders become since you have to determine whether each light affects the material and if so how much. (Ok, so there’s also multi-pass forward rendering, but that has its own problems – more passes mean longer render times and thus a lower frame rate – and we wanted to keep the descriptions simple).

In the last 5 years, many games started using a technique called deferred rendering. In classic deferred rendering, there are two rendering passes. The first pass renders the positions, normals, and material values of all the meshes in the scene to something called a G-Buffer (two or more render targets); nothing is actually drawn to the screen in this first pass. The second pass uses the data from the G-Buffer (which tells us everything we need to know about the geometry that appears at each screen pixel) and combines it with the lights to create the final image that you see. By doing this, we decouple geometry and lighting. This makes it possible to add more lights to the scene with a much smaller performance impact than in forward rendering since we don’t need to create a really complex pixel shader to handle all the lights (single-pass forward rendering) or draw the geometry over and over again for each light (multi-pass forward rendering).

There are drawbacks to classic deferred rendering though. Even a minimal G-Buffer takes up quite a bit of memory and the more different types of materials you want to support, the larger the G-Buffer will need to be. Wolfgang Engel, an XNA/DirectX MVP, came up with a variation on deferred rendering which he called Light Pre-Pass Rendering. This is a three pass technique. We once again use a G-Buffer, but in this case it is smaller than the classic deferred rendering G-Buffer and can even be squeezed down to a single render target which makes it viable for graphics hardware which does not support drawing to multiple render targets at the same time.

The G-Buffer is created in the first pass by rendering all the scene geometry. It only needs to store normals and the geometry’s world position. We stored the world position of the geometry at that screen position in one render target and its normal at that screen position in second render target for simplicity.

The next pass draws the lights to a light accumulation buffer. The buffer starts out entirely dark and each light that is rendered adds brightness (and tint, if any) to the light buffer. These lighting calculations take into account the normal and world position of the geometry that is at each screen position, drawing the values from the G-Buffer, such that each light only affects the pixels it is supposed to have an impact on. In Maelstrom we ended up only using point lights (spheres of light that fade out as you get further from the light’s position), but you can use any kind of light you can imagine (spot lights and directional lights are the two other common light types). Adding more lights has a very low impact on rendering time and this kind of lighting tends to be much easier for the designer to work with since there’s no need for him or her to understand HLSL or even any complicated C++ in order to add, remove, reposition, or otherwise change any lights.

The final pass draws the geometry a second time. This time, though, all the lighting calculations are done so all we do here is just render the meshes with their appropriate materials, adjust the color values and intensities from the material based on the light buffer value, and we’re done. Each rendering style (forward, deferred, and light pre-pass) has its own benefits and drawbacks, but in this case light pre-pass was a good solution and choosing it let us show how a state-of-the-art graphics technique works.

Normal Mapping

We also incorporated normal mapping. Normal mapping makes us of a special texture (a normal map) in addition to the regular texture that a material has. Normals are values used in lighting calculations to determine how much a particular light should affect a particular pixel. If you wanted to draw a brick wall, you would typically create two triangles that lined up to form a rectangle and you would apply a texture of a brick wall to them as their material. The end result of that doesn’t look very convincing though since unlike a real brick wall there are no grooves in the mortared area between each brick since our brick and mortar is just a flat texture applied to flat triangles. We could fix this by changing from two triangles to a fully modeled mesh with actual grooves, but that would add thousands of extra vertices which would lower the frame rate.

So instead we use a normal map, which fakes it. One of the reasons that the two triangles + a brick wall texture approach doesn’t look right is because the lighting doesn’t behave correctly when compared to a real brick wall (or to a fully modeled mesh of a real brick wall). The normals point straight out perpendicular from the face of the rectangle whereas if we had the fully modeled mesh with actual grooves, the surface normals would only point straight out on the bricks themselves and they would curve along the mortared areas such that the lighting calculations would end up giving us the right levels of light and dark depending on the location and direction of the light. That’s where a normal map comes in. The normal map (which you can generate using a plugin for Adobe Photoshop or GIMP or by modeling a real brick wall in 3DSMax, Maya, or Blender which you then “bake” a normal map from) allows us to get the same lighting effect as we would with a fully modeled mesh while still keeping the simple two triangle + a brick wall texture approach that gives us really good performance for our game. There are limits to the effectiveness of normal mapping (you can’t use it to fake anything too deep and it doesn’t hold up as well if the camera can get really close to the object) but in Maelstrom it allowed us to keep the walls as simple triangles (like the two triangles + a brick wall texture example above) while making it seem like there were geometric grooves in the wall. Here’s a before and after screenshot using normal mapping:

Post-Processing Effects

We also used several post-processing effects. The first was the bloom effect. Bloom is an effect that analyzes a rendered image, identifies parts that are above a certain brightness threshold, and makes those areas brighter and adds a peripheral glow to them as well, giving it a look and feel that is similar to a neon sign or to the light cycles in the movie Tron. Here’s the same shot as above with the addition of bloom:

We also made use of two different damage effects. Whenever the player took damage, we had a reddish tinge around the edge of the screen. This was simply a full screen overlay texture that is actually white but is tinted red by the shader. It is alpha-blended over the final rendered scene and fades out over the course of a couple of seconds. Rather than fading out linearly, we use a power curve which helps to sell the effect as being more complicated than it really is.

Lastly we added in some damage particles. The particles themselves were created using a geometry shader. The vertex shader took in a series of points in world space and passed these points along to the geometry shader. The geometry shader expanded these points into two triangles by generating the missing vertices and applying the world-view-projection transformation matrix to transform the positions from world coordinates to homogeneous coordinates so that they can then be rasterized correctly by D3D and the resulting pixels passed along to the pixel shader. Once again we used a simple texture with alpha blending to simulate much more complicated geometry than we were actually drawing. In this case we also made use of a texture atlas (an image made up of smaller images) which, in conjunction with the randomizer we used to generate the initial vertices for the particles, allowed us to have several different particle textures. Like with the power curve for the damage texture, the texture atlas allowed us to make the particles seem more complex than they really were. It also let us show off the use of a geometry shader, a feature that was added in DirectX 10 and requires DirectX 10 or higher hardware.

Audio

All audio was done using the XAudio2 API.  Thankfully, we were able to get a huge head start by using some of the code from the sample project we started from.  The audio engine sets up the very basics of XAudio2, and then wraps that with a simpler API for the rest of the application to call.

We don’t have many sound effects, so we on startup, we load all sounds effects and music cues into a std::map, keyed on a SoundCue enum.  Sounds are loaded using the Media Foundation classes, and the resulting byte data of the sound (and some format information) are stored in our SoundEffect class.

void AudioEngine::Initialize()
{
    m_audio = ref new Audio();
    m_audio->CreateDeviceIndependentResources();

    m_mediaReader = ref new MediaReader();

    // Impacts
    m_soundMap[SoundCue::BallLaunch]    = LoadSound("Sounds\\Impacts\\BallLaunch.wav");
    m_soundMap[SoundCue::Buzz]          = LoadSound("Sounds\\Impacts\\Buzz.wav");
    m_soundMap[SoundCue::Impact1]       = LoadSound("Sounds\\Impacts\\Impact1.wav");
    m_soundMap[SoundCue::Impact2]       = LoadSound("Sounds\\Impacts\\Impact2.wav");

...

}

SoundEffect^ AudioEngine::LoadSound(String^ filename)
{
    Array<byte>^ soundData = m_mediaReader->LoadMedia(filename);
    auto soundEffect = ref new SoundEffect();
    soundEffect->Initialize(m_audio->SoundEffectEngine(), m_mediaReader->GetOutputWaveFormatEx(), soundData);
    return soundEffect;
}

When the game needs to play a sound, it simply calls the PlaySound method, passing in the cue to play, and the volume to play it at.  PlaySound keys into the sound map, getting the associated SoundEffect, and plays it.

void AudioEngine::PlaySound(SoundCue cue, float volume, bool loop)
{
    m_soundMap[cue]->Play(volume, loop);
}

MJPEG Cameras

To achieve the effect of seeing the opponent in stereoscopic 3D, we strapped two Axis M1014 network cameras side-by-side.  Using Brian’s MJPEG Decoder library, with a special port to Windows Runtime, individual JPEG frames were pulled off each camera, and then applied to a texture at the back of the arena.  The image from the left camera is drawn when DirectX renders the player’s left eye, and the frame from the right camera is drawn when DirectX renders the right eye.  This is a cheap and simple way to pull off live stereoscopic 3D.

void MjpegCamera::Update(GameEngine^ engine)
{
    if(m_decoderLeft != nullptr)
        UpdateTexture(m_decoderLeft->CurrentFrame, &textureLeft);

    if(m_decoderRight != nullptr)
        UpdateTexture(m_decoderRight->CurrentFrame, &textureRight);

    Face::Update(engine);
}

void MjpegCamera::Render(_In_ ID3D11DeviceContext *context, _In_ ID3D11Buffer *primitiveConstantBuffer, _In_ bool isFirstPass, int eye)
{
    if(eye == 1 && textureRight != nullptr)
        m_material->SetTexture(textureRight.Get());
    else if(textureLeft != nullptr)
        m_material->SetTexture(textureLeft.Get());

    GameObject::Render(context, primitiveConstantBuffer, isFirstPass);
}

With the distance between the cameras being about the distance of human eyes (called the intra-axial distance), the effect works pretty well!

Tablet/Controller

The Tablet controller is the touch screen that lets the player control their 3D paddle in the Game Console app. For this part of the game system, there wasn't a reason to dive deep into DirectX and C++ since the controller is neither stereoscopic or visually intense, so we kept things simple with C#.

Since the controller would also serve as our attract screen in the podium to entice potential players, we wanted to have the wait screen do something eye-catching. However, if you are moving from C# in WPF to C# and XAML in WinRT and are used to taking advantage of some of the more common "memory hoggish UX hacks" from WPF, you'll quickly find them absent in WinRT! For example, we no longer have OpacityMask, non-rectangular clipping paths or the ability to render a UIElement to a Bitmap. Our bag of UX tricks may be in need of an overhaul. However, what we do get in C# / XAML for WinRT is Z rotation, which is something we've had in Silverlight but I personally have been begging for in WPF for a long time.

Therefore, the opening animation in the controller is a procedurally generated effect that rotates PNG "blades" in 3D space, creating a very compelling effect. Here is how it works. The Blade user control is a simple canvas that displays one of a few possible blade images. The Canvas has a RenderTransform to control the scale and rotation and a PlaneProjection which allows us to rotate the blade graphic in X, Y and Z space.

<Canvas>
    <Canvas.RenderTransform>
        <ScaleTransform x:Name="scale" ScaleX="1.0" ScaleY="1.0" CenterX="0" CenterY="0"/>
    </Canvas.RenderTransform>
    <Canvas.Projection>
        <PlaneProjection x:Name="projection" CenterOfRotationX="0" CenterOfRotationY="0" CenterOfRotationZ="0" RotationX="00" RotationY="0" RotationZ="0"/>
    </Canvas.Projection>
    <Image x:Name="img0" Width="300" Height="100" Canvas.Left="-4" Canvas.Top="-12" Source="Images/s0.png"/>
</Canvas>

Each Blade is added dynamically to the Controller when the Tablet application first loads, stored in a List to have it's Update() method called during the CompositionTarget.Rendering() loop.

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    canvas_blades.Children.Clear();
    _blades.Clear();
    
    for (int i = 0; i < NumBlades; i++)
    {
        Blade b = new Blade { X = 950.0, Y = 530.0 };
        int id = _rand.Next(0, 5);
        b.SetBlade(id);
        b.Speed = .1 + id * .1;
        SeedBlade(b);
        _blades.Add(b);
        canvas_blades.Children.Add(b);
    }
}

void CompositionTarget_Rendering(object sender, object e)
{
    if(_inGame)
    {
        paddle.Update();
    }
    else if(_isClosing)
    {
        foreach (Blade b in _blades)
            b.UpdateExit();
    }
    else
    {
        foreach (Blade b in _blades)
            b.Update();
    }
}

Since each Blade has been assigned an individual speed and angle of rotation along all three axis, they have a very straightforward Update function. The reason we keep the rotation values between -180 and 180 during the spinning loop is to make it easier to spin them out zero when we need them to eventually leave the screen.

public void Update()
{
   _rotX += Speed;
   _rotZ += Speed;
   _rotY += Speed;

   if (_rotX > 180) _rotX -= 360.0;
   if (_rotX < -180) _rotX += 360.0;
   if (_rotY > 180) _rotY -= 360.0;
   if (_rotY < -180) _rotY += 360.0;
   if (_rotZ > 180) _rotZ -= 360.0;
   if (_rotZ < -180) _rotZ += 360.0;

   projection.RotationX = _rotX;
   projection.RotationY = _rotY;
   projection.RotationZ = _rotZ;
}

public void UpdateExit()
{
   _rotX *= .98;
   _rotZ *= .98;
   _rotY += (90.0 - _rotY) * .1;

   projection.RotationX = _rotX;
   projection.RotationY = _rotY;
   projection.RotationZ = _rotZ;
}

Network

To continue the experiment of blending C# and C++ code, the network communication layer was written in C# as a Windows Runtime component.  Two classes are key to the system: SocketClient and SocketListener.  Player one’s game console starts a SocketListener to listen for incoming connections from each game controller, as well as player two’s game console.  Each of those use a SocketClient object to make the connection.

In either case, once the connection is made, the client and the listener sit and wait for data to be transmitted.  Data must be sent as an object which implements our IGamePacket interface.  This contains two important methods: FromDataReaderAsync and WritePacket.  These methods serialize and deserialze the byte data to/from an IGameState packet of whatever type is specified in the PacketType property.

namespace Coding4Fun.Maelstrom.Communication
{
    public enum PacketType
    {
        UserInputPacket = 0,
        GameStatePacket
    }
    
    public interface IGamePacket
    {
        PacketType Type { get; }
        
        IAsyncAction FromDataReaderAsync(DataReader reader);
        void WritePacket(DataWriter writer);
    }
}

The controllers write UserInputPackets to the game console, consisting of X,Y positions of the paddle, as well as whether the player has tapped the screen to begin.

public sealed class UserInputPacket : IGamePacket
{
    public PacketType Type { get { return PacketType.UserInputPacket; } }
    
    public UserInputCommand Command { get; set; }
    public Point3 Position { get; set; }
}

Player one’s game console writes a GameStatePacket to player' two’s game console, which consists of the positions of each paddle, each ball, the score, and which tiles are lit for the ball splitter power up.  Player two’s Update and Render methods use this data to draw the screen appropriately.

Hardware

The hardware layer of this project is responsible for two big parts.  One is a rumble effect that fires every time the player is hit, and the other is a lighting effect that changes depending on the game state.

As all good programmers do, we reused code from another project.  We leveraged the proven web server from Project Detroit for our Netduino, but with a few changes.  Here, we had static class “modules” which knew how to talk to the physical hardware, and “controllers” which handled items like a player scoring, game state animations, and taking damage.  Because the modules are static classes, we can have them referenced in multiple classes without issue.

NETMF Web Server

When a request comes in, we perform the requested operation, and then return a new line character to verify we got the request. If you don’t return any data, some clients will actually fire a second request which then can cause some odd behaviors.  The flow is as follows:

1. Parse the URL
2. Get the target controller
3. Execute the appropriate action

private static void WebServerRequestReceived(Request request)
{
    var start = DateTime.Now;
    Logger.WriteLine("Start: " + request.Url + " at " + DateTime.Now);
    
    try
    {
        var data = UrlHelper.ParseUrl(request.Url);
        
        var targetController = GetController(data);
        
        if (targetController != null)
        {
            targetController.ExecuteAction(data);
        }
    }
    catch (Exception ex0)
    {
        Logger.WriteLine(ex0.ToString());
    }
    
    request.SendResponse(NewLine);
    
    Logger.WriteLine("End: " + request.Url + " at " + DateTime.Now + " took: " + (DateTime.Now - start).Milliseconds);
}

public static IController GetController(UrlData data)
{
    if (data.IsDamage)
        return Damage;
    
    if (data.IsScore)
        return Score;
    
    if (data.IsGameState)
        return GameState;
    
    // can assume invalid
    return null;
}

Making It Shake

We used a Sparkfun MP3 trigger board, a subwoofer amplifier, and bass rumble plates to create this effect.  The MP3 board requires power, and two jumpers to cause the MP3 to play.  It has an audio jack that then gets plugged into the amplifier which powers the rumble plates.

From here, we just needed to wire a ground to the MP3 player’s ground pin, and the target pin on the MP3 player to a digital IO pin on the Netduino.  In the code, we declare it as an OutputPort and give it an initial state of true.  When we get a request, we toggle the pin on a separate thread.

private static readonly OutputPort StopMusic = new OutputPort(Pins.GPIO_PIN_D0, true);
private static readonly OutputPort Track1 = new OutputPort(Pins.GPIO_PIN_D1, true);
// .. more pins

public static void PlayTrack(int track)
{
    switch (track)
    {
        case 1:
            TogglePin(Track1);
            break;
            // ... more cases
        default:
            // stop all, invalid choice
            TogglePin(StopMusic);
            break;
    }
}

public static void Stop()
{
    TogglePin(StopMusic);
}

private static void TogglePin(OutputPort port)
{
    var t = new Thread(() =>
    {
            port.Write(false);
            Thread.Sleep(50);
            port.Write(true);
    });
    
    t.Start();
}

Lighting Up the Room

For lighting, we used some RGB Lighting strips.  The strips can change a single color and use a PWM signal to do this.  This is different than the lighting we used in Project Detroit which allowed us to individually control each LED and used SPI to communicate.  We purchased an RGB amplifier to allow a PWM signal to power a 12 volt strip.  We purchased ours from US LED Supply and the exact product was RGB Amplifier 4A/Ch for interfacing with a Micro-Controller (PWM/TTL Input).

We alter the Duty Cycle to shift the brightness of the LEDs and do this on a separate thread.  Below is a stripped down version of the lighting hardware class.

public static class RgbStripLighting
{
    private static readonly PWM RedPwm = new PWM(Pins.GPIO_PIN_D5);
    private static readonly PWM GreenPwm = new PWM(Pins.GPIO_PIN_D6);
    private static readonly PWM BluePwm = new PWM(Pins.GPIO_PIN_D9);
    
    private const int ThreadSleep = 50;
    private const int MaxValue = 100;
    
    const int PulsePurpleIncrement = 2;
    const int PulsePurpleThreadSleep = 100;
    
    private static Thread _animationThread;
    private static bool _killThread;
    
    #region game state animations
    public static void PlayGameIdle()
    {
        AbortAnimationThread();
        
        _animationThread = new Thread(PulsePurple);
        _animationThread.Start();
    }
    #endregion
        
            
    private static void PulsePurple()
    {
        while (!_killThread)
        {
            for (var i = 0; i <= 50; i += PulsePurpleIncrement)
            {
                SetPwmRgb(i, 0, i);
            }
            
            for (var i = 50; i >= 0; i -= PulsePurpleIncrement)
            {
                SetPwmRgb(i, 0, i);
            }
            
            Thread.Sleep(PulsePurpleThreadSleep);
        }
    }
    
    private static void AbortAnimationThread()
    {
        _killThread = true;
        
        try
        {
            if(_animationThread != null)
                    _animationThread.Abort();
        }
        catch (Exception ex0)
        {
            Debug.Print(ex0.ToString());
            Debug.Print("Thread still alive: ");
            Debug.Print("Killed Thread");
        }
        
        _killThread = false;
    }
    
    private static void SetPwmRgb(int red, int green, int blue)
    {
        // typically, 0 == off and 100 is on
        // things flipped however for the lighting so building this in.
        
        red = MaxValue - red;
        green = MaxValue - green;
        blue = MaxValue - blue;
        
        red = CheckBound(red, MaxValue);
        green = CheckBound(green, MaxValue);
        blue = CheckBound(blue, MaxValue);
        
        RedPwm.SetDutyCycle((uint) red);
        GreenPwm.SetDutyCycle((uint) green);
        BluePwm.SetDutyCycle((uint) blue);
        
        Thread.Sleep(ThreadSleep);
    }
    
    public static int CheckBound(int value, int max)
    {
        return CheckBound(value, 0, max);
    }
    
    public static int CheckBound(int value, int min, int max)
    {
        if (value <= min)
            value = min;
        else if (value >= max)
            value = max;
        
        return value;
    }
}

Conclusion

We built this experience over the course of around 4 to 5 weeks.  It was our first DirectX application in a very long time, and our first C++ application in a very long time.  However, we were able to pick up the new platform and language changes fairly easily and create a simple, yet fun game in that time period.

Attributions

• Music track - "FatLoad- The Bullet(no master)" by FreaK NeoS
• Sound effects + music edition - David Wallimann
• DirectX shaders - Michael McLaughlin

KinÊtre: Animation + Whimsy

KinÊtre lets anyone create playful 3D animations.

Imagine you are asked to produce a 3D animation of a demonic armchair terrorizing an innocent desk lamp. You may think about model rigging, skeleton deformation, and keyframing. Depending on your experience, you might imagine hours to days at the controls of Maya or Blender. But even if you have absolutely no computer graphics experience, it can be so much easier: grab a nearby chair and desk lamp, scan them using a consumer depth camera, and use the same camera to track your body, aligning your virtual limbs to the chair’s geometry. At one spoken command, your limbs are attached to the chair model, which follows your movements in an intuitive and natural manner. KinÊtre is such a system. Rather than targeting professional animators, it brings animation to a new audience of users with little or no CG experience. It allows realistic deformations of arbitrary static meshes, runs in real time on consumer hardware, and uses the human body for input in conjunction with simple voice commands. KinÊtre lets anyone create playful 3D animations.

Project Information URL: http://research.microsoft.com/en-us/projects/animateworld/

KinÊtre: Animation + Whimsy

First, there was Kinect. You’ve probably heard of that one. Next, it was KinectFusion, which uses live data from Kinect for Windows to create high-quality, 3-D models of a room and its contents. KinectFusion made a splash in 2011 during the 38th International Conference and Exhibition on Computer Graphics and Interactive Techniques (SIGGRAPH).

Now, it’s time for KinÊtre, the latest Microsoft Research project that uses a Kinect depth camera to provide novel functionality: Among other animations, it can make chairs dance.

No, your eyes didn’t deceive: dancing chairs. If that sounds like fun, you’ve come to the right place.

KinÊtre, which can animate all sorts of inanimate objects, will be presented as a talk by Jiawen Chen during SIGGRAPH 2012, being held at the Los Angeles Convention Center from Aug. 5 to 9. Perhaps the best introduction to the project is this informative video:

The idea is that we want to let you bring the world around you to life,” Chen says. “We want to let you use Kinect for Windows and a PC and take arbitrary household objects and make them move like a cartoon character.”

The process to engage is deceptively simple. You use a consumer depth camera to scan an item such as a chair, a desk lamp, a bookcase, or a stepladder. Then you use the same camera to track your body and align your virtual limbs to the geometry of the item. With a word—“Possess!”—your virtual limbs are attached to the item. When you jump, the bookcase jumps. When you dance, the chair dances.

And, using KinÊtre—a portmanteau that combines “Kinect” with the French verb for “to be”—anyone can create playful, 3-D models.

...

Other usage possibilities for KinÊtre include storytelling by children—the technology is sufficiently intuitive and accessible for kids to use—and gaming.

At the core of the technology is non-linear numerical optimization, enabling what Chen calls “a fairly robust, very easy method to make arbitrary things come to life.”

Still, the best way to understand KinÊtre is simply to see it in action. (Watch that video!) Chen gleefully recalls the reaction he got in March while demonstrating its capabilities during TechFest 2012.

“The best fun was seeing tons of Microsoft employees realize how fun it is,” he smiles. “Explaining it to them didn’t make too much sense. You have to experience it.”

Project Information URL: http://blogs.technet.com/b/inside_microsoft_research/archive/2012/08/07/kin-202-tre-animation-whimsy.aspx

KinÊtre - Animating the World with the Human Body

When I first saw the KinÊtre project from Microsoft Research I wasn’t quite sure what to make of it – a novel use for Kinect yes, but what would it be used for other than some fun? And then I thought about my childhood watching cartoons with inanimate objects, animated to behave like humans.

KinÊtre is being presented at SIGGRAPH 2012 this week in Los Angeles. A project from Microsoft Research in the UK, it uses the capabilities of Kinect for Windows to map your virtual limbs to the geometry of a variety of household objects such as a chair or lamp. After scanning a physical objects using KinectFusion (another project from Microsoft Research in Cambridge, England) a 3D mesh of that object is created. A spoken command (possess) attaches your limbs (virtually) where they overlap with the mesh and the virtual object then follows your movements. This is far easier to understand by simply watching the video above.

KinÊtre isn’t targeted at professional animators but for those with zero experience in the field of animation, it’s a fun tool and another demonstration of how our own researchers are continuing to push the boundaries with Kinect – and advance the state of the art in graphical-based technologies.

Project Information URL: http://blogs.technet.com/b/next/archive/2012/08/07/kin-202-tre-animating-the-world-with-the-human-body.aspx

Helix 3D Toolkit

Project Description
Helix 3D Toolkit is a collection of custom controls and helper classes for WPF 3D. The toolkit contains controls to manipulate the camera, classes to import models (3ds,lwo,obj) and export models.

NuGet package
http://nuget.org/List/Packages/HelixToolkit (updated at every code check-in)

Features

• Camera manipulation control
  • Turntable rotation
  • Trackball rotation
  • Zoom extents
  • Zoom by rectangle
  • Change field-of-view
  • Zoom/Rotate around the mouse down point
  • Support for orthographic and perspective cameras
  • Support for touch manipulation events (e.g. pinch to zoom)
• Controls
  • HelixViewport3D - camera manipulation, lights and a Viewport3D
  • StereoView3D - cross/parallel stereo viewing
  • AnaglyphView3D - anaglyph viewing (requires red/cyan glasses)
  • ViewCube - rotates the view to align with selected faces of a cube
• Input
  • Support for 3D Connexion SpaceNavigator
  • Examples for Wii remote
  • Examples for Kinect
• Export
  • Kerkythea render engine
  • Wavefront files (.obj)
  • X3D (not finished)
  • Collada (not finished)
  • VRML97 (not finished)
  • POV-Ray (not finished)
• Import
  • 3D Studio files (.3ds)
  • Lightwave files (.lwo)
  • Wavefront files (.obj)
  • StereoLithography files (.stl)
• MeshBuilder - generates MeshGeometry3D
  • Extrude
  • Revolve
  • Loft
  • Boxes
  • Rectangular meshes
  • Tubes
  • Cone/Cylinder
• Subdivision surfaces (Loop)
• Visual3D objects
  • Arrow
  • Box
  • Cube
  • Rectangle
  • Lines (screen space thickness)
  • Points (screen space size)
  • GridLines
  • PieSlice
  • Sphere
  • TruncatedCone
  • Tube
  • Pipe
  • CoordinateSystem
  • Light
  • PanoramaCube
  • Terrain
  • Text
  • Billboard
  • Text billboard
  • Cutting planes
  • SortingVisual3D (sorts transparent objects by distance from camera)
• Effects
  • Anaglyph shader effect

The only way to really get a feel for this project is to download it and play with the Samples.

Here's just a few of them from the included Sample Browser

From real time cloth examples;

To building LEGOs

There's other demo's to, like the 360 degree panorama viewer;

And my favorite, the Solar System;

Why is this my favorite? A couple reasons. First, how the textures are used to show rotation. Check out the spot on the Sun and how it moves over time. Same for the Earth and other planets. Second is how the solar system is "created".

Yep, creating the Solar System via WPF (and MVVM). How cool is that?

And yes, you get all the source for all of this, the examples and the Toolkit too.

If you're creating 3D based applications in WPF, you need to check out this toolkit...

That's why today's post caught my eye. It's not "code" per-se (though there is a little C#!) instead it's a easy, simple and fairly short introduction to Unity3D.

Introduction to Unity3D

Unity3D is a powerful cross-platform 3D engine and a user-friendly development environment. Learn how Unity3D can help you create games in this article!

What is Unity3D?

Unity3D is a powerful cross-platform 3D engine and a user friendly development environment. Easy enough for the beginner and powerful enough for the expert; Unity should interest anybody who wants to easily create 3D games and applications for mobile, desktop, the web, and consoles.

The article starts off talking about cost, installation and basic getting started stuff.

Through to scripting and publishing;

If you've heard of Unity3D before but didn't know how to get started with it, this is the perfect article for you...

Geomagic demonstrates Kinect-To-Print for 3D printers (video)

We're still waiting to check out 3D Systems Corporation's 3D printing service at CES. In the meantime, Geomagic, which powers the Kinect-To-Print app for the company, has released a video demonstrating the process by which a Kinect image gets turned into a printable template. Essentially, Geomagic uses the Kinect to capture a series of points, then turns them into a 3D model which can be sent to the printer or, presumably, uploaded to "create-and-make" environment Cubify.

...

Project Information URL: http://www.theverge.com/2012/1/10/2696115/geomagic-cubify-3d-printer-kinect-video

Perfecting the 3D human face

Windows 7 in 94% of new PC's in 2011

Microsoft dresses up the ladies

The Excel Competition

and just for fun....

Kinect Jockey

• John's blog and on Twitter (@john_papa)

• Aaron's blog and on Twitter (@aaron_oneal)

• Shawn Hargreaves' blog on game programming with XNA

• Solar Wind sample app

• Housebuilder demo

• Babylon Engine and Toolkit

• Balder 3D engine

• Silverlight.net

Follow us on Twitter @SilverlightTV or on the web at http://silverlight.tv

• John's blog and on Twitter (@john_papa)

• Silverlight.net

Follow us on Twitter @SilverlightTV or on the web at http://silverlight.tv

Researchers at the company, alongside staff at the University of Washington are using 3D cameras and recognition and projection technology to build virtual worlds around physical objects made from Lego. 

This video shows the research in action – if you’re six years old (or thirty-six like me) prepare to be blown away. Place a Lego dragon on the table, it breathes fire. Place said fire-breathing dragon next to Lego house? Guess what happens next. But don’t worry – build yourself a quick fire engine and disaster can be averted.

But that’s nothing compared to what they can do with a Lego train. I won’t spoil the fun, but what I wouldn’t give to be six again! Back in the late 70s, we had to make do with spacehoppers and not-very-good Star Wars figures. Fingers crossed when my own son reaches that age, this tech will be ready to go!   

If you’ve been feeling sartorially challenged when getting your 3D on, then a more fashionable option may not be too far away.  Last week, Hot Hardware featured new eyeware from Calvin Klein, who have teamed up with Marchon3D to bring fresh style to 3D specs. According to the PR, these are not mere 3D glasses, but are 3D-enabled sunglasses infusing technology with “sleek, fashion-forward design.” So there.

The specs are certified to protect against UVA, UVB and UVC rays (although you’d actually need to be an astronaut to run the risk of natural UVC damage, as it gets filtered by the atmosphere before it lands here on planet Earth) and has photochromic lens technology, so you can wear them indoors or out.

If you want to enjoy your next 3D experience without being stopped by the fashion police, then these may well be for you. Or maybe not.

Samsung have spotted the problem, and have launched the world’s first prescription 3D glasses over in Korea (reports Akihabara News). The glasses are custom made to your prescription by an optometrist, and take around a week to manufacture.

There’s no word on price, but given you never see a poor optometrist out there, I’m sure there’ll be a healthy premium for the specs. It’s a potentially lucrative new line for your local optical professional though – who knows, maybe they’ll take on the big box retailers and throw in some decent service for once. Forget hours of online research, given we spend so much time looking at our TVs, a eyecare professional may well offer the best advice on which model to buy with those glasses.

3D is all the rage right now, with millions of marketing dollars being employed to convince to you switch your TV and Blu-ray player and pop on those 3D glasses every night. Right now, I wonder just how much of the noise is translating into sales, but of course, that conversion will almost certainly be driven by content.

Certainly Sky believe that Sport is a big winner in 3D, with Golf, Football and Rugby on offer in the new format. That’s a view shared by ESPN in the US, who have launched their own 3D Sports Channel showing College Football. DirecTV, Channel + and Discovery Channel have all announced plans to launch 3D Channels in the next 12 months.

That said, it still feels like it’s a little early for the 3D revolution, but with a lot more TV, Movie and Gaming content on the way, I wonder just how long it’ll be before you upgrade? 

Image credit: We Got Served

Also announced at the show was the next version of IIS Media Services, the media delivery platform that delivers live and on-demand media across an enterprise or from telcos and cable providers to their customers. One of the most notable new features in this version of IIS is the ability for broadcasters to “encode once” and then deliver content-protected media to both Silverlight and non-Silverlight devices.

Microsoft demoed these technologies at the show, in conjunction with Inlet Technologies, Level 3 Communications, THX Ltd. and TVN. Together, they were able to create a demonstration of live, high-definition 3D content using IIS’s Smooth Streaming and Silverlight. 

• Robby's Blog, Twitter
• Pete's Blog, Twitter
• Tor's Site, Twitter

If you want to see the games in action, Crunchgear has posted a video demonstrating some of the more interesting titles on their Zune HD device. And on the Mobility Site, they’ve reviewed a few of the new games including PGR, Lucky Lanes, and Audiosurf Tilt.

In order to download the new games to your device, you’ll need to do the following:

1. Connect your Zune HD to your computer and sign into the Zune software.
2. Click on Marketplace, Apps.
3. Select the game or app you want, then click Download.
4. Go to Collection, Apps, and drag the games and apps that you want to the Zune player icon to sync them.

Finally, to access games and apps on your Zune HD, on the home screen tap Apps, then tap the game or app you want.

You can learn more about each individual game by reading the descriptions provided here.