[Xenocide-programming] Engine Research Results (Nebula2)

[<red...@pr...>]

Hi everybody, I had been evaluating the Nebula2 Engine. 


It seams that it is a pretty good engine based on the core of what it was 
Nebula. The big drawback of Nebula was that it wasnt up to date at the time we 
choose to write our own engine. Nebula2 is on the other hand a fairly new (and 
uncomplete) open source engine that is being developed by a commercial party to 
make their own game, with the plus that they had already published 3 games.

There are several characteristics that make it pretty interesting, plus others 
that dont make it a good option.

Pros

It is shader centric, their other engine (Nebula) wasnt aware of the shaders 
technology (that is why at the time we choose to develop our own, none Open 
Source engine was shader centric).

It is very stable, most of the base classes are based on the very stable core 
of Nebula so it is an stable core to work with.

It has a fairly big community that is working on it, so an OpenGL port wont be 
that far away. Not to mention other projects that use it.

It is Open Source (at least everything that is not part of the XBox Port).

They had tons of utilities and stuff to work with models, skeletons, and other 
stuff.

Cons

It is fairly low level, most of the abstractions are more low level than the 
current design. There is not an object centric framework, not cameras, 
everything is done using plain matrix multiplication.

Their code standard is consistent and followed at least in most of the code, 
however there is ancient code that do not (for instance the vector classes, 
quaternion utils, etc). It is different from our code standard.

The current implementation is only Direct3D based, however it is pretty easy 
for someone (and I bet someone will) to port it to work with OpenGL (as it 
works in the same way as Nebula). The other drawback is that at the time of 
writing it I couldnt make it yet compile in Borland, but I am trying. Cause 
they had lots of interesting tools to build using VC7 (.NET) only, but it hasnt 
been released yet to the general public (Sourceforge) so I bet there will be 
sometime in the future... (If I can make it work on Borland I will contribute 
it :D ) ... The issue of Direct3D is not as problematic as it seams (more on 
this later).

They use a very different approach to publish the objects than we do (I am not 
saying their approach is bad, just different)... In fact it is a pretty 
different approach that deserves to be researched further. I had been using a 
similar approach in the past to make a Robot Simulation Programming Environment 
but the project got cancelled and we didnt work much on the practical part 
(most of the work was theoretic). It is based on the blackboard architecture 
scheme, every object can have a name and be stored in a virtual file space. So 
for instance you can get the kernel object with the following code.

	this->kernelObject = "/sys/servers/kernel";

where kernelObject is an NRef<nKernelObject*> object that works exactly as 
common pointer.



Evaluation Results

Using the engine will have a very big learning cost, and it isnt as easy to use 
cause the interface is designed to be efficient (not easy). And the fact that 
is uses Direct3D instead of OpenGL is a problem for compatibility. However, as 
we are doing a Windows Only Implementation now there is no reason why we 
shouldnt use it, given that lots of stuff is already done. We will have to 
reimplement lots of graphics code, but that code was prototype code so we was 
going to throw it away anyways.

There is already lots of code that works and a very high level object framework 
working (in XenoEngine) using Nebula2 is orthogonal to that. XenoEngine was 
designed as a very high level, API portable framework, so the only thing we 
have to do is: Improve on the XenoEngine API to incorporate some very 
interesting features that Nebula2 already provides out of the box. And then 
implement the core of XenoEngine functionality using Nebula2 as the underlaying 
engine. In that way we win from both sides, we keep using a very high level 
object framework and we get the efficiency and tools from Nebula2 engine at a 
marginal cost.

The approach would be to revisit the interface of the XenoEngine Framework and 
as we are going to reimplement it improve upon it to make it even simplier and 
more powerful. Then use implementation inheritance or just plain delegation to 
implement the core functionality. 

About the compiler issue, that is another stick on the wheel (we use that 
expression here is Argentina, I dont know if it is used in another place :D ), 
I will have to see how to make the Nebula2 compilation process more Borland 
Friendly but the people that wants to use other compilers (VC7 in this case) 
will have an easier starting point cause the engine will be fairly easy to 
compile on it.

Another issue is the Direct3D stuff, well certainly Nebula already provides 
lots of very nice abstraction so I dont think we will need to implement that 
much using the Direct3D API directly, however if we are to do it. Direct3D is 
not that difficult to learn either, and we should try to keep that code at a 
minimmum as a design constrain.

I am sending this to the mailing list cause I want everybody that is seriously 
interested to contribute with Xenocide to give his opinion and be heard. 
Notheless if some of you have better understanding on Nebula2 and I had made 
mistakes, remember that I had taken a very high level look cause I couldnt 
compile it (but I read lots of documentation and read lots of code). So dont 
hesitate to correct what I had learned wrong.

Greetings
Red Knight