- Platform independence: I am using CMake to manage build systems, which means that it is now possible to compile the tool for either Windows (32/64 bit) or apple osx (32/64 bit, Intel, PPC) using a variety of compilers (Visual Studio, XCode). It took me a while to learn the (quirks of the) CMake scripting language, but it was time well spent.
- I decided to drop the use of Cg: Previously I was using NVidia's Cg language to write shaders in, most importantly because it is able to generate both Glsl and Hlsl shaders based on the same Cg code. What I did not take into account was the bugs that Cg itself contains. For instance, some Glsl shaders which I had ported to Cg, work when compiled to Hlsl but not Glsl. With other shaders it is the other way around. After looking around on the internet for possible causes, I learned of the bugs in Cg. Even though I will keep support for Cg (and DirecX) in the tool, from now on I will write all shaders in Glsl (and use the OpenGl render system)
- Investigated other graphics rendering middleware: I briefly investigated using another graphics rendering library (Cinder) as a replacement of Ogre. I think I could reuse most of my tool's code (both the graphic user interface and the underlying engine code) and that it certainly is usable, however I decided to not pursue this any further. Although Cinder is a young and promising library, it is aimed more at 'creative coding'. Although that is in part the use that I have in mind for my tool, it is quite possible that I will have a need for my tool to do more than 'just' creative coding. Also, even though Cinder works just fine 'out of the box', as soon as you make a few changes (e.g. compile to a shared dll instead of a static library) the proverbial shit hit the fan. Although I lost little over a week on experimenting with Cinder, I decided to stick with Ogre (for now).
- Several small functional updates / code refactors: I made some small changes in the types of nodes that are available. Instead of having several camera nodes connect to a single scene node, each scene node now exposes its own (single) camera object. You can animate (keyframe) the camera object, and by connecting an Animation-multiplexer node, you can switch between any 1 out of up to 10 connected animations for the camera object. This allows you to switch between several camera viewpoints within the same scene. As a result of this and other changes, the way that functionality is now divided over several nodes looks and feels much 'cleaner'. I think this will work out just fine!
Here is a list of things to do, in no particular order:
- Test & fix bugs: I fixed a bug that has been present for a long time. But by accident I also discovered a new one: in the undo/redo system. Even though I have an idea about how to fix the bug that I came across, I need to test this more extensively before I add new features to the tool.
- Deferred particle renderer: I have not done much work on this yet, even though I intended to have it finished by the end of the summer. I did spend some time looking at the math that is involved though, but I lost track of the notes that I took of it. Oh well.
Unfortunately, the academic year is also about to start. Luckily I am not taking any courses this year (at least, none for which I need to take an exam) so I may still find plenty of time to work on this project. It is now much more likely that I will end up using this tool in my PhD research, but I'll talk about that a bit more when the time comes...
... to be continued ...
