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

Tried to send the crash report on 6/6/25 at 22:08 but I got a message saying there was a problem sending it. The message also says to send it by email so I've sent it to sdk_support(at)maxon(dot)net.

Steve

Hey @bojidar,

I would suggest that you write a mail about this, so that I can forward it. All I can tell you is that for variadic ports all bets are off. I really ran into this issue when I had to handle variadic ports for graph descriptions.

When you instantiate a node with variadic ports, it usually has some default children. I have never tried what happens when you try to remove all ports (graph description can do this, but they then do not test if the system does not regenerate them). There is also no guarantee that the 1st variadic port has the ID _0. It is just a convention, which is for example directly borken by the Standard Renderer Material node, as it gives its first BSDF layer port the ID 1, and the 2nd manually created layer then the ID _0 (because of course it does):

76bb0bfe-ff1f-4530-a55c-059bc195e46b-image.png
1aa63fb8-e9dc-4e83-80b6-7ffa782752af-image.png

You really have to write a mail here, because this is so deep in the Nodes API internals, it requires a true specialist to answer it.

Cheers,
Ferdinand

Hey @ECHekman,

well, I was talking about User Data, as they can be a nice way to inspect what data types and their custom GUIs can do.

c72e5dab-e512-48cb-8333-95ccee722325-image.png

For what you want to do, this will however not help, as there are only the description settings listed, which necessarily do not have to be all settings there are. To start with an expanded GUI, you must set LAYOUTMODE_MAXIMIZED. I think the little toggle arrows are not supported in dialogs, but I might be wrong. When you want to know more about the little toggle arrow, I would suggest to write us a mail, so that I can forward it to a GUI specialist, as I do not know if and how you could make the arrow work.

This is one of the cases how we internally setup such GUI in a dialog, maybe this already helps (but there are many, and they are not all the same). The a bit odd looking SetInt32('abcd', value)` thing, where we express an Int32 ID as four chars is something we sometimes do internally. Some people find it apparently easier to read/handle than symbols. It often also means that there is no proper integer value and symbol for that ID.

void MyDialog::AddColorAlphaChooser(Int32 id, Int32 flags, Int32 layoutFlags) { BaseContainer colorUISettings = GetCustomDataTypeDefault(DTYPE_COLORA); colorUISettings.SetInt32(CUSTOMGUI_LAYOUTMODE, LAYOUTMODE_MAXIMIZED); colorUISettings.SetInt32('iccc', layoutFlags & (DR_COLORFIELD_ICC_BPTEX | DR_COLORFIELD_ICC_BASEDOC)); colorUISettings.SetInt32('cfld', layoutFlags); AddCustomGui(id, CUSTOMGUI_COLOR, String(), flags, 0, 0, colorUISettings); }

Cheers,
Ferdinand

Hey @felixc4d,

You inheriting from AioReaderRef does not make too much sense. The Maxon API uses interfaces and references. A reference just points to an interface object and increases its reference count, so that the object can be garbage collected once its ref-count reaches zero. References are almost never manually implemented but implemented automatically by the source processor. So, the thing you declare and inherit from is the interface. But that as its name implies, it is actually only the interface and usually is not the actual implementation.

The Maxon API mostly uses components to implement relevant functionalities. Components are elements that are loaded dynamically into interfaces at runtime and effectively realize composition over inheritance. So, you can have a FooRef a and a FooRef b for two FooInterface objects which act completely differently at runtime, because the interfaces have different components loaded which realize them.

I guess you want to override the NotifyForRead function of AioReaderInterface. For that you would have to write a component for AioReaderInterface and then load it at runtime into an object of one of its concrete forms such as NetworkUdpServerInterface. When I look at for example NetworkUdpServerImpl (the component for NetworkUdpServerInterface), you are sort of in luck, as that component has not been marked as final, so you at least technically have the ability to load another component in there without the interface refusing that.

But when you realize a component, you must realize all the MAXON_METHOD methods of the interface the component is for, so you cannot just overwrite that one method. There are way and techniques around this, but then we really reach internal/non-public territory.

I could here into more detail but that is all a bit pointless, because when you do this for NetworkUdpServerInterface and its client counter part, you will just end up again at ReadToBuffer shown above. Because what you have to customize in the end, is the call to the native OS library functions and these are burried deep within our non-public code, so you cannot change that from the outside.

I am afraid you must either use another protocol, you said that TCP worked fine for you, or really implement things yourself. I am also not really convinced that you cannot communicate in chunks of 1kb, as you can split up and reassemble things. Finally, the last option would be to just use a third party library which wraps at least Windows and macOS for you (not sure if you want to support Linux).

Cheers,
Ferdinand

I actually quite like the Apple keyboard, even if Apple’s idea of a UK keyboard is different to everyone else. For example, shift-2 should produce a “ character but on this Apple kit, it’s the @ symbol. The odd key bindings just make it worse, but it’s a nice keyboard.

But I detest the Apple Magic Mouse, I can’t get used to those ‘gestures’. Give me my Logitech trackball any time. A bit of extra software does make a Mac so much more useful though. Pathfinder is way better than the horrible Finder, and BetterZip is very user-friendly.

Thanks for the reply @i_mazlov. Yeah, I already tried the workaround, it worked.