Topics created by ECHekman

Hey,

it seems I was a bit too tightlipped here. So in more verbose: You cannot customize the chosen unit of a parameter. This is impossible as this is a globally set value (which is also just smoke and mirrors as explained in the link above). There is a UnitScale custom GUI but it does not what you want, it is the field used in the document settings and is not really meant to store a value and unit but just a unit.

image.png

When you really-really-really want this, you can implement you own custom GUI, either targeting your own custom data types or existing data types. There you could then do whatever you want. But that might not mesh so well with the rest of Cinema 4D, given that Cinema 4D does not operate like that.

Cheers,
Ferdinand

Hey @ECHekman,

thank you for reaching out to us. This GUI does not support any of these flags (DESC_DEFAULT, i.e., DEFAULT is also not for gadgets but groups).

This means that you cannot toggle the collapsed state of a link box (be it a normal one or a texture one) by setting a description flag either in a resource file or programmatically. Which makes sense, because other than for example a color field or a group, a link box is not guaranteed to have content which could be unfolded.

Cheers,
Ferdinand

Hi,
yes, this is expected, and documented in NodeData::Read() / NodeData::Write() Manual. With that's said Read/Write is supposed to serialize data of your object (most of the time member variable) to the c4d file (the HyperFile), so accessing the BaseDocument is a sign of a bad design.

May I ask why do you really want to access the BaseDocument in the Read function?

Cheers,
Maxime

edit (@ferdinand): Just to be clear here, as we briefly talked about this in our morning meeting, what the docs write there is in a certain sense legacy information. When a branch, e.g., the Xbase (shader) branch of a material is being deserialized, the to be deserialized node is inserted into the branch and with that will have access to a document.

But what @m_adam wrote is of course true, the document in this context is the fruit from the forbidden tree, as the node is not yet fully deserialized and certain parts of the GeListHead::Read, GeListNode::Read, BaseList2D::Read, ..., YourPluginLayer::Read deserialization chain might pull all sorts of tricks to carry out the deserialization, including temporarily removing the node from the scene graph.

The documentation is therefore effectively still correct, as deserializing a node should never rely on the document context and accessing the document is forbidden in that context.

Thanks for your response. We found the issue. Turns out we had to delay load our dlls for earlier versions of the plugin R21 etc

Hey @ECHekman,

I assume you are looking here for some kind of approval from my side? That looks fine, but it is hard to give a concrete assessment with mock code. But as lined out above, there is little which can go wrong here. Splitting up your data into sub-containers could help with access times when you plan to add lots of 'attributes' and 'pins'. So, it is good that you do that. And shifting your application IDs into lower ranges for Cinema 4D is probably not technically necessary but will lead to more 'natural' IDs. I cannot really see much going wrong here.

The only thing which is not so nice, is the unsafe C-style cast in BaseContainer *data = ((BaseShader*)node)->GetDataInstance();. We recommend using static_cast for safe casts and reinterpret_cast for casts which are explicitly meant to be unsafe.

Cheers,
Ferdinand

Hello @ECHekman,

Thank you for reaching out to us. When you run into compiler errors, you should always include them, because how should we otherwise help you? Sure, I could throw your code into our code base, guess some things, and then try to compile it, but the guessing and compiling is unnecessary and makes our answers more imprecise.

But this should work:

iferr_scope; maxon::String myString = "Hello/World"_s; maxon::BaseArray<maxon::String> parts; // could also be const myString.Split("/"_s, true, parts) iferr_return; if (MAXON_UNLIKELY(parts.GetCount() < 1)) return maxon::IllegalStateError(MAXON_SOURCE_LOCATION, "Splitting path failed."_s);

FYI: There is also UrlInterface::GetComponents.

Cheers,
Ferdinand

Hey @ECHekman,

COLORA and VECTOR4D are both Maxon datatypes. For how to deal with custom data types, you can have a look at this. But since this is a maxon data type and not a cinema data type, you cannot use a static_cast. When you do not want to store your maxon data wrapped as data, the only thing which remains is unsafely casting the data (but our style guide recommends using reinterpret_cast to make the unsafe nature obvious).

const maxon::ColorA* myColor = reinterpret_cast<const maxon::ColorA*>(geData.GetCustomDataTypeI(DTYPE_COLORA));

I had a look and we do this in some UI related places too, so this might be a side effect of the 2024 changes to data types in relation to that specific custom gui.

Cheers,
Ferdinand

Ok thanks for the help Ferdinand. I will take the road of least resistance and just build on top of float64 vectors

Hey @bojidar,

well, we do not write these object views (the natvis for MSVC and the Python scripts for Xcode) for public usage but for internal usage. That we hand them out to third parties is just a courtesy. When we are looking at maxon::GraphNode,

<Type Name="maxon::GraphNode"> <DisplayString Condition="_mem[0] != 0">{((maxon::NodePath*)&amp;_mem[0]),na}</DisplayString> <!-- Root will have empty path and valid graph --> <DisplayString Condition="_mem[0] == 0 &amp;&amp; _graph._object != 0">Root</DisplayString> <DisplayString Condition="_mem[0] == 0">nullptr</DisplayString> <Expand> <Item Name="Path">(((maxon::NodePath*)&amp;_mem[0])),na</Item> <Item Name="Kind" Condition="_mem[0] != 0 &amp;&amp; _graph._object != 0">(maxon::NODE_KIND)((((nodes.module.xdl64!maxon::nodes::NodePathImpl::CountAndKind*) &amp; (*(nodes.module.xdl64!maxon::nodes::NodePathImpl**) &amp; _mem[0])->_path))->kind &amp; 0xFF)</Item> <Item Name="Kind" Condition="_mem[0] == 0 &amp;&amp; _graph._object != 0">maxon::NODE_KIND::NONE</Item> <Item Name="Info">((nodes.module.xdl64!maxon::nodes::NodesGraphModelImpl::Info*)this->_mem),na</Item> <Item Name="Graph">(this->_graph)</Item> <Item Name="Graph Storage">(this->_mem)</Item> </Expand> </Type>

then there are indeed quite a few references to the implementation (which means that this cannot work in the public API). You could rip these out to make it work, but would then be left with only a small subset of the debug attributes. But that would be up to you.

In general, you can expect the Cinema API to be more conservative and almost all object views working there, while the Maxon API is generally more internal in nature.

Cheers,
Ferdinand

As I said, you will run into access violations when you instantiate your fields on the class instead of the Init function. And as I also said, in your concrete case it would probably even be fine if you would directly do it in the class scope. But I would advise against breaking this rule. There is nothing to optimize here, either return a new instance when this is only called once in a blue moon and you do not want to bother with initializing a field. Or define a field and initialize it up in NodeData::Init. And no, scene elements (NodeData) should not share data on their class. We have types in the Maxon API to deal with this when you really want some heavy data structure which shall be initialized exactly once, but that is total overkill in this case.

Cheers,
Ferdinand

@ECHekman said in Compiling material nodegraph to shaders:

I take it this also means its not possible to manually convert node ourselves?

Right.

Hi,

without further feedback, we will consider this thread as solved by Monday and flag it accordingly.

Cheers,
Ferdinand

Hi,

without further feedback, we will consider this thread as solved by tomorrow and flag it accordingly.

Cheers,
Ferdinand