I'm trying to set up a simple Target camera as found in other 3d software:

Camera > Look at > Null, Upvector 0 1 0.

It turns out to work fine as long as I'm only moving the target null but as soon as I move the camera relative to the target, the camera starts to roll (rotate around object z). This happens even with rot z locked! When moving the camera rolls and stays in this pose on mouse release. When I click on the camera again it snaps back to a local Z 0 rotation or sometimes other rot z values.
I have noticed before, that the standard camera also produces unwanted rotation when using the target handle. Am I missing something here or is something weird going on?

Update:
I turns out that this happens with any object as soon as you use the move mode instead of the manipulator to transform the constrained object.
Reset all positions and rotations. Move the camera or the constrained object with the manipulator handle: no roll
Switch to move mode and move the constrained object: roll. Even if you switch then back to the manipulator the object will roll on transform.

So this is normal?

OneBigTree
So this is normal?

I believe the rotation values are added on top of the lookat transform. So, if they are non-zero, there's going to be additional rotations on the camera.

The .hip file has the rotates on the camera set to (21.5, 49.18, 0). Does it behave better if they are all 0? You might have to manually lock the x/y rotates at 0 to avoid this behaviour.

try this
I've made the camera a child of a null that has the other null as it's look at…

Thanks mark and arctor,

the rotational values in my hipfile are the resulting values of the constraint evaluation, they were 000 initially.

But it turns out that only when I lock X and Y rotation the constraint works as expected. Obviously there seems to be a conflict between the standard rotation and the values generated by the constraint. If you look at my new screenshot you see the camera has rolled and the rotation values do not reflect that.
However, if I lock the x and y rot when the camera is in a neutral position and move the camera after the lock, everything seems to be stable.
Also confusing is the different behavior when using the multi-handle tool for transformations instead of the dedicated move tool without the locks.

There is definitely something weird going on than can lead to errors if one isn't aware of it. I should be investigated and fixed. The locks can only be a workaround because there may be situations where you cannot or want not lock the rotations.

Anyway, thanks again for your assistance.

PS: another issue is: with a lookat active the transformhandles wont align to the object anymore! So it is impossible for example to pull the camera back along its local Z axis.

there may be some weirdness in the current camera…
but I would NEVER animate a camera directly (if I have a choice)
I'd build a simple rig - this prevents direct animation on the camera but also allows for offsets etc…

As I said, this isn't a Camera Problem, but a problem with the Upvector/Lookat.
So whatever rig you build, you can run into the same issues.

I think the main Problem is that the object rotation is not replaced by the rotation calculated by constraint which happens somewhere in the background, then added as marko said to the standard rotations which for some reason may get altered by the transform and the resulting rotations which leads to wrong calculation of the overall result´and so on. This is also the reason why the transform handle won't reflect the actual rotation when aligned to object.

The error is in the system. It is unreliable and unpredictable. If something shows up in a software shouldn't it be fixed instead of forcing the users to build a workaround? After all this works in literally any other 3d software.

I mean the solution can not be “It doesn't work, so I don't use it”, can it?

I started building a rig, but the time required to build a suitable rig that behaves like a standard target camera like in max, maya, softimage or even blender can better be used to animate the camera in, well, not houdini.

Hi OneBigTree,

I meet same problem. Have you solved it ? Or maybe a bug , should report it.