I have moved this into bugs.

Hey @moghurt, no, there is unfortunately not a permanent solution yet, we have talked about it, but nothing concrete has yet happened. But your verbatim statement that RenderDocument does not respect OCIO, is not true. It does, it just a bit complicated to serialize the linear render result into non-linear files on disk or to send them to the picture viewer. Check the Python SDK OCIO Examples for details. Cheers, Ferdinand

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

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

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

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

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.

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

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

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

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.

Thanks a lot @i_mazlov ! The issue is solved !

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

@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!

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.

Thank you for your reply and solution！ Cheers~

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

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

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

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.