I guess a Python script would do it fine, but I don't use Python. I can write you a quick plugin if that's any use? A plugin would give a few more options than a script I think.

Steve

Hi rui,

Yes, it's a pain in the neck doing macOS development. I almost gave up on it at one point it's such a hassle. But once you figure out all the hoops to jump through, it's not too bad. You might want to take a look at my guide to notarizing a mac plugin on my site at https://microbion.co.uk/html/createplugins_r23_3_notarize.htm. This explains the steps needed; the first step is the Apple developer account, which is what I think the tutorial you read must have been referring to. Unfortunately, unlike an Apple ID, getting a dev account is not free.

Steve

When rebuilding my plugins for R2024, I had to notarize the Mac version again for the new builds. The process worked fine, but I noticed that there was a message from Apple stating that the use of 'altool' to notarize was not going to be supported by the end of 2023.

In fact, they now say "The Apple notary service no longer supports altool from November 1, 2023. You use notarytool instead." See https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

So I looked into using 'notarytool' and surprisingly (for Apple and XCode) it's significantly simpler and faster than the previous method. I've written some notes on how to use it for anyone interested, which are on my site at https://microbion.co.uk/html/r2024macosnotarize.htm

Steve

@m_adam Thanks very much for your comments. You asked which parts of the manual page weren't clear. It's more that it's incomplete, in that it doesn't tell you how to get a bundle ID, app password or provider ID. Also, I don't think the statement that adding a timestamp is optional if you enable the hardended runtime is correct - from what I can see, you must provide a timestamp even though you enable the hardended runtime.

The other thing is that invariably at some point the process is going to fail and there's no mention of what to do when it does. It's extremely frustrating when the notarization fails and you have to figure out why. Apart from that, the page is actually very good - just needs a bit more detail (IMO).

Steve

No problem, give me a couple of days to get an initial test version working. Are you on PC or Mac?

Steve

Take a look at the command line arguments passed to the project tool in your screen shot. The project tool is looking in the wrong place.

Steve

Hi Bjorn,

I have a working version of this now which you can download from my site at https://microbion.co.uk/files/rounditr2024.zip

It's PC-only at the moment and requires C4D R2024. Try this and see if it does what you need. There's some basic documentation included which I'll tidy up for the final version.

There doesn't seem to be a DM facility here so we'd better take any further discussion to email. You can get hold of through the contact page on my site (link is in the PDF in the zip file). Do let me know what you think.

Cheers,
Steve

In C++ - I expect it's the same in Python - I would call GeGetPluginPath() to find the absolute path to the plugin, then append the filename to that path. This should work no matter where the user has installed your plugin.

Steve

@kmhfygg I must admit it isn't entirely clear what you are asking for. Since you have developed your plugin already, you are not asking for a licence for C4D itself. And since it's a free plugin, you don't need to licence it to other users.

I'm guessing that you need a plugin ID number, which makes your plugin unique and distinguished from all other plugins. To get that, go to the 'Support' menu at the top of the page, choose 'Plugin IDs' and follow the procedure to receive a new and unique ID number. You need to do that for every plugin you develop and intend to release.

Steve

Hi @ferdinand,

No problem, I got there in the end and it's actually not too tricky once you know how it's supposed to work. I'll have a go now at a material node, there are more examples of those so hopefully it'll be straightforward. I'll be sure to be back if it isn't!

In the meantime I've uploaded a detailed explanation of all the steps needed to build this kind of node to my site at https://www.microbion.co.uk/html/create_nodes_corenode1.htm so if anyone wants to see how it was done, it's all there. Hopefully it's fairly accurate; all I can say is that this is what I did and it worked for me

Thanks again for your help,

Cheers,
Steve

Unfortunately not (in my case) because my MacBook is too old to run Ventura. This means I can only build macOS plugins for R2024 or earlier, because I can’t run R2025 on my Mac (requires Ventura to run). Therefore, I’ve made the decision not to build my plugins for R2025 on macOS until/unless I can afford to buy a newer Mac. It just isn’t worth it for free plugins. If I had a newer Mac I would almost certainly do as you suggest; I’ve done it before with older macOS versions.

Why not just use a BaseArray of the data structures you want to use? Re-initialise this every time InitRender is called then you can iterate through it when needed (presumably in the Output function?).

You’ll also need to implement CopyTo() to make sure the data is available when rendering to the picture viewer.

Steve

Just to note for info, the SDK docs for 2025 have a page for notarizing a Mac plugin. However, it still refers to using 'xcrun altool ...' but as I have just discovered, the use of altool has been discontinued and you must use 'xcrun notarytool ...' instead. The command line is almost the same but slightly different if you don't use a keychain profile but enter your Apple ID, app-specific password, and team ID separately.

Thought I'd mention it so the page can be corrected (in all that wonderful free time I'm sure you have!).

Steve

That’s a very useful site, thank you. I already have Xcode 13.4 installed but I don’t know if it will still be available after upgrading the OS to Ventura. If not, I can get it from there and reinstall.

Hi @ferdinand,

Yes, I've seen those hacks needed to run Xcode 13 on Ventura. TBH, I think while Macs are lovely machines, Xcode as a dev tool is a pig, even more so if you can't match Xcode versions with the OS version, as here.

I'll try installing Ventura then seeing what happens when running Xcode 13 in the way you suggest, but it's getting to the point where supporting macOS for freebie plugins just isn't worth the time and effort required. I'd be interested to hear what the techs say about this. There's an interesting page on Stack Overflow about it.

Cheers,
Steve

Thanks Ferdinand. There's still my point about macOS. If Xcode 13 is required for R2025 development, this won't run on Ventura (macOS 13), but C4D R2025 won't install on Monterey (macOS 12). How do we square this circle? Can Xcode 14 be used for R2024 development?

Cheers,
Steve

The latest C++ SDK docs don't state the dev environment for C4D 2025, only for 2024. For Windows, I have rebuilt plugins for 2025 using VS2019 and it works fine, but the Mac is more complex (inevitably). My MacBook runs macOS 12 (Monterey) with Xcode 13, but when I tried to install Cinema on it, I get an error saying that it requires macOS 13.6 or later (Ventura). However, if I install Ventura, it seems that Xcode 13 won't run on that, and Xcode 14 is required. But if I do that, will I be able to build plugins for R2024 using Xcode 14? Because if not, that raises the annoying prospect of having to maintain two separate versions of macOS and Xcode if I want to support both R2024 and R2025.

Some guidance on this would be very helpful.

Cheers,
Steve

Hi Ferdinand,

That’s great, really very helpful, thank you. I’m glad my code was right in principle even if it didn’t work! I would never have guessed the layer returned a void pointer. That should now work perfectly and do exactly what I need.

Thanks again for taking the time to look into this, very much appreciated.

Cheers,
Steve

Hi Ferdinand,

No worries, I know you must be very busy. The shader works in itself, it’s just that I’d like to tidy the interface to avoid confusing users. Whenever you have some time to look at it is fine.

Cheers,
Steve

Just one small correction - the returned value of 14 when GeData::GetType() is called equates to DA_VOID, not DA_MISSINGPLUG. My mistake, sorry about that. That value makes a bit more sense; still fails though

Steve