I can't believe it's been nearly 3 months since my last post. Somewhat scary that time flew by so fast!

Well, over the last few months I have been very busy with work and my other projects. On top of being somewhat ill, it just seems that I cannot catch up on anything. And I have to admit it is quite depressing. Maybe it is just the winters here (yes, I need daylight!!) but the energy levels over the past few months have been really low.

Struggling both with my bipolar disorder and some digestive problems which have been getting progressively worse, some days, I feel like I am just sinking in quick sand!

About the bipolar struggles this winter, well I have been a little more "volatile" than normal. To me, this has been induced be either a combination of the yucky winter weather out here and stress, or simply that my medication isn't working as well. I am holding on for now at least until the spring weather comes in and hopefuly it will clear it up. If not, well a medication change might be in order, something that I am really not looking forward to. Oh, and to make things worse, well my cholesterol is high so my Dr does want to put me on some medication for that. Well the problem is that the Bipolar medication is already harsh on the liver (which comes up as already elevated in my blood tests) and well, the cholesterol medication is pretty harsh also. Maybe I should start looking for a liver donnor right now

What really bothers me however is in regards to my digestive problems. These are not new and I have had some problems for about 6 years now, getting progressively worse over time... This past year has been horendous... I will not get into the yucky details but lets say that on some days I simply cannot go to work due to the pain and the fact I spend half my day in the bathroom. Yet, my Dr's do not really seem to care!! Last year, I did see a specialist who did a few tests including a colonoscopy (not a fun test I can tell you that). However, the few tests did not reveal anything really wrong and the Dr decided it was easiest to simply label me as having IBS. Now, don't get me wrong, it is quite possible that I do have IBS but the problem lies in the fact that IBS is not really a diagnosis but is intended to be a diagnosis of elimination (i.e: you have problems but we excluded everything else which may cause these symptoms). And from what I read, the list of other tests that should be run is much longer than a few blood tests and a colonoscopy!!  In the meantime, I am left to suffer. Both my work life, love life and social life suffer from this. And no matter what I eat, I am almost guaranteed to feel sick afterwards. I do have another appointement with another specialist in 1 month. I hope that it will yield more information this time...

Either way, with both problems combined it does feel like I am fairly disabled. Missing way too much work, never knowing when I will need to run to the bathroom, feeling miserable every other day, ... To be quite honest, not the best way to live a happy life...

Ok, enough whining for today, I promise. Hey, after 3 months, I had a little venting to do. I will try to post on a more regular basis and will try to talk more about the things I am working on at my new (well not so new now) job...

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!

Yet again, the time has come!

After the success of ShaderX, the ShaderX2 books, ShaderX3, ShaderX4 (Game developer frontline award), ShaderX5 and soon ShaderX6, we are looking for authors for ShaderX7.

The book will cover advanced rendering techniques that run on the DirectX and/or OpenGL run-time with any shader language available. It will include topics on:

• Geometry Manipulation
• Rendering Techniques
• Handheld Devices Programming
• Effects in Image Space
• Shadows; 3D Engine Design
• Graphics Related Tools
• Environmental Effects. 

Of course, I will also be a section editor this time around.  

Proposals are due by February 28th, 2008. Please send them to wolf at shaderx.com.

An example proposal, writing guidelines and a FAQ can be downloaded from www.shaderx6.com/ShaderX6.zip. The schedule is available on www.shaderx7.com.

I wanted to appologize foy my lack of posts over the past few weeks. With the job transition and the holiday rush at ParadoxalPress.com, I had little to no time to make an actual post. I am currently still out of town and posting from my hotel room but more posts should start comming in over the next few days.

But I wanted to take the time and wish all my readers a happy holiday and best wishes for 2008!

The time has come for me to move on to another pasture. After 4 years as a graphics developer (and more than 8 as a game developer), I have decided to take the plunge and explore something new and different...

