Irrlicht Lime is a .NET wrapper for Irrlicht Engine

[Brainling]

I've been using Irrlicht Lime very successfully so far, but I am stumped on what should be a simple problem...

How do I extract the window handle from the the auto-created Irrlicht window? I've seen snippets of how to do it in C++, but all Lime seems to expose is the ExposedVideoData structure on VideoDriver, but that class has no properties of any kind...it just holds a pointer to the native structure. Obviously I can't "reinterpret_cast" in C#, so is there an accepted way to get this information using Lime?

I guess I could write some CLI/C++ to get the information, but that seems like overkill.

[greenya]

Yes you right.
Currently there is no Lime' ability to get window handle created internally by Irrlicht. I will add this very soon to trunk, next release will has it.

For now, most suitable way i guess would be to read property System.Diagnostics.Process.GetCurrentProcess().MainWindowHandle after Irrlicht actually spawned the window (so after CreateDevice()) (before - it returns handle of the console window).

[Brainling]

Yeah, the MainWindowHandle for the process is what I'm using right now. Thanks for the reply.

[Brainling]

One more quick one: Are there any plans to expose the draw2DImageBatch calls to the wrapped video driver class?

My game uses a lot of texture atlasing, and I'd like to be able to leverage those calls.

[greenya]

Yes, it should be no problem to expose this method.
Will be available in next release for sure.

[greenya]

Version 1.2 has been released

New examples:

L11.BulletSharpTest // simple physics usage with Lime (using BulletSharp, a .NET wrapper for Bullet) // preview
L12.StencilShadows // custom dynamic stencil shadows // preview
L13.FractalBrowser // Mandelbrot set generator // preview

Changes:
- Updated Irrlicht SDK to trunk rev. 4295.
- MaterialRendererServices changes: renamed SetPixelShaderRegisters() and SetPixelShaderVariable() to SetPixelShaderConstant(); renamed SetVertexShaderRegisters() and SetVertexShaderVariable() to SetVertexShaderConstant(); added 2 more overloadings to Set*ShaderConstant() which takes int array and 2 more overloadings for bool arrays.
- Added "double" versions for common types: Vector2Dd, Vector3Dd, Dimension2Dd and Rectd.
- Replaced SetRotationAxisRadiansLH() and SetRotationAxisRadiansRH() with SetRotationAxisRadians() in Matrix, which assumes left handed rotation.
- Removed assert check for !Locked in Lock() in TexturePainter, since Lock() returns bool, and it is OK to receive "false" and check it at runtime.
- Added Draw2DImageBatch() to VideoDriver.
- Added DeviceContext, RenderingContext, WindowID props and public constructor to ExposedVideoData.
- Added CursorPlatformBehavior enum. Added PlatformBehavior prop to CursorControl.
- Removed SetLoopMode() and added LoopMode prop (getter and setter) to AnimatedMeshSceneNode.
- Added overloading to DrawStencilShadow() which takes single color of the shadow in VideoDriver.
- Added DriverMultithreaded prop to IrrlichtCreationParameters.
- Added useAlphaChannel argument to AddImage() to GUIEnvironment.
- Added Name prop to GUIElement.

[greenya]

Hello.
I have created small website where I will try to gather all Irrlicht Lime related info http://irrlichtlime.sourceforge.net/
If you have some screenshots or videos of your project which uses Lime and you would like to share it, feel free to message me.

[bdpdonp]

From an earlier post, irrKlang has a NET dll as part of the distro and works well.

I am using Lime, irrklang and still investigating a physics engine. But I like the results so far. I have a side by side comparison, c# and Lime for one and the other is C++ with irrlicht. Overall less than 10% performance difference.

The physics is a pain, looking at Bullet/Bullet sharp and BepuPhysics non dependency version. It is getting very tempting to write my own that is tightly integrated with irrlicht types.

Edit: Going ti bite the bullet so to speak. I am taking the latest version of ODE and converting it to c#, and will utilize the math from Lime. If there is any interest I will be glad to post it when finished. I plan on implimenting the GIMPACT and the libccd, but not the OPCODE. At least for now.

[greenya]

It is good idea.
If you have anything to share - post it or pm me, i will check it.
Try to make your code as more educative as possible

[bdpdonp]

One thing I dislike about so may of the Physics Engines is they use the callback function. Literally becoming the core of the game. Not to mention they all seem to have their own math, requiring conversion to use with the graphics engine. More waste. Not to mention creating a model requires two classes, one for the graphics and one for the physics.

What I want is a physics engine that integrates well with Lime, and does not require conversion, does not do callbacks. And uses IList that are passed to the engine. Also a engine that is easy to modify and understand for anyone to make changes. Also, not a library, but code that is integrated into the game code as physics is very intensive.

