@berendkleinhaneveld we need to test this branch with your project before merging. I'm a little concerned it won't be compatible with your push-based render loop.

This is ready (and no longer requires a change in wgpu-py).

I added an example with a very wide texture, and a camera config that only allows horizontal panning. Funnily enough, the horizontal-only panning revealed that the panning also moved vertically, due to a bug where we calculate the panning vectors.

Another question: is it possible to disable damping?

Another question: is it possible to disable damping?

Yes, just set it to 0.

In that case, I'd like a test from berend to see how well this works on his project before we merge.

I'll try it out, but it will have to wait till next week. Unless we are in a hurry to get this in?

I'll try it out, but it will have to wait till next week. Unless we are in a hurry to get this in?

No, not in a hurry.

BTW, once this is merged I'll add a Trackball controller (which is just a few lines) and a FlyController (which also should be easy now).

@berendkleinhaneveld I added an explanation in the top post. If needed we can sit together to see how we can tie things together.

So I discussed this with Berend and here's what would need to change in order for collagraph to retain full control over the update-render loop:

• don't use the before_render event
• don't run update_cameras
• controller.auto_update = False
• call handle_tick on regular intervals via event loop (e.g. every 16.7ms), independently from calling render
  • in that loop, copy controller._last_cam_state to camera state object (not the pygfx camera instance, but an observ camera state object)

There's two essential requirements here:

• Controllers do not mutate cameras
• Handle_tick is not triggered by before_render (this trigger prevents running state updates independently from draws)

don't use the before_render event
don't run update_cameras

Is the controller hooked up to the renderer events in the collagraph case? If not, a lot of the requirements are met, which means that we can keep the controller Just Work when using register_events, and with just a few tweaks provide the flexibility needed by e.g. collagraph.

call handle_tick on regular intervals

Would it work if we made handle_tick public, and leave it to the application? It could return the camera state, so the application can process it the way it wants.

Is the controller hooked up to the renderer events in the collagraph case?

The controller is listening to mouse/keyboard events, but nothing else. I guess that's what you mean?

If not, a lot of the requirements are met, which means that we can keep the controller Just Work when using register_events, and with just a few tweaks provide the flexibility needed by e.g. collagraph.

Yes, I agree.

Would it work if we made handle_tick public, and leave it to the application? It could return the camera state, so the application can process it the way it wants.

Yes, that would work. We could also make the camera state a property, instead of returning it. I think that's a little more flexible.

The controller is listening to mouse/keyboard events, but nothing else. I guess that's what you mean?

How are these events fed into the controller? By calling handle_event() explicitly?

We could also make the camera state a property, instead of returning it. I think that's a little more flexible.

I'd rather not, because the internal camera state is only valid as long as any actions are active, and we'd have to figure out whether to e.g. set it to None when there are no actions, etc.

I just pushed a commit that I think should do the trick. The tick() method is not public. And when auto_update is False, the controller won't update the camera either.

I added the reactive example and adjusted it for the new controller.

Would this call not be necessary if controller tick was executed on a timer?

Exactly. Because of the inertia, it needs to be called somehow in addition to (mouse) events. A timer would work. At draw-time works too.