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

"you are trying to write a node material wrapper for a render engine, right?"
Yes, correct! I am working on node based shading for the 3Delight for Cinema 4d bridge plugin. The reason I want dynamic nodes is to allow using custom OSL shaders, with some metadata to describe the GUI. This allows users to add custom shaders, without having to touch C++. We currently have that implemented for non-node based shaders, and it is a feature I would like to keep.

Thanks for the clarifications regarding the limitations of the XPRESSO-based alternative! It looks like I may have to reconsider using the new Nodes API. I opted for the XPRESSO option mainly because I am more familiar with the classic SDK, but maybe now is the time to take the plunge :-).

Thanks for the response and support!
/Filip

So, I found this thread ("Item selection in GvOperatorData::FillPortsMenu") which suggests that I may need to implement the FillPortsMenu() and iGetPortDescription() functions myself to get this work. I have made some progress, and can now get the elements to show up in the port menu (when I click the top corners of the node in the Xpresso editor), but I have not yet implemented the functionality to actually add the ports to the node. Anyway, the approach seems promising.

Is this the correct way to approach this, or is there a simpler way? I was kind of hoping/expecting that GvOperatorData would behave the same as other plugin types in this regard, and that the ports would be visible in the menu by default - is there such an option?

Best regards
/Filip

Do you need to able to place the "Parent" and "Child" objects anywhere in your scene hierarchy? Otherwise, could one possibility be to make "Child" a generator object, that implements GetVirtualObjects() to generate the desired null objects based on the "parent" object? The "parent" object would need to be placed under the "child" object in the hierarchy, which may or may not be a problem depending on the problem you are trying to solve.

Or do you also need the generated nulls to be editable, i.e., not virtual objects created by a generator?

Best regards
/Filip

I am implementing a custom C++ Xpresso node, where the majority of the parameters/ports are to be generated dynamically via GetDDescription().

The dynamically added elements correctly show up in the attribute manager, but my problem is that they do not show up as ports that can be added to the node in the Xpresso editor.

A minimal example of the GetDDescription() that exhibits this problem looks like this:

Bool NodeTest::GetDDescription(GeListNode * 	node, Description * 	description, DESCFLAGS_DESC & 	flags) {
	if (!description->LoadDescription(node->GetType()))
		return false;

	flags |= DESCFLAGS_DESC::LOADED;

	BaseContainer bc = GetCustomDataTypeDefault(DTYPE_LONG);
	bc.SetInt32(DESC_ANIMATE, DESC_ANIMATE_ON);
	String param_name = String("Dynamic int");
	bc.SetString(DESC_NAME, param_name);
	bc.SetString(DESC_SHORT_NAME, param_name);
	bc.SetBool(DESC_INPORT, true);
	bc.SetBool(DESC_EDITPORT, true);
	description->SetParameter(DescLevel(1000, DTYPE_LONG, 0), bc, DescLevel(ID_GVPORTS));

	return GvOperatorData::GetDDescription(node, description, flags);
}

Here, the "NodeTest" class is derived from GvOperatorData. When I implement a similar version of GetDDescription() for other plugin types, e.g., a BaseShader, the dynamically added element correctly show up both in the active object manager and as Xpresso ports. Also, if I add non-dynamic elements to the "NodeTest" class via a description resource, everything works correctly. It is just for elements added dynamically to the GvOperatorData-derived plugin that I am experiencing this issue.

Any suggestions? Are there any special steps I need to take to make the elements appear as Xpresso ports?

Best regards
/Filip

Great, thanks a lot for looking into this and for the detailed explanations!

Now I know better what my options are! I am marking this thread as "solved".

Best regards
Filip Malmberg

"I will have a look tomorrow how we have solved such things in the past."
-Awesome, thanks!

"But you still did not tell us how you store your node graph. ..."
-The GvNodeMaster is stored as a private member of a BaseMaterial plugin. I have implemented the Read(), Write(), CopyTo() and GetBranchInfo() functions for this BaseMaterial as follows, where "node_master" is the GvNodeMaster member:

Bool DL_NodeMaterial::Read(GeListNode *node, HyperFile *hf, Int32 level) {
	return node_master->ReadObject(hf,true);
}

Bool DL_NodeMaterial::Write(GeListNode *node, HyperFile *hf) {
	return node_master->WriteObject(hf);
}

Bool DL_NodeMaterial::CopyTo(NodeData *dest, GeListNode *snode, GeListNode *dnode, COPYFLAGS flags, AliasTrans *trn) {
	DL_NodeMaterial* dst = (DL_NodeMaterial*)dest;
	return node_master->CopyTo(dst->GetNodeMaster(), flags, trn);
}


Int32 DL_NodeMaterial::GetBranchInfo(GeListNode *node, BranchInfo *info, Int32 max, GETBRANCHINFO flags){
	return node_master->GetBranchInfo(info, max, GETBRANCHINFO::NONE);
}

Out of these, I am mainly unsure about the GetBranchInfo() function, as this is a part of the SDK I have not worked with before. Any input on this part would be greatly appreciated!

/Filip

Making some progress on this! I have registered a custom mode with ActiveObjectManager_RegisterMode(), and wrote a message hook that traverses the nodes in my GvNodeMaster and fills the atom array with the currently active one.

When I select a node in the GvNodeGui of my dialog, and manually set the active object manager to show my custom mode, the attributes of the selected node are correctly shown in the active object manager. So far so good!

A remaining problem, however, is that whenever I click something in the GvNodeGui, the active object manager immediately switches its mode back to "Node", and then the active object manager no longer shows the active node in my dialog!

Is there some way to get around this? I.e. is there some message I could intercept when the user interacts with my dialog, and from there set the active object manager mode to my custom mode?

The context here (as you may have guessed from me mentioning BaseMaterials) is that I'm writing a node editor for a 3rd party render engine, and I would like for the shader nodes to be visible in the active object manager. From what I can tell, the Arnold plugin does show shading nodes in the active object manager in this way from a custom XPRESSO-based dialog, which leads me to believe it should be possible. A fallback approach would be to add a DescriptionCustomGUI to my shader editor dialog, and just show the attributes there (Like Redshift does?), but I would prefer using the active object manager if possible!

Best regards
/Filip

OK, thanks! I will continue looking into this and will post here when I find a good solution for my case.

/Filip

Thanks for the answer! I will look into this and see if it helps!

"I assume you are implementing your own nodes UI from scratch; you are neither using the GraphView (i.e., Xpresso), nor Nodes API? But the entities in your graph are instances of BaseList2D, right?"
No, I am using GraphView/Xpresso! But the GvNodeMaster is not from an Xpresso tag, it is stored in a BaseMaterial plugin. I also have a dialog that displays a GvNodeGUI for this nodemaster, when an item of this BaseMaterial type is selected by the user.

Does this change your answer, i.e., is there an easier way to get a selected GvNode to show up in the attribute manager, even when it does not belong to an Xpresso tag?

Hi,
I have a dialog that displays an XPRESSO style node graph - a NodeGUI, showing a gvnodemaster that is managed by my plugin. This works fine, with one exception: When I select a node in the dialog, it´s attributes are not shown in the object manager.

How can I make that happen? I have looked at the ActiveObjectManager_RegisterMode function, but I can´t seem to get that to work. Any suggestions or relevant examples I could look at?

(I am using the C++ SDK)

Thanks!
/Filip Malmberg