Tool updates

Apart from finally releasing the core engine on github we have of course been busy with the tools, working on streamlining the ui and making it more usable in general. Both major editors have received facelifts like dockable widgets and attribute editors that consume less space. The content browser has received support for browsing (and playing) sound, previewing ui layouts, resource browsers for textures.

The leveleditor has support for layers, selecting what ui layouts and sounds to preload, game entities can be transformed to other entity classes and environment entities and vice versa. On top of all that it is possible to drag and drop items between the two programs.


Nebula trifid now on Github

After messing around for all too long we finally moved our main development to github . It’s still rough around the edges and probably close impossible to build without knowing what you are doing, but we are working on that.
The demo content will follow suite soon as well so that it is easier to get started in general.

Fun with the content tools and other updates

We have been busy lately as our game projects will be starting up soon. General updates have been a bit slow but here is a short recap about what happened in the last months:

We implemented full linux support for both Nebula and the toolchain. There are some minor issues with the math library that is currently based on bullets vectormath and some of our own code, I think some matrix  functions are a bit off, but other than that everything works as expected. That obviously means that the OpenGL4 renderer has become the primary render engine now. Some other libraries have seen integration as well as for example support for  Havok (only windows due to licensing limitations) and Recast&Detour.

Apart from that there are obviously piles of all fixes everywhere, but mostly to the toolchain, namely the leveleditor and the contentbrowser.

Samuel has had some fun with the tools and took some screencasts while experimenting


New Domain and Name

As you may have noticed, we have moved the page to a new domain and have started on writing/collecting documentation. We are still working on a release but due to changed priorities it got delayed a bit. I hope to be able to finally wrap up the release in the upcoming month, but this time no promises. One of the main reasons holding everything back is demo content, we don’t have any suitable demo game/project to release along with the SDK, and since current documentation is either a bit outdated or incomplete, it would make it a bit hard to get started if you haven’t worked with any incarnation of Nebula before.

Apart from the new Domain we also decided to changed the name of our fork. The last release of the Nebula3 SDK from Radon Labs and our version have diverged considerably with respect to tools, file formats, and the whole pipeline, that we figured we should use a new name to avoid confusion. Our version will be called Nebula Trifid from now on, keeping the to the space theme. For those that are interested, the trifid nebula is a specific nebula located in the Sagittarius constellation.



Release soon.

The time has finally come to working on the public release of our Nebula3 version. In the true spirit of when Andre still worked at Radonlabs we will release our work on N3 with the same 2 clause BSD license. We were thinking of integrating some of the things we are working on first, but if you continue on that road you will never release anything, so we decided to go ahead and just release and keep working after that. There are still some things in the pipeline, as a fully working OpenGL4 port (using AnyFX that Gustav is working on), a fully working Havoc integration (mostly done) and a rewrite of the network layer.

Currently most of the work left is cleaning up random code, adding proper copyright/license stuff, revamping the build system a bit so that it is a bit more newcomer friendly and above all create some nice demos with content we have created here. Should be done by next week hopefully, so be ready!

And in other news, glad midsommar! ;D

NIDL files everywhere!

Everybody that actually worked with N3 has probably stumbled over NIDL files. They are basically XML files that are compiled to c++ code via the idl compiler and then included in the project. They are used for example for defining the messages between entities/properties and for defining new scripting commands.

One of our age old problem when creating a level editor tool was the use of properties and attributes in the project. If the editor wants to be able to display information about properties and allow editing of attributes, it has to be linked to the actual project in some way since all that information is defined only in the code. At first we had the idea to turn everything into a shared library and use a simple launcher that will load the games shared library and then run it. That would allow the level editor to actually just load in the specific game’s library and add the actual properties to the project. While that would definitely be awesome we decided against that for the time being since we don’t have enough time.

Our much simpler solution is to have the level editor only use very simple entities with graphics and physics (for picking) and just use generic editor widgets for all attributes used by the entity. The drawback with this option is that it’s not possible to see the effect of most attributes live, but at least it is possible to edit, save and batch them to the level database.
However, this does not solve the problem of the editor not knowing about what attributes exist and are used by which entity class. Now this is where the NIDL files come into play again. I extended the idl compiler to support new entries for attributes and properties and even the information about what attributes are used by which property. Those NIDL files can then be used by the level editor to display and edit unknown attributes and properties, additionally the idl compiler will generate code that automatically defines and declares all attributes and even registers them in the properties automatically so that they don’t need to be defined in the code as well, thus avoiding the risk for them being out of sync.


Things are moving fast these days.

Nebula3 has a nice and generic scripting system that allows to register commands into the scripting system via a declaration in a nidl file. The only thing required to use it to write small code stubs for exposing functionality to the underlying scripting engine (Lua in our case).
A lot of the the desired functionality is contained in the application layer, and even better, accessible with Messaging::Messages, also defined in a nidl file.
Instead of wrapping all the functions and messages by hand I decided to wrap messages into scripting commands.
The compiler for the nidl files has been extended to automatically create scripting commands for selected messages and everything works nice and smoothly. Obviously it does not make sense to wrap all messages (the scripting system cannot work with complex types from the C++ side anyway), so messages that want to be wrapped are explicit tagged as such.

Additionally a new ScriptingFeature as been added that integrates this into the application layer as well and includes a quick&dirty property that allows to register a script with some functions that are to be called on specific occasion (like onFrame, onCollision, etc)

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.