[alpha1 -> beta] How to get eye vector of Node after getCamera is removed

cocos2d-x C++
#1

We have a subclass of cocos::Node that use OrbitCamera as a repeat action.
Every tick, it continues to checks the camera eye vector as follows

float x,y,z;
getCamera()->getEye(&x,&y,&z);

As the function “getCamera” is now removed from cocos2d::Node in beta version, would you please let us know how to change the code for the value? Thank you.

#2

winipcfg.exe:
cocos2d-x v3.0 no longer has the Camera as an object.
Instead its functionality was merged into the OrbitCamera action.

Currently, OrbitCamera doesn’t have the getEye method exported, but if you need it, we can add it. thanks.

#3

Is it possible to get the Eye from Node as an adhoc solution at this moment? Only need a quick fix first as we all know this is beta.

Adding eye functions in OrbitCamera is fine but camera action will be removed once it finished. In alpha1, we use the Eye in Update function of Node and so we need to cache the value before released.

Unless later the ActionCamera class is revamped. For instance,
* OrbitCamera control a Camera, not the Node.
* Camera should view the Node

#4

winipcfg.exe:
this patch improves the API a little bit: https://github.com/cocos2d/cocos2d-x/pull/5049

History of Camera:
Back in 2008, in order to have 3D effects I introduced the Camera concept in Node.
But it was kind of hack because:
* The Camera was always looking at the center of the screen
* It was confusing because it was not the Scene camera. It was a per-node camera that was only useful for a couple of things
* The parent-child transform matrix didn’t include the Camera

So, what I tried to do in v3.0 beta was:
* Remove the concept of “each node has a Camera”
* Simplify the parent-child transform matrix
* Provide a way for users to keep doing the “camera” effect, but without the “Camera” object… (We will re-introduce the Camera concept in the near future, but it will be the Scene’s camera).

How ?

In v3.0-beta, both the “transform matrix” and the “additional transform matrix” were converted from 3x2 to 4x4.
That means that it is possible to transform each node in a real 3d space.
Why would you want that ? Well, that depends on your game, but 95% of the users won’t care about this new feature.
But this also means that it is possible to do any kind of 3d transformation on a node… including the old Camera effects without using a Camera.

As example, the Camera object was setting a GL Lookup Matrix… so in v3.0 you can do it yourself by doing:

    auto sprite2 = Sprite::create("hello.png");

    kmVec3 eye, center, up;

    kmVec3Fill(&eye, 150, 0, 200);
    kmVec3Fill(&center, 0, 0, 0);
    kmVec3Fill(&up, 0, 1, 0);

    kmMat4 lookupMatrix;
    kmMat4LookAt(&lookupMatrix, &eye, &center, &up);

    sprite2->setAdditionalTransform(lookupMatrix);

Benefits:
* cocos2d-x code is easier to understand, maintain an extend
* It is possible to add new 3D effects

Disadvantages:
* Users who were using the Camera API directly, will need to do it manually.

What do you think about it?

#5

I think we should use setRotationX and setRotationY for their local 3d rotations, the current setRotationX should be renamed to setRotationSkewX and vice versa

#6

Hao Wu:

Yes, setRotationX and setRotationY are very confusing names.

My concern is people who are using them will not know why suddenly their games behaves differently without any kind of warning.

Do you mean that the new proposal should do the real rotation in 3D ?
We can do that since we are using 4x4 matrix for each node.

#7

Yes, RotationX and RotationY should be their rotation around X and Y axis, which is way easier than using camera and eye vectors

#8

We checked transform matrix and now we are able to get the vector from it. Thank you.
Also it will be great if there are actions that handle self rotation of Nodes.

But as you mentioned that if you change the RotationX and RotationY, users using 2.x api will get messed up after they migrate to 3.x.
How about to do the following? The information should be get/set easily while keeping objects simple and easy to understand. i.e. moving all those information to “transform” information.

vec3 result = node.getTransform().getRotation();
vec3 result2 = node.getTransform().getSkew();
vec3 result3 = node.getTransform().getScale();

The benefit is that users know what they are doing (i.e. getting transform information) while keeping the Node class clean (users who not need it will not touch it)

#9

Hao Wu:
Yes, I agree with that. But changing the semantics of setRotationX, setRotationY will create issues (without any kind of warning) to v2.x users.
What is your proposal for that ? Thanks.

winipcfg:
Thanks. Planned for v3.1
We are going to add the Transform object to Node, and will have that interface.
But we are still going to support the old API. eg:

void Node::setPosition(x,y)
{
   _transform.translate(x,y,0);
}

///
// These 2 lines produces that same results
node->setPosition(x,y);
node->getTransform().translate(x,y,0);