So far, I have not gone into any much details about my new job. I wanted to settle into the position before giving a more complete overview of my job. Of course, I cannot say everything, especially when it relates to upcoming releases but an overview would be a good idea.

New new job is as part of the eHome Devices division, which focuses mainly on the Media Center Extender technology. Overall, Media Center Extenders are devices which can connect to a Media Center PC to share multimedia content. Until recently, the only extender out there was the Xbox 360 which could connect to Media Center PC to share video, pictures and music across a wired or wireless home network. But recently a first wave 3rd party extenders by manufacturers such as Linksys, D-Link and HP were released; essentially giving the same functionality at a lower cost than to have to dish out for a full Xbox 360.

Personally, I really like the new HP televisions with the extender technology built in. Simply plug your television into your home network and you can then browse your personal library of media content directly from your TV without the need for any external hardware. I think this is critical, especially for me, who envision the scenario where a single Media Center PC takes care of acting as a household DVR and all televisions simply act as extenders who access the video stream from the central computer.

You can find more information about the Media Center Extenders here: http://www.microsoft.com/windows/products/winfamily/mediacenterextender/default.mspx

So where do I fit in the scheme of all this? I am still technically a graphics programmer and will be focusing on the user interface technologies used by the Media Center Extenders (or MCX). This includes both the Xbox UI and also the needed technology for other 3rd party extenders. Although still graphics, it is done at a much lower level (especially on 3rd party extenders). For me, it is a move closer to my "Demo Scene" roots and should be an interesting challenge considering that most of 3rd party extenders run on fairly low-end CPUs where the user interface needs to be processed in real-time, even at 1080i resolutions!

About time hunh? I know, acceleration is already out and I was not even finished with the overview of all the features I worked on for my blog. That's life for ya...

Before I start explaining anything, the two videos below compare the DX10 and DX9 water effects...

See the difference? Well I swear there is one, and the quality of these video clips sure doesn't give it justice. Of course, those that remember this magical "PR mock-up" screen shot showing what DX10 could be, you probably say the dynamically moving water with waves crashing on the shoreline,... Obviously this did not happen. Probably the best way to approach this topic is to start explaining what happened and then go through the things that didn't happen and explain why.

What Did Happen in DX10

Most of the work for DX10 was kept as small size chunks. This was on purpose to try and keep our work balanced between the various features. But overall here is a breakdown of the improvements made:

• Performance improvements to the generation of the reflection map. Turns out we were doing alot of useless things to generate this low-resolution texute. This is still not perfect but in some extreme cases it did create a 20% performance improvement on my DX10 system.
• Significant enhancements to the water shader. For the most part this includes the addition of more bump for the water so the bumpiness appears less repetitive and more dynamic. I have also added a new "detail bumpmap" which only kicks in when the viewer is closeby. This is to compensate for the lack of resolution of the bump when on the water (which created really blocky lighting and reflection). This texture does fade out with distance to avoid any aliasing problems.
• Also, I added support for simple whitecaps. At this time, it isn't done through dynamically generated particles or other geometry but it is actually done procedurally within the pixel shader based on an estimation of the local turbulence. It actually looks quite nice considering the simplicity of the algorithm.
• I also started the implementation of the framework needed to allow the variation of the water settings on a per-waterclass basis. The code that is in place is not complete and was disabled. This feature came in too late and was too risky to turn on so we did have to "ditch it" at the last minute.

What Didn't Happen in DX10 :(

Actually, the main thing that did not happen and which is the main feature that is noticed is the dynamically waving water. This was indeed in the initial plans for SP2/Acceleration. Actually, this was even in the initial FSX plans but at the time the only solution was to do this on the CPU and seeing that it would consume 30-50% of the CPU on complex scenes, we decided to postpone this feature until it could be done on the graphic hardware.

Of course, DirectX 10 was a prime opportunity for this. However a few problems caused us some grief. The initial plan was to leave the water geometry as-is and let the GPU tesselate the geometry within the new geometry shader. Well once the real hardware came out, it turned out that geometry shaders we not performant enough to accomplish this. The second option was to pre-generate the water geometry but let the dynamic update happen on the GPU. The problem in that case is that it would roughly double the terrain/water geometry memory footprint.

In other words we were doomed either way and deemed this was just too risky at the moment, at least until we could fully investigate the consequences of each option and to see what else could be done.

