DotNet3D Interface Namespace - suggestion

In the RealmForge forums, we've had considerable discussion about a shared interface/types namespace. Previously I had suggested a namespace such as "Cora" to stand for "Cegui Ogre RealmForge Axiom" which are the originating projects that would comply with it. "Cora" was nixed (you don't have to act surprised), and the a new name was settled upon: "DotNet3D".

The purpose of DotNet3D namespace is to serve as the repository for Interfaces and Types implemented and used by all of these projects, and would be encouraged for use by other 3D applications in the future. Any project that implements these interfaces would not need to be wrapped, but instead could be used directly.

The current proposal looks like this:

DotNet3D.Rendering (contains the Ogre-specific interfaces/types)
DotNet3D.Gui (contains Cegui-specific interfaces/types)
DotNet3D.Math (contains the math types)

Axiom, RealmForge, and Cegui# are all being targeted to implement these interfaces directly.

The interfaces inside DotNet3D will be tailored to matchup to nearly comply nearly 100% with the OgreNet/CeguiNet implementations (i.e. they'll already implicitly implement these interfaces, but without the interface references, they'll require a full wrapper layer).

What do I need from OgreNet/CeguiNet? Answer: Nothing.

I'm just writing this note to notify you of our plans, so that you might consider a path that will converge on an implementation of common interfaces, to make the overall picture nicer (i.e. no wrappers needed for any of our projects). Unwrapped interoperability.

Our plan is to make everything work out, using the wrapper layer for OgreNet and CeguiNet, and show that we can swap it out and use Axiom/Cegui# seamlessly. Once we get this working, we'll show you all the progress we've made, and you can make your decision later. Either way, our plan is the same. The only difference will be whether or not OgreNet/CeguiNet require a wrapper to work with projects that use Axiom/Cegui#.

I wanted to start some discussions here and now, to see what folks in this forum think about the proposal. Your opinions will likely cause us to adjust our own plans (and naming) to better suit your preferences here.

Please voice your opinions about the DotNet3D proposal on this thread.

One of Ogre's greatest virtues, is that its independent: it's a graphics engine, nothing more, nothing less (excepting a few snippets of input code for the demos).

I want OgreDotNet to be the same. This means NO unnecessary dependencies. I'm not going to add a bunch of interfaces just to conform with one particular game engine. It's up to the game engine to be flexible enough to incorporate any graphics engine.

Forcing graphics engine developers to conform to a specific API will completely limit your game engine to Axiom and OgreDotNet. Maybe that's what you want, I don't know. Personally, if I were you I'd want to be able to incorporate other engines.

I think you're being overly concerned about the overhead of a wrapper. Any application worth spit, including games, has several layers of code.

I again suggest you go the route of using a simple abstract GraphicsSystem class, and derive specialized ones from it. The flexibility and extensibility of this would far, far outweigh any negligable performance loss.


public abstract class GraphicsSystem
{
public abstract void Initialise();
}

public class OgreDotNetSystem : GraphicsSystem
{
protected Root mRoot = null;
public override void Initialise();
{
mRoot = new Root();
..
..
}
}

public class AxiomSystem : GraphicsSystem
{
public override void Initialise();
{
*insert whatever the Axiom eqivalent is here*
}
}

public class EasyEngineSystem : GraphicsSystem //(my engine/side project)
{
public override void Initialise();
{
RenderApi renderapi = EasyEngine.Initialise("EasyEngine.Graphics.Direct3D9.dll");
..
..
}
}



Is DotNet3d supposed to be some independent project (aka, common set of interacts), or is it joined at the hip with RealmForge (the engine)?

You kinda keep flirting with both sides and use it interchangably, najak, so it is kind of confusing.

OgreDotNet is IN NO WAY affiliated with RealmForge.

OgreDotNet is IN NO WAY affiliated with RealmForge.

*Nods*

Part of my motivation for asking sinbad to create this forum was to keep OgreDotNet closely affiliated with Ogre. I'm sure Realmforge has plenty of knowledgable coders, but I've been following its development closely and a lot of their ideas strike me as half baked and poorly thought out.

