Hi @thestraycat, I see your frustration but although the topic is still under my radar I can't give an estimation on when it will be addressed. Unfortunately this looks like a regression that has nothing to do with API or plugin development and I can only increase the awareness on the issue.

Rest assured that I'll try to keep you posted upon the discussion.

Best, R

Hi @heilei thanks again for the comment! We'll try, where meaningful, to improve the typography in future releases.

Best, R

Hi @pyxelrigger thanks for the follow-up but actually it doesn't answer to my question of clarifying the final goal.
Explaining a bit better your intent will help us to be more effective in helping, because looking at the code it seems like that you expect to delete items from the scene as soon as their hierarchy is unfolded that's weird without a proper context.

Thanks, Riccardo

Thanks @heilei for reporting.
It will be fixed in a future revision.

Best, R

Hi @adlarch, thanks for reaching out us.

With regard to your issue, I don't understand if it has been solved or not, since the very first post has been deleted and, after, a reply has been left by you in the thread. Can we delete the thread, or can we restore the initial post to give everybody in the community the chance to understand the scope of the second post?

Cheers, Riccardo

Hi @d_schmidt the string I used looking in my bash history is

$ codesign -f -s "Developer ID Application: Riccardo Gigante" --options runtime latticeplane_R20.xlib 

which should be similar to the one you entered.

I've been trying to get R14 plugins notarized, but XCode 4.4.1 doesn't build for 10.9 which is required for notarization. Does this mean its impossible to get R14 plugins loading in Catalina?

Actually I agree with @kbar and I have strong doubts that R14 can run flawlessly on Catalina. I've tested up to R18 and although it loads properly I won't consider running as a stable-proof combination.

Best bet is to support recent revisions (we grant support up to one revision back from the current one) and get advantage of the design opportunities offered by newer system.

Best, R

Hi @d_schmidt, sorry for coming late here.

I've run some additional tests and I've some final considerations to share

• Fresh macOS (10.15)
  • Cinema >= R21 does RUN out of the box
  • Plugin running on Cinema >= R21 does RUN ONLY if notarized
  • Cinema < R21 does NOT RUN being not notarized
  • Plugin running on Cinema < 21 does NOT RUN – independently of being notarized or not – because Cinema doesn’t run (see #1.2);
• Upgraded macOS (from 10.xx to 10.15)
  • Cinema >= R21 does RUN out of the box being it notarized
  • Plugin running on Cinema >= R21:
    • Installed before the upgrade to 10.15: does RUN – independently of being notarized or not – because already existing on the system at the time of the os upgrade;
    • Installed after the upgrade to 10.15: does RUN ONLY if notarized because not existing on the system at the time of the os upgrade;
  • Cinema < R21:
    • Installed before the upgrade to 10.15: does RUN – despite not being notarized – because already existing on the system at the time of the os upgrade;
    • Installed after the upgrade to 10.15: does NOT RUN because not existing on the system at the time of the os upgrade;
  • Plugin running on Cinema < 21:
    • Installed before the upgrade to 10.15: does RUN – independently of being notarized or not – because already existing on the system at the time of the os upgrade;
    • Installed after the upgrade to 10.15: does RUN ONLY if notarized because not existing on the system at the time of the os upgrade;
• Former macOS (< 10.15)
  • Cinema (no matter what version) does RUN – independently of being notarized or not.
  • Plugin running on Cinema (no matter what version) does RUN – independently of being notarized or not.

I've also experienced during the tests, that non-notarized application/plugins can run on Catalina if the quarantine attribute is removed from the Zip archive that contains the application/plugin before unarchiving the application and running it.
Although this is not a recommended workflow, it can be achieved by calling:

$ xattr -d "com.apple.quarantine" <zip file>

Now about notarizing already built plugins: as already mentioned by @kbar it is possible and this afternoon I tried and it went ok.
Before notarizing the zip archive shipping the plugin as described in our documentation, you have to:

1. sign the plugin;
2. enforce the hardened runtime;
3. create the zip archive
4. submit the zip archive to the notarization service
5. wait for Apple to notarize the archive.

In the end steps 1 and 2 are achieved by calling

$ codesign -f -s "Developer ID Application: <Your Name>" --options runtime <xlib file>

whilst the remaining ones are the same reported in the link above.
With this method I've successfully signed and notarized the latticeplane binaries found in the archive on Maxon Labs and made them working on R19 and R20 in Catalina. Finally these additional notes will be added in the documentation.

Cheers, R

Hi @C4DS , maybe I wasn't enough clear.

you end up with a single merged object, which has 2 selection tags, and both still have the specific name ... but none have the added unique ID. Surely you start to think something is really wrong.

Actually you end up in a new mesh with new selection tags which beside having the data copied from the two source selection tags, they are NEW and hence the UniqueID is not supposed to be kept. The names are kept for convenience but I don't see any reason to have also the UniqueID being kept considering that - in the end - they are indeed new instances and have nothing to do with the source selection tags.

Cheers, R

Hi @C4DS, thanks for following up.

One note that it's worthy to share: the outcomes of this thread are valid as long as you need to stick to Classic API. In Maxon API (R20 and higher) you can make very good use of the CustomDataTag (see also GitHub example) whose data merging is managed directly by the modeling kernel.

Last but not least, as usual, if the discussion has come to an end, please don't forget to mark the question as SOLVED.

Cheers, R

Hi @pyxelrigger thanks for following up.

With regard to be informed in the console about a hierarchy in the Object Manager being folder or unfolded, there's no performance-penalty-free solution to be implemented. The only and heavily performance-affecting workaround, would be to monitor each entry of the object manager and check its NBit but, as you can imagine, it's cumbersome and could work only with a very limited number of entries in the scene.

At the same time, I wonder what's the final scope of checking this folded state, cause likely by looking at the problem from a different direction we might come with different, and more effective, solutions. Can you elaborate more on what's the final goal?

Cheers, R