Irrlicht Lime is a .NET wrapper for Irrlicht Engine

[bdpdonp]

I did try to compile a 64 bit version, unsuccessfully. For now I will wait as there is no pressing need, 64 bit gaming performance is not really superior to 32 bit. Using the wrapper and irrlicht is still far superior to XNA and I really do like C# better than C++

[greenya]

I don't know but if you simple tried to build Lime SDK (zip archive from sf.net) in 64 bit that just will not work. Because In SDK Irrlicht's lib and dll are 32 bit (there is no 64 bit provided by me).

[greenya]

Version 1.1 has been released

New example:
L10.ImageBrowser // demonstrates some way how multithreading can be used. Example represent simple image browser that allows to choose folder where images should be looked for. Thumbnails will be loaded in background (in 4 threads (configurable through constant in the code)), as soon as each thumbnail is ready - it will be applied as texture to the plate of the image. You can click on the image to zoom it to full rendering area; application will load another instance of the image with 2048x2048 resolution. In example also shown the way how resources (in our case textures only) can be managed (application correctly unloads old thumbnails and fullsize images at runtime). Also simple animation manager is implemented to bring nice look and feel to UI. If you have processor with 4+ cores (8+ virtual cores), you will not feel "hangs" or some sort of delays in responding of UI at time of loading/unloading images. If you have less cores, you may experience small twitching in UI respoding. However, even with 2 virtual cores you may browse previews and click and zoom images while rest content of the folder is loading.

Shot:


Updated Irrlicht SDK to trunk rev. 4098.
See changes.txt for full list of changes.

[bdpdonp]

Great news, look forward to doing more with the new examples.

[LanceJZ]

Sweet! Thank you!

[LanceJZ]

I have an issue, that is still present, I don't know if you are aware, but shadows don't work if you use DirectX in Lime, though they should, with the same app in Irrlicht they work just fine. Try the SpecialFX example, and you will see what I mean. It has more then one issue, as you will see.
Thank you for your time.

[greenya]

The shadows don't work in DirectX in Irrlicht too.
This is the screenshot of what i have with trunk rev. 4098 (the latest)
http://filebeam.com/7b662773589e03a0482 ... b4f791.jpg

P.S.: but yes, with 1.7.3 release there is no such problem.

[LanceJZ]

The shadows don't work in DirectX in Irrlicht too.
This is the screenshot of what i have with trunk rev. 4098 (the latest)
http://filebeam.com/7b662773589e03a0482 ... b4f791.jpg

P.S.: but yes, with 1.7.3 release there is no such problem.

That is right, I tested it in Irrlicht before posting, as I said, have a look. There is problems with the alpha too, as you can see the black around the particles. Is this something that can be fixed? I have no clue as to why that would happen.
As you can see here.
It has worked sense at least 1.7.2 but not in Lime.

Thank you for your time.

[greenya]

I'm started to think that using trunk version was bad idea, because it has problems all the time. I should better use branches. Maybe i will release kind of 1.1.1 which will use 1.7.3 only.

[hindupower]

I was testing out the difference between native Irrlicht and Irrlicht Lime for dynamic mesh handling. In native Irrlicht a static mesh(derived from a heightmap) of around 16000 vertices give me around a 1000fps and if I change the mesh buffer to use stream hardware hint while also updating each vertex every frame I get around 150fps. I tried this out in Irrlicht Lime and got around a 1000fps also for a static mesh, but when I updated every vertex in the mesh each frame using a hardware hint of stream, I get around 20 fps.

EDIT: using vertices.Count() in the loop checking seemed to slow it down a lot and replacing it with buf.VertexCount gives me around 40 fps, but that is still way off from 150.

I think I'm doing something wrong with the way I update the vertices and if not is this a known problem.

This is the function that updates the vertices in the mesh and this function is inside my HeightMap class and it is called from the main function:

public void UpdateVertices(MeshSceneNode node)
{

for (int i = 0; i < vertices.Count(); i++)
{
Vector3Df pos = vertices.Position;
pos.Y += 1f;
vertices.Position = pos;
}
//buf.SetDirty(HardwareBufferType.Vertex);
buf.UpdateVertices(vertices, 0);

buf.RecalculateBoundingBox();
node.Mesh.RecalculateBoundingBox();
}

Any ideas as to what is wrong?

[WaxyChicken]

Code: Select all

Vector3Df pos = vertices[i].Position;
pos.Y += 1f;
vertices[i].Position = pos;

I Don't Speak C, but can't you reduce this to save computing power or ticks?
i know it doesn't sound like a lot but with 16,000 verts it can add up.

Vector3Df pos = vertices.Position;
pos.Y += 1f;
vertices.Position = pos;

something like:
vertices.Position = Vector3Df(vertices.position.x, vertices.position.y + 1f, vertices.position.z);

it looks like that would remove:
A: assigning vertices values to temporary pos variable.
B: pos.y = pos.y + 1.0f

would that reduce execution time or just make the line messier? LOL

[LanceJZ]

I'm started to think that using trunk version was bad idea, because it has problems all the time. I should better use branches. Maybe i will release kind of 1.1.1 which will use 1.7.3 only.

That may be a good idea, as that is a more tested/stable version.

[greenya]

would that reduce execution time or just make the line messier?

I don't think so.

Here are some tips:
- you should use GetVertex(i) instead of Vertices;
- if you need to read vertices data to much and to often, and the data can be doubled - keep a copy locally and use it for calculations (so you make less reads - calls to GetVertex());
BUT UpdateVertices() is slow, because it copies all managed data (vertices array) to unmanaged - this is slow if you need to do this every frame.

P.S.: from your code, i see, you may do not change Y+1 of every vertex, but simply change the position of the mesh (e.g. world transformation matrix) before you actually render this meshbuffer.

[hindupower]

if you need to read vertices data to much and to often, and the data can be doubled - keep a copy locally and use it for calculations

Yes, the vertices array is a local copy.

from your code, i see, you may do not change Y+1 of every vertex, but simply change the position of the mesh (e.g. world transformation matrix) before you actually render this meshbuffer.

Moving every vertex by the same value was just a test to see how well Irrlicht Lime performs. Later I will change it so that the vertices match some math function...like or sine or something like that.

UpdateVertices() is slow, because it copies all managed data (vertices array) to unmanaged - this is slow if you need to do this every frame.

Is there a way I can directly access the values or the unmanaged values, because copying an entire array every frame seems very inefficient in my case?

[greenya]

Is there a way I can directly access the values or the unmanaged values, because copying an entire array every frame seems very inefficient in my case?

No you can not access directly unmanaged data from .NET. This is restriction of .NET, not mine.
If you want this fast, you should use C++ and Irrlicht without wrapper.

P.S.: your issue is quite the same as DrawVertexPrimitiveList(), when you have large data and want this to be drawn every frame, you will have bad performance. But if your data static, you can create meshbuffer(s), and call DrawMeshBuffer(), and this will perform very fast.