MoGraph data index and Multi-Instances

[peter_horvath]

When using a MoGraph Cloner in Instance or Render Instance mode, the MoGraph data index is available via the BC_ID_MODATAINDEX id in each clone.

clone->GetDataInstance()->GetInt32(BC_ID_MODATAINDEX);

This is the index of the clone in the data arrays of the MoGraph Data tag.

Is this index available in Multi-Instance mode as well via the SDK? Via the InstanceObject maybe?
We'd need this index to be able to export MoGraph attributes to each clone/instance.

[ferdinand]

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

[peter_horvath]

Hi Ferdinand,

Thanks for your feedback, Yes, I'm aware of the object structure. Let me explain a bit more what I'm trying to do and what I'm missing.

Here's a simple example of a Cloner with two shapes, a Sphere and a Torus, and a Plain Effector with a Spherical Field. The effector sets the weight of the clones (1 to zero from the middle) and also modifies the shape order ("Modify Clone" is enabled), so that Torus shapes are in the middle and Spheres are outside the field. So the shape order is not necessarily the same as how the data is stored on the mograph tag. I'd like to export weight as user data per shape. In Instance or Render Instance mode I can read the mograph data index from the clones, that tells me the weight from the MoData tag.

In Multi-Instance mode, I would expect the same result. However, since the indexes are not available, I can not connect the MoGraph data to the instances and read the weights. As you said, in Multi-Instance mode there are reference shapes and Instance Objects per each reference shape in the cache. The InstanceObject can return the matrices and colors of the individual shape instances, but no indexes as far as I can see. I'm not sure how complicated is to generate this data, but would be nice to have.

Cheers,
Peter

[ferdinand]

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

[peter_horvath]

Hi Ferdinand,

Thank you, I will consider different approaches based on your reply and might file a feature request as you suggested if I can't find any solution.

Thanks,
Peter