Daniel Lehenbauer - Demo of Avalon 3D | TheChannel9Team

Mark Newell

I'm another XAML & XML newbie but could you make XAML understand the following syntax?

<Viewport3D>
<.Camera>
<PerspectiveCamera ... />
</.Camera>
</Viewport3D>

The . implies it's a property of Viewport3D (or the first matching object in the hierarchy that has the Camera property> and not a new object.

stewarts
Cowbell Baby...

So I am curious about the databinding capabilities of 3D controls. Will I be able to databind information to a 3D object. Let me be more specific. Let's say I build a 3d Object in Avalon. Let's say its an engineering application. I would love to be able to have a 3D model of my part and bind information to different 3d objects within my control that could say, identify which areas break, have stress, etc... without having to save multiple iterations of the drawing to the database.

Does that make sense?

dcw

Another excellent video!

On the subject of xaml interfaces:

I'm assuming that at some point we are going to see a set of standardised 3d form controls (textboxes, list boxes, etc) for use within Avalon.

This video was great for showing a rather low level way to plot 3d primitives point by point, but most app developers will want to use much more abstract commands to set the interface.

I think xaml will really shine when we can see how easy it is to build slick, 3d styled interfaces with a minimum of camera plotting needed.

And a thought, how about making xaml forms backwards compatible with asp.net forms?

danlehen

dcw wrote:
I'm assuming that at some point we are going to see a set of standardised 3d form controls (textboxes, list boxes, etc) for use within Avalon.

This video was great for showing a rather low level way to plot 3d primitives point by point, but most app developers will want to use much more abstract commands to set the interface.

I think xaml will really shine when we can see how easy it is to build slick, 3d styled interfaces with a minimum of camera plotting needed.

Something we didn't get a chance to explore in this 20-min slot is that in the CTP build the Viewport3D element works inside of VisualStyles. This means that you can author a style that replaces the appearance of all instances of, say, <Button /> with a Viewport3D rending a Model3D that looks like, for example, a toggle switch. You can even respond to PropertyTriggers so that the toggle switch animates to a flipped state on mouse down.

The best part is that only the appearance is replaced. You are still coding against an instance of a Button class so the code to handle the clicked event, etc. stays the same.

danlehen

Halcyon wrote:
Avalon on the other hand is a solution looking for a problem. Perhaps Microsoft have something up their sleeves here but if that's the case, nobody is in on Microsoft's vision, and we can't make that happen.

There is a lot more to Avalon than the 3D features we were demonstrating in this segment. Avalon is a new client platform being built by the Windows OS team. I happen to be part of the group delivering the new hardware accelerated graphics, animation, and composition features for this platfom and as such tend to focus on the sizzle and wow factor, but there is much more to Avalon. Avalon adds Xaml, a new Control heirarchy with rich styling and layout features, a new application model with navagation framework, new input, automation and data services, and much more.

However it is important not to confuse Avalon with the next generation Windows user experience (Aero). Avalon is a development platform targeted at addressing a set of very pragmatic problems faced by Windows developers. Avalon is not attempting to be a paradigm shift in the fundamental ways that humans interact with computers, although it does enable some very cool opportunities for developers to experiment with altenative UI systems.

The scenarios that motivated us to build 3D features into the platform were primarily to add subtle 3D transitions and effects to primarily 2D content and data visualization. There are other scenarios as well, such as a parts catalog where the user can freely rotate the parts to attempt to find a match with the component they are physically holding in their hand.

danlehen

Mark Newell wrote:
I'm another XAML & XML newbie but could you make XAML understand the following syntax?

<Viewport3D>
<.Camera>
<PerspectiveCamera ... />
</.Camera>
</Viewport3D>

The . implies it's a property of Viewport3D (or the first matching object in the hierarchy that has the Camera property> and not a new object.

I had the same question the first time I saw this also. Smiley

Prepending the type name solves another problem for us. Avalon's property engine allows one type to attach a property to another. (Drew has a nice post on this topic.) Potentially multiple types could attach a property with the same name. Explicitly specifying the type of the owner disambiguates.

If I remember correctly, there is also an issue with starting an XML element name with a dot.

Avalon

i'm quite interested in the possibility of adding a depth-of-field property to the 3d viewport. The ability to render the depth-of-field effect is an important feature of any image synthesis algorithm.

Depth-of-field is inherent to camera models with lens of finite aperture, in computer graphics the most commonly used camera model is the pinhole camera, where the lens is supposed to be infinitely small.

The pinhole camera model produces images that are in sharp focus in any distance from the viewer. This can be a desired feature (e.g. for technical visualizations), but often a more realistic 3D image including depth-of-field is required.

Post filtering algorithms suffer from intensity leakage, and algorithms that solve those problems are currently slow, especially for large amounts of depth-blur.

The solution may be in pointbased graphics - an algorithm enabling fast depth-of-field rendering for point-based objects.

Anyway I could talk about this stuff all night. Avalon is still in its infancy, who knows what its capabilities may hold.

Horshu

Minh's point is something that has bothered me as well about Avalon. His example had all the information necessary to build an object (at least, it looks to be, and I've written a deserializer that handles properties that way with a few caveats for explicitly declaring a concrete type), so why is there a need to specifically say that a child element is a property? What else would it be? If it is a child control and not a property, then why not structure it like so, as Controls is itself a property of ViewPort3D:
<ViewPort3D>
   <Camera .../>
   <Controls>
      <Panel .../>
      <Button .../>
   </Controls>
</ViewPort3D>

?

Halcyon

jBuelna wrote:

The best way to garner interest in a product is to give your target audience something really good to look at.

The addition of 3D features to the user interface so far has been demonstrated in a very superficial manner. It's true that you can dazzle clients with trinkets and baubles, but in the end they will be taking your business because of the product's practical application. There are many examples of excellent looking and useful application interfaces in Windows XP. Media Player, Office, and WinAMP, are examples of various stylish and functional interfaces possible with Windows XP, although it's clear that they have had to go beyond a normal implementation for creating a user interface.

danlehen wrote:

Avalon is not attempting to be a paradigm shift in the fundamental ways that humans interact with computers, although it does enable some very cool opportunities for developers to experiment with altenative UI systems.

I see, that makes a lot more sense. I'm glad to learn that the emphasis is on usability and not a lot of 3D controls haphazardly combined to create an application.

danlehen wrote:

However it is important not to confuse Avalon with the next generation Windows user experience (Aero).

It's definitely important to have these guidelines in place to provide a consistant interface.

danlehen wrote:

There are other scenarios as well, such as a parts catalog where the user can freely rotate the parts to attempt to find a match with the component they are physically holding in their hand.

For now the same results would be obtained with a streaming video of the object, or perhaps QuickTime 3D but would presumably not achieve the desired results, especially when trying to target the lowest common denominator. Will Avalon's 3D component face the same challenges?

But this brings up another point, it will definitely be useful in presentation software and will probably provide an avenue for MS to deliver new features in PowerPoint (as with Apple's Keynote).