Bugs

Debugging in VS Code does not pause at breakpoints

idealflaw — Mon, 02 Feb 2026 17:51:39 GMT

Thank you @ferdinand for the warm welcome And thank you for having a look and for the detailed reply! I made sure to read through the posts you linked above and will keep them in mind for the future. I'm really looking forward to being a member of this amazing community 🤩

ObjectData handles - Unexpected position jitter

ferdinand — Thu, 04 Dec 2025 13:07:11 GMT

Good to hear!

The value of 'progress' during the use of RenderDocument() is greater than 1.0

ferdinand — Tue, 21 Oct 2025 01:01:56 GMT

Hey, almost forgot: We have fixed this, an upcoming release will contain the fix . We, however, went with a fix removing the offending call instead of fixing the incorrect progress handler method (which was the issue). So, in other words: The workaround I showed here won't work in future versions, as the number of progress calls will be halved. Before one got two calls per update when rendering with the preview renderer: One for the correctly working image progress update and one for the buggy generic progress update. We have removed the latter. Halving the number of calls is more technically correct, since it made no sense to call the progress hook twice per update but will break any plugins that relied on that incorrect behaviour. Cheers, Ferdinand

ExecutePasses performance keeps slowing down per-frame and per-run — possible cache issue?

ferdinand — Wed, 09 Jul 2025 13:02:35 GMT

Hey, your second code snippet never sets self._result. Regarding loading vs. cloning documents: That I did it how I did it was no accident, but that does not necessarily mean that cloning things is bad. C4DAtom::GetClone is implemented in the different scene elements independently; i.e., BaseObject::GetClone, BaseDocument::GetClone, BaseTag::GetClone, etc. and C4DAtom::GetClone is just the empty implementation. The different implementations then rely on C4DAtom::CopyTo to copy data from the reference into a new instance of that scene element type. On top of that comes that Cinema 4D is largely Copy-on-Write these days, with data actually only being copied when you try to modify it. This all explains why BaseDocument::GetClone is so inexplicably performant, it just copies the metadata and only copies the real payload of the scene when it has to. On top of that comes that cloning from the same document from multiple threads in parallel could entail read-access violations (although somewhat unlikely). On the other hand, our rendering pipeline does exactly the same, it clones documents for rendering (the cloning is however done on the main thread). I personally would say what you are doing is probably okay, but I would not write such code as example code. I would have to spend more time on this to figure out if this is absolutely safe. Doing the actual cloning off-main-thread seems risky though (but is probably also fine in 99,9% of the cases). Cheers, Ferdinand

Userarea keyboard focus issues in 2025.3

ferdinand — Tue, 24 Jun 2025 12:27:55 GMT

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

adding assets to a userdatabase in the assetbrower with Python

m_adam — Thu, 05 Jun 2025 09:46:36 GMT

Hi @wen I've moved your topic to the bug section since it's indeed a bug, I will ping you on this topic once the fix is available, it should come in one of the next update. The issue is that the internal cache is not properly updated and therefor this is failing. With that's said there is a ugly workaround which consist of calling it twice so the cache is properly updated. Find bellow a version that is going to work in all versions import c4d import maxon import os def CreateRepFromUrl(url: maxon.Url) -> maxon.UpdatableAssetRepositoryRef: """Create a new repository from a given database URL. If there is no valid database at the given URL, it creates a database at the URL. It always create a new repository and the associated database asset, even if there are existing repositories for that database. """ # Make type checks if not isinstance(url, maxon.Url): raise TypeError("First argument is not a maxon.Url") # Create a unique identifier for the repository. rid = maxon.AssetInterface.MakeUuid(str(url), True) # Repositories can be composed out of other repositories which are called bases. In this # case no bases are used to construct the repository. But with bases a repository for all # user databases could be constructed for example. bases = maxon.BaseArray(maxon.AssetRepositoryRef) # Create a writable and persistent repository for the database URL. If #_dbUrl would point # to a location where no database has been yet stored, the necessary data would be created. if c4d.GetC4DVersion() < 2025200: try: repository = maxon.AssetInterface.CreateRepositoryFromUrl( rid, maxon.AssetRepositoryTypes.AssetDatabase(), bases, url, True, False, False, None) except Exception as e: repository = maxon.AssetInterface.CreateRepositoryFromUrl( rid, maxon.AssetRepositoryTypes.AssetDatabase(), bases, url, True, False, False, None) else: try: repository = maxon.AssetInterface.CreateRepositoryFromUrl( rid, maxon.AssetRepositoryTypes.AssetDatabase(), bases, url, True, False, False) except Exception as e: repository = maxon.AssetInterface.CreateRepositoryFromUrl( rid, maxon.AssetRepositoryTypes.AssetDatabase(), bases, url, True, False, False) if not repository: raise RuntimeError("Repository construction failed.") return repository if __name__ == '__main__': if not maxon.AssetDataBasesInterface.WaitForDatabaseLoading(): raise RuntimeError("Could not load asset databases.") dbPath = os.path.join(os.path.dirname(os.path.abspath(__file__)), "testdb") print(CreateRepFromUrl(maxon.Url(dbPath))) Cheers, Maxime.

