Hey @Gregor-M,

so, had a look, and it is mostly as I said.

The actual bitmaps saved to disk are the same in your case and correct. The reason why your script produces bitmaps that will look differently in Photoshop or an external image viewer, is because you set the BaseBitmap::COLORPROFILE_INDEX_IMAGE profile to a linear sRGB profile. A manually started rendering will there usually use sRGB2.1. If you wanted to do this correctly, you would have to take the image color profile from the render settings (but since the user will usually have the default value there, this does not really make a difference in most cases):

rd: c4d.BaseContainer = doc.GetActiveRenderData().GetClone().GetData() bmp: c4d.bitmaps.BaseBitmap = c4d.bitmaps.BaseBitmap() bmp.Init(int(rd[c4d.RDATA_XRES]), int(rd[c4d.RDATA_YRES]), 32) bmp.SetColorProfile(rd[c4d.RDATA_IMAGECOLORPROFILE]])

But bitmaps have more than one color profile since OCIO was introduced, they also have a profile for the render space, view transform, and display space. In Python, you cannot yet set these from code yet, as BaseBitmap.Get/SetProfile lacks the index argument there, and you also cannot access these profiles in the document.

After some deep dive into our render pipeline, we found out that this profile data is still incorrectly being copied, the bitmap never gets the correct view transform and display sapce profile assigned.

Independently of this, we implemented OCIO for Python, but it will not yet make it into the upcoming 2025.1 release. There is currently no way for Python API users to fix this on their side. This also impacts C++, and there are some hoops to jump through there too. You cannot just get the view transfrom profile for the view transform for the render document and set that. Because that is the actual trasnform chain, i.e., view transform + display space, e.g., "ACES 1.0 SDR-video + sRGB2.1". Set on the bitmap must be the raw view transform profile, e.g., "ACES 1.0 SDR-video. When someone runs into this, and needs C++ code to do this right now, please drop a note here.

Finally, to reiterate:

This only impacts how images are displayed in the PictureViewer when shown via ShowBitmap. The actual content of the bitmaps is correct. The OCIO profiles of the bitmap are incorrect at the moment (which impacts the Picture Viewer). We will fix this, one of our developers is working on it. But we decided not to do the fix in the SDK (RenderDocument) as the core issue lies deeper within the rendering pipeline.

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.

Hey everyone,

so, I did indeed overlook something here (which I apparently did correctly on MacOS without noticing). Our command line arguments are a bit non standard in that they expect an equal sign between the argument label and value instead of the commonly used whitespace. So, it is -g_encryptPypFile=myfile.pyp and not -g_encryptPypFile myfile.pyp. I have also fixed this in the docs, as this was also incorrect there.

So the full correct syntax would be:

> c4dpy d:\scripts\myscript.py -g_encryptPypFile=d:\plugins\py-commanddata_dialog_r13.pyp

My apologies for the inconvenience,
Ferdinand

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

Dear community,

The core issue of the ABI regression in the connector object has been fixed in the 2024.5.0 SDK Release. The 2024.5 release is again ABI compatible to 2024.0.0 SDK binaries.

Exposing ItemTreeNode and the missing callbacks and messages did not make it into this release (that was also never the plan). This will be done in a future release.

Cheers,
Ferdinand

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

I think it must be a bug ! and I'm surprised I haven't heard anyone talking about this so far, since the "DrawHUDText" is so common for people to use 🤔
I also noticed the same problem happening with "DrawMultipleHUDText".

Thanks!
Flavio Diniz

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()