Thank you, Maxim.
No further testing is needed—this works very well.
I’m calling it from the ToolData::MouseInput() callback at the end, which is sufficient. The panel updates nicely after the mouse event finishes (on mouse up).

SendCoreMessage(COREMSG_CINEMA, BaseContainer(COREMSG_CINEMA_FORCE_AM_UPDATE));
GeUpdateUI();

You can close this thread.
Thanks!
V.

Thank you both!

Thanks for pointing it out, changed it 🙂

Hey,

well, the reason for the "compiler" restrictions mentioned in the docs, is that the SDK is shipped with code example projects and precompiled static libraries for these targets. But the SDK also comes with its full source (the 'includes'), so nothing is really preventing you from using another IDE/compiler. The VS 2019 projects should also be relatively safe to upgrade to 2022. With XCode things are more complicated, and I would there recommend creating your own project from scratch instead of updating the existing one.

In the bigger picture, we probably should update the Cineware SDK to also using CMake as the Cinema 4D SDK does these days, and with that offer more flexibility. I have this on my bucket list, but it is not very high in priority, because the Cineware SDK is our least requested SDK. When you have concrete problems with creating a build system for the Cineware SDK for your desired compiler (and IDE), just post the questions here, and I will try to help you.

Cheers,
Ferdinand

Hey @Dunhou,

I have edited your posting. It is fine to mention the beta forum, but we would rather not see its name written here.

When you are talking about 'C++', I assume you are talking here about the Windows SDK/API, as for example GetGUIThreadInfo. I would doubt that you get very far with that here. Cinema 4D is very OS agnostic and we have our whole GUI decoupled from the OS. The little rename window in our tree view control is not an OS rename dialog. I am not even sure if this is something with an HWND handle which you could address so that you could intercept keyboard events to it, or if this is just a virtual window within our API.

For this IMM thing to work, we would have to use the IME API in Cinema 4D, so that our text edit gadgets support it. I also do not quite understand what you are trying to do. The missing piece is here probably that our text edit gadget does not send its current content to the IME API (at a glance, via ImmSetCompositionStringW as shown here). And as a third party, you cannot really fix that. Because you (a) do not own the implementation and you (b) are not informed about an edit event, so you cannot just write a plugin which sends the object name to the IME API.

Cheers,
Ferdinand

Hello @Aaron,

Thank you for reaching out to us. Please follow our support procedures.

You should consolidate your postings until we answer, i.e., update your last posting instead of creating new ones. I have consolidated your postings for you. You should also spend more time on making your problems reproducible for us. I know it can be easy to overlook in the heat of the battle but your question(s) are not as obvious to me as you probably think they are. As lined out in our support procedures, example code and/or scene data is usually required.

I cannot answer every possible angle and interpretation this topic of yours could take, but I can state three things which come to mind when reading your two postings.

What's the way to get several steps of motion blur transformation matrices for BaseObjects of the BaseDocument.

That is simply not possible. A document has no notion of motion blur as it is a render effects implemented by a render engine, not something documents implement. Cinema's time system BaseTime allows for sub-frame accuracy, e.g., you could set a 10fps document to BaseTime(i, 30) and with that step with three sub-frames through the document. Simple things like position animations or other interpolated values will also work doing this. But simulations might yield different results than stepping with the natural frame rate through the document.

And the most important thing is that there is absolutely no guarantee that this approach will result in 'matrices', i.e., transforms, that will match with what a render engine produces when you add some kind of sub-frame-based motion blur. Using this BaseTime approach is one way how the render engine could do it, but since render engines always have their own scene format, they could also do the calculation there, yielding different results than what Cinema's animation system would yield.

When we want to add Motion Blur and call document->ExecutePasses(...) for some time then this POC is flushed and has no polygons or vertices, so it's not collected and can't be rendered

It is too opaque for me what you are doing there to give a real answer, but:

