[fixed]MAYA Camera problems with the input receiver

[christianclavet]

Just remarqued a problem with the Irrlicht (1.7.2) maya camera. I'll try to give you some kind of "real" bug report as I'm working as a tester now.

Description:
Each time the input receiver of the camera is enabled, it completely overide the position and angle of the camera! I was assuming the camera would start rotating, zooming and moving from the position and angle given by code. It doesnt seem so.

Reproductibility of the bug:
5/5

Steps to reproduce the bug:
1. Take the Helloworld example. (Or any other Irrlicht example)
2. Change the camera for a maya camera.
Mine was added like this: (app class contain the device pointer)

Code: Select all

editCamMaya = App::getInstance()->getDevice()->getSceneManager()->addCameraSceneNodeMaya(0, -45.0f, 200.0f, 100.0f);

3. Try to set a position for the camera and disable the inputreceiver.
I tried that:

Code: Select all

editCamMaya->setInputReceiverEnabled(false);
editCamMaya->setPosition(vector3df(250,250,-250));

4. Notice the position of the camera. It should go at the specified coordinates
5. Go at the line where you disabled the input receiver and now enable it:

Code: Select all

editCamMaya->setInputReceiverEnabled(true);

6. Notice now the position and angle of the camera. It completely change.

Current behavior:
The camera doe not take into consideration position change / angle change when it input receiver is activated.

Expected behavior:
The camera should take into consideration position change / angle change even if the input receiver is activated.

System:
OS: Windows Vista Home x64, French edition (SP2 Build 6002)
RAM: 4 Gb ram
Video card: GeForce GTX 460

Irrlicht version:
1.7.2 (official release)

Video Driver used:
Open GL (Supported as Open GL 4.1.0, GLSL: 4.1)

Note: This "bug", as only been remarked using Irrlicht 1.7.2. I don't know if it happenned on previous release or the SVN version.
Note 2: As a "wish", It would be really cool, if we could "map" the mouse/keyboard button to an action as we can do with the FPS camera... Or trigger theses "actions" by code.

Screenshots:
Screenshot 1 - Here the camera is positionned by code at a "start" position. The input receiver is currently disabled:


Screenshot 2 - Activation of the input receiver is done and the camera angle and position change:

[hybrid]

The maya cam always hovers around the target. If you change the target, the camera will move. I don't know how we could define a proper reaction on the position change.

[christianclavet]

Hi, Hybrid.

Activation of the input receiver is done and the camera angle and position change:

I'm a little dissapointed. I was thinking my description of the problem was clear and accurate, It seem I was very wrong.

I never actually changed the targetor anything on the camera while it was activated with the input receiver. When we activate the input receiver it should compensate with the current values (so the initial position stay the same) I just enabled the input receiver. Before that all was fine. I'm just about as noob as it can be and I think I could fix this.

When the event receiver activate and set the position and rotation to the cam, it look like it doesnt look at all the current initial position and angle of the camera. Strangely once past that, If I rotate the camera directly with the mouse control, it seem to "remember", so I don't think it a big thing to fix.

So when I get more time, I'll fix it for us. I just hope that you will accept my code as I absolutely don't know how to do a patch. I'll also will check when the event receiver is activated to try to compensate if the "setPosition" and "setTarget" or "setRotation" are triggered while the event receiver is active. I just think that it could tell the event receiver that the new Position or angle is the new initial position (like a reset). For me right now the maya camera status is "broken" and I don't have any other word for it.

[CuteAlien]

I just hope that you will accept my code as I absolutely don't know how to do a patch.

Patches are one of those things that sound a lot more scary than they are :-) If you are working with trunk then the simplest way to create a patch is to use "svn diff > MyChanges.patch". Just calling that will spit out a patch.
Tools like WinMerge can also create patches I think.

[hybrid]

