Published: 15 Sep 2010
By: Xianzhong Zhu

In this second part of the series, we are going to continue to discuss the Balder engine in the aspect of other advanced concepts and features, i.e. Light, View and Camera.

Contents [hide]

The Integrate the 3D Engine Balder into Your Silverlight Applications Series

  • Part1 In this series of articles, you will learn how to integrate the famous 3D Engine - Balder into your Silverlight applications.
  • Part2  In this second part of the series, we are going to continue to discuss the Balder engine in the aspect of other advanced concepts and features, i.e. Light, View and Camera.
  • Part 3 In this final part of this series, we are going to learn other advanced concepts support in Balder, such as Sprite, Skybox, HeightMap, the MVVM pattern, and more.
  • Introduction

    In this second part of the series, we are going to continue to discuss the Balder engine in the aspect of other advanced concepts and features, i.e. Light, View and Camera. And at the same time, related samples are provided; please do note the relevant sample Silverlight UserControl name.

    NOTE

    1. The second part related samples are located in another project named Balder_tut_Adv.

    2. The development environments and tools we'll use in these series of articles are all the same as the ones covered in the first part.

    Let's start to check out the light support in the Balder engine.

    Light Support

    In this section, we will first introduce the basic support for lights in Balder. Then, we will discuss the commonly-used properties in terms of light programming. Finally, we will create the corresponding sample applications.

    How many kinds of lights introduced in Balder?

    In fact, in the samples in the first article we have already put Light into use, only mainly around the OmniLight. In fact, three kinds of Lights have been introduced into Balder, i.e. DirectionalLight, OmniLight, and ViewLight. The following figure gives the relationships between them.

    Figure 1: Different kinds of lights in Balder and comparison

    Different kinds of lights in Balder and comparison

    • Directional light: as the name implies, it casts light in a specific direction, which is similar to sunlight. In Balder this is referred to as DirectionalLight.
    • Point light: It casts light from a single point in all directions. It is similar to the real-case light bulbs, which is also known as omni light (omni directional light). In Balder this is referred to as OmniLight.
    • View light: It casts light using the shape of a cone. Thus, only the models that fall inside the cone will be affected by this kind of light, which is spot light (similar to the spot lights used in theaters). In Balder this is referred to as ViewLight.

    All the above kinds of lights are located in the namespace Balder.Lighting. Figure 2 below illustrates the dependency graph in this namespace, through the Visual Studio Architecture tool.

    Figure 2: The objects dependency graph defined in the namespace Balder.Lighting

    The objects dependency graph defined in the namespace Balder.Lighting

    Obviously, changing their properties to visualize the practical effects is the best way to understand the three different kinds of lights in Balder. Moreover, we can get an idea of their differences by creating related samples.

    Basic samples

    Now, let's build up some basic samples to look into the basic usage of the different kinds of lights in Balder.

    1. The directional light

    Let's look at a basic application of the directional light. Listing 1 below shows the main part of related XAML markups (in the UserControl DirectionalLight.xaml).

    Listing 1: DirectionalLight sample related XAML code

    For simplicity and emphasis, we've only put a directional light in the scene. The Position property refers to the position of the light; the Direction property specifies the shine-out direction of the light, which defines a vector from the original coordinate point to point (0,-1, 0). However, the value (0, 1, 0) of the Direction property defines a vector from point (0, 1, 0) to the original coordinate point. The default value of the Strength property is 1.0. Please make clear all the properties here in combination with the figure listed above. Figure 3 below illustrates one of the related running-time snapshots of this demo.

    Figure 3: A directional light in action

    A directional light in action

    Note in this sample, since we specify the InteractionEnabled property of the box to true, you can easily rotate it to the directional effect of the light by dragging the box. Also, for clarity, we've placed a small red box representing the position of the light.

    2. The omni light

    Listing 2 below shows the main XAML markups associated with the omni light sample (in the UserControl OmniLight.xaml).

    Listing 2: The omni light sample related XAML code

    In the definition of the OmniLight object, we should pay special attention to the Diffuse property and the Strength property. As you've known, an omni light is also called point light. The Diffuse property mainly represents the color of this kind of light, while the Strength property, as with the directional light, indicates the strength of this color. Another property - Range will participate in the calculation of the final effect of the light. In this case, we specify its value ranging from 0 to 100. You will notice when the value of the Range property equals to 0, the box turns black, while for other values the color of the box changes little. Related complex calculation formula will not be discussed here.

    Figure 4 shows one of the related running-time snapshots.

    Figure 4: An omni light in action

    An omni light in action

    Here, you can use the slider controls to change the values of the Range property and the Y coordinate of the Position property to give a closer study. And also, you can rotate the box by dragging it.

    3. The view light

    First of all, we should notice that the ViewLight is derived from the DirectionalLight class. To gain a clearer idea, you can refer to code in Listing x below.

    Listing 3: The definition of the ViewLight class

    Apparently, the only special things are the three properties, XAngleOffset, YAngleOffset, and ZAngleOffset. As for how the three properties participate in the light related calculation and affect the finial lighting, we are not going to go deep into this. Instead, a simple sample will bring to you a more intuitive understanding with them, by changing the related values.

    Listing 4 below shows the main XAML markups associated with the view light sample (in the UserControl ViewLight.xaml).

    Again, the only special things are the three new properties, XAngleOffset, YAngleOffset, and ZAngleOffset defined in the ViewLight object. So, we are to elide the related explanations, but you can refer to the running-time result shown in Figure 5 to do simple test.

    Figure 5: One of the snapshots of the view light in action

    One of the snapshots of the view light in action

    Here, you can change the values of the height, strength, and the three properties, XAngleOffset, YAngleOffset, and ZAngleOffset of the light to watch the final result.

    Till now, we've only illustrated the simplest usages of the three kinds of lights in Balder. I suggest you to refer to other samples in this series to try to depict the rest stuffs like that in 3DS MAX to gain a better understanding with the related concepts. And also, you can, as you see in 3DS MAX (or any other 3D modeling IDEs), place several lights (possibly of different kinds) in a 3D scene as required.

    Anyway, I believe by combining the different kinds of lights, their colors, positions, rotations, and parameters, you are sure to create the final splendid effects, such as explosion, flash, sunrise, nightfall, etc., in your Silverlight applications.

    Camera Support

    To create dazzling real-time scenes in our Silverlight games, we have to familiarize ourselves with the inner-workings of 3D cameras. Only when we are capable to control the properties of the 3D cameras on the fly, and further to switch between multiple cameras, can we achieve the final target to give breath-taking life to our 3D models. In fact, the camera defines an eye for the models in the 3D world, so that moving and rotating the camera animates the models in our 2D screen.

    In the first part of this series, we have always been working with simple 3D scenes with merely a single camera. Although we were able to show a 3D model, we were neither able to move the camera nor changed its properties, not to mention defining and controlling many cameras. Starting from the next section, all of these undone things will become true.

    Definitions and related properties

    To achieve the above goals, we'd better first exploit the powerful camera classes offered by Balder and all related supports. Then, we can define the related kinds of cameras and change their properties in real time. Lastly, we can combine the camera's management with the model's animations and create amazing scenes from a 3D world in a 2D screen.

    Now, please look into the Camera class definition.

    Listing 4: The Camera definition in Balder

    Notice that the above definition virtually shows you a perspective camera, which is just the frequently-used one. As seen from above, generally-used properties of the Camera class are:

    • Position: a 3D coordinate point (default: {0, 0, 0}), where the center of the camera is located.
    • Target: a 3D coordinate point (default: {0, 0, 1}), where the center of the target is located.
    • Up: a 3D coordinate vector (default: from {0, 0, 0} to {0, 1, 0}, in the positive Y direction), which specifies the orientation of the camera.
    • FieldOfView: a float value (default: 45f), which defines the angle for the perspective camera's lens. A low value for this angle will narrow the view, so that the models will appear larger in the visible part of the 3D world. Conversely, a high value for this angle will widen the view, so that the models will appear smaller in the visible part of the 3D world.
    • Near: a float value, whose default value is 0.1f.
    • Far: a float value, whose default value is 4000f.

    Now, let's look more closely at the 3D representation and its relation with the near clipping plane, far clipping plane, and perspective field of view in the following diagram.

    Figure 6: The frustum defined in Balder using the near clipping plane, far clipping plane, and perspective field of view

    The frustum defined in Balder using the near clipping plane, far clipping plane, and perspective field of view

    In detail, the near clipping plane is used to control the position of the plane that slices the top of the pyramid and determines the nearest part of the 3D world that the camera is going to render in the 2D screen. You can change the near clipping plane to define the frustum through the Near property. Its default value is 0.1f. The far clipping plane is used to control the position of the plane that slices the back of the pyramid and determines the more distant part of the 3D world that the camera is going to render in the 2D screen. Note the value is expressed taking into account the Z-axis. You can change the far clipping plane to define the frustum to render through the Far property. Its default value is 4000f.

    As for the ProjectionMatrix and ViewMatrix properties, these are advanced concepts participating in the camera related calculation.

    Another kind of camera provided in Balder is OrthographicCamera. It simple derives from the Camera class. Listing 6 gives its definition.

    Listing 5: The OrthographicCamera class definition in Balder

    Now, let's examine a related sample. Please refer to the following XAML code (see file OrthographicCameraTest.xaml in the sample project Balder_tut_Adv).

    Listing 6: The OrthographicCamera in action

    Here, I don't want to explain what the difference between a perspective projection and an orthographic projection is (you can refer to elementary documents about DirectX or OpenGL), but let Figure 7 tell you the differences.

    Figure 7: OrthographicCamera and Camera lead to different rendering results

    OrthographicCamera and Camera lead to different rendering results

    For brevity, we merge the two pictures into one. As you've seen, the left one is taken using OrthographicCamera while the right one Camera. An important thing worth noticing is in the OrthographicCamera case the InteractionEnabled property of the Box geometry loses its effect. Is this a bug in Balder 0.8.8.8?

    So much is for the abstract concepts. Next, let's build up some related samples.

    The first sample (ModifyCamera.xaml)

    Now, let's start to write a sample to watch the intuitive influence upon the objects in the scene by changing the values of the important properties of the camera.

    First, let's look at the key part of the XAML code, as listed below.

    As is shown, a teapot is put into the scene, with the value of the InteractionEnabled property set to True, through which you can rotate the teapot freely to look at the teapot better. Also, an omni light is placed inside the scene. Finally, we defined a perspective camera, with some of its properties specified - using the default values for the rest omitted properties.

    There is no coding required in the behind file ModifyCamera.xaml.cs. So, let's see the running-time snapshots. Figure 8 illustrates the initial one.

    Figure 8: The initial snapshot for the first camera modifying sample

    The initial snapshot for the first camera modifying sample

    Please note here we are going to change the parameters to affect the camera (with which to look at the scene), but not to move or rotate the teapot itself.

    Now, change the value for the perspective field of view (usually 45 degrees by default). You will notice that fewer models (if there are any, but only one in our case) in the scene, but the teapot will be shown bigger (further away from the camera), as in the following screenshot.

    Figure 9: The snapshot with the value of the property FieldOfView changed to 27

    The snapshot with the value of the property FieldOfView changed to 27

    As you reduce the far clipping plane value, you will see that many pieces of the 3D model in the rendered scene begin to disappear, as shown in the following screenshot.

    Figure 10: One of the running-time snapshots when the value of the Far property set to 100

    One of the running-time snapshots when the value of the Far property set to 100

    Till now, we've created a simple sample changing the values of the properties of the camera using XAML data bound mode. Next, let's build another sample to still change the values of the properties of the camera but using the more flexible and advanced way.

    The second sample(Balder_Camera.xaml)

    This sample is a revised one from the online Balder samples. Let's first look at the running time snapshot.

    Figure 11: Rotate the object around the x and y axes and zoom in/out it

    Rotate the object around the x and y axes and zoom in/out it

    In this figure, you can drag the first two slider controls to let the ball rotate around the x-axis and y-axis, respectively. By dragging the third slider control, you can zoom in or out the earth object. Moreover, to gain a better understanding with the effect, we put a camera picture (a Sprite) at the camera corresponding position. Of course, when the sphere revolves around the axes, it rotates too.

    Now, let's take a look at the related XAML markups.

    Two things are worth noticing here. One is the Sprite object that is used to indicate the position of the camera; the other is dragging the sliders will trigger the behind ValueChanged event.

    NOTE:

    By setting the value of the InteractionEnabled property to true, we can conveniently do all kinds of tests in Balder 0.8.8.8. This case is suitable to Meshes or built-in geometry objects, but not fit for the Sprite. It is true at least for version 0.8.8.8.

    Next, let's follow up the scent to see the ValueChanged event related coding.

    Inside the method CalculateCameraPosition, there are several matrix related calculations. The final aim is recalculate the position of the camera. Here, the complexity of 3D programming appears. I.e. if you do not have a clear idea of the matrix calculations, this kind of programming may be not suitable to you. However, this is indeed the most flexible way in the 3D programming. In the next article, we will look into the 3D matrix related knowledge and related application.

    Multiple cameras in action(Multiple_Games_Sim.xaml)

    In Balder, one Game instance can only hold one camera. However, in real-case 3D animation applications, multiple cameras are frequently required. For this, the latest 0.8.8.8 provides support for multiple Game instances.

    Now, let's see a related sample to use multiple Game instances, and accordingly, cameras. Figure 11 shows one of the running-time snapshots.

    Figure 12: Multiple cameras in action

    Multiple cameras in action

    Let's look into the XAML code first.

    Here, we've put two empty Game instances. As for the PassiveRendering property, according to the author of Balder, by controlling the PassiveRendering and PassiveRenderingMode properties, we can specify the rendering type that will occur between full-frames when it actually renders. I'm sorry for now that I've not done the related test.

    Then, in the behind file Multiple_Games_Sim.xaml.cs, we populate all that are needed into the scenes.

    Till now, I believe there are not any to worthy to be explained. There are only two things required to be emphasized. One is there is a method named Clone defined in the Node class. For simple geometries or lights, we can use it to create another cloned one to simplify the operations. For the above meshes, however, if you use the Clone method to create teapot2, there is still much to do due to the Clone method cannot copy the materials and other related info except for the simple geometry info. The second point deserves noticed is the LoadContent event will be triggered before the event Loaded of the UserControl (Multiple_Games_Sim in our case). This is why we created the required objects in the constructor.

    Summary

    In fact, in this article, we've mainly discussed two things, the light and camera. These two are the MUST HAVE in any 3D programming, both of which (especially the camera) are relevant to complex matrix calculations and much solid geometry knowledge. As seen from this article, although the Balder engine only provides limited support in these aspects, they can assuredly meet the requirements of most 3D scenarios. In the next article, we will continue to explore other advanced support in Balder, i.e. Sprite, Skybox, HeightMap, the MVVM pattern, and more.

    The Integrate the 3D Engine Balder into Your Silverlight Applications Series

  • Part1 In this series of articles, you will learn how to integrate the famous 3D Engine - Balder into your Silverlight applications.
  • Part2  In this second part of the series, we are going to continue to discuss the Balder engine in the aspect of other advanced concepts and features, i.e. Light, View and Camera.
  • Part 3 In this final part of this series, we are going to learn other advanced concepts support in Balder, such as Sprite, Skybox, HeightMap, the MVVM pattern, and more.
  • <<  Previous Article Continue reading and see our next or previous articles Next Article >>

    About Xianzhong Zhu

    I'm a college teacher and also a freelance developer and writer from WeiFang China, with more than fourteen years of experience in design, and development of various kinds of products and applications on Windows platform. My expertise is in Visual C++/Basic/C#, SQL Server 2000/2005/2008, PHP+MyS...

    This author has published 81 articles on DotNetSlackers. View other articles or the complete profile here.

    Other articles in this category


    Code First Approach using Entity Framework 4.1, Inversion of Control, Unity Framework, Repository and Unit of Work Patterns, and MVC3 Razor View
    A detailed introduction about the code first approach using Entity Framework 4.1, Inversion of Contr...
    jQuery Mobile ListView
    In this article, we're going to look at what JQuery Mobile uses to represent lists, and how capable ...
    Exception Handling and .Net (A practical approach)
    Error Handling has always been crucial for an application in a number of ways. It may affect the exe...
    JQuery Mobile Widgets Overview
    An overview of widgets in jQuery Mobile.
    Book Review: SignalR: Real-time Application Development
    A book review of SignalR by Simone.

    You might also be interested in the following related blog posts


    Visual Studio Add-In vs. Integration Package Part 3 read more
    Why Embedded Silverlight Makes Sense read more
    Telerik Announces Support for Microsoft Silverlight 3 read more
    What is .NET RIA Services? read more
    Moonlight 1.0 Released, Silverlight script updated – and a Chrome hack read more
    Rendering A Single View Using Multiple ViewEngines read more
    URL Rewrite for IIS - SEO Friendly URLs love it ! read more
    Some Silverlight ecosystem updates read more
    Search for Rich Internet Applications read more
    The Social API we really need. read more
    Top
     
     
     

    Please login to rate or to leave a comment.