Some people from Realmforge have been VERY impatient at OgreDotNet's pace of development, but we have different design philosphies. I prefer to make sure something actually works before moving on to something else, whereas some of the Realmforge devs appear to enjoy taking shortcuts.

Whoa, sorry if I ruffled any unnecessary feathers!

Although I agree that RealmForge's development is kind of... different... I didn't mean to start some kind of jihad, sorry. =D

What I really meant to ask was,

"is the concept of DotNet3d meant to be abstract of any back-end and serve simply as a generic interface for multiple rendering engines (kinda like that Gangsta physics engine thingy for OGRE), or is it meant to be used exclusively with RealmForge?"

I appreciate the work you've put into OgreDotNet, Maleficus and others.

It'll be fun to play with once the prebuilt binaries aren't linked against debug builds of Ogre.

It's called "OgreDotNet" for a reason... it's exclusive to Ogre.

Now the Math3D module, that's another story...

It's called "OgreDotNet" for a reason... it's exclusive to Ogre.

Now the Math3D module, that's another story...

He is not asking about OgreDotNet, I'm sure everyone is well aware by now that OgreDotNet is separate, or at least should know.

If I understand correctly, they want to create a namespace that would simply house all the different projects in such a way that you could "pick and choose" what parts you would like to use from one big project.

Personally, I have mixed emotions about this. Unless you have a large enough team or a supremely dedicated hardcore team that can devote large amounts of time to this, I would think this would be a difficult undertaking. On the other side of the coin, however, the end result would be a monolithic platform with choices that would tickle anyones developmental fancy.

In any case, you can't possibly expect every new project to conform to DotNet3D. That's why I think najak was just saying that if OgreDotNet did not want to head in that direction, it's cool. But if they did, all the better for the DotNet3D platform.

My head is still spinning from all the debate on the previous forums. And as you can tell by these latest posts, it has all left a bitter taste in some peoples mouths.

Don't worry, l33ts0n, you didn't ruffle any feathers. I knew you were talking about DotNet3D specifically, not OgreDotNet. I was just backing up EagleEye's assertion. Well, ok so maybe you ruffled HIS feathers[/crappy pun]

Debate is a healthy thing: if I felt otherwise I'd have locked this thread .

Anyways l33ts0n, as to your question:

My understanding from what najak has posted here and what I have read in the Realmforge mail list, is that they're using actual .NET interfaces. ie, they'd want all DotNet3D compatible engines to derive their classes from DotNet3D interfaces (INode, IRenderSystem, whatever).

So for example, for OgreDotNet to work with DotNet3D, I'd have to do something like the following with the Node class in the swig .i file:

%typemap(csbase) Ogre::Node "DotNet3D.Rendering.INode";

DotNet3D.Rendering.INode is an example taken from the realmforge maillist.

So in the generated .cs files, the class declaration becomes:

public class Node : DotNet3D.Rendering.INode
{
..
}

This is something I absolutely will not do, both because DotNet3D.Rendering.INode would have to be stored in another class library, creating an additional dependency that most users will never use, and because like Ogre, OgreDotNet should be completely independent of a game engine.

And of course, as I said in my first post in this thread, I think it's a silly way to go about it .

DotNet3D is completely separate from RealmForge. We're trying to establish a standard set of interfaces that match up to OgreDotNet right out of the box, for the DotNet3D.Rendering namespace.

Everyone has to choose a standard. OgreDotNet already has theirs, and it currently doesn't play well with anyone else; not even Axiom. It would seem to be a shame that Axiom and OgreDotNet won't explicitly implement the exact same sets of interfaces. (e.g. INode)

Rather than having RealmForge implement yet another new set of interfaces, our goal is make use of interfaces that already implicitly exist.

Mal, the wrappers required for OgreNet are very hefty. The fact that you've agreed to use Math3D is a nicety. Because at least that will be common.

