C++ SDK 2026.4 — Supported ordered mouse movement input for keyboard-initiated modal transforms

[hey2495]

Hello Maxon SDK Team,

I am developing a C++ viewport transformation plugin for Cinema 4D 2026.4, using the Cinema 4D 2026.3 SDK.

The plugin supports keyboard-initiated modal Move/Rotate/Scale operations (G/R/S), without holding down a mouse button. It needs continuous mouse movement, including when the cursor wraps across viewport boundaries.

Currently, cursor positions are sampled through GetCursorPos() during viewport cursor callbacks and periodic updates. The plugin uses SetCursorPos() when wrapping is necessary.

Under rapid mouse movement, especially while holding Shift for precision transforms, we have observed cases where cursor positions appear discontinuous after a warp. A large apparent displacement can then enter the transform calculation.

We would like to replace this polling-based approach with a properly supported event-based solution, if the Cinema 4D SDK provides one.

Could you clarify the following?

Is there a supported way for a C++ plugin to continuously receive ordered mouse movement events during a keyboard-initiated modal operation, without any mouse button held down?

Can EditorWindow::BfGetInputEvent() be used for this purpose? Does it provide the original mouse event coordinates, modifier state, and reliable ordering relative to cursor repositioning performed through SetCursorPos()?

Does calling BfGetInputEvent() remove events from the queue that Cinema 4D or other plugins would otherwise process? If so, is there a supported way to preserve or forward events not owned by our plugin?

If BfGetInputEvent() is not suitable, which API or callback mechanism would Maxon recommend for this type of keyboard-initiated continuous viewport interaction? Are there specific thread, window ownership, or lifecycle restrictions?

We are specifically looking for the supported SDK input and event ownership contract, rather than a workaround based on motion thresholds, delays, or repeated cursor repositioning.

Thank you for your guidance.

[ferdinand]

Hello @hey2495,

Welcome to the Maxon developers forum and its community, it is great to have you with us!

Getting Started

Before creating your next postings, we would recommend making yourself accustomed with our forum and support procedures. You did not do anything wrong, we point all new users to these rules.

• Forum Overview: Provides a broad overview of the fundamental structure and rules of this forum, such as the purpose of the different sub-forums or the fact that we will ban users who engage in hate speech or harassment.
• Support Procedures: Provides a more in detail overview of how we provide technical support for APIs here. This topic will tell you how to ask good questions and limits of our technical support.
• Forum Features: Provides an overview of the technical features of this forum, such as Markdown markup or file uploads.

It is strongly recommended to read the first two topics carefully, especially the section Support Procedures: How to Ask Questions.

About your First Question

Please excuse the delay, I will be answering your topic next week.

Cheers,
Ferdinand

[ferdinand]

Hey,

please excuse the long delay. Please have a look at Support Procedures for future topics, we do not allow for multi-question topics, as they have a tendency to derail.

Is there a supported way for a C++ plugin to continuously receive ordered mouse movement events during a keyboard-initiated modal operation, without any mouse button held down?

Yes, there are multiple ways to do this. I cannot highlight each way in all details due to the broad nature of this question and topic. Some ways are:

• Implement SceneHookData and implement ::MouseInput, ::KeyboardInput etc. Scene hooks are sort of spider in the net node types which exist always exactly once in each document. They are often used to do command and control tasks. Things like render regions or the simulation system in Cinema are all backed by scene hooks.
• Implement a GeDialog, start a timer via GeDialog::SetTimer and on each tick, poll the current input state yourself via GetInputState (the current state) or GetInputEvent (the last enqueued input event, could lie in the past).
• Implement a thread or job, and poll from there on each tick.

Can EditorWindow::BfGetInputEvent() be used for this purpose?

EditorWindow::BfGetInputEvent() just like GeDialog::GetInputEvent and similar methods is a specialization of the generic cinema::GetInputEvent. It is often better to use the global functions rather than the specific ones, unless one wants to filter out all events that do not go to a specific viewport or dialog. As hinted at above, you often also want to poll for the state and not for events, as they can be consumed (the user is still holding down "X" but something has already consumed this event) and temporally offset (the user is not pressing x anymore, but the event is still last in queue).

Does calling BfGetInputEvent() remove events from the queue ...

I would quite frankly have to check this, and this is probably not an easy "look it up in file foo.c on line 4555". Without checking, I would say that the InputEvent methods do not consume the events, as there is no way to signal back that you have consumed an event. The canonical way to consume events are plugin methods such as the scene hook methods discussed above, or similar methods of other plugin types. There you can then return true ore false to indicate if you want to consume an event or not.

If BfGetInputEvent() is not suitable, which API or callback mechanism would Maxon recommend for this type of keyboard-initiated continuous viewport interaction? Are there specific thread, window ownership, or lifecycle restrictions?

This is exactly why we disallow multi question topics I could write an essay alone on this because while this is a precise question it covers so much ground. In general, you should avoid polling the input state off main thread if you can. The input methods are not explicitly thread-unsafe but I would still avoid it. The reason is that the plugin type specific methods which are about inputs, such as SceneHookData::MouseInput, ObjectData::MoveHandle, or ToolData::KeyboardInput usually run on the MT. I would advise the against polling inputs in heavily parallelized methods such as SceneHookData::Execute, ObjectData::GetVirtualsObjects, TagData::Execute. While it might not provoke crashes, it is for sure not good for performance. Polling for the input in your own custom thread spawned from the MT is fine.

But you usually do not have to use threading, there should be a plugin interface with input methods which fits your needs. And when the plugin interface you use does not have an input polling function, e.g., you implement a tag, it means that you should not poll for inputs there and use another plugin type or rethink your whole design. You could for sure make it technically work that a tag behaves differently depending on the key(s) the user presses, but from a Maxon point of view, this would be a rogue UX.

Cheers,
Ferdinand