Crash when using C4D shader in Redshift

spedler — Thu, 05 Jun 2025 09:03:52 GMT

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

Weight Manager UI Not Updating Immediately After Locking Joints via API？

Oliver — Tue, 03 Jun 2025 15:28:09 GMT

@ferdinand Got it, thanks for the heads-up!

ImportSymbols with single file didn't return as expect.

ferdinand — Tue, 03 Jun 2025 12:31:15 GMT

FYI: This has been fixed and will be shipped in a future version of Cinema 4D.

Load presets args in python?

Dunhou — Tue, 06 May 2025 05:19:37 GMT

It sounds worth a try, but there may be latency issues when it comes to changes, or data changes can be manually processed during the changes Perhaps for my needs, I can force the database to be use GetSceneRepository, anyway, it's worth a try. Thank you for your guidance

Set RenderData framerate causing C4D to crash

m_adam — Wed, 16 Apr 2025 16:27:56 GMT

Hi I was able to reproduce the issue and fix it for the next version. The bug is that setting RDATA_FRAMERATE require the RenderData to be part of a document in case the "Use Project Frame Rate" is enabled on the render settings. If this is enabled and this is enabled by default the value you enter will be disregarded. "Use Project Frame Rate" is a new setting added in 2025.2. I will ping you once the fix is available. Cheers, Maxime.

c4d.documents.RenderDocument does not apply OCIO Viewtransform

ferdinand — Tue, 04 Mar 2025 10:20:48 GMT

Hey @hSchoenberger, as I said, what we provided is mostly a workaround, we'll have to streamline things. I cannot talk much about the details, since I do not yet know myself how we will solve this. Please open new topics for new questions in the future, especially bug reports should remain clean. Our render pipeline, and that includes commissioning third party renders, converges into a singular point. There are currently four entry points into that pipeline: The built-in commands such as "Render to Picture Viewer", "Render View", "Render Region", etc. For them this pipeline has been built initially. Also headless Cinema 4D instances such as the command line or c4dpy use this mechanism when invoked for a rendering. The c4d.document.BatchRender, uses mostly the same route as (1), but the drawback compared to RenderDocument is that you must always operate with files on disk. I.e., you cannot just change a document im memory and then render it, you must first save it to disk, and also your output will provided on disk and not as bitmaps in memory. As stated before, this is the way I recommend. You should not have to apply an OCIO hacks here, we are at least not aware of any issues. The .net Renderer, a.k.a, Team Render, similar to (2) functionally, just more complicated. And other than for (2), not all third party renderers do support Team Render. RenderDocument differs from these three in that it does not take the full length of our render pipeline, but just a subsection of it. RenderDocument is used internally to render icons and preview images and was never intended to be the 'programmatic rendering interface' it unfortunately has been marketed as and is used as by many third parties. The advantage of RenderDocument is that you can easily operate in memory only without any disk activity. Whenever I was asked in the past, I always told people that using RenderDocument as a render pipeline endpoint is not such a good idea because that is not what it is designed for. Mainly because there are also other short-comings due to it not taking the full route in the render pipeline (animations for example or the render data handling). With OCIO this worsened, as we have intertwined the render pipeline, the Picture Viewer, and saving output to disk even more, i.e., things RenderDocument is naturally left out of. I simply do not know yet how we will fix this, as this is largely not my code. But for me it is clear that this must be simplified in Python. This could either happen in the form of fixing RenderDocument regrading its Picture Viewer and BaseBitmap.Save, i.e., BitmapSaver interactions, or by giving the BatchRender more RenderDocument like qualities. The solution to this will not be super simple, and it will likely not arrive within 2025. For now there is a somewhat functional workaround for RenderDocument and you can always use the BatchRender. Cheers, Ferdinand

Change posemorph's name

m_adam — Thu, 12 Dec 2024 03:19:53 GMT

Hi thanks for the question, I've opened a bug report, for the moment the only workaround would be to remove the Morph and re-add it. For the moment the name in the treeview is only updated when manually edited from the treeview and on the insertion of the item in the tree view. Cheers, Maxime.

Objects are still not displayed after ChangeNBit is works

gheyret — Tue, 10 Dec 2024 16:29:54 GMT

Thank you for your reply and solution！ Cheers~

Python reading fields issue

ferdinand — Fri, 08 Nov 2024 09:09:48 GMT

