Problem With Making a Camera a Child of a SceneNode.

[Whirled Peas]

So, I've gotten into working with Irrlicht's parent/child relationships, and it seems to work just fine for most things. However, when it comes to making a camera a child of a scene node, it doesn't behave like I would expect.

Now the mesh itself is set up to work with bullet physics simulation, and when I start the program, the simulation works fine, and the camera seems to be moving right along with the mesh/node like it is supposed to, but it doesn't follow orientation at all.

Here is the code that I use to create an instance of a camera and to parent it to the scene node of the mesh:

Code: Select all

 

ISceneNode* camera = smgr->addCameraSceneNode(0, vector3df(0,0,-10));

camera->setParent(node);

smgr is the variable for the instance of the scene manager.



I wondered if I was using the wrong kind of constructor which was creating a camera with the wrong kind of behavior, so I went with this line to create the camera instance in stead:

Code: Select all

 ICameraSceneNode* camera = ICameraSceneNode(node, smgr, 0, vector3df(0, 0, -10), vector3df(0, 0, 0), vector3df(1.0f, 1.0f, 1.0f));

and I get a compile error that goes like this

|149|error: cannot allocate an object of abstract type 'irr::scene::ICameraSceneNode'|

I've looked for this kind of error online, however most of the solutions I have found to the problem involve changing the code of the original class itself, which I shouldn't have to do.

I am pretty sure I implemented the code correctly based upon what the Irrlicht API documentation said, but perhaps it is out of date?

Anyway, can anyone help me out with this?


Thanks much in advance.

[serengeor]

1) Can't answer that, haven't done much of parenting, I usually do things like moving objects accordingly to others by myself.

2)You should read more about c++, abstract objects cannot be allocated because they have pure virtual functions like this

Code: Select all

class Object
{
public:
virtual void DoStuff()=0; //this is pure virtual function
};

if you would try

Code: Select all

Object * obj= new Object(); 

It would give you the same error.

You say, but how can I use this class?
Well abstract objects are made as interfaces and they should be inherited, and the derived class has to implement all pure virtual methods.
Like this

Code: Select all

class Derived:public Object
{
public:
void DoStuff(){printf("Doing some stuff\n");} //this is a normal function
};

Then you can use Derived class and make instances of it

Code: Select all

Derived * derived = new Derived();
derived->DoStuff();

In your case irrlicht has different derived classes for each type of camera(FPS, normal, maya). and it returns back the same ICameraSceneNode pointer.

[Radikalizm]

A camera scene node has a target vector which acts independently from the position of the camera, so the camera will always be oriënted towards this target

You could solve this by writing a simple animator updating the target vector every frame

[sudi]

Just call

Code: Select all

camera->bindTargetAndRotation (true);

On your camera then it works just fine.

[Radikalizm]

Just call

Code: Select all

camera->bindTargetAndRotation (true);

On your camera then it works just fine.

Yeah, that works too as long as bullet updates the parent node rotation correctly

[ChaiRuiPeng]

@serengeor

i think it you should also state

that you can do this

Code: Select all

// Object is abstract base class

// Derived implements a pure virtual function so Object can be the instianted

//you can do this:

Object* obj = Derived();

[Whirled Peas]

Thanks for the feedback guys, as for the ICameraSceneNode class problem, I think I managed to figure that out last night. I haven't had my morning coffee yet and I'm at work, so I can't get a look at the code right now, but I remember that sometime before going to bed last night I changed the way in which I declared the camera constructor, I forget exactly what I changed it to, but I think it was by type identifier, or the constructor, forget which. Will post the change after I get home.

Also, yeah, I kinda figured on the camera pointer location being the issue, although, what I first tried was to have the camera point to another object that was also parented to the camera's parent, however this only gets the camera to change where it is pointed, not how its roll and yaw angles are oriented. I'll try and use BindTargetAndRotation as was suggested, thanks for that.

[Whirled Peas]

Just call

Code: Select all

camera->bindTargetAndRotation (true);

On your camera then it works just fine.

Yeah, that works too as long as bullet updates the parent node rotation correctly

okay, I implemented the bindTargetAndRotation line and it still didn't work, what do you mean about bullet updating the parent node rotation correctly? Although I don't think that is the issue because the parenting seems to work just fine for a regular mesh node, just not a camera.

[sudi]

ok i guess no one know what you actually doing and what you are trying to achieve...

[Whirled Peas]

I'm trying to make a game/program where the player flies around using physics in stead of animators. The player input would control the movement of an actual mesh rather than the camera which would be "bolted to" toe player mesh, this is why I'm not using the FPS or maya camera.

[Radikalizm]

I'm trying to make a game/program where the player flies around using physics in stead of animators. The player input would control the movement of an actual mesh rather than the camera which would be "bolted to" toe player mesh, this is why I'm not using the FPS or maya camera.

There's a difference between animators and animations, physics for example could be completely implemented in irrlicht using animators

Animators are just pieces of code executed every frame which can update scene node information

[Whirled Peas]

I'm trying to make a game/program where the player flies around using physics in stead of animators. The player input would control the movement of an actual mesh rather than the camera which would be "bolted to" toe player mesh, this is why I'm not using the FPS or maya camera.

There's a difference between animators and animations, physics for example could be completely implemented in irrlicht using animators

Animators are just pieces of code executed every frame which can update scene node information

My point was I wanted to have the movement be governed by physics simulation rather than by having the program tell the player character to move "5 units forward per frame"

[Radikalizm]

I know that was your point Your node's physics calculations can be done perfectly inside an animator
this is how I'm implementing it in my engine, and how I implemented Havok in irrlicht a while ago

I'm not saying you have to do it like this, but this could solve your problem since you'll get direct control over your target vector

[Whirled Peas]

okay, update:

I decided to play around with the orientation relationship between the mesh node and the camera, and got rid of the parent/child relationship between the two. In stead I just made the camera have the same rotation as the mesh node using setRotation(node->getRotation()).

Now the bindTargetAndRotation(true) seemed to work this time as the camera wouldn't reorient itself without that line of code, however the camera seemed to have one axis inverted from how the mesh was oriented. Any ideas why that would be?

I know that was your point Your node's physics calculations can be done perfectly inside an animator
this is how I'm implementing it in my engine, and how I implemented Havok in irrlicht a while ago

I'm not saying you have to do it like this, but this could solve your problem since you'll get direct control over your target vector

So you plug the results from the physics simulation into the needed animators, is that correct? Also, I'm using IrrBullet, would that work with your suggested method? Or would I have to go back and use the original Bullet library?

[Radikalizm]

I don't know how irrBullet works exactly, so I can't answer that
I started off with the basic Havok library when I was implementing it in irrlicht, so I guess you'll have to do the same with bullet

You could for example create a rigid body animator which takes a reference to a rigid body as a parameter in the constructor, this animator would then be written to pass the data from your rigid body to the scene node, with additional data where need (an updated target vector for example)

This is a very clean method for implementing physics using irrlicht's existing infrastructure