Sorry if my very short response was not clear enough - it was already quite late and I tried to post just some hints about the current - and probably intended - behavior. You simply cannot change the position of the Maya camera by setPosition(). Instead you have to use setTarget(). This will make the camera jump to the orbit around the target and move around there when steering with the mouse. The thing here is that the position is calculated based on the current target. So if you change the position of the camera, the camera jumps there and updates it's viewing angle based on the new position and the old target. Next, the camera animator (if enabled) calculates the position based on the old target and the new viewing direction (but not taking into account the new position!). This will lead to a jump somewhere on the old orbit around the old target.
I don't see any better way for this type of camera. If we want to support moving position as well, we have to find a way to cope with the internal offset that would be placed on top of the new position (the animator adds the zoom distance to the current position at least). Hence, setting the position and getting the position back after the frame would differ (significantly!). Moreover, it's not clear how to deal with position and target changes at once. This would require to deduce many of the parameters from the changed values, which might not lead to desired behavior in all cases. So it's probably simpler to keep the setTarget solution, which should work.

[christianclavet]

Wow! Thanks Hybrid. I'll investigate this. Is there a way then to define the target distance? I want to have the camera at a specific angle and position at initialisation and remain there until we start to use the controls, so it's seamless.

I know that the dev team prefer patches, is there a place where I could look for tutorial to make patches? I'm using MSVC Express 2008. I think I could find a way to at least have the initial position matching the internal.

[hybrid]

Well, to make patches you need the initial Irrlicht code, the changed code, and a patch tool. The easiest way to do the first and third one is to get the SVN/trunk version of Irrlicht with SVNTortoise. You can simply input the http address of the repository and download the whole code. Then you take that code as a base for your coding inside the Irrlicht engine. Once you're down, you can simply choose 'Create patch' from the context menu of the file or directory you made changes to. You automatically get the patch now that you can name and test further. The proper addresses of the repositories are listed in the SVN sticky thread here in the bugs forum.
For the camera problem: The zoom distance is fixed to 70 initially. There's no parameter or method which alters this value. Which seems to be a rather unintentional limitation. I will add a parameter and getter/setter for this value so you are able to set the initial distance as well. There should be no problem with the calculations to change or update this value in between.

[christianclavet]

What about a method that will set initially the camera with the position and angle(target) of the camera. Take the position entered, calculate the proper distance,set it and ajust the target if needed so the camera is positionned at the given coordinates and is looking at the given target.

That exactly what I have in mind. Using this could define the initial position of the camera when the input receiver activate. Would solve all my problems. If that method would be there. I could disable the input receiver, use the method, activate back the input receiver and the camera would be positionned and looking exactly where I want.

Thanks for the infos about how to create a patch!

EDIT: Hi, I quickly looked at the last SVN code for this camera. This cam is really different from the FPS cam, but I have some suggestions:

- Easy way to add mouse button binding customisation to the maya camera:
From the current SVN code from lines 50 to 89: (CSceneNodeAnimatorCameraMaya.cpp)

Code: Select all

bool CSceneNodeAnimatorCameraMaya::OnEvent(const SEvent& event)
{
        if (event.EventType != EET_MOUSE_INPUT_EVENT)
                return false;
 
        switch(event.MouseInput.Event)
        {
        case EMIE_LMOUSE_PRESSED_DOWN:
                MouseKeys[0] = true;
                break;
        case EMIE_RMOUSE_PRESSED_DOWN:
                MouseKeys[2] = true;
                break;
        case EMIE_MMOUSE_PRESSED_DOWN:
                MouseKeys[1] = true;
                break;
        case EMIE_LMOUSE_LEFT_UP:
                MouseKeys[0] = false;
                break;
        case EMIE_RMOUSE_LEFT_UP:
                MouseKeys[2] = false;
                break;
        case EMIE_MMOUSE_LEFT_UP:
                MouseKeys[1] = false;
                break;
        case EMIE_MOUSE_MOVED:
                MousePos = CursorControl->getRelativePosition();
                break;
        case EMIE_MOUSE_WHEEL:
        case EMIE_LMOUSE_DOUBLE_CLICK:
        case EMIE_RMOUSE_DOUBLE_CLICK:
        case EMIE_MMOUSE_DOUBLE_CLICK:
        case EMIE_LMOUSE_TRIPLE_CLICK:
        case EMIE_RMOUSE_TRIPLE_CLICK:
        case EMIE_MMOUSE_TRIPLE_CLICK:
        case EMIE_COUNT:
                return false;
        }
        return true;
}

