@ferdinand said in Can a plugin use the native Node Editor for its own graph?: Hey, sorry for the delay. I checked and it is not possible to have arbitrary node systems, i.e., node systems that are neither scene nor material nodes. In the backed of things, you actually have almost all you need, so you could implement a node system that outputs sound files for example. One of the major hurdles is that this menu is hard-coded at the moment: [image: 1793790825815-b6453bab-c4e5-4ea3-9273-eb76465a7257-image.png] So, there is no way to display your node system of a custom node space purpose type. Cheers, Ferdinand I did manage to add a space to the dropdowns but couldnt connect the viewer to that. although it was only accessible from the top shelf menu Render/node space.

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

btw, same on windows

Hi @ferdinand , Yes, I do need the dimension overlay to coexist with another active tool. The plugin is mainly intended to help adjust objects to realistic dimensions and proportions. When precise dimensions are not required, the overlay helps me quickly resize and place objects in the scene. Once that is done, I can turn off the dimension overlay. The plugin can be enabled or disabled directly and includes some settings, with usage similar to the Symmetry tool. Inactive objects do not display dimension information, and grouped objects are measured as a whole, so the viewport does not become a sea of dimension annotations . Cheers, Anlv

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 I would try closing the file into which you imported the Alembic file. I just checked it, when I import any Alembic file, Cinema holds a lock onto it while the file into which you imported is still open. That seems to be an Alembic specific behaviour, not to say a bug. But it should be avoidable by simply cloning or merging the imported document, so that you can close the import document. I will give the exchange team a heads up on this. Cheers, Ferdinand

Thank you @ferdinand for looking into this, as well as bumping the request to the RS developers. Any update on this would be appreciated! Thanks.

I tried with a Cube where the only way to change colour is to use the display colour in the basic tab. At first sight this doesn't cause the problem, but in fact it does. Yes, that was what I meant. Thanks for confirming. The issue likely already has vanished in the current alpha, because there I could not reproduce it. But in 2026.3.2 I can. What is a bit odd is that no one seems to have touched the relevant code in the last months. But that is something for the GUI team to figure out.

@DronKozy Yeah, I got the general direction, that you are probably implementing a material mixer type of material/shader. When you implement a full render engine binding, you should go the event notification route, as I am sure you can then easily handle the (slight) complexity that comes with them. Regarding the architecture, in principle you can do with whatever you want. As Maxon employee I would of course recommend to use our Nodes API (what you call 'native'). The SDK contains both code examples and documentation about this. But this biggest flaw of the Nodes API is probably that it is not entirely non-trivial. But implementing a full node editor also requires a relatively high level of expertise about our APIs, although in different areas. Currently Redshift, Vray, Arnold, and CentiLeo use the Nodes API and all other render engines (Corona, Octane, Cycles, etc.) use either a completely custom system or the old Xpresso Nodes API. Cheers, Ferdinand PS: When you are developing a render engine binding, you might want to consider our Maxon Registered Developer Program.

This will be fixed in the next upcoming hotfix.

Hey @ECHekman, well, when a node displays an embedded description (what you exemplify at the case of a BaseLink), it uses a DescriptionCustomGui too. Other parameter types aside from a BaseLink which can do this are for example field lists. I am quite frankly a bit surprised that this even bubbles up in the form you report it, that you get a DescID which is selected inside a DescriptionCustomGui that is shown by the node in the DescriptionCustomGui you opened yourself. Attribute Manger selection states (and by extension DescriptionCustomGui) are not a public API feature, as we usually keep our GUIs sealed, i.e., inaccessible to third parties. DescriptionCustomGui is here a bit in a grey area, but I am afraid there is no way to do what you want to do. To do what you want to do, you would need access to internal systems. And other than in some other cases, where we do not always had the time to expose something (and are open to the idea of changing something), this is for GUIs not the case; they are intentionally sealed as we do not want third parties to change basic UX concepts. My general advice would also be to not to try to overcome this boundary (that a plugin reacts to which parameter in a node is being highlighted by the user), as you break UX conventions of Cinema 4D with that. Cheers, Ferdinand You can do this, but it is very hacky: Get the description of the node(s) you are currently displaying in the your DescriptionCustomGui. Check if desc is a member via CheckDescID (I think GetParameter would also work and return an empty container when the ID does not exist). When the ID does not exist, start browsing the container for parameters that are of a DTYPE that implies an underlying node, such as DTYPE_BASELINK. When you find such parameter, get the node node, and check there. Rinse and repeat recursively. Issues: You cannot distinguish the case where an object A has two BaseLink parameters which both hold an object of type T, but not the same instances. You will run into issues with DescID translations which some nodes might do. This is a really big point, which is probably already overlooked in your current code. Nested node relations can get REALLY complicated. BaseLink is trivial, but stuff like field lists, volume lists, or some special shader stuff can get really complicated. You would probably only have to worry about base links and field lists in your case, as other renderers are irrelevant for you, but field list alone are already complex enough that I would strongly advise against 'just implementing it'.

