Irrlicht Engine

I did this with Newton Game Dynamics a while ago:

http://img153.imageshack.us/img153/8427/out21024ph8.jpg

http://img183.imageshack.us/img183/2527/out104fs3.png

Crappy 2 minute AO:
http://img3.imageshack.us/img3/7898/out11024.png


Took 2 days to write the full thing, multithreaded and all ...

MarcinS wrote:

becosue in my Physics classes (studies) we use such version :

Those two are the same coordinate systems. The second image is just rotated.

Google Luabind.

Very useful piece of code, I'm sure some people will find it rather helpful. Now, if only Irrlicht didn't use Euler angles for node rotations, you'd be able to do something like this:

// if ISceneNode::getRotation() returned a matrix or quaternion
core::vector3df vel = barrelNode->getRotation ...

Sudi wrote:there is a better way to do this.
just use the dofor allbodies command and then draw lines for each newton object.

Not necessarily. The above code creates an actual mesh from a Newton collision object. Your suggestion doesn't create a mesh, it only draws a wireframe over-view.

Useful indeed, but only available in Newton Archimedia (not 1.53).

I'd encourage you to optimise it! Also, I'd like to see this integrated into Irrlicht. Why?

Because I think animated meshes could benefit from this. Tell me if it's nonsense. Animated meshes are changing every frame, so - I guess - they won't benefit from VBOs at all. Hence there this technique ...

p.s. whats forward fragment processing ?
Fragment shading done on the fly. Meaning, when you render your objects, you render them with all of your lighting and shadowing shaders and what-not right on the spot. With deferred shading, on the other hand, you basically render of the geometry to a ...

Yup, definitely faster now. ~590FPS with the per-face culling, which is just about on-par with the native GPU culling. (all of this is with the whole sphere in view)

Agreed, this technique would rather help out on powerful CPUs with weak GPUs - but newer GPUs definitely have the raw power to rip ...

@agi_shi : when you are saying "winding order culling" you are referring to the backface culling ? node->setMaterialFlag(video::EMF_BACK_FACE_CULLING, true); specifically this flag ? which as far as i can understand is described in this link : http://msdn.microsoft.com/en-us/library/bb204882(VS.85 ...

497 FPS with per face culling
594 FPS with native hardware vertex winding culling

There is no possible way that locking a mesh for thousands of dot products per frame and then re-uploading it to the GPU card is faster than native GPU winding order culling with over drawing. Why? Because these days ...

Didn't Lightsmark do this and much more quite a while ago (via Lightsprint)?

[...] And they are really fast.


[...] and to let Irrlicht keep its performance equally everywhere

:roll:


Irrlicht compiles with 7 (or even more) different compilers [...]

Any (good) programmer should be using either mingw/GCC or MSVC; getting something to compile across many (7 ...

also @ CuteAlien:

I think you're both missing the point here. It doesn't matter whether a "quick look" at the source reveals the bug or not - there's too many places for "quick looks". The C++ standard library is already looked at , it's got all of this fixed for you , and it is guaranteed (in ...

@agi_shi:
I've started this thread Because I think Irrlicht should be using STL so don't get me wrong, I'm all on your side about converting Irrlicht to STL.
Oh, sorry, it's just the quote that threw me off :lol:

I'm only trying to point out the common sense here. Too many Irrlicht users seem to ...