Hi Lars, thanks for reaching out to us.

At the moment the latest version of Cineware SDK is 22 and it does not come with arm64 support.

Next version is instead going to support it.

Best, Riccardo

hi @Boony2000 , these are Visual Studio Intellisense errors which you can safely ignore. If they bother you switch the filter from "Build + Intellisense" to "Build".

Cheers, R

Hi @Boony2000, thanks for reaching out to us.

From R20 to R21, as expectable, changes took place in the API which led to adapt R20 examples to be compiled against the newer API. I recommend having a look at Changes in R21 in our documentation and adapt your code or the demo examples consequently if you copied them straightly from R20.

I'm also a bit puzzled by your last reply where you stated that errors were all fixed but you confirm that warnings are still around. Can you clarify what warnings look like? Can you also provide a little bit of context in your code where the warning it's likely to take place?

Thanks, Riccardo

Hi Thomas, I'm sad to confirm that at the moment there is no updated version of ResEdit for R23.

Cheers, Riccardo

@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

Hi @JohnThomas, thanks for reaching out us.

With regard to your question, I confirm that what you see is correct since the deformer provided data is the tessellated representation of the original spline.

Best, Riccardo

Hi @chuanzhen thanks for reaching out us.

With regard to your question, I warmly recommend also thinking of using FindUniqueID and looking at the section BaseList2D Manual::Unique ID or to make good use of BaseLink.

Finally with regard to get the object, either you traverse and compare again the unique ID or, by keeping your BaseLink list updated when add/deletion operations take place, you can look into the list and retrieve desired C4DAtom.

Cheers, R

Hi Roger, thanks for the follow up.

I'm not here to discuss performances comparisons and again if you think there's a bug to report I again suggest the user to communicate with Maxon Support but I think it's fair to compare not only settings but also the final visual appearance.
Looking at the video posted and making screenshots of the different moments I think it's clear that numbers say something but appearance on screen says something different. IMHO it looks like as Maya without AA is more under-sampled than Cinema 4D without anything, as well as Cinema 4D AA-16 looks more over-sampled than Maya AA-16.

Hi roger, thanks for reaching out to us.

With regard to your observation I confirm that the reported behaviour is indeed linear except for the first entry: to give you a measure of the constant performance scale just multiply the pixel supersampling by the fps:

• 2 * 2 * 66 = 264
• 4 * 4 * 16 = 256
• 8 * 8 * 4 = 256
• 16 * 16 * 1 = 256

Finally, if you still think of a performance drop or a bug, please report to https://www.maxon.net/support.

Best, R

Hi @blastframe, I apologize for having left this thread unanswered for such a long time and I hope it still meaningful to you getting answered.

I confirm that Cinema 4D indeed stores such information, but the BaseContainers used are not accessible from the outside and you can't modify their data.

Can you provide us an example to reproduce the lack of consistency you mentioned?

Cheers, R