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).

I have just added a scripting system to the engine. Right now it supports Boo, but it will be extended to C# soon.

It uses coroutine in order to make scripting over frame/time very easy :

• "yield" will suspend execution until next frame.
• "yield StartCoroutine(coroutine)" will add a coroutine to the scheduler, and the calling coroutine won't be resumed before the called coroutine has finished.
• "yield Wait(3.5)" : the engine will wait for 3.5 seconds before resuming the coroutine

Simple example which move the camera every frame :

 class Test(IScript): 
    i = 0.0
    def Run() as IEnumerator:
        while true:
            rvs = SceneDesignerContext.Services.GetService(typeof(IRenderViewService)) as IRenderViewService
            rvs.Eye = Vector3(40 + i, 40, 40)
            i += 0.01
            yield
 

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've been working on the latest hype (or not) of 3d engine : megatexture ! However, I didn't want it to alter the toolchain with specific texturing tools.

After some thinking, I think I came up with an interesting idea :

• Mega texture (including atlas) is built on the fly, with a given texture block granularity (let's say 32 * 32 texels).
• To avoid wasting resource, tiling is detected via a simple CRC check of texture blocks when a texture is uploaded.
• Texture could also be checked for duplication before uploading (not sure of that, still to be determined).
• UV mapping of objects get remapped at loading.

My hope is to end with a system where you could paint in the middle of a very big tiled texture very easily while consuming minimum texture size. In fact, megatexture, or the idea of virtualizing textures is a neat idea, but some care should be taken (i.e. still use of tiling/texture reuse), because a 32k*32k seems a lot, but stretched over a very big terrain, it could end up with a very bad resolution.

My hope is it will be merged in the source within few days.

Update : After some prototyping, seems to behave fine (no artifact). I gonna take a look at perfhud to check if it's not too heavy (on pixel-shader side). In fact, with bilinear filtering, 8 texture lookups are needed.

Update 2 : Pixel shader complexity was increasing too much. As a result, I switched the way to do it and I ended up with border uploaded. Now pixel shader is basically two tex2D lookup, a frac and few additions/multiplications. It was a bit painful to get perfect mipmaps (including border) without any shifting artifact.

OK, just a little news to let you know that the project is (of course) not dead. I worked a lot on branch, and now everything is merged back. Lot of things has been added and improved, including :

• Collada exporter (don't support scene exporting, only mesh now).
• Advanced effect/shader system, including effect bouncing/forwarding support (check this gamedev thread), allowing advanced effect such as shadow mapping and cubemap reflection to be defined in a generic way (through xml by the way). I'll do a quick demo as soon as I can.
• Serialization engine rewritten, now based on a "node" architecture. It should allow for very great extensibility in the asset pipeline (choice between binary and xml, multi archive support, etc...).
• Expression parser written using Coco/R to parse things such as (World[Inverse]*View)[Transpose] for a later use in the effect system for data driven shader variable binding with xml.

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.

Until now, I was reluctant to go the C# way as it wasn't portable across console and garbage collection (GC) could behave too much nondeterministically for gamedev IMO (GC freeze during gen0 collection, etc...).

However, in C++, the lack of reflection, JIT and RTTI, coupled with the very slow compile time is really a pain for engine development. Especially since C++0x won't feature them as it wasn't ready (it will be 2009 for god sake, not even speaking of the delay for compilers and console compilers to support them !).

I recently discovered LLVM project and was delighted by their technology. After some investigation, I think it should be possible to write a frontend for C# relatively quickly, and with the help of C, assembler, PPC 64 or JIT backend, should be portable with amazing speed on different platforms, including console. Moreover, it provides a very nice framework for writing optimizations, specific allocator/GC, and extensions of language that would be targeted for gamedev. Needless to say that I started to write a little LLVM frontend for C#. I don't know if it will end some day (as Entropia is still priority #1 right now) but it looks very easy to integrate with LLVM. Thanks to boost::spirit I was able to write C# parser of the (nearly) full grammar in (non-full) 3 evening !