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
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 @ferdinand
Thanks, I’ll submit a crash report as soon as I can. The power keeps going on and off here, when it’s restored I’ll send one in.
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
Tried to send the crash report on 6/6/25 at 22:08 but I got a message saying there was a problem sending it. The message also says to send it by email so I've sent it to sdk_support(at)maxon(dot)net.
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
Tried to send the crash report on 6/6/25 at 22:08 but I got a message saying there was a problem sending it. The message also says to send it by email so I've sent it to sdk_support(at)maxon(dot)net.
Steve
Hi @ferdinand
Thanks, I’ll submit a crash report as soon as I can. The power keeps going on and off here, when it’s restored I’ll send one in.
Steve
Hi @ferdinand
Firstly, many thanks for looking at this. The plugin ID is a silly mistake on my part (I didn't realise that VS had auto-completed with the wrong ID). It should be ID_RSC4DSHADER (not IDS...) in the register function. If you look in rsc4dshader.h, you'll see it correctly identified with a valid plugin ID there. I was in a bit of a hurry building this and didn't realise what had happened. I'm surprised it ran at all TBH!
The SDK version was 2024.5.1 (Build 2024_5_ac4bc44383e4_1378804312). Isn't this a newer SDK than 2024.4.0, not an older one?
I can get the crash in 2024 but I've tried now in 2025.2.1 and it doesn't crash, so possibly whatever it is was fixed. I've also tried several other of my shader plugins in 2024 and they all exhibit the same issue, crash in 2024 but not in 2025.
Cheers,
Steve
Hi,
I've written several shaders which I also use in Redshift using the C4D Shader material. I get a consistent crash in the following circumstances:
The crash occurs in customgui_gradient.cpp at line 59, which is:
maxon::Result<maxon::GradientRenderData> Gradient::PrepareRenderData(const InitRenderStruct &irs) const
{
GradientCallRC(maxon::UnexpectedError(MAXON_SOURCE_LOCATION, "Gradient::PrepareRenderData() not found."_s), PrepareRenderData)(irs);
}
It happens in all the shaders I've written which use a gradient. It looks as if scrubbing the knot forces Redshift to repeatedly bake the shader and doesn't like it for some reason, but that is just a guess.
To demonstrate this, I've written a very basic shader plugin - it just draws a red-blue gradient over the surface. The attached file has the source and a debug version of the shader built with the R2024 SDK. To see it, load the included example file, then scrub one of the knots in the gradient, increasing the texture parameter size until it crashes.
I should also mention that this does not happen in the standard renderer.
Cheers,
Steve
RSC4DShader.zip
I actually quite like the Apple keyboard, even if Apple’s idea of a UK keyboard is different to everyone else. For example, shift-2 should produce a “ character but on this Apple kit, it’s the @ symbol. The odd key bindings just make it worse, but it’s a nice keyboard.
But I detest the Apple Magic Mouse, I can’t get used to those ‘gestures’. Give me my Logitech trackball any time. A bit of extra software does make a Mac so much more useful though. Pathfinder is way better than the horrible Finder, and BetterZip is very user-friendly.
Ouch. I've never had that happen with VS, but I've had Xcode refuse to build for all sorts of reasons, all of which VS happily ignores. I have to say that building on this Mac mini compared to my old MacBook is a revelation though - so much faster, and the screen is way bigger. That said, I still prefer VS, it just seems easier to use. Xcode really is painful, and as you say, Apple clearly enjoy that.
Yes, that Xcode download site is extremely useful!
Cheers,
Steve
Well, for the benefit of anyone else in this position, I finally got it working. There was another problem in that Xcode 15.3 won't install on macOS Sequoia; you can apparently make it run with a small hack, but in the end it was easier to uninstall Xcode 16.3 and install 16.2 instead. Then it works fine and builds the SDK without incident.
On a side note: why do Apple make life so ^&%&^$^^(* difficult for developers?
Thanks again Ferdinand,
Steve
Hi @ferdinand,
Many thanks for this. It shouldn’t be a problem using an older version of Xcode for the time bring. I’ll get version 15.3 and give it another try.
Cheers,
Steve
I've tried for the first time to build the SDK C++ examples on MacOS and have run into a problem. I'm using a new Mac mini with Sequoia 15.4.1, Xcode 16.3, CMake 4.02 and Python 3.13. I've followed the procedure in the SDK docs and everything appears fine until I try to build the examples, when it fails with this error in interfacebase.h:
/Users/steve/Documents/C4DPlugins/C4D_2025/frameworks/core.framework/source/maxon/interfacebase.h:638:73 A template argument list is expected after a name prefixed by the template keyword
I have no idea what to do about that. The examples build fine on Windows but (as usual) Xcode throws up some sort of problem. Could I have done something wrong or is this an issue in the SDK code?
Thanks,
Steve
The green tick/red cross only indicates if an object is enabled or not. You can see it with deformers, fields, primitives (which are generators anyway), other generators such as the cloner or extrude, etc. The tick does NOT show that the object is a generator. You only see it with objects whose actions can be enabled or disabled, so you won't see it with polygon objects or things such as the floor object.
To get the status of the green tick for objects which have it, use GetDeformMode().
(Edit) I've never used it, but if you call obj.GetInfo() and test for the flag OBJECT_HASDEFORMMODE, if that flag is present then it seems that the object does have the green tick. This could be useful when looking at objects which aren't generators, etc. but still have that tick.
Steve