https://blogs.msdn.com/DirectX

From now on, this is where I will be posting about the work I do on my current team with Direct2D. Anybody who is interested in Direct2D or any other DirectX features should subscribe to this blog to hear from the team about what they are doing.

This is a native code graphics development platform for 2D graphics. There has been a lot already written about it to read.

We have white papers here:

https://msdn.microsoft.com/en-us/windows/dd262126.aspx

And the PDC2008 video can be found here:

https://channel9.msdn.com/pdc2008/PC18/

This has been a great product to work on and I am excited to see it revealed to you all. Feel free to give feedback to myself or the other D2D team members who have blogs (links on the left).

https://msdn2.microsoft.com/en-us/library/bb204909.aspx

Watch your debug output with this turned on and you will get a lot of helpful stuff. Try rendering without a viewport, for example.

One thing to watch out for though - this will only work on a machine with the SDK installed. The D3D10CreateDevice call will fail on a machine without the debug layer installed if you use this flag. This is documented, but you have to look around for it.

I have been working a lot with D3D10 lately, so I will endeavor to get more tips about it out as I find them.

On a whim I write some code to call FindResource myself to make sure that I can find the resource and it works, but that makes me think about the resource types on this page:

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/WindowsUserInterface/Resources/IntroductiontoResources/resourcereference/resourcetypes.asp

And then I remember that some other D3D resource functions like resources to be in RC_RCDATA format. Lo and behold, this is the problem - I had a bmp file as a resource, but it was marked with RC_BITMAP!

Lesson learned - D3D loads RC_RCDATA resources, even when they are bitmaps. I hope this saves somebody some time one day :)

Every time I have found the code for this I have thought "Cool!" and then a couple of months later I forget it again. Now that I don't write WPF code all day every day anymore (sniff) I have even less of a chance of remembering it. So I post it here for myself to find later and as a gift to anybody who reads it.

The trick is to use DependencyPropertyDescriptor. If you have the DependencyProperty already (normally a static member of the class, such as WidthProperty) then you can call DependencyPropertyDescriptor.FromProperty and pass that in. Once you have the DependencyPropertyDescriptor you can call AddValueChanged to subscribe to the change event.

Now Bob's your mum's brother. Remember though, for your own properties you can register a change event handler in the metadata yourself to avoid writing this.

The idea of MakeVisible is that it is called to ensure the visiblity of one of the children in the Panel. When will this be called? Well, if you fire up the AnnoyingPanel sample that has been written in the past three chapters, and click one of the buttons, you will notice that the application will crash because of the exception we are firing from MakeVisible. Pushing the tab key will also have this result. This makes sense - when you push a button or tab to it, WPF will ensure that the button is visible so that you can see what you have tabbed to or clicked on.

So how do we implement the method? The method takes a Visual and a Rect. The Visual is the thing that we need to make visible - it will be one of the children of the Panel. The Rect is the rectangle of the Visual that needs to be visible. The return value, another Rect, is the rectangle of the Visual that you managed to make visible.

So to implement this method for our sample should be fairly simple. We will search our internal child list for the Visual to see if it is there. Based on where it is in the child list, and the size of the children, we can calculate the offset that we need to scroll to in order to have the child at the top of the viewport. Then we can set the new vertical offset, and return the rectangle we were given, since we know that the children are always smaller than the viewport.

        public Rect MakeVisible(Visual visual, Rect rectangle)

        {

            for (int i = 0; i < this.InternalChildren.Count; i++)

            {

                if ((Visual)this.InternalChildren[i] == visual)

                {

                    // we found the visual! Let's scroll it into view. First we need to know how big

                    // each child is.

                    Size finalSize = this.RenderSize;

                    Size childSize = new Size(

                        finalSize.Width,

                        (finalSize.Height * 2) / this.InternalChildren.Count);

                    // now we can calculate the vertical offset that we need and set it

                    SetVerticalOffset(childSize.Height * i);

                    // child size is always smaller than viewport, because that is what makes the Panel

                    // an AnnoyingPanel.

                    return rectangle;

                }

            }

            throw new ArgumentException("Given visual is not in this Panel");

        }

If you build this and run it then things will look the same, but now when you click or tab to a button it will be forced to the top of the viewport (or as close as it can get to there, anyway). So now we have a minimal working version of MakeVisible.

There are several issues with our implementation, and they are things to think about if you are implementing this for real in a real world application:

• Our implementation is repeating the calculation of child size again. We have this code littered throughout the sample in many places. I have done this to try and make it easier to grok what is going on, but this stuff should really be in helpers to avoid bugs from having it being done slightly differently in places.
• We are assuming that the only difference in the coordinate system of the Visual and the Panel is the position. WPF allows much more interesting transforms, and I am unsure at this time what the input and output should look like. This is an interesting experiment for somebody to try one day.
• Our calculation of the rectangle that we scrolled into view is simple, because we always try to move the child to the top of the viewport, and the children are always smaller than the viewport. This shortcut might not apply depending on how your Panel works, and you may need to do some calculation to figure out how much you are showing.
• We are always changing the vertical offset, even if the child is already visible. This is a distracting way to implement things - the user does not expect the child to move around when it is already visible. A real implementation would look at the offset, and decide if any scrolling is needed or not. If scrolling is not needed, but the child is partially shown, then the returned rectangle would need to change as well.

