Hi again,
Thanks for your input! I have found the solution now:

The issue was not the camera field of view, but how I calculated the bounds of the viewplane (image plane). C4d fits the aspect ratio of the final render resolution into the size of the viewport in a specific way, that I reverse engineered. Here is the code for my solution, in case anyone else has the same problem:

double f=double(resolution[1])/double(resolution[0]);
double f2 =double(renderdata_resolution[1])/double(renderdata_resolution[0]);
double c = f2 / f;

double screen_window[4];
screen_window[0] = -1*c;
screen_window[1]=-f*c;
screen_window[2] = 1*c;
screen_window[3]=f*c;

In the above code, "resolution" is the resolution, in pixels, of the viewport and "renderdata_resolution" is the resolution we would have if rendering to the picture viewer.

/Filip

Hi!
Are there any news on the SDK for node based materials? I'm interested in the following:

• accessing all the nodes in a given material, as well as their connections.
  -creating my own custom nodes.

Are these things possible with the current SDK?

Cheers
/Filip

@WickedP said in Custom register plugin:

I have a dialog plugin with a graphical interface. I'd like to be able to register plugins for my plugin, so that I can build them separately if needed, or perhaps so others in the future may be able to.

Hi WickedP!
We are doing something similar in the 3delightForCinema4D renderer plugin. (source available here: https://gitlab.com/3Delight/3delight-for-cinema-4d/. We have a custom plugin system, separate from the normal c4d one, that allows 3rd party modules to add functionality to our plugin.

This is handled via the "PluginMessage" function. When c4d has loaded, our plugin sends a special message to all other plugins, and passes along a pointer to a "pluginmanager" structure. Other plugins can then respond to this message, and register their plugins via the pluginmanager. You can see how this works in our source code. Some hints on where to look:

The "API" for our plugin system consists of a few header files, describing the supported plugin types (called "hooks" and "translators"):

https://gitlab.com/3Delight/3delight-for-cinema-4d/-/tree/master/3Delight/API/include

Here is the main file of the module that manages plugin loading: https://gitlab.com/3Delight/3delight-for-cinema-4d/-/blob/master/3Delight/source/main.cpp

The "PluginMessage" function in this file is where the message to load custom plugins is sent (in response to "C4DPL_STARTACTIVITY".

Here is the main file of an example separate module that registers a number of plugins:
https://gitlab.com/3Delight/3delight-for-cinema-4d/-/blob/master/3Delight Geometry/source/main.cpp

I hope this description is somewhat clear. We have found it to be a really straightforward but powerful way of designing a custom plugin system for c4d! Let me know if you have any questions.

Best regards
/Filip

Hi @Virtualritz! Nice to see you on this forum. (Filip here, we talked on the 3delight discord)

Hi all! Thanks for your input in this matter.

For now, I have solved my problem by creating the needed resource files from my own code, before I register the plugin using these newly created resource files. This will do for now, although it means I have to ensure that the "res" folder of my plugin has write permission. I will try to solve that in the installer.

"What might be the confusion here is, that you can of course register the same implementation multiple times. But these then would pop up as different plugins in Cinema 4D - which is probably not what @Filip is trying to do. At least from my current understanding."
-This is actually exactly what I am doing! I am registering the same plugin class multiple times, using a different ID. Since the behaviour of the class depends on the ID, this appears to the user to be a series of entirely different shader plugins, which is my intention. The problem was that each such plugin also needed its own unique resource files (to avoid the problem that the resource name has to be unique). But as stated above, I'm solving this by creating the resource files themselves on the fly, whenever they are needed.

I consider this problem solved for now.

Best regards
/Filip

Thanks for the detailed breakdown @ferdinand! Yes, I'm very familiar with how plugins are "usually" registered. Since what I'm trying to do here (registering "auto generated" plugins dynamically) is a bit unusual, I just wanted to check if there was any possible workarounds that I was missing.

Another option I am considering is to write the neccesary description files from to disk from my plugin, and then use them in registration. This would require that my plugin has write access to the directory where the files would be stored. This has to be the "/res" directory of the plugin, right? Is there anyway I could guarantee to have write access there?

/Filip

Thanks for the input @kbar ! That's certainly a possibility, and I believe that is how RSL shaders were handled in the old cineman module. I'll consider this.

/Filip

A possible workaround would be to ask users to create a "dummy" description resource file for every OSL shader they want to load, but since everything else would be handled dynamically it would be a lot more elegant if I was able to use the same resource file for multiple shaders.

/Filip

Hi all!
When registering a shader plugin, the "RegisterShaderPlugin" function has a string parameter naming the resource file that should be used for the shader. The docs say this:

The name has to be unique, i.e. "Tdisplay" cannot be used for 2 different descriptions

For my rendering plugin, I am trying to dynamically create GUI representations for externally stored shaders (compiled OSL shaders), loading all shaders in a given directory. This means that the number of shaders to be created, and their descriptions, is not known at compile time but only at runtime (loaded when c4d starts). The solution I am looking at for this is to register the same shader plugin multiple times, but with different IDs. By associating the ID with a specific OSL-shader file, I can then build the correct GUI, representing the OSL shader, in the GetDDescription function of the shader. This almost works, except for the fact that as soon as I register more than one shader, I get a warning in the c4d console that the same description file is being used more than once, and the description is not loaded.

Since the entire GUI is build in GetDDescription, I would not really need the description resource file at all. Is there any way that I can register a shader without specifying a resource file? E.g., is there any way to have a purely dynamic description?

I am also looking a using the RegisterDescription() function to load the resource file once and then using LoadDescription(id) in GetDDescription to load it. So far, I have not had any luck with this approach.

Any other suggestions?

Thanks!
/Filip

@WickedP said in Custom register plugin:

I have a dialog plugin with a graphical interface. I'd like to be able to register plugins for my plugin, so that I can build them separately if needed, or perhaps so others in the future may be able to.

Hi WickedP!
We are doing something similar in the 3delightForCinema4D renderer plugin. (source available here: https://gitlab.com/3Delight/3delight-for-cinema-4d/. We have a custom plugin system, separate from the normal c4d one, that allows 3rd party modules to add functionality to our plugin.

This is handled via the "PluginMessage" function. When c4d has loaded, our plugin sends a special message to all other plugins, and passes along a pointer to a "pluginmanager" structure. Other plugins can then respond to this message, and register their plugins via the pluginmanager. You can see how this works in our source code. Some hints on where to look:

The "API" for our plugin system consists of a few header files, describing the supported plugin types (called "hooks" and "translators"):

https://gitlab.com/3Delight/3delight-for-cinema-4d/-/tree/master/3Delight/API/include

Here is the main file of the module that manages plugin loading: https://gitlab.com/3Delight/3delight-for-cinema-4d/-/blob/master/3Delight/source/main.cpp

The "PluginMessage" function in this file is where the message to load custom plugins is sent (in response to "C4DPL_STARTACTIVITY".

Here is the main file of an example separate module that registers a number of plugins:
https://gitlab.com/3Delight/3delight-for-cinema-4d/-/blob/master/3Delight Geometry/source/main.cpp

I hope this description is somewhat clear. We have found it to be a really straightforward but powerful way of designing a custom plugin system for c4d! Let me know if you have any questions.

Best regards
/Filip

@r_gigante said in SDK for node based materials, status?:

With regard to your question, we confirm that at the moment there are no news concerning this topic but, again, we are aware of the relevance of the request and it will be delivered accordingly to our product development plan.

Thanks!
On a related note: Is there any statement from MAXON on the future of the old xpresso-style node system?

We are looking to implement a node-system in our plugin, and since API for the new node system is not out yet we may consider using the legacy xpresso API instead. On the other hand, it would not be a good idea to invest resources in this if that part of the SDK might be deprecated and replaced with the new node system.

I realize that you may not be able to provide much info on the roadmap here, but any information that you can give would be super helpful for making this decision!
Cheers
/Filip

Hi!
Are there any news on the SDK for node based materials? I'm interested in the following:

• accessing all the nodes in a given material, as well as their connections.
  -creating my own custom nodes.

Are these things possible with the current SDK?

Cheers
/Filip

Thanks for confirming that this approach looks correct!
"never use NULL to check your pointers against to or to assign it to your pointers: rather prefer using nullptr cause while the first comes from a define the second is a built-in pointer type."
-Thanks, noted!

"with regard to the last implementation, why not using:"
-Because we only want to check the next object (obj=obj->GetNext()) if "inCache" is true. Otherwise, the function would not only check the object passed to the function and its cache, but also all subsequent objects on the same level of the hierarchy.