EDT:Using the class CCameraFPSSceneNode to create animators?

[christianclavet]

Hi.

I would like to use that class in my current projet and add new features to this class. (Like camera new moves (run, walk, crouch, camera tilt when strafing) and camera states (that will be useful if I'd want to sync sound to it).

I don't want to "hack" Irrlicht source code. I'd prefer to create a new camera from it (inheriting the class attributes) and I'd create an "advanced FPS camera" in my project.

This class was defined in IRRlicht source. As CCameraFPSSceneNode.h. Is there a way I could create this camera type from this class and access the methods?

On that class we can redefine the rotation speed and movespeed of the camera. There seem also to be a way to translate the mouse to a plane there if I add the method, since the data is treated there. I've looked the source and didnt find the link to the standard FPS Camera creation to this. So I don't know the right approach to do this. I'm still begginer in C++...

Before expanding the features, I'll need be able to use this class and create the standard FPS camera. Since I'll be able to access the methods. Expanding from there should be relativily easy.

[klikmaster]

You should be able to inherit from the original class. The class methods are public, so you should be able to access them from the new class.

It shouldn't be too hard. Be adventurous and try it!

Oh, and you're going the right way about it, much better to inherit than changing the source code.

[hybrid]

No, because the code is not exported and the header file is not accessible outside of the library. So you have to copy the cpp and .h file, rename it, and create your own camera.

[rogerborg]

It's a good way to go, but as an alternative, I'd suggest dropping the idea of using a "camera" as the base of your player presence. The Irrlicht cameras are useful for demos, but (IMO) they're a spurious model for a full game.

For example: in a FPS, every actor in the game should obey the same rules for interacting with the environment; e.g. changing LOS and collision behaviour when a model crouches or jumps. Much of the functionality that you might cram into a "camera" should also apply to every actor. Rather than using a "camera" as the basis for actor functionality, the camera functionality should be a very thin layer that's applied to a single actor - the player.

[klikmaster]

Haha I was so sure I was at the level where I could answer his question. I was wrong, i suppose it was worth a try

[christianclavet]

Thanks Guys!

rogerborg: yes, that the good way about it. But the FPS camera code is already written. Only have to re-use it. From what I see from the current code, it's already inhereting the STD CAMERA class and adding those input/response.

So I'll do the same. Since Hybrid say that I will have to copy the .cpp and .h files and rename them. Then I'll modify those for my need. The base for my player presence is the node, not the camera. I think, I will have to create a custom node to apply the class.

This kind of camera will be applied to every player (could even serve for ennemy code). Much later, I will have to create a ray casting collision algorigthm with JP to let the NPC "see" the scene, using the current parameters of it. Since it's methods will be exposed, the code could be used for other things.

Is there a file in the source where the class is applied to a new node?
I've searched for this in the source code but didnt find it yet:
addCameraSceneNodeFPS

That should show me how the new node is created with the class.

[hybrid]

Well, I didn't properly get what you just described, but I only said that you cannot easily inherit from the FPS camera. I did not say that this is a good way to do such things. As vitek showed in a different thread, a very clever idea is to use scene node animators to influence the camera. So it really depends on your needs if you have to add another camera type.

[fireside]

Copying c++ and header files probably wouldn't work either because there may be inheritance in them. You could probably write a class that called the functions of the camera class and then used them in the way you wanted, so you would pass the class a pointer when it was instantiated and then you could access the functions. I think you'd have to make sure it got destroyed in the destructor. If the pointer is a data member of the class, you can still access all the old functions and you can call the functions of your own class.

[christianclavet]

Yes. I've look at the code. I will probably have to "interpret" the way the code is written and write my own.

I'll create a standard camera and write the extended function around it. This will take me some time, but will be a good learning exercise for me. Hope I'm able to make it as smooth as the standard FPS one.

[fireside]

Pointers are fast so you shouldn't see much difference. You can have it return the pointer to use the old functions, or just do higher level stuff in the class using the pointer. I haven't done any of this yet with Irrlicht because I'm working on a game in another engine right now, but it would definitely be a good experience. I plan on doing it for my own specialized actor classes, etc.

[christianclavet]

Hi, Found this in the class:

Code: Select all

//! OnAnimate() is called just before rendering the whole scene.
//! nodes may calculate or store animations here, and may do other useful things,
//! dependent on what they are.
void CCameraFPSSceneNode::OnAnimate(u32 timeMs)
{
	animate( timeMs );

	core::list<ISceneNodeAnimator*>::Iterator ait = Animators.begin();
				for (; ait != Animators.end(); ++ait)
					(*ait)->animateNode(this, timeMs);

	updateAbsolutePosition();
	Target = getPosition() + TargetVector;

	core::list<ISceneNode*>::Iterator it = Children.begin();
				for (; it != Children.end(); ++it)
					(*it)->OnAnimate(timeMs);
}

If I'm understanding correctly this seem to animate the FPS Camera node using the animate function, but seem the check for multiples animators...

I am right? We could define more than 1 animator for a node?
If this is true, then do you know where I could find a small tutorial to create a custom animator?

The idea (if we can apply more than one animator per node):
Create 2 animators:
- Keyboard move animator
This animator will move the node based on the keymap definition and the node orientation (taken from the FPS camera code)
- Mouse rotate animator
This animator will rotate the node based on the mouse position (taken on the FPS camera code)

With those 2 animators, (if they can be applied together with the collision response animator), could be much more flexible than what we have now.

Since it's based on inputs, we could define then an similar animator for Joystick input (Like the XBOX pad) to animate the node.

[christianclavet]

Hi, I've checked some post, and I got another idea.

It seem possible to have more than 1 animator per node. From what I've seen so far in the posts.

I've not yet seen any post relating to creating custom animator.

There are 2 defined animators there.
- Flystraight animator (moving the node from point A to point B)
- rotate animator (rotating incrementaly the node)

Would I have to use theses or can I create my own animator?
I don't want to modify the source.
EDIT: I've downloaded the docs for 1.4beta. Found a
irr::scene::ISceneNodeAnimatorFactory Class Reference.
I'll check that more in detail.

[christianclavet]

Ok. I understand more now!

The methods are in CSceneManager.cpp!

All the camera type are in fact inherited STD camera type with extended functions not available after their initialisation. If I would modify the source, I could define a second class that would get all the method I would want from the FPS camera. But this would implie modify the source, and I don't want to to this. I'll look again. Perhaps there a way to get it. Define the class inside my code, then do the same code that the CsceneManager is doing but inside my code... I'll check. This could save me a lot of time if it work.

What I see it that I would have to do about the same thing.

I've located the CSceneNodeAnimatorRotaion.h" that I will use as a reference to create my own Animator. I'll replicate the same type of class. So when I'll define the new animator. I'll do it like that:

ISceneNodeAnimator* anim = new CSceneNodeMouseRotation(os::Timer::getTime());

And do the working stuff inside the CSceneNodeMouseRotation class

[bitplane]

For Irrlicht 1.5, we plan to have a "camera controller" interface, which is similar to a scene node animator but has an event receiver and deals only with cameras. The FPS and Maya cameras will be a standard camera with a controller attached, and most people won't have to make custom cameras anymore. This doesn't help you at the moment, but you could use a custom animator to do the same job.
There's no need to add your own factory if you don't plan on saving or loading the camera, just make a new class derived from ISceneNodeAnimator and IEventReceiver, and pass events to the animator from your event receiver.

There's no animator tutorial, but this should give you a place to start from-

Code: Select all

class MyAnimator : public ISceneNodeAnimator, public IEventReceiver
{
public:
   // animator methods-

   virtual void animateNode (ISceneNode *node, u32 timeMs)
   {
      if (!node || node->getType() != ESNT_CAMERA)
         return; // only works on cameras

      ICameraSceneNode *camera = (ICameraSceneNode*)node;

      // do stuff with your camera here

   }

   virtual ESCENE_NODE_ANIMATOR_TYPE getType() const
   {
      // if anyone asks, this is a 'walk' animator
      return (ESCENE_NODE_ANIMATOR_TYPE)MAKE_IRR_ID('w','a','l','k');
   }

   // methods for event receiver

   virtual bool OnEvent (const SEvent &event)
   {
      // respond to events here, and return true if you acted on the event

      return false; // otherwise return false
   }
};

[christianclavet]

Thanks Bitplane! Reading and learning the source has been very good to me so far. Now I think will be able to do this!