New 0.1.7 release and SDK installer

A new release of Mogre is out there and this time you can get everything installed by grabing the modified Ogre SDK installer from here:
OGRE+MOGRE SDK Installer

Here's a list of what's new with this release:

1. Added PLSM2Helper library for accessing the options of PagingLandScapeSceneManager2[/*:m]
   
2. Added additional overload methods of SceneManager.SetOption/GetOption for convenience
   (unsafe context not needed for primitive values)[/*:m]
   
3. PlaneBoundedVolume gets cleaned up at finalization[/*:m]
   
4. Classes with copy assignment operator get a 'CopyTo' method that has the same functionality[/*:m]
   
5. Added ParticleEmmiter, ParticleAffector, ParticleEmitterFactory, ParticleAffectorFactory, and ParticleSystemFactory classes[/*:m]
   
6. All *Ptr classes (MaterialPtr etc.) are immutable value classes (like String). For example, two different MaterialPtr classes
   that point to the same Ogre:Material* pointer are considered equal and return the same value at GetHashCode, so that
   collection classes (like Dictionary) can treat them as equal.[/*:m]
   
7. The 'freeOnClose' parameter in the constructor of the MemoryDataStream class is removed, because if you pass a value other than
   the default, it will lead either to access violation exception, or to a memory leak.[/*:m]
   
8. Classes that implement interfaces (i.e Renderable for IRenderable) have been moved from 'Mogre.Subclassing' namespace to 'Mogre'[/*:m]
   
9. Added Codec, ImageCodec classes[/*:m]
   
10. Added ExternalTextureSource, ExternalTextureSourceManager classes[/*:m]
    
11. Added ParticleSystemRenderer, BillboardParticleRenderer classes[/*:m]
    
12. Added StringConverter, StringInterface/IStringInterface classes[/*:m]
    
13. Added ParamCommand class, ParameterDef_NativePtr and ParamDictionary_NativePtr structs
    (for Ogre's ParameterDef and ParamDictionary)[/*:m]
    
14. Added Box, PixelBox, PixelUtil.[/*:m]
    
15. Removed ManagedDataStreamPtr and added ManagedDataStream.
    To get the equivalent of ManagedDataStreamPtr use "new DataStreamPtr( new ManagedDataStream(stream) )". If you don't wrap
    ManagedDataStream with a DataStreamPtr, call Dispose to clean it up.[/*:m]
    
16. DataStream and MemoryDataStream do not have a finalizer now. If you don't wrap them with a DataStreamPtr/MemoryDataStreamPtr,
    you have to call Dispose to clean them up.[/*:m]
    
17. Removed SetNull method from all *_NativePtr structs, a "ptr = new OgreClass_NativePtr();" accomplishes the same thing[/*:m]
    
18. Renamed 'Destroy' method of *_NativePtr structs to 'DestroyNativePtr' to be more clear that this is not an Ogre method[/*:m]
    
19. Fixed a bug that caused "Entry point not found" exceptions when TextureUnitStates were copied and deleted[/*:m]
    
20. Added OgreException class. You can catch an Ogre exception using the .NET SEHException class and then use
    OgreException.LastException to get information from the native Ogre exception. Added exception handling to the samples.[/*:m]
    
21. Added Fresnel demo[/*:m]
    
22. Added constructors for all classes[/*:m][/list:u]

great works!

we are looking forward the new version.

thanks Bekas!

I have to agree. This is 8 kinds of awesome. I've just started porting my personal project over to Mogre. =)

Thank you for the support. As I state in the roadmap there are more stuff coming in the future

Bekas - good stuff!

We want to use Ogre via C# in our application, and we're planning ahead and trying to clarify our options.

We've been looking at OgreDotNet for a while, and we wondered just how complete a wrapper it is around Ogre 1.2.0; I've asked the question on the Forum but got no response.

I've also noticed the problems that have been encountered using OgreDotNet 1.2.0 with dll's for Ogre 1.2.3.

Obviously, we want to keep current, but we'll be facing a decision over the coming weeks about how to proceed:

1. Is OgreDotNet / Ogre 1.2.0 complete enough for our pursposes?
   Is enough missing to justify writing our own swig wrappers?
   Should we find out how to use unmanaged C++ / Ogre 1.2.3 in our C# application?
   Or, having just discovered that Mogre covers Ogre 1.2.3, should we just use Mogre?[/list:u]
   
   So my question is, how much of Ogre 1.2.3 is wrapped by Mogre? And if there is anything left to do, exactly what?
   
   Many thanks
   cheers
   Greenjacket

The only advantage of OgreDotNet over Mogre is linux support (I'm planning support for Mono in the future but you shoudn't depend on it). So

1. If you want your app to run on linux choose ODN[/*:m]
   
2. If you're only interested in Windows choose Mogre[/*:m][/list:u]
   So my question is, how much of Ogre 1.2.3 is wrapped by Mogre? And if there is anything left to do, exactly what?
   For applications that use (and not extend) Ogre's features, the wrapping is complete (all Ogre demos can be ported). It's missing classes/methods for registering .NET plugins; these will be in the 0.2 version.

Hi Bkas!

I read roadmap, it is very attractive. But I think that will spend your a lot of time to complete the work, maybe you need some partners.

A managed OGRE should be very very useful, provide our higher productivity than C++ platform.

For applications that use (and not extend) Ogre's features, the wrapping is complete

... Excellent! Many thanks!

Greenjacket