Interested in Axiom's features

Hello all,

I'm part of a project focused on building a solid game engine, and we're currently trying to pin down what base tech we want to use. Most things have been chosen (Bullet for physics, FMod for audio, etc), but there was some talk recently of using Ogre in C++ or C# (we're using C# as our script language and most game mechanics are powered by script, so having it all in C# will avoid interop and such). Using Ogre (or some adaptation) is a requirement, so I've been looking into managed wrappers and ports for Ogre. MOgre looks to be the most up-to-date and solid, but has the critical failure of not supporting Mono (or I found no docs that said it did). We need tri-platform (Win/Linux/Mac) compatibility.

Browsing through Ogre's wiki, I run into a link here. This engine looks like a pretty solid port of Ogre to C# and says it's fully compatible with Mono (what we'd be building on). Is that all true? How up to date, compared to Ogre 1.7.1, is Axiom? What features are missing, if any? I searched your forum and saw a few threads saying that Axiom is lagging behind Ogre by a few versions. Your wiki also has some pages suggesting that. Is there anywhere or anyone I can get more detail from as to what exactly is missing? Are there are added complications using Axiom over Ogre for cross-platform development? Would a skilled C/C++/C# team have trouble shifting (at a very early stage of development) from C++ Ogre to C#/Mono Axiom?

If Axiom meets our requirements, my development team may be interested in using it, and are capable of patching most things we run into (and will of course contribute our patches back to the codebase). Just want to get a feel for the development here and how usable this is. I'll be playing with the code this afternoon.

Thanks for any replies ahead of time and cheers,
Sean

[Borrillis]

Welcome,

Everything you've read is as true as far as I know, and I've been double checking everything to make sure I'm not lying . There are a couple of issues with building on Mono, but I've isolated them to just the BSP SceneManager for the moment until the Mono team resolves a compiler issue. There is also an outstanding Mono bug in the Font Generation that I have a workaround for.

How up to date is Axiom Compared to OGRE? A most excellent and oft asked question. Unfortunately the answer is not as succinct as the question. I have verified that we are at a minimum 1.0 compatability. For the most part I think we also meet 1.2 compatibility but I have not verified every enhancement and bug fix from the OGRE 1.2 Changelog yet.Many features are updated to 1.4, and several 1.7 features are being ported or updated now ( Compositors, Terrain, Paging, SkyX, Hydrax )
If you wanted more detail, contact me directly and we can discuss it.

A team would find it easy to switch over. Although Axiom is not a straight port ( that would not make any sense ) however many of the classes are very similar to their OGRE counterparts. It goes with saying ( but I will anyway ) that patches and contributions are most welcome.

Hi pkpeachykeen,

your Project sounds interesting. Can you tell me a bit more in detail?

Also, i would like to tell you that in case you are missing something for your GameEngine, i'am very sure Borrillis will help you to succeed.
And iam also sure about the fact that some of the other guys arround here will help you too (me including ).

Would be great to see some Axiom based GameEngine



//Bostich

Well, the project itself is still in the planning stage with only a little bit of code written. We're still getting the details, like whether to use Ogre or Axiom, smoothed out. We're trying to decide whether the core components should be C++ or C#, but much of the high-level stuff is definitely C#. Thus, using Axiom could give us a one-language engine and cut development time (no writing wrappers). The team consists of a half-dozen programmers, most with at least 5 years experience in C++ and/or C#, quite a few professional programmers, and another half-dozen people involves in modeling, writing, etc. We're supporting a few legacy formats (Neverwinter Nights 1 and 2 resources, in particular) in addition to Ogre's native formats. We'd like 100% backward compatibility, so existing NWN1/2 modules and servers can be played in a new engine, while allowing the extended features Ogre et al provide.

Focus is an open-source, highly modular game engine, script-driven with minimal hard-coded mechanics. Ogre's plugin system allows us to write import modules for a variety of formats (model and archive). Using scripts and binding particular scripts or functions as callbacks (from GUI buttons, physics collision, key-presses, etc) allows us to easily adapt to whatever world/game needs to be written without recompiling the core components. We're also trying to use existing code where appropriate (SQLite for most resource handling, for example, XML heavily for definition files, that sort of thing).

The reason I'm looking into Mono-based systems is we decided a while ago to use Mono for running scripts and C# as our scripting language. We need legacy support for an older script language, which already has a very C-like syntax but is not object-oriented. C# allows us to write headers and compile the scripts down to CIL in the toolset and then native at runtime, plus allowing all the libraries and other languages that Mono supports. Seeing as we're definitely using Mono for our script system, I suggested porting the entity, world and physics systems to C#/Mono for tighter integration. It kind of went from there. :p

One of my team members is reviewing the MOgre codebase for porting to non-Windows systems and I'm checking into other methods.Using C#/Mono fully provides the script system full access to the internal SQLite database, physics, etc at runtime without using P/Invoke and other such calls back to native code. Also provides a better compile-once system, and providing platform-specific modules is much easier. On top of all that, C# is just faster to write, especially when it's as object-oriented as Ogre is.

I played with Axiom a little bit yesterday, had a few issues but I'm not sure my system was set up right. Going to keep playing with it today.

I need to check and make sure we won't be needing any features Axiom doesn't support. Compositors is the only one that strikes me as a potential issue, but I have a few years experience writing shaders and frameworks to run them where they don't belong, so that's not a big deal. I don't have a problem contributing back patches, but I'd rather not have our code team doing a whole lot of work on Axiom itself; we have quite a few other things to worry about. I'll definitely be getting in touch with you, Borrillis, as to details once I have more questions.

The first thing that comes to mind is that Ogre runs, out of the box, on OpenGL and DirectX for Windows, Linux and Mac. The tri-platform compatibility is a project requirement. I've seen that Axiom supports DX9 and OGL. Are there any complications added, or is it just like using Ogre? Will we have to add any crossplatform code or is the engine capable of handling that?

[Borrillis]

I played with Axiom a little bit yesterday, had a few issues but I'm not sure my system was set up right. Going to keep playing with it today.

Let me know if you need any assistance, I wouldn't want you to waste time with a configuration problem I could solve for you quickly.

I need to check and make sure we won't be needing any features Axiom doesn't support. Compositors is the only one that strikes me as a potential issue, but I have a few years experience writing shaders and frameworks to run them where they don't belong, so that's not a big deal. I don't have a problem contributing back patches, but I'd rather not have our code team doing a whole lot of work on Axiom itself; we have quite a few other things to worry about. I'll definitely be getting in touch with you, Borrillis, as to details once I have more questions.

Compositors are supported, there is one known issue that I've been tracking down, but other than that they are fairly solid, and updated.

The first thing that comes to mind is that Ogre runs, out of the box, on OpenGL and DirectX for Windows, Linux and Mac. The tri-platform compatibility is a project requirement. I've seen that Axiom supports DX9 and OGL. Are there any complications added, or is it just like using Ogre? Will we have to add any crossplatform code or is the engine capable of handling that?

If you use the OpenGL Renderer ( OpenTK ) then you can write once, run anywhere. The assemblies are cross platform so I compile on Windows using VS2008, then xcopy the applications to SUSE/ubuntu/MacOS to test runtime functionality.

Compositors are supported, there is one known issue that I've been tracking down, but other than that they are fairly solid, and updated.

That's good to hear. Obviously any modern engine has to at least support effects, and writing shaders is a hobby of mine (I've written a few designed more for screenshots than playing that ended up taking quite a few lines ).

