GvOperatorData, GetDDescription() problems

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

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

ferdinand

Hello @Filip,

Thank you for reaching out to us. In short, yes, you are on the right track, but you are also in unsupported territories. The thread you found there contains correct information but is also quite old. GvOperatorData effectively always has been a semi-private interface and while we can help people over some minor bumps with it, the forum is not the right place to discuss in detail one of the most complex cases: a node with dynamically allocated ports.

When I understood you correctly, you are trying to write a node material wrapper for a render engine, right? I would generally recommend to use the Nodes API as it is the actively developed and supported technology for that. For the case of wrapping render engines, we also have quite extensive examples. When you insist on using the GraphView API, I would suggest reaching out to us via our contact form (the icon in the menu bar of this page), lining out what you want to do, so that we can evaluate custom support options.

I must also point out that we cannot consider customized support options if you are not working on a commercial project. We would have to ask you to use then the Nodes API instead.

Cheers,
Ferdinand

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

ferdinand

Hey @Filip,

Good to hear, but I would still recommend reaching out to us via the contact form. I have already checked when this topic chain started, but you do not seem to be a Maxon Registered Developer, right? At least I could not find your e-mail handle from this forum and the name implied by it in our databases.

For developing a render engine binding, I would strongly recommend considering signing onto the MRD[URL-REMOVED] program as it will allow for a more direct information flow between you and us.

PS: This is a non-commercial project, right? Being non-commercial is not necessarily an exclusion factor for MRD, but it is for the other route: source code sharing. I.e. you would keep using the GraphView API and you request a source-code sharing for example for the object node which does that dynamic ports thing you want to do.

Cheers,
Ferdinand

[URL-REMOVED] @maxon: This section contained a non-resolving link which has been removed.

jana

Hello @Filip ,

without further questions or postings, we will consider this topic as solved by Friday, the 11th of august 2023 and flag it accordingly.

Thank you for your understanding,
Maxon SDK Group