Having worked with Avalon for a couple years now, I've gotten used to ignoring compiler errors.  So often, the warnings are the result of XAML schema false positives and negatives.  In the September CTP of Avalon, if you are working with 3D and you use ViewPort3D.Models.Children.Add, you will get a compiler warning as follows:

Warning  'System.Windows.Controls.Viewport3D.Models' is obsolete: 'Please use the Children property instead.' 

It turns out that this warning should not be ignored, as it speaks to a relatively important change in the Avalon3D API, having to do with the introduction of Avalon’s notion of visuals to the 3D programming surface. 

You'll notice that the Models collection hanging off of ViewPort3D is of type Model3Dgroup.  However, the new Children collection hanging off of ViewPort3D is of type Visual3DCollection.  The primary type you will add to this Children collection is the new ModelVisual3D.  Okay, so where do I actually put my Model3DGroup objects, including lights and geometries? Well, ModelVisual3D has a Content property that takes a Model3D which of course Model3DGroup derives from.  ModelVisual3D also has a Children property of type Visual3DCollection so that additional ModelVisual3D objects can be nested. 

In essence, this change is an additional layer between the viewport and the models, a visual layer.  Daniel Lehenbauer explains in a recent blog post exactly why this additional visual layer was added.  He has a relatively deep discussion of the architectural underpinnings that governed the change.  Highly recommended reading.  (Nice to have you blogging again, Daniel!)

With the next release of Avalon, the ViewPort3D.Models collection will be removed, so start porting those 3D apps now.

So, you ask, why the change?  Is there anything new/better/enhanced with the addition of this visual layer?  In fact, there are two very nice things that are gained:

1. Extensibility.  Model3DGroup and GeometryModel3D are sealed, which meant you couldn't derive from them and create your classes.  For example, you couldn’t create your own cube class that could be instantiated directly in XAML.  But ModelVisual3D is not sealed, so the ability to inherit from it enables the ability to create your own classes that create reusable models. 

2. Databinding.  With this change, databinding is directly enabled on properties of 3D objects instead of the indirect databinding.

Expect samples of both these features soon.  In the meantime, I cleaned up my Sandbox3D sample so that I was no longer getting those compiler warnings.  It is now properly architected to use ModelVisual3D.