If you use the OpenGL Renderer ( OpenTK ) then you can write once, run anywhere. The assemblies are cross platform so I compile on Windows using VS2008, then xcopy the applications to SUSE/ubuntu/MacOS to test runtime functionality.

What difficulties are involved in taking advantage of DirectX on Windows? Obviously we're going to be using OpenGL heavily, but I'd like to offer a DX fallback route for Windows users with Intel chipsets or newer ATI cards.

[Borrillis]

What difficulties are involved in taking advantage of DirectX on Windows? Obviously we're going to be using OpenGL heavily, but I'd like to offer a DX fallback route for Windows users with Intel chipsets or newer ATI cards.

Mostly shaders, if you are going to support both API's then it's probably best to use CG ( supported on all platforms as well ). Otherwise your writing both GLSL and HLSL, which can be done easily too using the UnifiedGPUProgram which wraps up a HLSL/GLSL shader pair and uses which ever is supported ( based on the loaded renderers ).

Shaders I can handle (I know Cg and HLSL both, and some GLSL).


I've been working to set Axiom up on my system and having a bit of trouble there. I was able to get one of your demos running (the tessellated bezier surface) and it ran as fast as stock Ogre. All the others, though, give me errors. I installed SlimDX and have had XNA for a while, but neither are found (SlimDX gives a version-related exception). I checked out the source and tried rebuilding, had a few minor issues there (related to some assemblies I needed), but I'll try that again later.
The rest of the demos fail in a couple ways. The Mono app doesn't even start, throws a few errors instead (I don't remember those but I can look them up later). The .Net app starts, but the BSP demo hits the shader compiling stage and starts recompiling the water shader to infinity ("vertex texture" unsupported or error, in the log). The others variously crash or run until I click inside the window, at which point they go to a white screen and have to be killed ("end now" usually doesn't work). Not sure what's wrong with that, but for the moment I'm going to assume it's on my system; one of my other developers was able to put together a basic Mono/Axiom app in a little over an hour and is testing it now. I need to get her report and get it working on my system.

I'd like for Axiom to work smoothly, it would definitely cut down on our development time. If we can't use Axiom or something like it, we're going to have to wrap Ogre ourselves, which obviously will be more work. I can't spend too long trying to get Axiom working, but if I can get it up in a reasonable amount of time (there's probably something little I'm missing, although I think I followed the tutorials to a T), then I'll certainly be recommending it as our rendering engine.

[Borrillis]

Axiom is currently compiled against the SlimDX Feb 2010 release.