I would like to propose adding 6 new variables as: (I'm sure there could be a better way to make this), with their "current" default values. Perhaps with an even better idea it could also be mapped to a mouse/keyboard key. At least with this proposed method, we could have lots of alternate workflows with the mouse. So we could mimic more the behavior of the mouse to match applications with the maya camera.

u32 keyRotationBindingUp = EMIE_LMOUSE_PRESSED_DOWN ---> For containing the current enum of the mouse key that would be used for rotation in the scene
u32 keyTranslationBindingUp = EMIE_RMOUSE_PRESSED_DOWN --> For containing the current enum of the mouse key that would be used to translate the camera in the scene
u32 keyZoomBindingUp = EMIE_MMOUSE_PRESSED_DOWN--> For containing the current enum of the mouse key that would be used to set the camera zoom

u32 keyRotationBindingDn = EMIE_LMOUSE_LEFT_UP;
u32 keyTranslationBindingDn = EMIE_RMOUSE_LEFT_UP;
u32 keyZoomBindingDn = EMIE_MMOUSE_LEFT_UP;

So the code would look like this now:

Code: Select all

bool CSceneNodeAnimatorCameraMaya::OnEvent(const SEvent& event)
{
        if (event.EventType != EET_MOUSE_INPUT_EVENT)
                return false;
 
        switch(event.MouseInput.Event)
        {
        case keyRotationBindingUp:
                MouseKeys[0] = true;
                break;
        case keyTranslationBindingUp:
                MouseKeys[2] = true;
                break;
        case keyZoomBindingDn:
                MouseKeys[1] = true;
                break;
        case keyRotationBindingDn:
                MouseKeys[0] = false;
                break;
        case keyTranslationBindingDn:
                MouseKeys[2] = false;
                break;
        case keyZoomBindingDn:
                MouseKeys[1] = false;
                break;
        case EMIE_MOUSE_MOVED:
                MousePos = CursorControl->getRelativePosition();
                break;
        case EMIE_MOUSE_WHEEL:
        case EMIE_LMOUSE_DOUBLE_CLICK:
        case EMIE_RMOUSE_DOUBLE_CLICK:
        case EMIE_MMOUSE_DOUBLE_CLICK:
        case EMIE_LMOUSE_TRIPLE_CLICK:
        case EMIE_RMOUSE_TRIPLE_CLICK:
        case EMIE_MMOUSE_TRIPLE_CLICK:
        case EMIE_COUNT:
                return false;
        }
        return true;
}

With this in place, and putting the "defaults" in the constructor, the camera would work exactly as before, but by adding the proper methods (Almost 1 liner each), we could be able to define the mouse button for the specific action we would like to do. (So it would be similar as the current FPS camera to have the ability to map keys to the camera movement)


-- Camera initial position: my real problem with this camera
You were right the default distance is fixed at 70.0 units from the camera. But in the code I have found this, it seem to relate to the current camera position (camera->getPosition()) to translate it:

Code: Select all

        core::vector3df translate(OldTarget);
        const core::vector3df upVector(camera->getUpVector());
        const core::vector3df target = camera->getTarget();
 
        core::vector3df pos = camera->getPosition();
        core::vector3df tvectX = pos - target;
        tvectX = tvectX.crossProduct(upVector);
        tvectX.normalize();
 
        const SViewFrustum* const va = camera->getViewFrustum();
        core::vector3df tvectY = (va->getFarLeftDown() - va->getFarRightDown());
        tvectY = tvectY.crossProduct(upVector.Y > 0 ? pos - target : target - pos);
        tvectY.normalize();

I see the variable pos that use the current camera position here, and get also the current camera target position. So perhaps having the current distance between the camera position and the target position would position the camera when events are enabled at the same place as when it was initilized (I hope). I would have to check if only giving it the proper distance would fix the problem...

If not, then if I found something I will have to modify something in that block. (Lines 216-234) Adding something like in the FPS Camera (firstupdate?) That will use the current position of the camera as a base to start then (so the 'pos' at initialisation is the one that was set on the camera.)

Code: Select all

        // Set pos ------------------------------------
 
        pos = translate;
        pos.X += nZoom;
 
        pos.rotateXYBy(nRotY, translate);
        pos.rotateXZBy(-nRotX, translate);
 
        camera->setPosition(pos);
        camera->setTarget(translate);
 
        // Rotation Error ----------------------------
 
        // jox: fixed bug: jitter when rotating to the top and bottom of y
        pos.set(0,1,0);
        pos.rotateXYBy(-nRotY);
        pos.rotateXZBy(-nRotX+180.f);
        camera->setUpVector(pos);
        LastCameraTarget = camera->getTarget();

[hybrid]

I've added a way to access and alter the distance value of the animator. It can also be set in the constructor directly. The pos variable is not really related to the camera position (only upon creation of the animator). So it's not that easy to update the position in an existing animator. For creating the animator at a certain position, simply do this: Create animator and attach, set position of the camera, set target of the camera, set distance to the length from cam position to target. Then upon rendering the animator will be positioned exactly where you wanted it to be and everything should work as expected.
For the event array I'm not sure if this really would fit for this camera. At least we would have to refactor the currently used SKeyMap for the FPS cam and add another one for the Maya cam. Please add this wish in our feature request tracker, as it will take more time and will not be part of the next release (unless someone else will code this)

[christianclavet]

Hi, Hybrid.

Cool idea about the SKeyMap structure. I decided to "dive in" and add the feature for being able to assign keys to the maya camera like the FPS Camera. Was able to create a modification from the last svn (revision 4003 from the trunk).
I added to the EKEY_ACTION enum 3 new enums as EKA_ROTATE, EKA_TRANSLATE and EKA_ZOOM.

The "default" behavior is set in the constructor, for the mouse button assigments.

They are assigned like this in the constructor:

Code: Select all

              // create key map
        if (!keyMapArray || !keyMapSize)
        {
                // create default key map
                KeyMap.push_back(SKeyMap(EKA_ROTATE, irr::KEY_LBUTTON));
                KeyMap.push_back(SKeyMap(EKA_TRANSLATE, irr::KEY_RBUTTON));
                KeyMap.push_back(SKeyMap(EKA_ZOOM, irr::KEY_MBUTTON));
        }
        else
        {
                // create custom key map
                setKeyMap(keyMapArray, keyMapSize);
        }

I recopied the setKeyMap methods from the FPS camera, so we can use the same command to assign the ACTION for the MAYA cam.
The methods added are:

Code: Select all

virtual void setKeyMap(SKeyMap *map, u32 count);
virtual void setKeyMap(const core::array<SKeyMap>& Keymap);
virtual const core::array<SKeyMap>& getKeyMap() const;

I tested the default behavior with the Model Viewer and it work.

This patch is only adding this feature to the maya cam. And it affect 3 files:
SKeyMap.h
CSceneNodeAnimatorCameraMaya.h
CSceneNodeAnimatorCameraMaya.cpp

Here is the link to the patch:
http://www.clavet.org/files/patches/May ... ions.patch 7.92Kb

EDIT: Also submitted the patch to the project page in the patch request as ID: 3449668
EDIT2:
Ok found what I was looking for. This will take me some time as my math skills are very poor... Here what I found:
3 variables are used to set the angle and position of the camera:
distance -> distance from the target (Default at 70)
RotX -> Rotation in X (Default at 0)
RotY -> Rotation in Y (Default at 0)

So I would have to create something to give these variables a proper values to match what I want. (Get the distance from the camera to it's target, then fill in the current camera angles)
It this work, I'll propose another patch.

[hybrid]

Ok, I'll see if I find some time for adding this patch before release, but please don't rely on this. The thing is also, that I want to put the keymap structures into the camera animators. They are not really generic, so should live in their dedicated classes instead. But I also have to check which changes this requires to existing code and other things.
About the math in the maya cam: Yes, the code is really weird. I doubt that there's really much math involved, but it's almost impossible to get a clear comprehension of what should happen at those places. That's why I am always cautious when altering this code.

[christianclavet]

Ok. I've added a FirstUpdate flag like the FPS camera, and this is used to get the initial position. Without using the "distance" variable, the camera calculated the distance between itself and the target and this provided the value for the "distance". Tested and this work perfectly.

Since finding the distance between two vectors is ultra simple, this was easy. The other part is to get the angles (x and y angle) between theses 2 vectors (as the first vector normal is facing the second vector). It's really possible, and will surely find it out tomorrow after some searching about this math problem.

EDIT: Done! Getting the angle was not so bad. Used the vector math command "getHorizontalAngle()" tested a lot and seem to match the camera settings every time. So no need to set the distance, just position your camera and assign it a target and the camera will position at the right place at startup.

I did not modify a lot of code, since the only thing I'm doing is when the "FirstUpdate" flag is active, calculate the proper angle and distance and put them in the 3 variables that I've found:

as
"CurrentZoom" (used for distance)
"rotX" (used for X rotation)
"rotY" (used for Y rotation)

Here is the patch for your review. Since most of you are better than me in math, you could check and see if the calculation is ok.
I've tested by giving different positions to the camera in the model viewer and compared when the inputReceiver was on/off. As the code is at the moment, this seem to match perfectly visually.

http://www.clavet.org/files/patches/May ... _fix.patch 2.1Kb
The patch request ID is: 3449955

This patch content the two(2) previous improvements (camera key mappings, and camera initial position fix)
http://www.clavet.org/files/patches/May ... ents.patch 9.09Kb
It only provided here, since the patch request only accept one feature or fix per patch.

Edit2: Hybrid, your set distance and get distance methods is a great feature! I was looking at it and it could be used to "autofocus live" on selected objects in an editor. For the key binding, I tried mapping a keyboard key instead of a mouse key to a Maya Cam action and it also worked, using the keycodes for this as the FPS camera seem to look better in code for me and is much more flexible than it was before.

Thanks to you Hybrid and CuteAlien for giving me hints to create a patch! I use Tortoise SVN now and it not that hard! I had just a few problem when I tried to create my "cumulative patch", as I was putting back the 2 patches back on the source. I had some mention of "refused patch" and some part of the code was not put back. I had to put them back manually.

[mchiasson]

Hi,

This seems to be exactly the problem that I am having with the Maya camera, and seems to have been solved, but when I look at CSceneNodeAnimatorCameraMaya.cpp from Irrlicht 1.8, there is not FirstUpdate flag in there. Was this patch supposed to be applied to 1.8?

Thanks

[mchiasson]

Hi there.

I patched my own copy of CSceneNodeAnimatorCameraMaya from irrlicht 1.8 with Christian's patch (http://www.clavet.org/files/patches/May ... ents.patch). It works exactly as I wanted! Having the zoom on the middle click is so much better too!

Good work Chris!! If you are in the Ottawa area, let me know, cause I owe you a beer my friend!!

[christianclavet]

Hi, Thanks! I live in Montreal. The patch was made for 1.7.3,
Thanks for updating the code for 1.8.0! I use a modified (using my patch) version of the maya camera now in my editor(IRB) and really work as I wanted. This will take some time to be integrated (if it happen) since they must clean it up and be sure it won't affect other parts in Irrlicht.

I'm really happy that my patch had use for someone else! Thanks!