I have came across an interesting issue latest days, which I will first describe the naive way !

Let's say I have a Geometry class, which holds GPU hardware buffers and some render variables.

• The next step is realizing that collision data is needed. So let's add a pointer to collision data.
• Then come the time to realize that in editor mode, access to source mesh would be needed. OK. Well, let's add a reference to a Mesh class holding triangle data in system memory.
• Well, now it's time to implement culling. Let's add AABB to the Geometry class.
• Damn, sphere tree would be nice too, since my engine could also support that.
• And again...
• And again...
• Now there is an horrible Geometry with hundreds of definitions to variables that Geometry shouldn't even know about (even though they are for sure logically bound to this geometry, but they break lot of OO principle and add a lot of coupling). In fact, collision and culling system are way higher level than the system in which Geometry is defined. How to escape that hell ?

Well, I realized that a system similiar to WPF with its DependencyProperty and DependencyObject would fit perfectly ! Objects that have such external variables should either inherits from a specific class or have a member of that class, which will act as an external property container. Performance shouldn't be a concern, as it could be very fast (pre-sorted) and it's very high level : bottlenecks should never happens there.

The end result looks like :

 geometry.SetValue(SourceMeshProperty, sourceMesh); ICollisionShape collisionShape = geometry.GetValue(Collision.CollisionShapeProperty); 

A very nice feature that come from it is the ability to setup delegates to build default value of such properties (WPF could only return a static value independant of the object).

Latest news from the coding front !

• I have implemented a 3ds max export plugin over socket. As a result, exporting mesh is now a one click process, the mesh gets loaded in the scene designer. It should allow for artist to do continuous testing with in-game engine rendering.
• Speaking of the scene designer, I started working seriously on it. More precisely, I'm currently working on a very central component : its object editor. I tried to take advantage of many features of the new C# 3.0 framework, and to be honest, it's really a breeze to develop that kind of advanced UI control with it ! I aim to get a property grid like the one in Microsoft Expression Blend (which is perfect !).

Screenshots of the current version :

Latest days, I have spent some time playing with Windows Presentation Framework aka WPF, the presentation layer of the new .NET Framework 3.0/3.5, with Visual Studio 2008 Beta 2.

The learning curve is rather low at the beginning, but once you get used to the basis, it becomes totally exponential.

• Controls are built from other in a tree-like way. By the way, ever checked Microsoft Blend Expression ? It got an awesone PropertyGrid like control, in which you can bind every property to external sources. However, after some investigation, I realized that it should be relatively easy to do one like that in WPF thanks to this tree-like architecture. Note that care has to be taken due to airspace issues between D3D and WPF (a pixel can't belong to both). However, in an editor, controls should be in their own airpsace.
• System.Windows.Data also holds another big stone of their system : their DependencyProperty & Binding system. It could be a great architecture for a game engine (shader variables, entity variables, etc...). I started working on a similiar system. However, performance requirements (thousands of variables updated each frame) made me go the JIT way (binding are compiled at runtime with DynamicMethod).

All of this will be included in the engine some time in the future.