My new C++ logging library

It has been a while since I’ve made my last post. I always prefer to write code instead of updating my blog, but once or twice a year I feel like the blog is looking abandoned and then I react with an update of the current project status.

Although I’ve done several updates to the Cassini engine, this post is to talk about my new lightweight C++ library: cpplogging.

The Cassini engine uses it’s own logging implementation, which is very simple and lightweight, but so embedded in the code that it isn’t reusable in other projects. It also lacks of some basic functionality a logging API should always have, like formatters and support for log rotations.

When I started a new project a few months ago, I tried to use the Cassini’s logging subsystem, but I’ve found it hard to extract from the core engine, and no external logging library (at least the ones I’ve tried), seamed to fulfill my requirements for a logging library: simple, fast, portable, flexible, and ready to use (no compilation needed). Even the few ones that were close to my requirements, seemed outdated or abandoned.

So I’ve decided to start a new library called cpplogging, you can take a look at http://cpplogging.sourceforge.net/ .

The library isn’t officially released yet, but you can test it  by checking the mercurial repository, or wait a few days until I release the version 1.0.

The general features of the library are:

  • Header only C++ library (no compilation needed).
  • Highly portable (it works in Windows and most Linux/Unix based systems).
  • Really fast (although it’s written in C++, the file handlers and string operations use pure CRT calls to improve performance).
  • Support for log rotations (rolling).
  • Automatic platform detection (changing the end-of-line mode according to the running OS).
  • Thread safe
  • Full Unicode support.
  • Very flexible and customizable (you can write your own handlers -syslog, eventlog, etc…-, and formatters).
  • BSD license (very liberal).

I’ll be porting the Cassini’s logging subsystem to this API soon, and then I’ll release the first cpplogging beta version on SourceForge.

Stay tuned!!


Some updates

After several months, I’ve finally got some time to write a new entry into this abandoned blog. That doesn’t mean the project is abandoned; in fact, I’ve been working a lot on it for the last months. You can always checkout the mercurial repository to keep track on the project’s activity.

The purpose of this post is mostly for giving some feedback on the project’s status, and posting a few screens of what’s going on in Cassini.

The engine has suffered several improvements and fixes, and also a lot of new features. Although several parts of the engine where rewriten, this can’t be considered as a major code refactoring like it was from the old Casandra’s engine. Cassini is now a very modular engine, and it’s easy to rewrite an entire subsystem without affecting the rest of the modules, or the general architecture; that’s why I changed some parts of he engine that were needing attention, without touching the already stable ones.

There are however some major updates that need to be explained. Here is a short list of the changes of the last year:

  • Implemented a new OpenGL 2.0 render system, entirely based on GPU programs (fragment and vertex shaders).
  • Several fixes and improvements to the Linux port (now working as stable as Windows).
  • Implemented a new material system, fully compatible with GPU programs, and legacy fixed-function based renderers. This new material system supports animations, vertex deformations, etc.
  • The geometry system has been entirelly rewriten, including several new features, like shared VBOs, multiple geometry areas per index/vertex buffer, complex culling algorithms, etc.
  • Support for Quake3 levels loading is almost complete, including support for PVS rendering, full shaders support (even animated ones), BSP models, etc.
  • Implemented support for font & text loading and rendering (using FreeType).
  • Software tessellation support for path surfaces.
  • Implemented support for 2D billboards.
  • Implemented support for 2D overlays.
  • The pixel conversion routines have been rewriten.
  • Implemented Phong Lighting model (per pixel lighting).
  • Huge code cleanup
  • Hundreds of bugs fixed.

Although the engine is quite stable right now, it is not enough featured yet to make an alpha release, I still have to implement collision detection, support for animated models, better 2D effects, fix some remaining bugs, and implement more GPU programs (like bump mapping, specular reflection, more complex ambient models like spherical harmonics or HDR, etc.).

In the meantime, you can take a look on some screens of the Urban Terror and Quake levels I’ve testing with Cassini. This shows the -almost- finished support for idSoftware’s Quake3 shader system.

The first three screenshots were taken from levels of the popular UrbanTerror game. The last one is a nice Quake3 mod level I’ve found on the web. All these levels were rendered with the current Cassini engine development snapshot.





The next step is to finish the OBJ mesh loader, add some missing features to the lighting shaders, add support for mesh animations, and add support for collision detection.

I’ll post some more screenshots once I’ve finished the new features I’me working on.



Multiple render targets and multiple view ports

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 viewports in a single render target.



New I/O subsystem progress

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.

OpenWatcom compatibility

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


Loading Urban Terror levels with Cassini

ut_subway_01I’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.ut_subway_02

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!


Cassini engine coming soon

Welcome to the Cassini engine website!!

chiropteradm_02Cassini 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…

A real time 3D graphics engine