DotNet3D has no affiliation with RealmForge. If anything, it will become the other way around. RealmForge will choose to implement to the DotNet3D interfaces, which, by the way, match the interfaces implemented by OgreDotNet3D and Axiom.

Same case goes for CeguiDotNet and Cegui#.

If all 5 projects agree to comply with the same set of non-project-dependent interfaces, then game code will look like this:

using DotNet3D.Rendering;
using DotNet3D.Gui;
using Math3D;

INode myNode = SceneManager.CreateNode(... args...);
myNode.Position = Vector3(x,y,z);

IPushButton myButton = GuiSystem.CreatePushButton( ... args ...);
myButton.BackgroundColor = Color.Grey;

....................
There will be no wrappers involved for any of the projects that comply with this same set of interfaces. RealmForge, Axiom, and I think Cegui# will all be adding the Interface references, to assure the compliance, and ensure there will be no need for wrappers.

We've already got a lot of layers... OgreDotNet is already a wrapper. I sure won't like wrapping this wrapper.

..............
Take a Poll. Of those who are planning to use OgreDotNet as their base for making their next game, who here is going to build it solely upon OgreDotNet, and rule out Axiom?

Mal, is that your plan? EagleEye, yours too? If it is, then I can understand your reluctance to implement interfaces, rather than just leaving them as raw classes.

And as I've said... I will maintain the wrapper for OgreDotNet3D, to make it look the same as Axiom. Axiom, on the other hand, won't require a wrapper, since it already will implement interfaces, and will also make use of Math3D.

I would suggest that Math3D be called DotNet3D.Math instead, or at least keep it as a consideration. We're trying to establish the "DotNet3D" base namespace as a separate franchise for commonality among projects. Ogre and Cegui are the grandfathers of the interfaces that will be put into DotNet3D. It sets you up as a leading "standard".

There's no need to argue. No matter which way you go, we'll get it working.

--------- REALMFORGE ---------
Yes, RealmForge has floundered, and it has been an embarrassment to varying degrees. Xeonx started it as a Junior in highschool, and so the mistakes made are typical of a young buck with no prior experience for large software projects. He implemented 95% of what's in SVN. Hands down, Xeonx is an intellectual and creative giant, whose roots are just starting to take hold. For his age, his accomplishments are astounding. Just keep his age in mind and realize that you are criticizing an 18 year old (e.g. he's currently at Univ Illinois, taking graduate level CS courses).

We're hard at work behind the curtains. Give us a bit of time, and RealmForge will be mostly refactored into a truly functional and effective GDK, which will initially sit on top of both Axiom and OgreDotNet.

Currently, Axiom development is now headed up by Borillis, with help from DapperDan. I think we might see a revival in Axiom coming soon. Luckily, I have my RealmForge eggs in two baskets -- yours and Axiom's.

Cheers. Mal, thanks for giving me another basket to put my eggs in.

Mal, the wrappers required for OgreNet are very hefty.


Again, you're overly concerned about layers of code. It's already been demostrated to my satisfaction that OgreDotNet runs only slightly (barely perceptibly) slower than Ogre. Which means it's speed is probably comparable to Axioms.


DotNet3D has no affiliation with RealmForge. If anything, it will become the other way around. RealmForge will choose to implement to the DotNet3D interfaces, which, by the way, match the interfaces implemented by OgreDotNet3D and Axiom.

Nice, though I still wonder why you're choosing to limit yourself to those engines. What if something else comes along in the future, or god forbid, development of Axiom or Ogre halts? (I might be bucking for a bolt of lightning from the sky by suggesting the latter ).

Same case goes for CeguiDotNet and Cegui#.

Best of luck with that . I suspect it'll require a LOT of work, since if memory serves, Cegui and Cegui# have very different APIs. Not to mention how much I had to bastardize some aspects of Cegui to get it working.

Of those who are planning to use OgreDotNet as their base for making their next game, who here is going to build it solely upon OgreDotNet, and rule out Axiom?

Mal, is that your plan?

