Correct here are all the one we expect to fail: bz2 curses gzip lzma zlib As a quick reminder, Python 3.7.7 doesn't officially support M1, and only Python 3.9.1 (released in December does fully support it). Cheers, Maxime.

We found another AA option on Settings, Viewport Hardware, that performs much better than the View Settings Supersampling, probably using a different technique. Thanks.

Ok, clear. Thank you.

Hi, without further feedback, we will consider this thread as solved by Wednesday and flag it accordingly. Cheers, Ferdinand

@gsmetzer said in Adding multiple cameras from a single file to the render queue: My only question: Can you run this script without saving a multiple iterations of the source .c4d file to the OS? Sadly, this is not possible, you are forced to create a c4d file each time. However this is a feature we will tackle in the future, but I can't say when neither give any guarantee. Or, is it possible to delete the source .c4d file iterations upon completion? You can iterate all elements, call GetElementStatus and check for its finish state. If you need help to achieve that please open a new topic. Cheers, Maxime.

Works like a charm! It's much more flexible than I hoped;) Thanks a lot!

Hi @delizade, Thanks @a_block for helping out! @delizade you can find the description for the priority options in the Python Tag section of the user manual. Cheers, Ferdinand

hi, i was saying not to use the same ID (in case of conflict) But it seems that there's no conflict neither with the symbol name or the symbol ID. A bit strange. Cheers, Manuel

Hi, without further feedback, we will consider this thread as solved by Monday and flag it accordingly. Cheers, Ferdinand

@ECHekman said in Compiling material nodegraph to shaders: I take it this also means its not possible to manually convert node ourselves? Right.

well sorry for the misleading. I was thinking it should work because the object is inserted with doc->InsertObject Cheers, Manuel

Hi @kbar I'm able to reproduce the issue and I've opened a new bug report about it. The only workaround is to return a new VolumeObject each time. Cheers, Maxime.

Thank you @m_magalhaes !

@kbar said in Plugin compiled on macOS Catalina for R23, not working on Big Sur?: @fwilleke80 I think setting the hardened runtime when you code sign solves the timestamp issue. I don’t set a timestamp. codesign --force --options runtime --sign 'Developer ID Application: YOURCOMPANYNAME' 'sdk/plugins/yourplugin/yourplugin.xlib' Thanks a lot Kent, for pointing this out! The one below is the string I use which, as said by Kent, doesn't need the timestamp because of the hardened runtime. codesign -f -s "Developer ID Application: <YOUR DEV ID>" --options runtime <binary file>.xlib Documentation updated accordingly

@m_adam Thanks for that extra info. I had done a search in the documentation regarding DrawTexture but didn't see it listed in the API changes. Hence, I didn't expect its behaviour to have changed so drastically. I haven't worked with S22 nor R23 before, so I didn't look in detail about the DrawTexture documentation, since it wasn't listed as changed. May I encourage this to be added in API Changes ... as it is quite a big deal encountering this issue when all worked fine in R16 upto R21.

Hi @pyr, thank you for reaching out to us. I am afraid we will need a little bit more than that, as otherwise it will be very hard to answer your question What kind of plugin do you implement? What does it do or what would you consider as running? On a very abstract level you cannot really prevent plugins from running other than not registering them at the start of the application. But you can of course modify their output depending on basically everything, including render events and at what time offset some given document is. Cheers, Ferdinand

@zipit Thanks, I thought so... but you never know whether some functionality has a hidden internal purpose. Deprecating it will probably be the best solution.

Hi @jochemdk, without further questions or feedback, we will consider this thread as solved by Monday and flag it accordingly. Cheers, Ferdinand

Hi Manuel, thanks for getting back to me! The size of the bitmap you want to display ? It's 320x116 pixels. Do you want to bitmap to scale when you scale the GeDialog ? No. I rather want the dialog to be just wide enough to fit the bitmap in it. And that seems to happen automatically. Even if I open the dialog with a width of e.g. 100 px, it doesn't get any smaller than (width_of_bitmap + strange_gap * 2). Is it possible that it's a macOS-only issue? Maybe it's the radius of the windows' round corners that gets added to the size. Anyway, maybe this issue isn't worth spending more of your time on. Since it works with a ASYNC_POPUPEDIT style dialog, I think I can live with what I got.