That is of course also a valid option, just pick the scripting language you are most comfortable with.

Hey, there is no shame in using the 'old' stuff since it is part of our API (and it will stay like that). I just point it out whenever a user is dealing with one of the hollowed out types. My guess would be that there is a threading issue or threading safety mechanism in the way. I think the memory struct stuff is internally using locks to avoid race conditions/corrupted data. When the renderer backend is doing its threading thing, this could cause issues. But ramdisk should work because our assets use the concept heavily (most assets are only a 'promise' which will only be truly created once accessed). You would even profit from the ramdisk caching in the temp folder of Cinema 4D. So, in its simplest form, this should just look like this: void RenderMyDoc(...) { // --- Error Handling and Resource Management ---------------------------------------------------- // Declare heap allocated resources that must be freed once the function exists either normally or // through an error. HeapRescource * myResource = nullptr; BaseBitmap * bmp = nullptr; // Catch any Maxon API error and turn them into the return type of this function and do optional // logging. We could also free resources here, but then we would have to do it twice, once for // normal exit and once for error exit. iferr_scope_handler { // DiagnosticOutput("Error during RenderMyDoc: @", err); return; }; // finally is Maxon API syntax to execute code once a scope (not necessarily a function) is left, // no matter if it is left through normal execution or through an error. This way we can ensure // that resources are freed. finally { if (myResource) HeapResource::Free(myResource); if (bmp) BaseBitmap::Free(bmp); }; // Allocate all the resources we need. When we use AutoAlloc<T>, we would not need the finally block // above, but not all types have an AutoAlloc allocator. myResource = HeapResource::Alloc(); if (!myResource) return maxon::OutOfMemoryError(MAXON_SOURCE_LOCATION, "Failed to allocate heap resource."); bmp = ... // --- Main Logic -------------------------------------------------------------------------------- // Create our ramdisk mounting point and an URL within it. In practice, we probably would want this // ramdisk mounting point to be a class member or even a global singleton. RamDiskRef mountingPoint = RamDiskInterface::Create("net.mycompany.ramdisk.foo"_s) iferr_return; const Url ramdiskUrl = (mountingPoint.GetRoot() + "my_virtual.psd"_s) iferr_return; // Call BaseBitmap::Save with the ramdisk URL converted to a Filename. bmp->Save(cinema::MaxonConvert(ramdiskUrl), ...); // ... } Cheers, Ferdinand

For now I am good. If I need further help, I will send the endpoint and function by email.

Thank you. MSG_DESCRIPTION_USERINTERACTION_END is just what was needed.

Hello @atg, 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 I can see why would think that, but you mixed things there a bit up. The CMake SDK build system was introduced with 2025.2.0 and became the standard with 2026.0.0. Between 2025.2 and 2025.3 we supported both build systems as a grace period for developers to get accustomed. Chances are very good, that you can just copy the CMake setup, i.e., the cmake folder and files such as CMakeLists.txt, CMakePresets.json, and sdk_modules.txt to a 2025.0 folder and it will generate a correct build system for you. But the supported range is only 2025.2+. For older projects you would have to use the old project tool based build system. Since I know what you are trying to do, I would recommend trying copying before you get into the old build system of ours. 2025.2 Release Notes 2025.2 Build System Docs (which covered both the old Project Tool and CMake) Cheers, Ferdinand edit: You will only find the old project tool tooling in old extended SDKs which supported it, such as 2025.2 or 2025.0.1

Hey @SteveHill3D, Storing a tool state in a tag is possible, but a bit unusual. But generally you are on the right track. Tags are also internally often used as hidden data containers. When you write a modelling tool, you probably already found out that points and polygons are are actually stored in hidden tags on objects. I am not sure though if using tags in tools is a good advice, as injecting all that data all the time into the scene graph is probably not the fastest. It depends a bit on what you are doing, but in general the solution is a bit unusual. Cheers, Ferdinand

Hello @Jespersather, thank you for reaching out to us. This is a developer forum, not an end user support forum. We cannot help you here with your end user issues. Please use our Support Center to get end user support for Cinema 4D. I have moved your topic into General Talk. Cheers, Ferdinand