next »

[ChrisE]

Marvin,

Another little thing to add. In the View class, some sort of helper moveForward, moveRight, moveUp functions would be nice. Additionally, pitch and yaw functions too would be appreciated. At this point I've implemented this in my own code, but having the ability to easily manipulate the camera in its local coordinate system would let me clean up my code significantly (and I imagine others' code as well).

-Chris

[Marvin Fröhlich]

While I agree, that this would be convenient, it wouldn't be good on the other hand.

Having a method moveRight() would mean to either get a vector and matrix instance from the pool or store instances in the view object (or create them just to discard them afterwards). The vector would need to be normalized and then multiplied by the distance parameter. Then it needs to be set to the matrix' translational components and then the view's matrix would have to be multiplied by that matrix.

Much of this doesn't have to be done, if you have it in your own code. So you can do it a lot faster and cheaper and no memory is wasted for the case, this is not used (of course this is a minor issue).

Maybe you want to post your code for this. Maybe I can simplify it.

Marvin

[ChrisE]

Sure. The code to do it looks something like this:

Code:

void handleCameraFromInput(float _dt)
{
Vector3f movedir = new Vector3f(0f,0f,0f);

// we change movedir from the input
// movedir is set to have +1 on x-axis for right movement, +1 on z-axis for forward, etc.
// ...snip...

Transform3D localcam = XithRenderView.this.xithEnv.getView().getTransform();
localcam.transform(movedir);
movedir.normalize();
movedir.scale(_dt);
xith.getView().getPosition().add(movedir);
}

Edit: _dt is the time delta from the previous frame.

[Marvin Fröhlich]

Ok, first if done that way, I would use a vector instance from the pool instead of a new instance each frame. Otherwise you might see hick-ups from the garbage collector.

Code:

Vector3f movedir = Vector3f.fromPool(0f,0f,0f);
...
Vector3f.toPool(moveDir);

xith.getView().getPosition().add(movedir) does nothing. It just adds some values to a vector, that isn't used internally.

You can put some knowledge into this piece of code to save some computations.

Code:

private static final float MOVEMENT_SPEED = 1.0f; // one unit per second
private final Vector3f movement = new Vector3f( 0f, 0f, 0f );
private final Vector3f tmp = new Vector3f();

void handleCameraFromInput( float dt )
{
    View view = XithRenderView.this.xithEnv.getView(); // We could also store this pointer in this instance.
    view.getRightDirection( tmp );
    // Here we can know, that the view's transform doesn't include scaling.
    // Hence we can spare the normalization.
    tmp.scale( dt * MOVEMENT_SPEED ); // I assume dt to be a fraction of a second.
    movement.add( tmp );
    view.getTransform().setTranslation( movement );
}

I agree, that the improvement is minimal. Though normalization is expensive. Anyway this isn't that much code.

If rotation is also done in the same code, the advantage becomes bigger, since you can do everything at once and can safe some additional computations.

Marvin

[ChrisE]

Ah, okay, thanks for the fromPool trick. That'll find its way into my other routines as well; I'm guessing that fromPool "checks out" a vector, and toPool "checks in"? Cool.

The xith.getView().getPosition().add() was kind of punting to avoid the full getPosition/add/setPosition call. The normalization stuff was done mostly due to my innate fear of denormalization errors creeping in during matrix multiplies. Thank you again.

[Marvin Fröhlich]

Ah, okay, thanks for the fromPool trick. That'll find its way into my other routines as well; I'm guessing that fromPool "checks out" a vector, and toPool "checks in"? Cool.

Yes