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.
It’s been a while since my last commit. I have been really busy with my private life (work, studies, and my family). But I’ve invested the last two weeks in rewriting the I/O subsystem of the engine. The purpose of this change is that the old subsystem inherited from Casandra was quite limited, and with poor error handling.
The new subsystem has a stronger error handling architecture, it’s hardly object-oriented, offers better support for Unicode strings, and uses much less memory than the ancient one, including a really efficient object reference count algorithm which prevents buffer overflows and memory leaking in almost any case.
The new subsystem is also thread safe, including support for multithread implementations (parallel loading of resources), high precision timers, mutex, auto-locking mutex, and fast atomic mutex (spin locks).
Finally, support for zip files has been extended, adding support to “bzip2” and LZMA algorithms to the existing “deflate” one.
I’m actually documenting the code to push the first snapshot in the mercurial repository. After that, I’ll start working with the render subsystem.
I’ve also been trying to add support for the OpenWatcom c++ compiler, but the problem is that the STL implementation of OW is incomplete; and Cassini makes a heavy use of STL. So after a lot of research, I’ve found some blogs where people says it’s possible to use STLPORT with OpenWatcom, so my porting strategy will be focused on STLPORT compatibility rather than OpenWatcom’s STL implementation. Anyway, the official supported compilers will still be GCC, MingW-GCC and Visual C++ (2002, 2003, 2005, 2008 and 2010).
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!
Welcome to the Cassini engine website!!
Cassini is an open source 3D graphics engine written in C++. The engine is still under development, and is the result of several years of research from many sources; I’ve started my work with a “learning” engine named “Casandra” (http://casandra.sourceforge.net) some years ago. Casandra wasn’t supposed to be a production engine, but just a “research & learn” API that I’ve been developing entirely as a hobby.
So, Cassini will take the foundations of Casandra, and will learn of many other popular 3D engines like OGRE, G3D and Irrlicht. In fact, part of my work is inspired on those awesome engines. Some other parts of Casandra’s code are made by taking ideas from popular forums like gamedev.net or flipcode. And finally, some fantastic books I’m basing parts of my work are: OpenGL Superbible, OpenGL Redbook and OpenGL Shading Language. Game Engine Architecture and Real Time Rendering. I’ll post something about those books soon.
In the upcoming days I’ll be posting the URL for the mercurial repositories. The first alpha version of Cassini won’t be as cool as I’d like, but will be a starting point…