[fixed]Result difference between Irrlicht 1.4.1 and SVN

[comicsteam]

i don't know whether they're bugs or not
for same piece of code, Irrlicht 1.4.1 and the SVN (Irrlicht 1.4.2 ??) give different results.

(1)

• i added a FPScamera and set its position and target.

  Code: Select all

  cam = smgr->addCameraSceneNodeFPS();
  cam->setPosition(core::vector3df(100,100,-100));
  cam->setTarget(core::vector3df(0,0,0));

  what i would expect is a camera looking at the world origin.
  it works in 1.4.1, but not in 1.4.2.
  so i take a look on the source code,
  i found that in 1.4.2, setTarget() is simply CCameraSceneNode::setTarget() instead of CCameraFPSSceneNode::setTarget().
  which means that 'target' is only a relative position, but not absolute position.
  if i want to achieve the same result, i must modify my code in this way:

  Code: Select all

  cam = smgr->addCameraSceneNodeFPS();
  cam->setPosition(core::vector3df(100,100,-100));
  cam->updateAbsolutePosition();
  cam->setTarget(core::vector3df(0,0,0) - cam->getAbsolutePosition());

(2)

• i added a billboard and set a camera as its parent:

  Code: Select all

  scene::IBillboardSceneNode* test = smgr->addBillboardSceneNode(cam, core::dimension2df(12,12), core::vector3df(0,0,50));

  i want to have a billboard which always stays in front of the camera with 50 unit distance.
  again, i got what i expected in 1.4.1.
  however, in 1.4.2, the billboard neglects the camera's rotation, and only moves to pos(0,0,50) relative to the camera's position.
  to fix this, i added some code before smgr->drawAll()

  Code: Select all

  core::vector3df tempVect = ((scene::ICameraSceneNode*)test->getParent())->getTarget() - ((scene::ICameraSceneNode*)test->getParent())->getPosition();
  tempVect.normalize();
  tempVect *= 50;
  test->setPosition(tempVect);
  test->updateAbsolutePosition();

  the result is bad since it's not really synchronized with the camera movement.
  i don't know how to solve this problem.

[hybrid]

There are at least two SVN repositories, you have to tell use which one you're using: SVN/trunk or the 1.4 branch? Anyway, I also have some problems with the FPS cam in the meshviewr example, so moving this to bug forum...

[comicsteam]

There are at least two SVN repositories, you have to tell use which one you're using: SVN/trunk or the 1.4 branch? Anyway, I also have some problems with the FPS cam in the meshviewr example, so moving this to bug forum...

i'm using the trunk one.

[rogerborg]

i don't know whether they're bugs or not
for same piece of code, Irrlicht 1.4.1 and the SVN (Irrlicht 1.4.2 ??) give different results.

SVN is 1.5. I'll only talk about 1.5 / the current SVN trunk here.

(1)

• i added a FPScamera and set its position and target.

This behaviour has changed because cameras are now done with animators. So instead of having a CCameraFPSSceneNode, we now have a CSceneNodeAnimatorCameraFPS that acts on a generic CCameraSceneNode.

Unfortunately, as a side effect of this, the first time that the CSceneNodeAnimatorCameraFPS is run, it uses the absolute camera position before updating it. So in this case what's happening is that the camera position and its look-at position are both 0,0,0, and the camera's look direction is thus "undefined" (translation: screwy).

[Update: I can and will fix this on the trunk]

(2)

• i added a billboard and set a camera as its parent:

Ah, sorry about that. In 1.4.2, the FPS camera's scene node rotation changed to match its target. In 1.5, it doesn't.

I'll fix that, and add an ICameraSceneNode method to specify the binding between camera target and scene node rotation, i.e. independent (the current behaviour), rotation follows target (the FPS behaviour, and which creating a FPS camera will set), or target follows rotation.

I'm working on that now.

[Dorth]

Actually, if you could have a side animator that do that rogerborg, that be even nicer. Or generalize this to all camera. I mean, what's the point of having a rotation and a different target?

[rogerborg]

OK, I've made a start in SVN 1748. The first issue should be fixed, and the second issue has a partial fix, although I need to get the ordering of operations sorted.

By default, we'll leave the behaviour as it was in 1.4.2, i.e. the FPS camera slaves its rotation to its target, while all other cameras keep them independent. There's an ICameraSceneNode method to change the binding of rotation and target (independent, rotation follows target, target follows rotation).

[Dorth]

My apologies then, I failed to properly inform myself before voicing my opinion, only reading this topic

On the plus hand, this method seems perfect, though why isn't it set to the second or third option by default, I'll never know.

Couldn't there be a fourth way, aka, modifying the rotation modifies the target position and modifying the target modifies the rotation? I realize you could just keep switching between methods, but it seems somewhat aggravating.

For example, given a 3d game in the genre of Secret of Mana (2d), you might want to rotate the camera (and have the target follow suit) and then select an enemy with let's say tab, place the target on it and have the camera rotate accordingly...

[rogerborg]

My apologies then, I failed to properly inform myself before voicing my opinion, only reading this topic

Eh? Me neither, I thought that the FPS camera still slaved rotation to target.

On the plus hand, this method seems perfect, though why isn't it set to the second or third option by default, I'll never know.

Legacy. I tend to agree; in fact, it might have been better if camera scene nodes had never had a separate look target to begin with, but we've got what we've got, and the flexibility is handy for those that want to use it.

Couldn't there be a fourth way, aka, modifying the rotation modifies the target position and modifying the target modifies the rotation? I realize you could just keep switching between methods, but it seems somewhat aggravating.

Hmm, good point. Now that I think about it, that might be the only sensible way to do the binding. Slaving target to rotation or vice versa makes either setTarget() or setRotation() essentially no-ops, which doesn't seem particularly user friendly.

I'll try that now...

[UPDATE]
WINNER, DORTH. Yes, that seems to make the most sense. That's the 1.4.2 FPS camera behaviour restored. We could make that the default for all cameras, but the mob might get restless. I'll open a poll question in Open Discussion. Thanks for the great suggestion.

[Dorth]

w00t
Thanks for your time once more