Cassini Engine

After finishing the new I/O subsystem, I’ve been working with the renderer itself, trying to take the entire good job done in Casandra, and replacing all the bad things with good ones. One of the problems I had with Casandra’s rendering pipeline was the lack of support for multiple render targets, and the poor flexibility for attaching multiple viewports into a same target, or even sharing a same view port between multiple render targets.

So, the last week I’ve been implementing this new render targeting system, focusing on flexibility and portability, without losing the most important thing I want for Cassini: an “easy to use” interface. The only supported render targets at this moment are windows objects, but render textures will be added in the near future.

The input system has also been drastically improved, allowing to attach keyboard objects into different render windows, and grab input data from the current active window, or to do whatever you like to do with input handling, even by creating your custom input handler and attaching it to the window.

With the new render targeting system almost finished and running in both Linux and Windows platforms, I’ll start with the most complex engine component: the render subsystem. I’m currently working with the OpenGL driver, but I’d like to have at least a technology preview of a functional D3D driver for the first alpha.

Once I’ve finished the first alpha of the engine, I’ll probably start developing a GUI editor with different viewports over QT or GTK; this will make development easier to test, and also an excellent way to test the multiple render target functionality.

I leave showing a test sample with four different render windows, each using a dedicated render context, rendering the same scene (a stupid wireframe cube for debugging purposes), but with a dedicated viewport; each render target has a different background color. And the last sample shows a simple render target with four different attached view ports.

Multiple render targets on Windows 7

Multiple render targets on Linux

Multiple view ports on Linux

I’ve been working on the BSP level loader of Cassini. The current step is the shader material loader. Although all static shader properties are implemented and running, there is still some dynamic features I’m currently working on (all animation data and some dynamic features like vertex deformations). Anyway, I’ve been testing the loader with some Urban Terror assets and the results are very nice.

This is the “Subway” level, showing some nice blending effects and environment mapping techniques.

After finishing the shader loader, the next step will be to improve performance rendering. As actually I’m making a unique “standard” mesh for an entire level, and making a basic “traditional” frustum culling by isolating by-material submeshes. This is useful for small levels, but it is a big problem for large levels. So, the “easy” solution should be to implement PVS (potential visibility set) to make use of the pre-calculated space partitioning of Quake 3 based levels.

This is the definitive solution for large levels, but smaller levels perform faster with the current technique. And also, the current technique could be optimized by implementing octrees. This technique is used by the Irrlicht engine to avoid a custom renderer just for BSP levels: fast on small/medium levels, slow on large levels. On the other hand, the BSP sample of OGRE demos uses the classic PVS technique: slow for small levels, powerful for large levels.

So the final solution will be to give both options: the current one (perhaps optimized a little more with octrees), and the PVS one (the traditional way in BSP word…).

I’ll keep uploading screenshots of new features and cool things rendered with Cassini. There is also an image gallery coming soon at sourceforge, I’ll post the link once the service is ready and running. After the release of the gallery, I’ll upload the first source snapshot in the mercurial repository hosted on sourceforge.

Have a nice day!