My plan isn't to rely solely upon OgreDotNet. I've starting laying the foundations of a system to use OgreDotNet, Axiom, and my own engine, which has a unique API from the former two. Without creating interdependencies between them .


And as I've said... I will maintain the wrapper for OgreDotNet3D, to make it look the same as Axiom.

If you're going to maintain a version of OgreDotNet, why not implement those interfaces in your version? There's no saying there can't be two versions out there. Call it DotNet3D.Rendering.Ogre or something . I think I've made it sufficiently clear that I'm not going to do this. I'm even kind of regretting placing the math classes in a separate library.

edit: in fact, I believe I'm going to move the math classes back into OgreDotNet.dll. The current setup is unnecessarily awkward, and I want to avoid a slippery slope. I'm not going to implement your interfaces, so there's no reason for a common math class.


--------- REALMFORGE ---------
Yes, RealmForge has floundered, and it has been an embarrassment to varying degrees. Xeonx started it as a Junior in highschool, and so the mistakes made are typical of a young buck with no prior experience for large software projects. He implemented 95% of what's in SVN. Hands down, Xeonx is an intellectual and creative giant, whose roots are just starting to take hold. For his age, his accomplishments are astounding. Just keep his age in mind and realize that you are criticizing an 18 year old (e.g. he's currently at Univ Illinois, taking graduate level CS courses).


I didn't realise that, and my hat goes off to him. Hell, a while ago I was looking at some old pascal code I did in my early twenties, and all I can say is... eww. I clearly didn't know the first thing about OOP back then.

Take a Poll. Of those who are planning to use OgreDotNet as their base for making their next game, who here is going to build it solely upon OgreDotNet, and rule out Axiom?

I for one am using Axiom to prototype my little game at the moment. (I'm not talking about the Axiom in the Realmforge svn, but still the original one. I tried to get the realmforge one only once, but i was kinda shocked when i saw that it had things like"using RealmForge.Serialization;using RealmForge.Scripting;" in it's sources since i do in no way want to use Realmforge.).
I plan to switch over to OgreDotNet once it provides the basis of what i need, since there are things missing in Axiom and it's not updating at the moment.
I'm not using any interfaces(for the Ogre/Axiom part that is) though, but plan to just replace the "using Axiom.xyz"s with "using OgreDotNet". I can fix up the differences then, which is a not too big (one time) job due to the fact that i'm not doing anything big.

Just my 2 cents.

Without creating interdependencies between them . Thats a principle I like.

Maybe a little of my intollerance for this discussion stems from me opting to not even bother with Axiom anymore. I'm fully Ogre and OgreDotNet now. I'm not going to use CEGUI# or Axiom in any way.

I like the Math3D thing being seperated... it makes sense to do so... that's the whole PURPOSE of a library; interopability and portability. I mean honestly... a vector3 is a vector3 wherever you go, right? Quaternions are the same as well... I would consider Math3D to be a base math libraray for any Math functions for any 3D engine. Unless someone comes up with a better way to represent XYZ spaces...

In my mind, Axiom is no longer necessary... it's an anachronism... it's obsoleted by OgreDotNet... so why bother with it, except for some of those same DotNet math functions that can be easily replaced or moved in to its own library?

RealmForge I have no real clue about. I'm still trying to get a good feeling for exactly what they're trying to accomplish. Frankly, if they rely on Axiom in any way (for the reasons stated), I won't use it. I don't want Axiom on my system, and I don't want to have to get 3 or 4 dependancies just to use something that's been "alpha" for 2+ years now with little to no real progress being made on it.

I am with Ogre because it's damn near "complete"... it surely is functional, and is to the point where bug fixes are for obscure problems specific to a certain video card or chipset... that's stable, lemme tell ya!

So honestly, I see no reason for any axiom or realmforge discussions here.

So honestly, I see no reason for any axiom or realmforge discussions here.

Well, the comparisons to axiom and realmforge will persist for a bit because they were out before OgreDotNet and those folks are now taking notice of OgreDotNet. So please, lets be considerate of that and feel free to ask them to post on the realmforge forum as well.

