addendum, I briefly spoke with the dev:

In SetDParameter, there is code that sets the correct group automatically if force_type or force_type_mode is specified, and the other way around. One thing to keep in mind is that, when you set the parameter force_type_group, the mode is set to default value for that group, i.e., ball and socket for spherical, hinge for angular, slider for linear. This is what you see ig you play in with the dropdown menus in the UI as well. So, if one first sets force_type_mode and then force_type_group, the latter resets the mode to a possibly different value. But in the code snippet attached it looks though like the order is correct (assuming is the actual code used in the plugin).

In a way, I understand that if you are setting mode and group manually from you plugin and you know what you are doing, you are setting a combination that makes sense. But in general, to be extra safe, I decided to go with this solution, so if you change the group the mode is automatically set to something that makes sense. And, btw, also when you set the mode there is a check on the group, and if the values don't match it gets overwritten with the correct group.

so, valid options are:

• simply set force_type (as before)
• set force_type_group and force_type_mode (in this order)
• only set force_type_mode (group set automatically)

If any of these don't give the expected combination it is a bug

I think he too struggled a bit with understanding what you did concretely, so I would recommend creating a bug report as lined out above.

Cheers,
Ferdinand

Hello @yaya,

Thank you for reaching out to us. Although your problem might be related to your old problem for you (as introduced by the connector object changes in 2024.4), I would say this is an entirely new issue. Please open a new thread for a new issue, as lined out in our Support Procedures.

Your problem description is also rather hard to follow, at least for me. I would recommend that you follow the pattern shown in Support Procedures: Examples - Reporting Bugs & Crashes very closely.

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

Hi @Gemini,

In short, @gheyret is correct and the drag&drop feature is mostly used to explore the IDs that stay behind the attributes all across different parts of cinema. You can have a further look into our documentation, namely the Python Console Manual¶ describes this with some details on what to expect to see in the console.

Please note, knowing the correct ID is often not sufficient and you need to explore more, depending on the context of your attribute. For example, in your case the "Render pass file" is an attribute of the "Octane Renderer" videopost data. This is typically out of scope on this forum. However, this topic was tackled not once, e.g.

• Dunhou showed some Octane-specific approach
• Ferdinand showed general approach of accessing render settings

Cheers,
Ilia

Hi @chuanzhen,

Glad you've solved the issue! We're grateful to you for sharing your solution with the community (moreover in such a visual way), this is highly appreciated!

Cheers,
Ilia

Hey @peter_horvath,

So, you do call InstanceObject.GetInstanceMatrices() etc. and construct the clones yourself. That was what confused me in your fist posting, as you talked about 'clones' in 'We'd need this index to be able to export MoGraph attributes to each clone/instance.'

What you effectively want to do, is associate the matrices/colors in an multi InstanceObject with the MoGraph particle IDs they have been created for, right? That is not possible, at least for all cloners which have more than one particle geometry. I briefly talked with the current developer of MoGraph, and he does not see an option either.

I also tried to have a look at the Redshift code base, and as far as I can see, they simply seem to unravel things from the MoData side and mostly ignore the true cache and then end up with the ability to match a clone with its particle index even in Multi Instance mode (that is at least what it looks like to me, I have reached out to one of their devs). In the end I do not see anything particularly bad with this approach, because when syncing scene graphs, you have to reallocate geometry anyway. The problem with this is that MODATA_MATRIX does not reflect the deformed matrix, i.e., it does not respect BaseObject::GetDeformMatrix and with that simulations like for example RBD. I have absolultely no idea how Redshift handles that, I might be misinterpreting their code.

So, long story short, what you want to do, does not seem possible at the moment for externals. But the MoGraph Developer mentioned that we could try to store the InstanceObject::GetInstanceUniqueIP in the MODATA_ALT_INDEX . But we would have to check first that this does not break anything. When you really want this, I would suggest filing a feature request (your Nodes API menu sorting thing is still cooking btw.)