Yep, starting Dec 3rd, I will be moving from the ACES team to the Media Center Extender team.  Although somewhat of a sharp direction change from my previous position, the new job is still graphics related but obviously focuses on low-level and embeded technologies. I always wanted to work on something that was more of a driving technology than a singular product. Although this is not within the console environment as I would have initially thought, the Media Center Extender is essentially at the center of the digital home (or at least will be) and it is actually exciting to be part of such a central piece of technology!

Why am I moving on? Well this is a tough question. There is alot of factors, some personal, some professional. But overall, suffice to say that I had reached the point where I needed new challenges. With the new year comming up, the best time ever for a fresh start :)

I do wish the best to the ACES crew... They have alot heading their way, but I also know they can step up and deliver!

The purpose of this post is to address a question that was sent to me in regards to water reflections in general. The question actually is two questions... The first one asks me to explain the difference between the various Water 2.X settings (Low/Mid/High/Max) and why these settings have such an effect on perf. The second question was in regards sd to why dynamic reflections are only on bodies of water and not other wet surfaces (such as a wet runway). I want to keep the answer as simple as possible but at least provide some insight as to how things work and why we have to make some specific decisions some times...

Why no Reflections Elsewhere? 

This is actually a good questions. We do apply "reflections" to the other wet surfaces but the reflection map that is used is static and is not dynamic as with the water. There are a few reasons for this but I will cover the main ones. The approach that is used with water surface reflections is to assume that the water is a flat surface and to treat as if it was a plain mirror. With this assumption, we can generate a reflection map simply by reflecting the camera around the plane that is generated by the water surface and taking a "screen shot" from that point of view. This is a really nice and easy way to accomplish water reflections and when dealing with waves, we simply distort the lookup into this reflection map. This is far from perfect but does the job really well in this case.

But what about adding reflection maps on everything else? There are a few problems with this in general. The first one was implied in the first paraghaph "to assume that the water is a flat surface"... This is not generally true for general objects and this method breaks down rather quickly as soon as a surface is not planar. The next best alternative is to use a cubemap as a reflection map, but this automatically increases the cost by a factor of 6x. Going back to the specific case of runways and wet pavement, in the majority of cases, we could likely assume a flat surface. But there is another overall problem (which is also a problem with water in genral). What if there is more than one planar surface in view? What to do in the case where you can see two lakes that are at a different altitude within the same view? The correct approach in this case would be to generate a seperate reflection map for each planar surface that is visible. But as you can imagine, that would be impractical and would make the cost of rendering the reflection maps unpredictable. For water, we simply look at what is in view and make a good faith guess as to what is the predominent body of water and use its elevation to generate the water reflection map.

Also, in the case of water, we have nice vector data which outlines the contour of the body of water, making it easy for us to determine the outline of the bodies of water. For generic reflective materials, it is more difficult. We do have similar information for airport related asphalt but not necessarily for other reflective surfaces in the game. Dynamically generating a reflection map is something that can get hairy real quick so it was decided that, at least for FSX, we would focus only on water reflection.

Visual Results for the Various Detail Settings 

Instead of writing a long paragraph on this, I think a picture is worth a thousand words. I have captured a snapshot of the same scene using the various 2.x water settings. In the caption below the image I indicate what is rendered inside the reflection map and I've also turned on a debut feature which shows the content of the reflection map in the top-left corner. I will not go into the details of where all the performance goes, but you can likely extrapolate from the amount of detail in each map that the Max setting is going to cost LOTS MORE than the Low setting.

Water 2.X Max - All is rendered, equivalent to rendering the whole scene twice with the exception of a few optimizations which take advantage of the autogen and batching LOD system to reduce the overall number of draw calls.

Water 2.X High - Only the aircraft, full sky (with clouds), terrain and non-autogen scenery is rendered.

Water 2.X Med - Only the aircraft, full sky (with clouds) and non-autogen scenery is rendered.

Water 2.X Low - Only the aircraft  and sky (without clouds) is rendered.

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.