Camera motion is done in two steps when called inside an enqueue() method

I use the function camera.setFrame(position, left, up, aim). When the function is called inside an enqueue() block, what appears to happen is the camera updates it’s position, waits a frame, and updates it’s angle. This becomes jerky when doing a camera orbit since the object of interest shifts left as the camera moves left and shifts back right as the camera turns right to keep it’s gaze on the same point.

The problem goes away when it is not in enqueue(), or when use app.runQueuedTasks(), but both can only be called in the main render thread (or else you get the dreaded “don’t modify <node> from another thread” error).

Calling app.runQueuedTasks() at the end of simpleUpdate() appears to fix the problem.

So what’s going on? Is there a way to prioritize queued camera motion updates (so that an expensive graphics update doesn’t bog down moving the camera)? Is there a way to prevent rendering when an enqueue() block is half-done (i.e. wait until you finish the block to render, and don’t move onto the next block until you are done rendering)?

Why are you enqueing something to run the next frame if you are already in the right frame to do it?

I think you will have to show code because it’s kind of confusing from your description. enueue() is for executing things from a different thread and it runs at the beginning of simpleUpdate()… by design.

Because I am in a different thread when I modify the camera. That means that I can’t just call camera.setFrame, because if you modify the scenegraph from the wrong (not the main render) thread you get an error. Enqueue forces it to wait for the next thread. What’s weird is that a single command gets split across two frames rather than simply being delayed until next frame!?

@KevinKostlan said: Because I am in a different thread when I modify the camera. That means that I can't just call camera.setFrame, because if you modify the scenegraph from the wrong (not the main render) thread you get an error. Enqueue forces it to wait for the next thread. What's weird is that a single command gets split across two frames rather than simply being delayed until next frame!?

No, you are seeing something else happening… or you are changing rotation separately or something. You talked about setFrustum but then you also talked about rotation.

I think we will have to see some code to spot your error.