There is no guarantee that the caches of an object are built at any point except for when a render engine gets a scene state to render or inside GetVirtualsObjects when you manually build your dependent objcts. Usually, caches are built but depending on where you are, the cache of another object might not have been built or updated yet, resulting in either an empty cache or you looking at the cache output from the previous scene update. ExecutePasses has become a bit too popular tool recently. I guess that is partially my fault, because I have shown its usage in some examples. But executing the passes on a document is a very expensive operation and should only be carried out when absolutely necessary. I would absolutely not be surprised if something like liquids do not support stepping through a document with a frame rate lower than the documents frame rate. But without concrete data and example code I am just guessing.

Cheers,
Ferdinand

@ferdinand said in BaseBitmap.Init("somefile.exr") crashes with multiple std::thread:

omp #parallel

Sorry for late reply, I am not advocating for std::threads, I understand your design explanation.
The omp #parallel thing is OpenMP directive to launch parallel threads. It's an old but simple method.
Actually I have made a solution by exploiting Cinema way of launching threads and it works fine.
However, I hope it would be good to make BaseBitmap->Init a thread safe and independent call from other C4D threads and resources.
I will collect an example for you with exr images soon.

Cheers,
Aaron

Hey @Viktor-Velicko,

Thank you for reaching out to us. Generally, our codebase supports Unicode, but in C++ source code and in *.str resource files, we only support Unicode escape sequences, not Unicode symbols directly. In Python, we do support Unicode symbols directly. In the 2025.3 SDK, I just added a code example for how to use Python to create a Unicode escaping pipeline around *.str files.

So, the Unicode string const String slopeLabel = "Slope 90º"_s; would be written as const String slopeLabel = "Slope 90\\u00b0"_s; in C++. A bit more verbose variant would be const String slopeLabel ="Slope 90"_s + String("\\u00b0", STRINGENCODING::BIT7HEX));. In Python, you can use the string directly as slopeLabel: str = "Slope 90°".

Cheers,
Ferdinand

Hey @shir,

Thank you for reaching out to us. A Program Database (PDB) is a debug information format from Microsoft. It is comparable to the DWARF debug information format often used under Linux and macOS. However, unlike DWARF under Linux, where debug information is directly compiled into the binary, Microsoft chooses to store debug information in separate files, the pdb files.

When you attach a debugger to a binary without any debug information, it will by default only see the machine code of the binary. So when you have an issue and the debugger puts out a stack trace, it will only show you the offsets in a library, e.g., something like this:

#1 0x0000000000767576 in myBinary.dll #2 0x0000000000767df4 in otherBinary.dll #3 0x0000000000773aca in myBinary.dll #4 0x00000000004b893e in myBinary.dll

You can see this happen in the call stack window in your screenshot. VS only provides information in the format someBinary.ext!someAddress(), e.g., c4d_base.xdl64!00007ffb200acfb7(), as it has no further information. With bin!address() VS means a function at that address is being called. In my opinion, VS has one of the most cryptic stack trace formats out there and can be a bit confusing for beginners.

To see meaningful output, you need the debug information for that binary, which among other things contains the mapping of addresses to source code. If you have the pdb file for the binary, you can load it into your debugger, and it will then show you something like this instead:

#1 0x0000000000767576 in MyClass::MyMethod() at myClass.cpp:42 #2 0x0000000000767df4 in OtherClass::OtherMethod() at otherClass.cpp:15 #3 0x0000000000773aca in MyClass::AnotherMethod() at myClass.cpp:78 #4 0x00000000004b893e in main() at main.cpp:10

When you compile the Cinema 4D SDK and your source code, it will automatically generate the pdb files for these binaries for you, so that you can debug them in a meaningful manner. But what we see here is Visual Studio asking you for the pdb for c4d_base.xdl64, one of the core library binaries located in the corelibs folder of the Cinema 4D application you are debugging with. You did not compile that binary, so you do not have the pdb file for it. And we do not ship our binaries with debug information, as that would not only be a very large download, but also would expose our source code to the public.

You are hitting a debug stop there (VS tells you that in the info box by stating this is a __debugbreak). This is the less critical case of a debug event, which is covered by the very tutorial you are following (the other one being a critical stop). You can simply hit continue in your debugger and ignore this. The event seems to be raised from Redshift, judging by the stack trace we can see in the screenshot you provided. There is probably some minor hardware issue or so, and Redshift is trying to handle it gracefully by raising this debug event.

