Page 1 of 1

Orbiting Camera

Posted: Wed Oct 21, 2009 10:15 am
by happilylazy
Hi everybody.

I want to make an Orbiting Camera (like the Maya one when you click left mouse button) but i want to have it react to keys WASD instead so I have free mouse cursor to click around the model.
Camera would orbit around the model in space like a planet or an atom.

I have three examples to work with,

WoW Camera
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=24054

RTS Camera
http://www.irrlicht3d.org/wiki/index.ph ... ByCmdKewin

And current Maya camera from IrrLicht source code file

WoW like is really easy to implement with Events, but I would really like to share this with the community so I would like to make it inheritance style like RTS or Maya.

But is it better to inherit Camera interface (like RTS) or Make Animator (like Maya)?

-----------* EDIT *-------------

Oh, I found this thread
http://irrlicht.sourceforge.net/phpBB2/ ... m+animator
answering my question.
So I go with Animator interface, I thought that was the best idea anyway. Factory here I come.
Anyway, if i have any question and problems I'll post here

Posted: Wed Oct 21, 2009 8:16 pm
by happilylazy
To be able to add custom scene node animators to Irrlicht and to make it possible for the scene manager to save and load those external animators, simply implement this interface and register it in you scene manager via ISceneManager::registerSceneNodeAnimatorFactory. Note: When implementing your own scene node factory, don't call ISceneNodeManager::grab() to increase the reference counter of the scene node manager. This is not necessary because the scene node manager will grab() the factory anyway, and otherwise cyclic references will be created and the scene manager and all its nodes won't get deallocated.
What is the benefit of implementing your own ISceneNodeAnimatorFactory?

If I make my own ISceneNodeAnimator for my cam and register it like registerSceneNodeAnimatorFactory, does ISceneManager treat it like a factory after registering or?

Posted: Wed Oct 21, 2009 8:44 pm
by hybrid
This is necessary for deserializing your scene including the animators and later on reload them again. Actually, it's only necessary for the second step (the reload), at which point the scene manager has to be able to create the animator based on the name (a string).

Posted: Thu Oct 22, 2009 10:40 am
by happilylazy
hybrid wrote:This is necessary for deserializing your scene including the animators and later on reload them again. Actually, it's only necessary for the second step (the reload), at which point the scene manager has to be able to create the animator based on the name (a string).
I got that.
But do I need to implement ISceneNodeAnimatorFactory that is createSceneNodeAnimator, getCreateableSceneNodeAnimatorType, getCreateableSceneNodeAnimatorTypeName methods?
Or with registerSceneNodeAnimatorFactory my ISceneNodeAnimator gets those methods default without me implementing them?

Posted: Thu Oct 22, 2009 1:39 pm
by hybrid
If you need serialization, you have to implement a factory. Otherwise, just don't use it (and don't register as a factory if you just want an animator).

Posted: Thu Oct 22, 2009 2:59 pm
by happilylazy
hybrid wrote:If you need serialization, you have to implement a factory. Otherwise, just don't use it (and don't register as a factory if you just want an animator).
Thanks, that was just what I wanted to know.
OK, back to implemetation.

Posted: Fri Oct 23, 2009 2:33 pm
by happilylazy
So what is the most meaningful type value to return for custom camera animator?
As you can see from the code I return ESNAT_UNKNOWN since nothing I need is defined in enum ESCENE_NODE_ANIMATOR_TYPE.

Code: Select all

//! Returns type of the scene node
virtual ESCENE_NODE_ANIMATOR_TYPE getType() const {

	return ESNAT_UNKNOWN;	// TODO: Change this to some meaningful value
}
What to do?

:( Maya and FPS camera have they own types ESNAT_CAMERA_MAYA & ESNAT_CAMERA_FPS defined.

Posted: Fri Oct 23, 2009 3:15 pm
by randomMesh
There's no harm in returning ESNAT_UNKNOWN. You could hack the engine and add your own type though.

Posted: Fri Oct 23, 2009 8:47 pm
by vitek
You shouldn't need to hack the engine to add your own type. You just need to return a value that doesn't collide with values used by the engine. It is perfectly valid to do something like this..

Code: Select all

#define ESNAT_MY_ANIMATOR_TYPE    ESCENE_NODE_ANIMATOR_TYPE(0x1000)

//! Returns type of the scene node 
virtual ESCENE_NODE_ANIMATOR_TYPE getType() const { 

   return ESNAT_MY_ANIMATOR_TYPE;
} 
If I remember correctly, the value is only important for serialization, so if you don't provide a factory, it shouldn't matter much. That said, it would be nice if Irrlicht would set aside some set of values that it reserves for future use to avoid value collision.

Travis

Posted: Mon Oct 26, 2009 11:01 am
by happilylazy
vitek wrote:You shouldn't need to hack the engine to add your own type. You just need to return a value that doesn't collide with values used by the engine.
Travis
Thanks, I'll implement your proposal. momentarily I am not thinking of serialization, but you never know if I need a Factory in future.

Posted: Thu Oct 29, 2009 2:00 pm
by happilylazy
I want to rotate the camera around an object (her target) telling camera how many degrees to rotate around specified target, so in animateNode I put:

Code: Select all

RotX = 0.0f;
RotY = 0.0f;
core::vector3df target = camera->getTarget();

// Rotation ------------------------------------

if (CursorKeys[EKA_STRAFE_LEFT])
	RotX += RotateSpeed;
if (CursorKeys[EKA_STRAFE_RIGHT])
	RotX -= RotateSpeed;
if (CursorKeys[EKA_MOVE_FORWARD])
	RotY += RotateSpeed;
if (CursorKeys[EKA_MOVE_BACKWARD])
	RotY -= RotateSpeed;
	// Set Pos ------------------------------------
Pos.rotateXYBy(RotY, target);
Pos.rotateXZBy(-RotX, target);

camera->setPosition(Pos);
The problem is that the camera is always looking in the same direction, and the camera's target is also moving even though I'm not changing it.

What could be the problem?