Irrlicht Lime is a .NET wrapper for Irrlicht Engine

[netpipe]

works good on mono http://i.imgur.com/9a0gc9O.png tried compiling a few versions, one compiled without too much of a struggle think it was one of zaki's older ones. um the irrlicht lime contains vcxproj files that are incompatable with mono if someone could get rid of them it might compile fine too. IrrlichtLime.vcxproj L08.WPFWindow.csproj are showing as incompatable 20 and 21 examples are showing as load failed http://i.imgur.com/kbl9EYu.png

[Foaly]

I am trying to use lime on updated VS IDE's. VS2013 works fine, but not 2015 CTp..

Well, I only have VisualStudio 2010, so I can't check what's wrong.

works good on mono

Well, what you show on you first screenshot is Irrlicht .NET CP. It has nothing to do with our project. It is - as far as I know - written in C# and uses a modified Irrlicht source. Our project uses unmodified sources.

irrlicht lime contains vcxproj files that are incompatable with mono if someone could get rid of them it might compile fine too

I don't think so. The project which creates the .dll is incompatible. Currently, mono doesn't support compiling projects which are written in C++/CLI, but IrrlichtLime needs that to work.

incompatable 20 and 21 examples are showing as load failed

Oh, sorry, I created two extra examples, which I did not commit yet to the svn. They both aren't yet stable and the code needs a lot of cleanup.

[bruce965]

I think I found a nice way to actually do non-marshalled native calls from Mono to C.

Extremely elementary sample code:

Code: Select all

 
[DllImport("libTest.so")]
static extern void init();
 
[DllImport("libTest.so"), MethodImpl(MethodImplOptions.InternalCall, MethodCodeType=MethodCodeType.Runtime)]
static extern /*IrrlichtDevice*/IntPtr irr_createDevice(DriverType deviceType, Dimension2D<UInt32> windowSize, uint bits, bool fullscreen, bool stencilBuffer, bool vSync, /*IEventReceiver*/IntPtr receiver);
 

Code: Select all

 
irr::IrrlichtDevice* irr_createDevice()
{
    return irr::createDevice(irr::video::EDT_SOFTWARE, irr::core::dimension2d<irr::u32>(640, 480), 16, false, false, false, 0);
}
 
extern "C" void init()
{
    mono_add_internal_call ("Test.Program::irr_createDevice", (gpointer)irr_createDevice);
}
 

Code: Select all

 
static void Main(string[] args) {
    var device = new IrrlichtDevice(DriverType.Software, new Dimension2D<uint>(640, 480), 16, false, false, false);
}
 

Console output:

Code: Select all

 
Irrlicht Engine version 1.8.1
Linux 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64
Using plain X visual
 

So... is there a chance Irrlicht Lime will ever be running on Linux now?

References:
http://forcedtoadmin.blogspot.it/2014/0 ... mance.html

[Foaly]

That's certainly interesting. Thank you for showing us.

As I see it, we would have to split Lime into two projects, one containing the C code and one with C# code. Please correct me if that's wrong.
But the idea behind Lime is, that it is written in C++/CLI, which makes writing it very easy. And I don't have much experience with Linux, so I'm not sure if I could even get it to compile.
So I don't see a way of getting Lime to run on Linux until Mono supports C++/CLI, sorry.

[bruce965]

I will try to do something interesting, maybe I'll even find a way to make it binary-compatible with Lime.

[bdpdonp]

Compiles and runs fine on Community Edition 2015 RC, no changes.

[matty]

Hi,

I am interested in the design of the L11.BulletSharpTest project - specifically how threading is used.

This project creates a new thread for each physics timestep but then updates the Irrlicht objects from within this thread (ie outside the main thread that Irrlicht is being processed in).

I am curious what are the implications of this. I mean, there is no synchronisation anywhere in the example, so are the Irrlicht / Irrlicht Lime objects thread safe and hence there is no issue?

Just wondering if anyone has any thoughts?

Cheers
Mat

[Foaly]

If you want to write a serious program, you should make proper use of locks and all that stuff.

Irrlicht by itself is NOT thread safe.
In this case it's just a simple example and the main point is, that it can't crash.
That's because the simulation thread only uses scene nodes, that aren't deleted (because only the sim thread removes them) and it does not access the video driver.
If you try to render from more than one thread, you quickly get problems, but here it only calculates the physics.

But it is not guaranteed that the scene is consistent every frame. (e.g. you could have some objects at their positions of previous step and some at new positions in one frame.)

