camera is jumpy, why?

[chronologicaldot]

I never base motion off of frame rate. I always base it off of some clock. The clock is (generally) consistent, the framerate isn't. Any odd frames will throw off your calculations.
Consider this: If the math for rotating at near distances (perhaps big rotations) is more intensive than the math for rotating at far distance (perhaps little rotations, which may be optimized), then the rotating at nearer distances will take longer, thus creating a slow frame and causing jerky motion.
That said, my advice is: Use a clock. It can be a controlled clock, of course, and you can obviously control the speed of the clock. But the clock itself should tick with a clock outside your program (or perhaps ITimer, but I read that's not the best?), not be incremented with the frame.

tl;dr - Rewrite your function to use a real clock.

[suliman]

But my "SPEED" is the deltaTime (maybe not obviously named i know, but its a shortcut to "www.master.deltaTime"), thus the time in ms since last frame. Isn't that a real clock?

I think irrlicht must use the system clock right?

[mongoose7]

This is a distraction. Yes, you normally use changes in time to create changes in distance. But this is all talk. You are just talking. Do what CuteAlien has said and try to *debug* your problem. The situation is simple, yes, but the implementation may be imperfect. Debugging is the technique we use to fix errors in implementation. Stop talking, start debugging.