My Winzip trial expired again, but this time I noticed something interesting. In addition to the "Buy Now" option, there was now a "Use TrialPay" option. Out of curiosity, I checked it out.

Turns out that they offer a new twist on affiliate marketting. Instead of loosing a sale when a customer does not feel like spending $XX for your software, you can use TrailPay to instead offer them a variety of partner offers for which they can join. If they do decide to signup for the offer, then TrialPay does pay you a portion of the affiliate proceeds and at the same time the customer gets a free copy of your software as a bonus. To quote their website:

TrialPay is an innovative payment method that enables customers to pay you by trying something else. Through TrialPay, customers can purchase your product or receive a gift certificate for your site by trying an offer from a reputable advertising partner. Because we have advertising partners who place high values on interacting with new customers, we can often pay you more for your product than the retail price. We have access to diverse offers from thousands of companies so your customers are guaranteed to find something they like. Why would you use TrialPay? The answer is simple — we are dramatically increasing sales for our merchants in the software, games, publishing, online services, and traditional retail goods industries.

I myself have signed up and will be implementing their checkout as part of the checkout process for EasyBarcode. I am unsure how many more sales it will generate but from my experience, my customers do prefer to have various payment options. And TrialPay do offer a plus as they can sign up for another offer for which they may be interested and at the same time and get your software/product as a bonus. If you are selling software online, this is an option to consider. Click the logo below to visit the TrialPay website to get more details...

Yay! Time for another post about some of the upcoming graphical changes in FSX SP2/Acceleration. This time I take a look at the topic of Bloom (as in DX9) vs HDR (High-Dynamic Range which is DX10 only). From some of the forum posts I have read, there seems to be alot of speculation as to what the difference really is and as to whether or not there is actually any difference (you just have to love those conspiracy theories). The point of this post is to give a side-by-side comparison of the two approaches and then I will make a brief talk as to what the differences actually are from a more technical point of view...

The two videos below compare the DX9 Bloom with the DX10 HDR...

If you take a close look at the videos, you can see some visible but subtle differences between the two clips... But the hot question, is what really happens behind the scenes...

Although the techniques used in DX9 and DX10 are different, they both aim to reproduce the same effect. To keep this simple, bloom or HDR is the effect that occurs when lights of various intensities affect the viewer (generally by darkening or oversaturating the image). The best way to picture the effect is to imagine that you are driving on a bright sunny day and that you approach a dark tunnel. From a distance, the inside of the tunnel appears black, which is due to the fact that the bright intensity of the sun forces our eyes to adjust themselfs to the ambient light intensity. This means that even though there is light inside the bridge, our eyes are adjusted to brighter intensities and the lesser intensities get filtered out (essentially the same thing as playing with exposure setting on a camera). The reverse is also true... If you are inside the tunnel looking towards the exit, it will generally appear quite bright, mostly white and washed out. This is due to the reverse process where the overall ambient lighting is low and the eye adjusts itself consequently meaning that any bright source of light will have a tendancy to appear saturated.