All of the four things above are incremental, and typically change depending on your scenario, which is why I am not being too specific about what to do or demonstrating it. IScrollInfo is an extension point designed to allow a maximum of flexibility, and there is a huge number of ways that you can use it. All that I am trying to do is let you be aware of the possibilities.

I have attached the final AnnoyingPanel.cs file for you to look at if you want all of the code. You may need to change the namespace to use it in your app, but I figure that this small implementation might be a starting point that somebody would want to use.

AnnoyingPanel.cs

As the project closed, I decided to make a move in the company to where I can continue to work on cutting edge graphics and user interfaces, namely the Windows Client team. As Vista has been completed, the team is busy figuring out what the next version of Windows will look like, and this is an exciting team to move over to the team and help with that figuring out.

Just because Max does not work anymore does not mean that I will not be posting about WPF or answering questions about it. I have been slack with my posts lately with all of the moving around and goings on, but I hope to get some answering done today.

The last day of SIGGRAPH 2006. I divided my time between papers and sketches, so there was a lot to push into my already overloaded and sleep deprived brain at this stage. But I gave it a college try.

The first paper that I caught was most of the "Streaming Computation of Delaunay Triangulations" paper. The main advantage of this approach was being able to do both the input and output of the triangulation as a stream without large intermediate storage, and a modest memory requirement. The algorithm took advantage of the typical locality of the input data and created a system for figuring out when partial quadtrees of the input data were done. The results of the time and memory taken for doing very large sets of data were very impressive. One thing that stuck in my mind about this was seeing a data set from an aeroplane flying over some area, and the comment from the presenter that the pilot forgot to turn the data collection off. Even with this issue hurting data locality the algorithm handled things well.

The next paper in the session that I caught was "Spectral Surface Quadrangulation", which presented a technique for taking an input mesh and creating large quad patches that could be further divided to create mostly undistorted quads across the whole mesh. I have read some papers of this kind of thing before, but never in huge detail. The approach here was to create a function that had maxima, minima and saddle points, and to select a function that created these extremes in appropriate places. After this the points are refined with various techniques and quads can be generated.

After the morning break I caught "Simulating Multiple Scattering in Hair Using a Photon-Mapping Approach". I have never looked into hair rendering before, but from what I gather the scattering is quite directional with hair and hence typical methods suffer from a very small quantity of samples, making even blonde hair look dark. The approach shown in this paper deposits photons uniformly along path lengths, rather than at interaction points. This effectively has photon density mapping directly to radiance, which is what is needed to be calculated. The results are very interesting - especially simulating hair viewed in front of a light.

Following that was "Statistical Acceleration for Animated Global Illumination", which demonstrated a mechanism for sampling temporally as well as spatially for global illumination. Since the changes in illumination are very small from frame to frame (as well as from pixel to pixel in most cases) and you need to render every frame anyway, this approach gives both better looking results as well as faster rendering. The paper also showed how dramatic changes in the scene geometry or lighting can be handled as well.

Next up was "Multidimensional Lightcuts", which showed how to extend the lightcuts algorithm to handle effects such as motion blur. Doing effects like this effectively adds another dimension to the lighting equation integral, and this paper showed how to use similar techniques to the original lightcut algorithm to bring the discretized version of the integral into a small enough set of samples to calculate the lighting effectively.

The final paper before lunch was "Direct to Indirect Transfer for Cinematic Relighting". This showed a system that assumed that the camera was fixed, and then calculated the direct to indirect transfer matrix for the scene at a viewpoint. The transfer matrix is compressed in a GPU friendly way using wavelets, which allows for the scene to have completely different lighting at interactive rates. Even though the viewpoint and geometry are fixed, this still shows a very effective way to relight a scene.

After lunch I decided to round out the SIGGRAPH experience with a couple of sketches. The first sketch session was titled "Fast & Cheap", which sounded great because I love real-time and interactive stuff, and to do that everything must be fast and cheap. The first presentation was about "Fast Approximation to Spherical Harmonics Rotation", which presented a fast and simple way to approximate a rotation in spherical harmonic space. At the sketch it was admitted that a previous method is actually about as fast (which was only discovered right before the conference) but the mathematics employed were very interesting regardless. The basic idea was to decompose the transform into smaller, simpler transforms (rotations around Z are cheap and easy) and then to approximate the non-simple transform (apparently Y rotations are very yucky). It is interesting to see here something which I think happens often in graphics - that expanding a simple formula into a big complex one sometimes makes it much faster.

Speaking of complex mathematical constructs, the next presentation in the sketch (Real-time All-Frequency Relighting in Local Frame) used some very interesting constructs in order to achieve their impressive results. BRDFs are stored in the local frame and compressed using a spherical wavelet approach. Since the BRDF is in local frame, effects such as bump mapping can be done more easily. The lighting is also done per-pixel, using a visibility texture for shadowing. As with many other approaches I saw at SIGGRAPH there is a pattern here of very targetted precalculation and mathematical transformation enabling things to be done in real time that would have been unthinkable five or ten years ago (by me, anyway).

After this Sing Bing Kang from MSR presented a technique to render rain in real time using the GPU. After seeing the ATI presentation on a similar topic it was interesting to contrast the approaches. This approach worked by first using some image processing techniques to extract rain from video, and then uses a PRT based rendering approach where raindrops are assumed to be spherical and non-interacting to render the drops. This is a less memory and shader intensive technique than the ATI one.

This concluded the last day for me. The whole conference was a blast, and it exceeded the expectations of what to expect from the years of wondering what it was all about.