RE: [Xenocide-programming] Engine Research Results (Nebula2)

[mamutas <ma...@pr...>]

Hi everybody,

I finally found some time to comment on that email.

First, I want to say that RK did really good job on evaluation keeping =
in
mind the time he had for that. Second, I like pros and cons section. =
That is
really helpful.

Pros are clear, so I will comment on cons only.
* Low level. I am not certain, but I think that most of the existing =
engines
will feature different level of implementation or different set of API, =
so
we would be forced to write our wrappers around them anyway. So, I do =
not
see it as a big con, since it is pretty much unavoidable with =
third-party
engines.
* Code standard. I do not expect we would be dealing with their code a =
lot
(same like with third-party headers), so it does not appear like a big =
con
either.
* I understand that there is going to be an OpenGL implementation of
Nebula2. I also understand that if we will be writing our wrapper around =
it,
it would not make any differences if we would swap DX implementation =
with
OpenGL lately. Would it?

The biggest problem I see is a compilation issue. We probably need to
discuss it a bit further.

So, the bottom line seems like that we all agreed to move on it, right? =
In
that case, it would be nice to make some transition plan. I mean we need =
to
look over what do we need to do: what do we need to replace in engine, =
what
do we need to write around, etc.=20

Regards,
mamutas

> -----Original Message-----
> From: xen...@li...=20
> [mailto:xen...@li...] On=20
> Behalf Of red...@pr...
> Sent: Tuesday, October 28, 2003 4:14 PM
> To: xen...@li...
> Subject: [Xenocide-programming] Engine Research Results (Nebula2)
>=20
>=20
> Hi everybody, I had been evaluating the Nebula2 Engine.=20
>=20
>=20
> It seams that it is a pretty good engine based on the core of=20
> what it was=20
> Nebula. The big drawback of Nebula was that it wasnt up to=20
> date at the time we=20
> choose to write our own engine. Nebula2 is on the other hand=20
> a fairly new (and=20
> uncomplete) open source engine that is being developed by a=20
> commercial party to=20
> make their own game, with the plus that they had already=20
> published 3 games.
>=20
> There are several characteristics that make it pretty=20
> interesting, plus others=20
> that dont make it a good option.
>=20
> Pros
>=20
> It is shader centric, their other engine (Nebula) wasnt aware=20
> of the shaders=20
> technology (that is why at the time we choose to develop our=20
> own, none Open=20
> Source engine was shader centric).
>=20
> It is very stable, most of the base classes are based on the=20
> very stable core=20
> of Nebula so it is an stable core to work with.
>=20
> It has a fairly big community that is working on it, so an=20
> OpenGL port wont be=20
> that far away. Not to mention other projects that use it.
>=20
> It is Open Source (at least everything that is not part of=20
> the XBox Port).
>=20
> They had tons of utilities and stuff to work with models,=20
> skeletons, and other=20
> stuff.
>=20
> Cons
>=20
> It is fairly low level, most of the abstractions are more low=20
> level than the=20
> current design. There is not an object centric framework, not=20
> cameras,=20
> everything is done using plain matrix multiplication.
>=20
> Their code standard is consistent and followed at least in=20
> most of the code,=20
> however there is ancient code that do not (for instance the=20
> vector classes,=20
> quaternion utils, etc). It is different from our code standard.
>=20
> The current implementation is only Direct3D based, however it=20
> is pretty easy=20
> for someone (and I bet someone will) to port it to work with=20
> OpenGL (as it=20
> works in the same way as Nebula). The other drawback is that=20
> at the time of=20
> writing it I couldnt make it yet compile in Borland, but I am=20
> trying. Cause=20
> they had lots of interesting tools to build using VC7 (.NET)=20
> only, but it hasnt=20
> been released yet to the general public (Sourceforge) so I=20
> bet there will be=20
> sometime in the future... (If I can make it work on Borland I=20
> will contribute=20
> it :D ) ... The issue of Direct3D is not as problematic as it=20
> seams (more on=20
> this later).
>=20
> They use a very different approach to publish the objects=20
> than we do (I am not=20
> saying their approach is bad, just different)... In fact it=20
> is a pretty=20
> different approach that deserves to be researched further. I=20
> had been using a=20
> similar approach in the past to make a Robot Simulation=20
> Programming Environment=20
> but the project got cancelled and we didnt work much on the=20
> practical part=20
> (most of the work was theoretic). It is based on the=20
> blackboard architecture=20
> scheme, every object can have a name and be stored in a=20
> virtual file space. So=20
> for instance you can get the kernel object with the following code.
>=20
> 	this->kernelObject =3D "/sys/servers/kernel";
>=20
> where kernelObject is an NRef<nKernelObject*> object that=20
> works exactly as=20
> common pointer.
>=20
>=20
>=20
> Evaluation Results
>=20
> Using the engine will have a very big learning cost, and it=20
> isnt as easy to use=20
> cause the interface is designed to be efficient (not easy).=20
> And the fact that=20
> is uses Direct3D instead of OpenGL is a problem for=20
> compatibility. However, as=20
> we are doing a Windows Only Implementation now there is no=20
> reason why we=20
> shouldnt use it, given that lots of stuff is already done. We=20
> will have to=20
> reimplement lots of graphics code, but that code was=20
> prototype code so we was=20
> going to throw it away anyways.
>=20
> There is already lots of code that works and a very high=20
> level object framework=20
> working (in XenoEngine) using Nebula2 is orthogonal to that.=20
> XenoEngine was=20
> designed as a very high level, API portable framework, so the=20
> only thing we=20
> have to do is: Improve on the XenoEngine API to incorporate some very=20
> interesting features that Nebula2 already provides out of the=20
> box. And then=20
> implement the core of XenoEngine functionality using Nebula2=20
> as the underlaying=20
> engine. In that way we win from both sides, we keep using a=20
> very high level=20
> object framework and we get the efficiency and tools from=20
> Nebula2 engine at a=20
> marginal cost.
>=20
> The approach would be to revisit the interface of the=20
> XenoEngine Framework and=20
> as we are going to reimplement it improve upon it to make it=20
> even simplier and=20
> more powerful. Then use implementation inheritance or just=20
> plain delegation to=20
> implement the core functionality.=20
>=20
> About the compiler issue, that is another stick on the wheel=20
> (we use that=20
> expression here is Argentina, I dont know if it is used in=20
> another place :D ),=20
> I will have to see how to make the Nebula2 compilation=20
> process more Borland=20
> Friendly but the people that wants to use other compilers=20
> (VC7 in this case)=20
> will have an easier starting point cause the engine will be=20
> fairly easy to=20
> compile on it.
>=20
> Another issue is the Direct3D stuff, well certainly Nebula=20
> already provides=20
> lots of very nice abstraction so I dont think we will need to=20
> implement that=20
> much using the Direct3D API directly, however if we are to do=20
> it. Direct3D is=20
> not that difficult to learn either, and we should try to keep=20
> that code at a=20
> minimmum as a design constrain.
>=20
> I am sending this to the mailing list cause I want everybody=20
> that is seriously=20
> interested to contribute with Xenocide to give his opinion=20
> and be heard.=20
> Notheless if some of you have better understanding on Nebula2=20
> and I had made=20
> mistakes, remember that I had taken a very high level look=20
> cause I couldnt=20
> compile it (but I read lots of documentation and read lots of=20
> code). So dont=20
> hesitate to correct what I had learned wrong.
>=20
> Greetings
> Red Knight
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.=20
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/=20
> _______________________________________________
> Xenocide-programming mailing list=20
> Xen...@li...
> https://lists.sourceforge.net/lists/listinfo/xenocide-programming
>=20
>=20
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.525 / Virus Database: 322 - Release Date: 2003/10/09
> =20
>=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.525 / Virus Database: 322 - Release Date: 2003/10/09
=20