Somewhere, I've got another physics example which uses proper multi threading and interpolation. (But it's part of a bigger project.)

[matty]

Thank you for your insight.

[lumlum]

Hello,

I've been using and testing Irrlicht along with Irrlicht Lime the past few weeks because I plan to use it in a future 4 months project. Everything has been working pretty well so far except for a few things such as http://irrlicht.sourceforge.net/forum/v ... =4&t=51126 . However in my project I will need to create and save custom scenes and meshes from point cloud data and I was quite surprised to see that the createMeshWriter method from which you can then use a MeshWriter in order to save a mesh to a file is not implemented in Irrlicht Lime. I was wondering if you planned to add it anytime soon since using .NET C# could be very interesting for me and thus your wrapper could potentially be a better option than Irrlicht.
I could certainly still use Lime and write something to save meshes by myself but I think adding it to Lime since it's already in Irrlicht and just has to be wrapped could be a good thing for the wrapper.

Lumlum.

[Foaly]

Hey Lumlum.

Sadly I didn't have time recently to keep Lime up-to-date.
The last release was in April 2014, my last commit was in April 2015.
Are you using the trunk version or 1.4? I always tried to keep the trunk as stable as possible, so if you want the most up-to-date Lime, use it from there. (But I can't promise anything.)

If you plan on using your own mesh format, using the MeshWriter class won't help you at all, because there is no way to inherit it and give it back to the scene manager. (CreateMeshWriter is hard-coded.)

The only use for createMeshWriter is to access an MeshWriter, that's already existing in Irrlicht.
Actually I think I've already implemented that method, but I did not commit it, because I always update everything that's changed since the last commit on the actual Irrlicht repos, and I wasn't done yet. I was also changing the Rect class to a struct and I don't know anymore, whether I was already done.

So it's generally no problem to add it, but because I didn't do anything c++ related in a long time, so it will take a while to get started again, maybe I'll get to it after christmas.
Though, if you can compile Lime yourself, I can give you a .diff with the changes necessary for MeshWriters.

[lumlum]

Hey Foaly, thx for answering quickly.

Hey Lumlum.

Sadly I didn't have time recently to keep Lime up-to-date.
The last release was in April 2014, my last commit was in April 2015.
Are you using the trunk version or 1.4? I always tried to keep the trunk as stable as possible, so if you want the most up-to-date Lime, use it from there. (But I can't promise anything.)

Yes i'm already using the trunk version compiled for both x86 and x64 bits and I haven't had any issue with any of the versions so far which is why i'm considering using it since the trunk version is also x64 compatible (which is a must for me).

If you plan on using your own mesh format, using the MeshWriter class won't help you at all, because there is no way to inherit it and give it back to the scene manager. (CreateMeshWriter is hard-coded.)

Yeah, when I said i'd write something myself I actually just meant something like Irrlicht's MeshWriter for one of its supported format in order to replace the original MeshWriter since it's not implemented yet. I don't really plan to use my own Mesh format.

Though, if you can compile Lime yourself, I can give you a .diff with the changes necessary for MeshWriters.

However if you've got a Lime version with it already implemented I'd gladly compile it and test it out.

Merry Christmas,
Lumlum.

[Foaly]

There's a patch containing the MeshWriter only: .patch
It's untested and has no documentation yet.

Merry Christmas!

[lumlum]

I was going to say that I tested the patch last week and it was working fine except for a few lines I had to remove but I just saw that you've actually already added it to the trunk, thanks.

[stuzor]

Hello,

Nice job with Irrlicht Lime, it is working great for us so far.

I'm fairly new to this library, I was hoping you could help point me in the right direction? We're trying to create some print functionality in our application so I'm wondering how to get access to the render buffer of an IrrlichtDevice.

Currently the only way we can figure out how to save the view contents to a file is to get the Windows screen buffer, which wouldn't work for obvious reasons - like what if there's another window covering ours? Plus we'd be limited to the resolution of the screen etc.. So presumably there is a way to get access to the render buffer from the IrrlichtDevice?

For the first stage of this print functionality our plan is to simply save the view to a file, and let some other program handle the printing. Ideally what I'd like to do is create a new IrrlichtDevice with an existing SceneManager, have it render into a large view (often larger than the screensize) and then write that render buffer to a file stream. Is this even possible with Irrlicht / Irrlicht Lime?

Thanks
Stu