How stable / usable is .Net wrapper for Ogre3d?

How stable / usable is .Net wrapper for Ogre3d?

In the wiki, it says that Directors arent supported for C# by Swig. What limitations will this impose in practice for using Ogre3d from .Net?

What would be the most accurate description of the state of the .Net wrapper for Ogre3d at the moment?: Experimental? Beta? Stable?

I think Ogredotnet is vary stable at this point, and definitely usable.

The absence of Directors are a big problem, it limits a lot of usability. but we have gotten around a few of these with custom wrap code to call back into dotnet.

state of the .Net wrappers? Beta.

Rastaman,

Ok, that's cool. Do you have specific examples of things I'm probably going to want to do that are tricky without directors? What sort of things are you doing to work around these cases? What things work ok at the moment?

I can tell you that my own project has me rendering a scene with the PLSM2 as my scenemanager. I have CEGUI working and doing everything I need it to do (combo boxes & listboxtextitems are the most advanced stuff I'm using so far).

To me, this means the core is stable and usable for basic stuff. I haven't gotten to the point of actually putting objects in the scene yet. I'm not bothering with that code until I get my server up and going to the point where network communications will allow it to tell the client to put an object in the scene. I don't want to do a bunch of work on the client to tell it to do that stuff on its own, since it won't be used once the server is doing that work.

So as of right now, I have a skydome, landscape, and GUI... and I'm working with the wrapper quite seamlessly.

@hughperkins
I don't have a list of thing that work or don't. But an example of something you may want to do is BillboardChain http://www.ogre3d.org/phpBB2/viewtopic.php?t=9549&highlight=billboardchain. It requires overriding a lot of function from different interfaces in ogre. With out directors we would have to create a lot of custom code to create callbacks in to .net. Plus access to ogre::RenderOperation class witch is private in ogre and giving me a lot of trouble wrapping it. I had to put Line3D in OgreDotNet because I couldn't find a way to expose RenderOperation in swig. For things like billboardchain it may be necessary to create your own c++ dll to do these things, just send it pointers to the ogre objects it would need.

Well as EagleEye sad OgreDotNet at this point works well and is stable for basic things. More advances things may need more work in OgreDotNet and we would welcome any help.

@hughperkins
Well as EagleEye sad OgreDotNet at this point works well and is stable for basic things. More advances things may need more work in OgreDotNet and we would welcome any help.

I should say that part of my own goal in making my game is to build on the ODN engine and ultimately get to the point where I will stress test it and get in to the more advanced features in a PRACTICAL application (not just a demo). It kinda makes sense to do it this way, because I'm building on a foundation of a game with a foundation of a wrapper. Ultimately I will have a fully-functional game using a fully-functional wrapper.