The exact detailed technical description of what is HDR and how it can be repsented can be quite long. Maybe the beat and easiest is to simply refer and quote the relevant Wikipedia article (http://en.wikipedia.org/wiki/High_dynamic_range_rendering):

Preservation of detail in large contrast differences
One of the primary features of HDRR is that both dark and bright areas of a scene can be accurately represented. Without HDR (sometimes called low dynamic range, or LDR, in comparison), areas that are too dark are clipped to black and areas that are too bright are clipped to white. These represented by the hardware as a floating point value of 0.0 and 1.0 for pure black and pure white, respectively.

Graphics processor company nVIDIA summarizes one of HDRR's features in three points[4]:

Bright things can be really bright
Dark things can be really dark
And details can be seen in both

Accurate preservation of light
Without HDRR, the sun and most lights are clipped to 100% (1.0 in the framebuffer). When this light is reflected the result must then be less than or equal to 1, since the reflected value is calculated by multiplying the original value by the surface reflectiveness, usually in the range 0 to 1. This gives the impression that the scene is dull or bland. However, using HDRR, the light produced by the sun and other lights can be represented with appropriately high values, exceeding the 1.0 clamping limit in the frame buffer, with the sun possibly being stored as high as 60000. When the light from them is reflected it will remain relatively high (even for very poor reflectors), which will be clipped to white or properly tonemapped when rendered.

Likewise when light passes through a transparent material, the light that passes through has a lower brightness than when the light entered. An example of the differences between HDR & LDR rendering can be seen in the images to the right, from Valve's Half-Life 2: Lost Coast which uses their game engine "Valve Source". In the example pictures, with low dynamic range rendering, much less light passes through the stained glass, causing the scene to be darker. The reason for this is that when light passes through a transparent material, it lowers the light’s brightness. In a simple example, say the stained glass can block 40% of the light. Since the highest value of the low dynamic range light is 1.0, this means a brightness of 0.6 is illuminating the other side. The high dynamic range light is perhaps 100, which means a brightness of 60 is illuminating the other side.

As I have mentioned, both the DX9 and the DX10 approach aim to accomplish the same goal but use different approaches.

DirectX 10 VS DirectX 9:

The easiest implementation is actually the one taken under DirectX 10. As mentioned above, true lighting intensities cannot be represented by a simple 0->1 range and DX10 guarantees floating-point texture support. The implementation takes advantage of the this feature and do all our rendering directly to a floating point texture. We then use this texture and apply standard texturing operation such as a blur filter (to create a bloom/glow) and a star filter which is used to crate the stat-like patterns that generally occur when the light traverses a imperfect medium such as glass.

Under DirectX9, the back-end (bluring and filtering) is mostly the same. However the main difference is that we do not use floating point textures. I can already hear the conspiracy theories right now that we didn't use the DX9 support for floating point textures to force users to upgrade to Vista and purchase new hardware. This is far from true....

The main problem under DX9 is that support for floating point textures was introduced late and is an optional feature (although most Shader 3.0 cards have some support for it). In addition, alpha-blending and filtering on floating point textures is not required and most cards under DX9 do not support these features which are not a requirement but can make a huge performance difference when we do the actual bluring and filtering passes (under DX9 we would have to potentially filter the texture manually wihin the shader, not the most efficient approach). Since proper floating-point texture was so sparse under DX9 and that DX10 had guaranteed support for the features we needed to implement proper HDR, we decided to keep the floating point implementation for DX10 only.

So what do we do under DX9? We seperate our Bloom rendering into two distinct passes which are only applied to blooming objects. In the first pass, we capture the color of the pixel as it would occur during regular rendering. In the second pass, instead of capturing the color of a pixel, we capture its intensity (which is in essense a multiplier to the base color). We then use these two sets of information to complete the bloom filtering in a similar way as it is done with the DX10 HDR. The main advantage of using this approach is that it can be implemented on any video cards that has support for shaders and render targets. There are a few drawbacks:

• The intensity map is sampled at a lower resolution (1/4 resolution) in order to optimize bandwith
• There is a small overhead due to the need of having to render two passes for any Bloom emitting object.
• Using a 8-bit value to represent the intensity does not give us as much fine grain detail as the use of a floating point texture. Consequently, the DX9 Bloom has a tendancy to get "hot" really fast and has less of the warm glow feeling that the DX10 HDR effect gives.

The art of computer programming is about to get easier thanks to Paradoxal Press’ future releases of “Practical Ruby on Rails” and “The Complete Effect and HLSL, DirectX 10 Edition” as well as its just-released second edition “Practical .NET2 and C#2,” a new book that is now available for purchase. This book on .NET and C# programming expands on the first edition by offering revised and adapted content to meet the changes that came with the release of the .NET 3.0 Framework.

Redmond, WA (PRWEB) October 12, 2007 -- One of the world’s foremost publishers of computer programming guides Paradoxal Press is proud to announce the release of its second edition of “Practical .NET2 and C#2,” a guide to C# programming and using the .NET platform.

Released this month, the second edition of Practical .NET 2 and C#2 takes upon the success of the first edition which is the English adaptation of the best selling French title on the topic which has sold over 3,800 copies in the French market since its release (ISBN 978-09766132-5-1, C# programming. Its latest additions are sure to make it one of the greatest resources available on C# programming.

Paradoxal Press is also introducing an introductory program to allow purchasers of the first edition to upgrade to the second edition at a rate of $20.00. For more details on the second edition and the upgrade program, visit: http://www.ParadoxalPress.com/Book_PracticalUpgrade.aspx

In addition, Paradoxal Press is proud to announce its upcoming fall 2007 and spring 2008 lineup of new books, which is composed of two titles: “Practical Ruby on Rails” and “The Complete Effect and HLSL, DirectX 10 Edition.”

“Practical Ruby on Rails” is another adaptation of a French title, authored by Eric Sarrion, that is an in-depth reference of the new and buzzing Ruby on Rails technology which allows optimal web design by adopting a MVC (Model, View, Controller) model. Eric Sarrion explains everything with his legendary level of detail in a book that is very progressive. Practical Ruby on Rails is composed of five parts: An Introduction which shows in 15 pages how to install Ruby and to create a simple application. It then dives into the basics of computer programming using the Ruby language, which is required to take full advantage of Rails. The part on the topic of controllers shows how to create the actions that are meant to be called through the Web server based on the URL provided by the client. In the section about models, the programmers learn not only how to create and modify the objects of a database, but also how to properly design a relational database from the ground up. The part on views focuses on the rendering of the values computed by the controllers and the other objects of the model. This is where the reader will learn to page HTML code as well as making usage of CSS, JavaScript and Ajax. The final section tackles some of the various methods which come in handy on a regular basis. These are utility functions such sending emails or the publication of a Web service.
This title is a complete and progressive guidebook for any reader wanting to learn how to master Ruby on Rails. “Practical Ruby on Rails” is scheduled for release in early 2008.

“The Complete Effect and HLSL Guide, DirectX 10 Edition” takes from the success of the first edition “The Complete Effect and HLSL Guide” (ISBN 978-09766132-1-3). The topic of the first edition is focused around the development of graphical shaders and their management. It is written for any developers who have an interest in being efficient at using and integrating shaders within their applications. This computer programming book was written to serve as both a teaching and reference manual, making it a must-have to everybody from hobbyist programmers to professional developers. The approach taken throughout “The Complete Effect and HLSL Guide” makes it the perfect book for anyone who wants to integrate shaders into their application and take advantage of the power of the DirectX SDK and the HLSL shading language. The book covers the following topics:
* Introduction to both the HLSL shading language and effect file development including their detailed syntax and use.
* Complete reference with performance considerations to every HLSL and assembly shader instructions.
* Introduction the DirectX Effect Framework and complete overview to its API.
* Optimization tips and tricks to make the best out of shaders.
* Coverage of all the main components of the DirectX effect framework in addition to putting the pieces of the puzzle together allowing a programmer to develop a shader management framework.

The second edition, “The Complete Effect and HLSL Guide, DirectX 10 Edition,” takes off where the first edition left and introduces several revision and corrections as well as expanding the existing content to cover both the DirectX9 and DirectX10 platforms.

For more information about “Practical .NET2 and C#2” and to see how it helps its readers learn the art of computer programming and C# programming, or to see sample chapters or download code samples from the book, please visit www.PracticalDOT.net.

For more information about Paradoxal Press, visit www.ParadoxalPress.com

The second edition of Practical .NET2 and C#2 is finally available for sale on www.ParadoxalPress.com. The official release date is technically on October 15th but it is possible that outside orders (such as on Amazon) be a little delayed. This is due to the fact that copies of the book were delivered to our distributor only ~1 week ago and the copies need to spread from our distributor to the wholesalers and finally to the retailers.

I have received my inventory on Friday and have updated the www.ParadoxalPress.com website so the book can now be purchased directly. We offer a special release pricing of $36.99, which includes free USA shipping. If you already have the first edition of the book, we are also offering an Upgrade Program which allows you to purchase the second edition for only $20.00.

Book Description
The second edition of Practical .NET 2 and C#2 takes upon the success of the first edition which is the English adaptation of the best selling French title on the topic which has sold over 3800 copies in the French market since its release. With the recent release of .NET 3.0 in 2007 and the ever increasing popularity of the .NET platform, the second edition of Practical .NET 2 and C#2 continues in the footsteps of the success of the first edition by offering revised and adapted content to meet the changes that came with the release of the .NET 3.0 Framework.

The book can also be purchased on Amazon.com using the following link: Practical .NET2 and C2 Second Edition: Harness the Platform, the Language, the Framework

Apparently, saying "could have been implemented on DX9" in my previous post in regards to VC self-shadowing stired all sorts of drama on some of the user forums. Although the statement is accurate, I did not explain in more details WHY this was not done and why we kept this feature for DX10 only. This post is not intended to be harsh but a mere clarification of why the decision was made. My tone may seem somewhat pessimistic but this is mainly due to frustration from the fact that some of our fans seem to be on a constant quest to crucify us no matter what we do.

Back to the topic of why self-shadowing is only present on DX10, I was really quick and vague into giving actual reasons and wanted to be true and honnest in my statement, which apparently got taken out of context and distorted... Since the VC self-shadowing is essentially another form of shadow mapping as done with the exterior, it could have been implemented on DX9. However, there are two reasons why the self-shadowing of VC was kept as a DX10 features (beyond the force people to upgrade conspiracy theory).

• The first reason was briefly stated above which was for performance reasons. If we were to release this feature on DX9 and drop performance, well we would get crucified for doing so. Then again, I was being honnest and did say such a feature could have been done on DX9 but would hit performance significantly, yet we still get crucified. No matter what I say here, it is a loose-loose scenaro at least from the perspective of some of our fans...
• The second reason, which was not mentioned in my original post, is in regards to visual quality. Under DX9, the shadowmap resolution used is significantly lower and the type of filtering we can use is also fairly limited. This yielded some really blocky looking shadows within the VC. DX10 does give us more options and we were able to use a larger shadowmap for the interior and also use a high quality filter which allowed the shadow to be of good quality. Yet again, if we released the low quality VC self-shadowing, we would have been crucufied for doing so...

The first point that is worth mentioning here is that SP2 (and therefore Acceleration) do introduce a new slew of performance improvements. These improvements are various but the bulk of the work focused around the improvement of our scenery/autogen batching technology. These goals were main in order to reduce the number of “draw calls” (number of times we ask DirectX to draw something) made to the hardware as the overhead involved is actually quite significant and is one of our major bottlenecks (especially on multi-core machine where other background tasks are spread across various cores). I do not have specific numbers on this and millage will generally vary based on settings and location. But overall, based on our test suite, the improvements offset the costs that came with some of the architecture changes we had to make in order to support DX10 and in some cases goes a little further and gives a reasonable performance boost.

Of course, the question on everyone’s mind is “But what about DX10?”. To start, it might be good to set some context. A recent article on HotHardware.Com actually looked at some of the new DX10 releases and compared the performance to their DX9 counterpart. Overall, for most of the titles, the performance was lower. The consensus seemed that this drop was likely due to the addition of several visual features which take advantage of the new DX10 hardware. Here is a snippet from the article which summarizes well the content of the overall article and the conclusions that are making.

From:http://www.hothardware.com/articles/The_State_of_DirectX_10__Image_Quality__Performance/?page=1

The DX10 exclusive effects available in the five games we looked at were usually too subtle to be noticed in the middle of heated gameplay. The only exception is Call of Juarez, which boasts greatly improved graphics in DX10. Unfortunately these image quality improvements can't entirely be attributed to DX10 since the North American version of the game -- the only version that supports DX10 -- had the benefit of a full nine months of extra development time. And much of the image quality improvements in Call of Juarez when using DX10 rendering were due to significantly improved textures rather than better rendering effects.

Our test results also suggest that currently available DX10 hardware struggles with today's DX10 enhanced gaming titles. While high-end hardware has enough power to grind out enough frames in DX10 to keep them playable, mid-range hardware simply can't afford the performance hit of DX10. With currently available DX10 hardware and games, you have two choices if you want to play games at a decent frame rate; play the game in DX9 and miss out on a handful of DX10 exclusive image quality enhancements, or play the game in DX10 but be forced to lower image quality settings to offset the performance hit. In the end, it's practically the same result either way.

While the new DX10 image quality enhancements are nice, when we finally pulled our noses off the monitor, sat back and considered the overall gameplay experience, DirectX 10 enhancements just didn't amount to enough of an image quality improvement to justify the associated performance hit. However, we aren't saying you should avoid DX10 hardware or wait to upgrade. On the contrary, the current generation of graphics cards from both ATI and NVIDIA offer many tangible improvements over the previous generation, especially in the high-end of the product lines. With the possible exception of some mid-range offerings, which actually perform below last generation’s similarly priced cards, the current generation of graphics hardware has a nice leg-up in performance and features that is worth the upgrade. But if your only reason for upgrading is to get hardware support for DX10, then you might want to hold out for as long as possible to see how things play out.

My point of view is similar. The two main components in my opinion for poor performing DX10 titles are the abuse of DX10 features and the lack of maturity of DX10 drivers...

The second aspect, well, we don’t really have control over. Hardware manufacturers are dealing with new architectures and a totally new driver model. It will likely take a while for the DX10 drivers to take full advantage the hardware as DX9 drivers are today.  When it comes to the abuse of DX10 features, it’s plain simple. The hardware does allow you to do more in terms of flexibility, but this does not mean that this is all free. Increasing shader complexity, bumping up texture sizes, … All this does add up and even if the new DX10 hardware is faster, that it is still more than it can handle. So most of these games does perform poorly mostly because they decided to sacrifice performance for eye-candy.

If you read Phil Taylor’s Blog, you probably already have the information I will post below. But essentially, here are two shots of SP2 running on the same system and flight settings. The only difference is whether we used DX9 or DX10. Here are the two screenshots to show the performance improvements (with our new visual improvements such as water and bloom turned on), taken on a 2.4 Ghz Intel Core Duo, with 1GB of RAM, and a GeForce 8800 GTX.

DX9 ( 24.1 FPS, 30 set as goal )

DX10 (30 FPS, 30 set as goal )

So roughly, this is about a 20% performance increase. In fact, as far as we know we are the only title so far that does benefit from a performance increase under DX10. There were several things that had to be factored in our design but overall the main problem we had was a time and resource constraint and we had to aim for a smaller set of features that gave us the best bang-for-the-buck.

I know some are disappointed and this probably stems from two reasons. The first part being the overall level of hype and expectation towards the new DX10 hardware. The fact is that the hardware cannot necessarily do more in terms of computing power (well slightly more) but only drops several of the barriers that were preventing developers to express more creative freedom and explore new rendering techniques and algorithms. Unfortunately, many developers took this a little too far and essentially bring these cards to their knees. This was a decision on their part, aiming more towards eye-candy and hype than providing a “usable” gameplay experience on the new hardware. We knew this would pose a problem if we took the new features too far and decided to concentrate our efforts on a few key points:

• Restructure our rendering engine so it can properly handle DX9 and DX10. We are essentially thinking forward so we can make future releases even better.
• Take advantage of the new hardware to improve performance. We do take advantage of this under DX10 to improve our batching and our handling of textures/materials, hence the ~20% performance increase.
• Add visual eye-candy in areas where we can control the cost and get the best improvements considering the constrained amount of time we had.

This being said, this is why we are now calling SP2/Acceleration a DX10 preview. Visuals should go through SIGNIFICANT improvements in the next release.

The second part comes from this “mockup DX10 screenshot” that was released a while back… As Phil mentioned, this was a really big mistake on our part. The initial intent was for our artists to express themselves and give a visual representation of what a DX10 version of Flight Simulator should look like (and it did serve as a template when deciding which items we should be focusing on). However, I doubt this mockup was ever intended to be a “promise of what FSX DX10 will look like”. We did try to get as close as possible but due to various factors including hardware delays and re-architecture work we had not predicted, there was no way we could meet the expectations in this mockup.

So where are the differences? Well as mentioned in a previous post, the changes we made that affect the visual look of FSX are mainly concentrated in the lighting (real High-Dynamic Range lighting versus the fake bloom we were using), improved shadowing on the aircraft (higher resolution on the exterior and enabled on the interior) and water (it does not dynamically move, but the shader was significantly improved and includes some new features such as whitecaps). Single screenshots may not do justice to the new features. So as I start discussing some of the new features (as I have already done with the VC self shadowing), I will attempt to provide screen captures and videos which does a better job at demonstrating the before-and-after…

One of the DirectX 10 additions to FSX SP2/Acceleration is the use of self shadowing within the aircraft VCs. For the VC, we use shadowmapping, in a similar way that it is used for the external airfraft self shadowing. This could have technically also have been implemented on DX9 but we made the decision to keep this a DX10 only feature mainly for performance reasons.

Note: This feature will only appear for models that are properly built for this feature so will only work with updated FSX and Acceleration models out of the box. Third party models will need to be updated to take advantage of this feature, which mainly involves setting a new flag in the model and re-exporting. The reason for this choice is that shadow mapping does require a model to be "visually closed" when looked at from the outside. However, most of the time this is not the case as some material may not be properly double-sided or pieces of geometry may be leaving holes where there should not be any. Think of it this way, any holes when looking at the VC model from the outside is essentially a point where the light will shine through from the shadow map, leading to incorrect shadowing. We decided it made more sense to have the feature off by default unless someone explicitly marks the VC model as being "shadow map ready".

Below is a little video capture of the feature in action. It is mid-resolution to keep size and bandwidth reasonable but still shows off the feature fairly well and gives yo uan idea what to expect.

You can also download the video here: fsx_dx10_vcshadow.wmv (4.05 mb)