Posts made by spedler

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

Hi @skibinvitaliy
There's a few things to watch out for here. First, you will need to include at the very least the file c4d.h from the framework, if this is missing that might account for the undeclared identifiers.

Assuming you're doing that, you must either use the cinema namespace or specifically qualify function declarations etc. If you don't, the compiler won't recognise the C4D functions and objects as valid. The manual explains how to do this, it's not difficult - just an extra step to take which I keep forgetting because it's new to R2025.

The error 'int Bool' redefinition is because what it looks like you're doing there is declaring a variable named 'Bool' to be of type 'int'. But 'Bool' cannot be a variable, it's a variable type (actually a typedef defined by the SDK) so the compiler thinks you are redefining it, which isn't allowed.

These are all just guesses though without seeing any code, but the first thing to look at is the namespace. Catches me out every time.

Steve

Excellent. Glad you got it working okay.

Steve

What I meant was, if your resource files are now named curvaturetools.res/h/str then RegisterTagPlugin() must contain the ‘description’ parameter to be “curvaturetools” not “Tpylookatcamera”.

Steve

@mogh If you are using the same code but just different resource files, did you remember to change the resource name in the RegisterTagPlugin() function?

Steve

@mogh Ah, this is the old symbol cache bug/feature. I'd forgotten about that. With Cinema not running, go into the prefs folder - you can get the location by running Cinema, opening the Preferences dialog, and click 'Open Preferences Folder...'.

In that folder you'll see a file called 'symbolcache', probably with today's date. Delete that file, then run/restart Cinema and all should now work with your revised resource files.

AFAIK this was only a problem with Python plugins, not C++. I've tested this in R19, not R20, but my guess is that it's the same in R20.

(Edit - yes, same in R20.)

Steve

@mogh I think it's unlikely to be anything VS Code does. Millions of people use it and I've never heard of a problem caused by whatever line endings it adds.

Much more likely is an error in the resource files. Earlier versions of Cinema were incredibly sensitive to mistakes in the resource and the stock response is to show that message. Misleadingly, it says the error is in the .res file but it could actually be in the matching .h. or .str files.

The most common errors I find are:

• the name of an element in the .res file doesn't match with any in the .h or.str files, so if you change one you need to change the others
• there's a formatting error in the .res file - a missed semi-colon, comma, or mismatching parentheses or curly braces
• the 'CONTAINER' or 'NAME' strings at the start of the .res file don't match the 'STRINGTABLE' line in the .str file or the line which follows it

There are probably other causes but these are the commonest ones (IMO). If you altered the name of an element .res file of your plugin did you change the .h and .str files to match? And if you did, did you alter the Python source code to use the new name?

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

Hi Ferdinand,

No worries, attached is a zip with the compiled test plugin and a scene file. Just open the file, switch to the material in the AM and check the console for output. The plugin's source is in the previous file I uploaded.

Cheers,
Steve
Attached: LayerShaderTest_Scene.zip

Hi Ferdinand,

There is no scene file worth sending because all I do is add my shader to a layer shader and try to retrieve a pointer to it from the layer shader. So at it's most simple all I would do is create a new standard C4D material (not Redshift or any other renderer) in a blank scene, add a layer shader to the mat's color channel and add my shader as the only layer in that layer shader.

To show what I mean, I've created an absolutely bare-bones shader to reproduce the problem. A zip with source and resource is attached to this post. It should be straightforward to build if anyone wants to do that.

It may be, of course, that what I'm trying to do is not possible. In case you're wondering what exactly I am trying to do, all I want is to discover which channel the instance of the shader is in. This is easy at render time by checking the cd->texflag in the Output function but I couldn't find a way to do it when not rendering. The reason I want to do this is because I want to disable parts of the shader's UI depending on the channel. For example, my shader has a colour gradient which is used in the Color channel but not in the Bump channel. Now, this all works fine if the shader is not in a Layer shader, but if it is I need to traverse the layer shader to find out if my shader is present. But I can't do that because I can't get a pointer to any of the shaders in the layer shader.

(There may well be a better/easier way to do this, in which case I'd really love to know what it is )

Cheers,
Steve
Attached: LayerShaderTest.zip

Hi @ferdinand,

Many thanks for your very helpful comments and code. I've investigated this a bit further and I may have found where the problem lies. This is the slightly modified code snippet:

	while(lslayer != nullptr)
	{
		if (lslayer->GetType() == LayerType::TypeShader)
		{
			if(lslayer->GetParameter(LAYER_S_PARAM_SHADER_LINK, gd) == true)
			{
				if(gd.GetType() == DA_ALIASLINK)
				{
					const BaseLink* link = gd.GetBaseLink();
					if (link != nullptr)

The main difference is that I've added a check for the GeData type. This test always fails: that is, the GeData type returned is not DA_ALIASLINK but a value of 14, which appears to be DA_MISSINGPLUG - a mssing datatype plugin, whatever that means.

Given that, if that check is not carried out and it is assumed that it must be a DA_ALIASLINK (as I did in the previous code) it's not surprising that a nullptr is always returned, in fact it's surprising Cinema doesn't crash . In fact, in the debugger if you manually bypass that GetType() check, Cinema triggers a breakpoint in c4d_gedata.h but it doesn't actually crash.

Unless, again, I've done something wrong this is looking like a bug but it's odd that the Python version works correctly. Should I submit a bug report?

Cheers,
Steve