Why I selected Irrlicht over Ogre3d

[Radikalizm]

OGRE looks as if it has an animation system, whereas Irrlicht hasn't.

What?

[Kojack]

All Ogre demos are fully using shaders while most of the irrlicht demos are just using fixed-function materials that is why the difference is so huge.

Actually only 16 of the 34 demos provided with ogre use shaders and some of those don't change appearance, only performance (eg. hardware skinning and instancing). The rest are fixed function.

[LizardGamer]

OGRE looks as if it has an animation system, whereas Irrlicht hasn't.

What?

Mongoose7, Irrlicht has an animation system!

[mongoose7]

I said "system". Irrlicht has animation, but if it has an animation system then that system is called "Blender".

That is, in Irrlicht, you do all your animation outside Irrlicht and then load it. Even Horde3d has animation separate from models. Ogre3d seems to have the capability of procedural animation.

I've done some skinned animation in Irrlicht (http://irrlicht.sourceforge.net/phpBB2/ ... highlight=, http://irrlicht.sourceforge.net/phpBB2/ ... highlight=) but it isn't really supported, for example, the headers are not in the binary release.

So, yes, Irrlicht does not have an animation system.

[Mel]

That is, in Irrlicht, you do all your animation outside Irrlicht and then load it. Even Horde3d has animation separate from models. Ogre3d seems to have the capability of procedural animation.

You still can use the animation from a skinned mesh on other skinned mesh given they have the same skeleton.

http://irrlicht.sourceforge.net/docu/cl ... _mesh.html

And bones are other kind of scene nodes, they can be animated as such, and follow the rules of hierarchy that governs the Irrlicht nodes, including their procedural animation.

http://irrlicht.sourceforge.net/docu/cl ... _node.html

There are already IK solutions for Irrlicht and ragdolls, still not in the standard distribution, but those features are also there. The question would be what features do you miss in Irrlicht that are already present on other engines, for instance.

[mongoose7]

Well, here is some code from OGRE3D:

Code: Select all

		while (tracks.hasMoreElements())   // for every node track...
		{
			NodeAnimationTrack* track = tracks.getNext();

			// get the keyframe at the chopping point
			TransformKeyFrame oldKf(0, 0);
			track->getInterpolatedKeyFrame(ANIM_CHOP, &oldKf);

			// drop all keyframes after the chopping point
			while (track->getKeyFrame(track->getNumKeyFrames()-1)->getTime() >= ANIM_CHOP - 0.3f)
				track->removeKeyFrame(track->getNumKeyFrames()-1);

			// create a new keyframe at chopping point, and get the first keyframe
			TransformKeyFrame* newKf = track->createNodeKeyFrame(ANIM_CHOP);
			TransformKeyFrame* startKf = track->getNodeKeyFrame(0);

			Bone* bone = skel->getBone(track->getHandle());

			if (bone->getName() == "Spineroot")   // adjust spine root relative to new location
			{
				mSneakStartPos = startKf->getTranslate() + bone->getInitialPosition();
				mSneakEndPos = oldKf.getTranslate() + bone->getInitialPosition();
				mSneakStartPos.y = mSneakEndPos.y;

				newKf->setTranslate(oldKf.getTranslate());
				newKf->setRotation(oldKf.getRotation());
				newKf->setScale(oldKf.getScale());
			}
			else   // make all other bones loop back
			{
				newKf->setTranslate(startKf->getTranslate());
				newKf->setRotation(startKf->getRotation());
				newKf->setScale(startKf->getScale());
			}
		}

This shows me that animations are separate from meshes. Well, in Irrlicht of course one can get to the bones in a similar manner so this may not be a strong case for separate animation.

But consider this, there have been a number of requests for separate animations for different parts of the body, for example, swinging a sword while walking, or for merging animations. Now, there are not a lot of these requests but there is not much interest in these forums on skeletal animation, apart from "load and go". I think probably people run Irrlicht on their phones. All the animation I've seen to date has been pretty crude. The animation sample has Sydney, is it or is it Ninja, "skating" across the screen, and the RTS's I've seen have a walk animation played in about 1/10 sec on my machine and then the character "warps" to a new position.

But I think that, if animations were separate from meshes then much more could be done. Also, as I pointed out in the other posts, you cannot do procedural animation because of the missing headers.

Finally, you would be aware that, if the mesh is at all detailed, frame rates would be low, say 10 fps. So i think support for hardware skinning would be a requirement. Once again, OGRE3D seems to have given this some thought.

Code: Select all

When using shadows (See section 7. Shadows), the use of vertex programs can add some additional complexities, because Ogre can only automatically deal with everything when using the fixed-function pipeline. If you use vertex programs, and you are also using shadows, you may need to make some adjustments.

If you use stencil shadows, then any vertex programs which do vertex deformation can be a problem, because stencil shadows are calculated on the CPU, which does not have access to the modified vertices. If the vertex program is doing standard skeletal animation, this is ok (see section above) because Ogre knows how to replicate the effect in software, but any other vertex deformation cannot be replicated, and you will either have to accept that the shadow will not reflect this deformation, or you should turn off shadows for that object.

If you use texture shadows, then vertex deformation is acceptable; however, when rendering the object into the shadow texture (the shadow caster pass), the shadow has to be rendered in a solid colour (linked to the ambient colour). You must therefore provide an alternative vertex program, so Ogre provides you with a way of specifying one to use when rendering the caster. Basically you link an alternative vertex program, using exactly the same syntax as the original vertex program link:

But, maybe this is not the direction the Irrlicht wants to pursue?

[Kalango]

You brought the point here. Irrlicht is planned to work on a big range of devices and thats why it still supports old hardware stuff and dx. Also the fixed function pipeline is still here because of this wish to make the engine run anywhere....
I think its a cool thing, but the engine should make decisions on what it want to be in the future, what its target and not keep with the safe architecture that it always had.
This has been discuted already, and stuff like not having people to support some branches were also brought to the board, but if you see other engines, they have user that still take on the adventure to make their engines for iphones and androids, etc.
anyway... that has been discusted already.

EDIT: I wanted to bring some questions to the board:
Are people using Irrlicht for old architectures?
Are people using Irrlicht for custom devices?
Are people using Irrliht for updated hardware?
Are people using Irrlicht for successfull indie games?

What is Irrlicht being used for? i see small or limited examples over time and they are descontinued or forgotten and only a very few reach the status of indie game or published application. Master thesis applications are really rare and i dont know any mobile games done with Irrlicht except one gravity thing game for android. Is Irrlicht performance really lighting fast? Is it really community open? Is it really multiplatform?
Is Irrlicht or people that use Irrlicht making real stuff or they are just talking with a nice cool brotherlike community random stuff?
really... is it?

[CuteAlien]

What is Irrlicht being used for?

Hm, I used it so far in a (released) racing game, in a VR (still in work) and I'm working for an architecture company using Irrlicht. And I hope to do more projects in the future.

2 of those projects are multiplatform Linux+Windows, but there's some chance I'll try porting any of them to further platforms one day (android most likely, but maybe also OS X one day).

As for pipelines - there exists already a OpenGL ES driver, which seems to work, so drivers without fixed function pipelines are also possible.