I have no problem with Axiom/Realmforge/DotNet3D discussions here, so long as they relate to OgreDotNet.

I personally don't see OgreDotNet as replacing Axiom, it's just an alternative. Some people would prefer to use a port rather than a wrapper, and more power to them. Let's not forget OgreDotNet's primary weakness as well: swig's lack of director support.

I too have issues with Realmforges implementation of Axiom, but they're things that can be fixed.

I have no problem with Axiom/Realmforge/DotNet3D discussions here, so long as they relate to OgreDotNet.

I personally don't see OgreDotNet as replacing Axiom, it's just an alternative. Some people would prefer to use a port rather than a wrapper, and more power to them. Let's not forget OgreDotNet's primary weakness as well: swig's lack of director support.

I too have issues with Realmforges implementation of Axiom, but they're things that can be fixed.

Exactly... Let's not have discussions HERE about how RF implements Axiom and such... I don't mind comparisons, etc... but people need to get something very clear: we are not here to help Axiom or RealmForge, and I think it's inappropriate to attempt to sway the development of OgreDotNet so it will fit better or work better with another independant project.

In short, don't push your agenda on us... accept what we have, and if it fits with whatever the hell you're doing, then fine... but don't ask for changes or design decisions to be made simply for your own pet project's convenience.

Simply asking if there is interest in using a common set of interfaces and types is not inappropriate. You obviously don't think this is a good idea, that's fine. We hear you Eagle, and definately respect your opinion.
Maleficus has respectfully explained why he doesn't want to do it, and no one here is arguing with him. His professionalism is much appreciated.
Let's hope this forum continues to be open to other peoples ideas.

Dannomite, you go guy!

Mal, I am not maintaining a separate version of OgreDotNet, but simply a set of wrappers that make OgreDotNet look like DotNet3D interfaces... which will make it so that I can swap in/out with Axiom at will. I simply said that I'll keep this working, for this purpose. I realize that it won't add much to the cpu load; but hey, who wants an extra layer if it doesn't really add value (assuming the DotNet3D interfaces *do* match OgreDotNet 100%%).

I hope the Cegui# deviations don't bring us to a halt.

RF using DotNet3D interfaces does *not* tie it to Axiom nor OgreDotNet. DotNet3D is just an attempt to extract some common interfaces from a few project, so that we'll at least start out common.

In the future, we can always write wrappers to adapt to other rendering solutions... the same as we're doing for OgreDotNet3D now. My point aim is to start out with some cleaner integration among RF and the projects which we were founded upon.

Whether we choose DotNet3D interfaces or RF-specific ones.... we still face the same issues of having to write wrappers for *every* renderer that we support. It would sure be nice if there were a few renderers out that the didn't require wrappers (as well as any others in the future that implemented using DotNet3D).

Life would be better, IMO, if there were more standards. Collada for 3D modeling/meshes is a good example. I wish there were more standards for Math classes, and other 3D rendering interfaces. Standards are good, and that's why I'm pushin' for one.

That said, we'll make it work no matter what path you choose. I do hope that you'll at least stick with the Math3D library... which can be implemented by all of the projects, to give us some foundation for commonality. (otherwise, we'll be doing a lot of buffer copies from our Vectors to yours, etc...) Again, no matter what you choose, we'll make it work out.

And again, Mal, thanks for giving us another basket for our eggs.

Dannomite, you go guy!


Uh, thanks, but everyone please understand that I'm one of the moderators here and I'm not taking sides, I'm just trying to keep the peace a bit. There seems to be an us vs them thing going on between the rf/axiom guys and the ogredotnet guys and it's not healthy nor productive to say the least. Nobody here is a game programming guru and we can learn so much more from each other if we get along than if we don't.
A wise man learns from others, a fool goes it alone.

I don't mean to start a fight here. I'm just stating my own opinion. In my view, this forum is for discussions regarding OgreDotNet... if you guys want to create something else, fine... but all I ask is that before posting about it here, ask yourself if it really pertains to ODN or not.