Topics created by ECHekman

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