It is, however, not normal when this happens permanently and usually it hints at a corrupted installation of Cinema 4D or a hardware issue when you are always greeted by debug events on startup (or even when just running and interacting with Cinema 4D). Sometimes debug stops can happen as a one-time thing when you are debugging for the first time against some Cinema 4D instance (and it has not yet built all its prefs, caches, and other things Cinema 4D builds in the background). When this persists and you are annoyed by having to press continue, I would recommend trying to either remove Redshift from your Cinema 4D installation or reinstall Cinema 4D altogether.

You could also check inside of Cinema 4D if you can see any errors in the 'Redshift Feedback Display' window. For you as a third party, it is however not possible to find out what that issue in c4d_base.xdl64 at the offset 7ffb200acfb7 is.

Cheers,
Ferdinand

PS: There is also g_enableDebugBreak=true|false which you can pass to your Cinema 4D instance as a commandline argument. With that you can permanently mute debug stops. But that is more of an expert feature and you probably do not want to enable that as a beginner.

Hey @ECHekman,

I sense there is some frustration, but I am not sure telling us how bad our API is will get us anywhere. Yes, the Nodes API ist not trivial, but you are only on the using part (which is not that hard to understand) not the implementation part (which is the trickly one). There are multiple render engine vendors who took that hurdle. I already answered your questions, and as always you will not see source code from us, unless you give us executable code in the first place upon which we can build, or we deem a subject new.

I often bend these rules a bit where it makes sense to meet our customers and third parties halfway. But you cannot just throw a snippet at us and then expect us to invent everything around it and then fix that for you. Executable code makes a difference as lined out in our support procedures. My hunch would be that your getConnectedNode does not work because you do not check if your nodes are valid.

You can get the value of a port with GetPortValue or GetEffectivePortValue. What you are doing with GetValue and EffectivePortValue is the old way but will still work.

// Redshift expresses a lot of its enums as strings and not as ints (did not check if that is here the case). const String value = myPort.GetEffectivePortValue<String>().GetOrDefault() iferr_return;

And as lined out before, what your function is trying to do, can likely be done via GraphModelHelper too, e.g., with GraphModelHelper::GetDirectPredecessors. An alternative and more manual approach would be using GraphNode.GetInnerNodes and GraphNode.GetConnections.

And as always, I am not really looking for a discussion about what you or I would consider a good API. I am telling you that you will be in a world of hurt when you terminate your errors everywhere as you did in your code. Your code will then just silently fail without you knowing why. So, I gave you an example on how to use our error handling.

Cheers,
Ferdinand

Hey,

I now know how our API will look like in this regard in 2026.0.0. Its compile/runtime behaviour will be as for 2025.2.1 and before. And we will introduce a new flag NOHANDLEFOCUS which must be set when attaching the area when one explicitly wants to ignore focus events. So, you will not have to change your code when you were happy with your user area behaviour as it is has been.

Cheers,
Ferdinand

Hey @ECHekman,

you can find our general answer here.

This is unfortunately an unintended regression caused by an intentional bugfix, not taking API stability into account. The flag USERAREAFLAGS::HANDLEFOCUS is meant to signal if a user area is focusable or not. But before user areas were always focusable, as this flag was erroneously being ignored.

We then 'fixed' this, causing the chain of events. The in detail logic is then that some types of events are not possible for non-focusable gadgets, as for example keyboard events. I will touch up the docs a bit in that area, as things are indeed a bit thin there. But the doc changes will probably not make it into the next release, given how close it is, unless I patch them in there manually.

So, long story short, compiling with USERAREAFLAGS::HANDLEFOCUS against the 2025.0.0 SDK will result in a binary that will be compatible with all versions of 2025, you did the right thing.

Cheers,
Ferdinand

Hey @WickedP,

It did not come across as abrupt or rude, but it was clear that you were a bit frustrated, and I was just trying to make clear that they had to choose some magic number, as that is the nature of rendering an orthographic projection. As to why we chose this number, I have no idea, as this happened 20 years or an even longer time back, long before I was at Maxon. It could either be because programmers simply love powers of two, or something more concrete such as that a power of two leads to less floating precision losses when multiplying other numbers with them, or simply that they did chose 1024x576 as the norm render size then.

