Progress on the pipeline and everything else

We have been a bit slow on the progress reporting, mostly because we have been fairly busy recently. In the last few weeks/months we have been working towards our goal to create a new content pipeline that is both easier to use, more stable, and easier to maintain and extend. The first big component, the new content browser/importer is gearing towards its completion and supports importing of FBX files with both previewing, live updating, configuring of texturing, materials and physics properties.
Textures can be easily added to a project by just opening them from the importer or even just drag and dropping them into the application. Textures can be previewed, the conversion parameters can be configured and they can be easily applied to objects.

Apart from the work on the content browser, things have been happening behind the scenes, we started on a unix/OpenGL4 port and have made quite some progress there. The main showstopper at the moment is the shader system, requiring all shaders to be written in GLSL and nody to be adapted to creating GLSL shaders. Since this was more of a fun sidetrack and our game project draws closer we chose to put it on hold and focus on more pressing things instead.
The physics integration has been rewritten from scratch, this time properly wrapping the underlying physics engine (in this case bullet), making it easier to integrate other physics engine and also cleaning up the first version that was a fairly quick hack. Apart from being an overall nicer and cleaner implementation it has been integrated into the render component, making it a first class citizen of nebula and also tying it close to the graphics system. All physics objects are using the resource subsystem, properly loaded and reused/instanced. The use of bullet files as a resource has been scrapped since it cause more problems than it was able to solve, mostly due to the fairly inconsistent manner tools and plugins create the files, apart from that it locked us to the use of bullet which we wanted to avoid as well. Physics meshes are stored using native nebula mesh formats and binary nebula files, making them independent of the physics engine used.

On a positive side note, we have acquired more workforce and have a person working full time on a new leveleditor (that will combine all the old tools into one application) and will be tightly coupled to the content browser, as well as add more extensive scripting abilities.

Since our version of Nebula3 is not really compatible with the last open source version any more we figured we should probably change its name. We have some tentative working names but haven’t really decided on something final yet.


  1. Alexander

    Great work!
    I would like to ask you, whether your work of Open Source is?
    If yes, where it is possible to get access to a source code?
    If isn’t, is your work of free ware and where it is possible to get then access to utilities and libraries?

    • johannes

      The goal is to release the engine and tools opensource under a similar kind of license the radonlabs version had. We are planning to release everything in Q2 2013, after our big game projects, since we hope to have reached a somewhat usable and stable release by then. We might release it earlier as well, depending on our progress and if there is sufficient interest from the outside world.

Leave Comment