GPU Geometry clipmaps in progress, with cone step mapping !
There is still some cracks between clipmap levels, they will be removed soon.
Currently NVidia only (vertex texture fetch) but I'll do a R2VB path for ATI.

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
 

Finally, I was able to do a not-too-ugly screenshot of the engine !

It features the current dev version of the SceneDesigner with a Cone Step Mapping effect that I quickly implemented to test the effect system (it lacks shadow, but it's on the way). The Scene Designer works with a fully pluggable architecture thanks to Mono.Addins.

More to come soon !

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.