Yes, we will treat it as a bug. Apparently we implemented it, but then someone disabled the implementation (probably because it caused performance issues or something like that), and then we forgot do follow up on that disabled implementation. Generally we cannot give ETA's for fixes but we try to do them in a timely fashion, i.e., within a couple of minor releases such as 2024.1, 2024.2, 2024.3, etc. I am not the dev here, so I can give even less guarantees. We will update this thread when something blocks us from fixing this in the near future. And yes, it does work in C++. The reason why this is not working in Python is because of the C++ API changes with 2024.0. This link shows how you sample things in C++, the changes revolved around making sampling a field a const operation, i.e., an operation which does not change data on the object. Which was before not the case and now requires that mutable data to be manually passed arround as the extraData as shown in the example. The changes were carried out to speed up the core of Cinema 4D. Cheers, Ferdinand

Compilation of Extended SDK C++ SDK will halt on macOS for SDKs older than 2024.4.0

ferdinand — Tue, 10 Sep 2024 18:18:14 GMT

Hey everyone, I fixed the issue, the legacy SDKs now have again the correct line endings, the downloads have been updated. Cheers, Ferdinand

use thicken generator inside a python generator

datamilch — Wed, 04 Sep 2024 14:15:52 GMT

hi @i_mazlov, ok, good to know. i also tried to insert the thicken generator into a temp_doc, activating the selections and executing passes. but that didn't work either.

How does C4DAtom.GetHDirty(c4d.HDIRTYFLAGS_OBJECT_HIERARCHY) work?

m_adam — Mon, 26 Aug 2024 16:56:53 GMT

Hi just to let you know that the bug has been fixed, this will be available in one of the next releases. I will post on this topic once the fix is available. Cheers, Maxime.

ToolData Linkbox does not retain object when one is dragged in.

BretBays — Mon, 05 Aug 2024 05:03:25 GMT

Blah! Bummer. Seemed like a bug to me. I guess I will just convert this to a CommandData plugin and use GeDialog.

When exporting FBX using c4dpy.exe, there is no texture or material information for the material

i_mazlov — Mon, 05 Aug 2024 02:28:11 GMT

Hi @qq475519905, You issue is likely a bug in the material export code, I've created a ticket (ITEM#530704) in our internal bug tracking system. Thank you for reporting the issue! Cheers, Ilia

c4dpy -g_encryptPypFile fails: cannot find pyp file - plugin registration failed

ezeuz — Fri, 26 Jul 2024 01:19:06 GMT

@ferdinand Wow, thanks a ton for that! Our workflow was working just fine without c4dpy, so I didn't get to check the forum again, but this is very nice. Happy new year!

Volume Builder GetInputObject returns something different?

d_schmidt — Thu, 25 Jul 2024 20:46:00 GMT

Thanks for the info! Dan

3d Connector problem after 2024.4 update

ferdinand — Fri, 14 Jun 2024 12:08:40 GMT

addendum, I briefly spoke with the dev: In SetDParameter, there is code that sets the correct group automatically if force_type or force_type_mode is specified, and the other way around. One thing to keep in mind is that, when you set the parameter force_type_group, the mode is set to default value for that group, i.e., ball and socket for spherical, hinge for angular, slider for linear. This is what you see ig you play in with the dropdown menus in the UI as well. So, if one first sets force_type_mode and then force_type_group, the latter resets the mode to a possibly different value. But in the code snippet attached it looks though like the order is correct (assuming is the actual code used in the plugin). In a way, I understand that if you are setting mode and group manually from you plugin and you know what you are doing, you are setting a combination that makes sense. But in general, to be extra safe, I decided to go with this solution, so if you change the group the mode is automatically set to something that makes sense. And, btw, also when you set the mode there is a check on the group, and if the values don't match it gets overwritten with the correct group. so, valid options are: simply set force_type (as before) set force_type_group and force_type_mode (in this order) only set force_type_mode (group set automatically) If any of these don't give the expected combination it is a bug I think he too struggled a bit with understanding what you did concretely, so I would recommend creating a bug report as lined out above. Cheers, Ferdinand

Updated Redshift node material examples

Dunhou — Tue, 04 Jun 2024 16:28:17 GMT

Hey @ferdinand , Thanks for your answer, unfortunately, the answer is the same as I thought, and I am powerless to do anything about it. I can only wait for the exposed parameters. Based on your suggestion, there may be many issues, and it is not worth spending a lot of time debugging them. Fortunately, this is not a very urgent task. Cheers~ DunHou

2024.4.0 crashes when setting key-values

m_adam — Wed, 22 May 2024 11:32:44 GMT

Hi @ThomasB, sorry for the issue. This is going to be fixed in the next version of Cinema 4D. With that's said you can workaround the issue by using directly SetParameter like so: # key[c4d.ID_CKEY_PRESET] = 2 key.SetParameter(c4d.DescID(c4d.ID_CKEY_PRESET), 2, c4d.DESCFLAGS_SET_NONE) Thanks for the report ! Cheers, Maxime.