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.

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.

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

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

Thanks for the info! Dan

Hey @peter_horvath, Just as an FYI, you are currently limited by the issues lined out in the video, i.e., you will have to use LoadFile at the moment to get a meaningful particle simulation (or let the document be cloned by RenderDocument). The Simulation team has already fixed that issue, it will be delivered with the next major release of Cinema 4D, i.e., 2025.0.0. In case you want to test that fix, I would recommend moving this discussion over to the beta forum. Cheers, Ferdinand

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.

Hey @baca, feel free to send us a mail to sdk_support(at)maxon(dot)net in case you cannot share code publicly. But we have to have a look at your code to see what is going on. When you say this worked before, we either have a soft regression (you did something which you should not but it somehow worked and we now broke that) or a strong one (we broke something that should work) on our hands. And for that we will need code to see what is going on. And I would not say that the performance penalty is dramatic, it more likely will be neligable. But if everyone would do that everywhere, Cinema 4D would come to a crawl. I would say you can ship your plugin with that "fix" when it does not cause any issues for you. But we should work towards solving this properly. Cheers, Ferdinand

Hey thanks for the report, I indeed fix one issue with the InsertLayer but in your case it was another one, sadly there is no workaround for you (except the one you found). The fix will be provided in the next release. Cheers, Maxime.

Hi Adam, thanks for the update and the workaround!

Awesome, Thank you so much @m_adam ! Cheers and best regards Ben

Hey @JACK0319, thank you for reaching out to us and reporting this. You are right, up is incorrect and upvector is the correct keyword. I fixed this and double checked the other keywords for the next upcoming Python documentation release. Cheers, Ferdinand

@datamilch said in Calling BaseDocument.SetMode twice in a row leads to freezes: always had the feeling, that i could print feedback while it is running That is a misconception many users have. This is because most code usually runs very fast, so you do not realize it. Note that I also wrote Script Manager script. While it technically applies to all Python Scripting scene elements, the execution of the Python VM is there always blocking, it is much more prominent for a Script Manager script. Because there the module is only executed once and it is also okay to run scripts here which take seconds to execute. But it also applies for example to a Python Programming tag, the execution of the module is there also blocking. But because the module of a Python Programming tag is called many times - on each scene update at least once, and you are anyway in a world of hurt when your Python Programming tag module takes more than ~100 ms to run, it is not that obvious there. Syntax errors are evaluated before the VM actually runs because then the compilation of your code into byte code fails (which is then later interpreted by the VM). But the error is here also displayed only after the VM stopped (just as a RuntimeError which is raised by the VM and not by the compiler), but syntax errors prevent the VM from running your code in the first place. Cheers, Ferdinand import time def main() -> None: """Run as a Python Script Manager script to see that the execution of a scope in the Python VM is blocking. This will not print five 'A's with a stride of one second, but five 'A's after five seconds. """ for _ in range(5): print('A') time. Sleep(1) if __name__ == '__main__': main()