I have been looking at a few engines and ODE is probably the best as far as the code, but it is still not well documented. Guess I am spoiled by irrlicht. Decided maybe I should put my education to use, so here comes another physics engine that is a hybrid of others, written in C#, will be documented and tight integration with Lime (uses the Lime Vector3Df rather than create its own!)

I think I have all the 3D vector stuff needed:

cpp Code: Select all

 
using IrrlichtLime.Core;
 
namespace FleetCommand.Physics {
 
    // the core class will contain definitions used in the physics portion
    internal class core {
        internal static float GRAVITY = -9.81f;         // gravity does not necessarily affect the y axis so use as a float
        internal static float HIGH_GRAVITY = -19.62f;
    }
 
 
    internal class Vector {
     
        // create a new vector that is the componenet wise product of the  two vectors passed   V = V1 o V2
        internal static Vector3Df ComponenetProduct(Vector3Df v1, Vector3Df v2) {
            return new Vector3Df(v1.X * v2.X, v1.Y * v2.Y, v1.Z * v2.Z);
        }
 
 
        // in place componenet product update.   V1 = V1 o V2
        internal static void ComponenetProductUpdate(Vector3Df v1, Vector3Df v2) {
            v1.X *= v2.X;
            v1.Y *= v2.Y;
            v1.Z *= v2.Z;
        }
 
 
        // add a vector that is also scaled    V1 = V1 + V2 * S
        internal static void AddScaledVector(Vector3Df v1, Vector3Df v2, float scale) {
            v1.X += v2.X * scale;
            v1.Y += v2.Y * scale;
            v1.Z += v2.Z * scale;
        }
 
 
        // puts a alimit on the size of the vector, no point in have a vector magnitudes larger than the view area.
        internal static void Trim(Vector3Df v, float size) {
            if (v.LengthSQ > (size*size)) {
                v.Normalize();
                v.X *= size;
                v.Y *= size;
                v.Z *= size;
            }
        }
 
 
        // creates a normalized unit vector
        internal static Vector3Df Unit(Vector3Df v) {
            Vector3Df vt = new Vector3Df(v);
            vt.Normalize();
            return vt;
        }
 
 
        // create a triple of orthogonal vectors where each vector is a right angles to the other two.
        // order of the cross product is critical as this is a left hand coordinate system
        internal static void OrthonormalBasis(Vector3Df v1, Vector3Df v2, Vector3Df v3) {
            v1.Normalize();
            v3 = v2.CrossProduct(v1);
            if (v3.LengthSQ == 0f) return;
            v3.Normalize();
            v2 = v1.CrossProduct(v3);
        }
 
 
 
    }
 
 
}
 

[bdpdonp]

After investigating ODE a bit, I also looked into 2 c# physics engines. Both are fairly current and free.

BEPU has a dependency free version, that does not depend on XNA, and I currently have it working quite nicely with irrlichtLime. http://bepuphysics.codeplex.com/

There is another called Jitter, that also works well. This is undergoing some upgrades so get the SVN source for the latest.
http://www.jitter-physics.com

Both are native c#, numerous collision bodies etc. This is a short demo that compares them, basically the same.
http://www.youtube.com/watch?v=3kX8zfBokW4

No point in reinventing the wheel, so I will use one of them rather than port ODE.

[bdpdonp]

I just did some simple benchmarks to evaluate performance as far as Vector and Matrix math. I did numerous tests and took an average. I only times the math section.

irrlichtLime (using Vector3Df) 3.37 seconds
Jitter Physics 3.26 seconds
BEPUphysics 3.04 seconds
C++ /irrlicht 3.09 seconds

[greenya]

Not bad at all as for the wrapper.
I hope you use Release build

[EagleEye]

I'm really enjoying using Lime. I have a problem, though. I can't figure out how to access point entities from a Q3 BSP, nor can I figure out how to access brush entities. I know that example 21.Quake3Explorer demonstrates how to get point entities, but it isn't included with Lime. Additionally, I was converting example 27.Quake3BrushEntities from here to Lime, but I can't find any version of these:

cpp Code: Select all

tQ3EntityList
tQ3EntityList.binary_search()
IEntity
AnimatedMesh.GetEntityList()
AnimatedMesh.GetBrushEntityMesh()
//I might be forgetting a few classes or functions

I assume stuff related to point and brush entities just aren't wrapped yet, right? If so, approximately how long would it take to wrap them?

P.S. Thank you for making Irrlicht Lime. It's definitely made Irrlicht much more accessible to me.

[greenya]

Well, 21.Quake3Explorer is not ported because stuff from irr::quake3 namespace should be ported first.
I cannot say for sure when this will be available in Lime.