Cheers,
Ferdinand

Hi thanks for contacting us, since you are calling node.GetPath() then use the + operator. This will use the + operator from the NodePath which add \ at the beginning so its not a bug but the expected behavior since it add a new folder.

In your case if you really want to build the string then you need to first build a string and then construct a NodePath from this string like so:

pathPort: maxon.GraphNode = graph.GetNode(maxon.NodePath(str(node.GetPath()) + '<' + str(inTexturePortId)))

Cheers,
Maxime.

Hey @peter_horvath,

Thank you for reaching out to us. I am a little bit confused as I do not truly understand your question. You are an experienced developer, so it seems a bit unlikely that you overlooked what I am explaining next.

In the video below I have unfolded the cache of a MoGraph cloner and switch through the modes, which are admittedly named quite confusingly, but the docs mostly clear up their purpose:

• Instances: Nothing is really being instantiated here at all, there are three copies of the clone geometry in the cache of the cloner. Not the most memory efficient thing in the world when you have many clones. Would probably be better named as Copies.
• Render Instances: Here we have one copy and two instance objects pointing to that copy. So, we pay the price of one original, a the low price of two objects pointing to that one original. Would probably be better named just as Instances.
• Multi-Instances: Again, there are no instances going on here, and also no 'multi' at all. Opposed to the previous modes, this mode only holds a singular object in its cache (wrapped in an additional null) which is a copy of the input. The cloning will only happen at render time (at least that was always what I thought would happen).

So, in the Multi-Instances case, there is neither a cloner nor some geometry where we could store additional information. Because that singular object is cloned just for the renderer. Just to be sure, I looked effectively into what is GetVirtualObjects for the cloner and set breakpoints on all cases where BC_ID_MODATAINDEX is written. As to be expected, Instances writes the indices 0, 1, and 2 on its three copies, Render Instances writes 0, 1, 2 on its one copy and two instances, and Multi-Instances only writes 0 on its one copy because there is nothing other to write into?

What I haven't done here, is looked into how both our viewport and render engine implementations deal with this. I do not see in the object implementation any signal that would tell you that a cache content is Multi-Instances blueprint copy. The only thing which stands out, is that Multi-Instances copies (there can be more than one particle geometry other than in my example) are wrapped into an additional null. You can of course just check the cloner but that strikes me as a bit iffy, but could very well that we handle it like this.

As I wrote in the beginning, I assume you did not overlook all that. And I assume the scene tree you get passed in your render document looks differently, with mock data already being inserted for the "multi-instances"? I would have quite frankly assumed that to be the task of the render engine, but I must be wrong.

Cheers,
Ferdinand

Hi @shurkan,

Welcome to the Maxon developers forum and its community, it is great to have you with us!

Getting Started

Before creating your next postings, we would recommend making yourself accustomed with our forum and support procedures. You did not do anything wrong, we point all new users to these rules.

• Forum Overview: Provides a broad overview of the fundamental structure and rules of this forum, such as the purpose of the different sub-forums or the fact that we will ban users who engage in hate speech or harassment.
• Support Procedures: Provides a more in detail overview of how we provide technical support for APIs here. This topic will tell you how to ask good questions and limits of our technical support.
• Forum Features: Provides an overview of the technical features of this forum, such as Markdown markup or file uploads.

It is strongly recommended to read the first two topics carefully, especially the section Support Procedures: Asking Questions.

About your First Question

Great that you've managed to find the solution yourself! Thank you in advance for sharing it with the community!

Just a short note about your solution is to be careful with threading, namely, in your case it's expected to execute DrawViewes in the following way:

c4d.DrawViews(c4d.DRAWFLAGS_ONLY_ACTIVE_VIEW | c4d.DRAWFLAGS_NO_THREAD | c4d.DRAWFLAGS_STATICBREAK)

Something similar to this topic here: Troubleshooting Safe Frame Calculations Across Different Takes in Cinema 4D

Cheers,
Ilia