And you can set the camera width and height, but you just do this in the render settings with the render resolution, which was pretty standard for 3D software I would say. The new Redshift camera then uses a more complex model with an actual sensor and fitting the sensor to the render resolution (which I ignored here since you showed us using a Standard camera).

Cheers,
Ferdinand

You do not have to do that; I only recommended this for the case when you happen to have to override a dynamic parameter of the same ID with a new GUI/datatype, then you should also set a new default value. But as I said and as you can see here at the Python dynamic description example (in C++ we have a similar one), Cinema 4D will do the bookkeeping for you. Here we read the value of Dynamic REAL 6 at 1106.

4361ae57-21f3-47d2-87e4-84709bf6f809-image.png

Once we have modified the description, in this case removed Dynamic REAL 6, Cinema 4D will update the data container for us and remove the data at 1106.

2712461d-c0c7-4280-96f5-ca9be93dfd8b-image.png

Cheers,
Ferdinand

Ok? will do

Hey @ECHekman,

Thank you for reaching out to us.

@ECHekman said in Getting debugbreak in atom.cpp:

Here is how i create the UI

// in MyData::GetDDescription() BaseContainer bc = GetCustomDataTypeDefault(DA_CONTAINER); bc.SetInt32(DESC_CUSTOMGUI, CUSTOMGUI_OCIOCYCLE); bc.SetString(DESC_NAME, String(pinInfo->mStaticLabel)); bc.SetBool(DESC_SCALEH, TRUE); description->SetParameter(IDCopy, bc, groupID);

That, the GetCustomDataTypeDefault(DA_CONTAINER) call, is illegal code. Check our documentation for the function. It could probably be put a bit more verbosely into the docstring, but:

cb400f4a-9cf9-43eb-83b2-0bd37b7127f8-image.png

DA_CONTAINER is not a resource data type. Which is a fancy way of saying that a C4DAtom parameter cannot be of data type DA_CONTAINER. On line 439 in atom.cpp is no crit stop (at least in the version of atom.cpp for 2025.2.x.yyyyyy I looked at), but on line 476 there is. This is inside C4DAtom::SetParameter, and it gets there the ID of the parameter container of the description element which shall be written, then switches through all the atomic DTYPE_ and when none matches, calls at the end FindResourceDataTypePlugin() on the ID of the parameter container, i.e., what you initialized as DA_CONTAINER. When it cannot find anything there, it raises the crit stop.

When you want to have there some OCIO data bundle, you probably should also implement a data type for it. Otherwise you should try DTYPE_SUBCONTAINER. But I am not sure how nicely DTYPE_SUBCONTAINER will play with custom GUIs. In general I would lean towards that writing a container as a singular parameter with a GUI like this is not intended, but you can try your luck. What will work in any case, is implementing your own data type.

And to be verbose, a resource data type is a data type that can be used in resources, i.e., res files.

Cheers,
Ferdinand

Thank you very much @ferdinand for your suggestions—I really appreciate your input and support. I will definitely experiment with your leads and see what works best for me. It’s always helpful to get an outside perspective, and your advice has given me some new things to think about. Thanks again!

Hey,

Please note that both options, a modifier that changes the number of points of its host, and a spline generator that has another spline as an input, are not great. We have internally two cases that do exactly these two things: The bevel deformer and the spline mask spline generator. But third parties do not easily replicate both because they require detailed knowledge of our API and in some cases access to non-public things.

For deformers, Ilia already gave a great explanation. In short, if you are not careful, you can crash Cinema 4D. For the other case, a spline generator which takes another spline as an input, you will run into the issue that splines are not intended to have as objects as inputs. This means you are not getting passed a HierarchyHelp in ObjectData::GetContour with which you could ensure that your child object dependencies are up to date (because by default they are being built after you). There are patterns to solve this, and you run here at worst into the problem of a laggy/malfunctioning plugin and no crashes. But I would still advise going down that rabbit hole when avoidable.

When you really must do this and now want to go down the spline generator road, I would recommend opening a new topic on that before you start.

Cheers,
Ferdinand