Thank you @ferdinand for the help!

Write raw memory does help a lot, appreciate!

Hi,
could you please help me to find out the efficient way of saving/reading an array with a large size of vectors to BaseContainer?

I could store/read each Vector in the array one by one as below, but when the size of the array is large, this method will cause performance issue.

save()
{
    maxon::BaseArray<Vector> arrayData;
    BaseContainer dataBC;
    Int dataCount = arrayData.GetCount();
    dataBC.SetInt32(XX_COUNT, dataCount);
    for (Int idx = 0; idx < dataCount; ++idx)
    {
        dataBC.SetVector(XX_ITEM + idx, positions[idx]);
    }
}
load()
{
    maxon::BaseArray<Vector> arrayData;
    BaseContainer dataBC;

    Int dataCount = dataBC->GetInt32(XX_COUNT, 0);
    arrayData.resize(dataCount);

    for (Int32 idx = 0; idx < dataCount; ++idx)
    {
        arrayData[idx] = dataBC->GetVector(XX_ITEM + idx, Vector(0, 0, 0));
    }
}

Then I remember vertex color tag has a special way of reading the color data stored. So I think C4D supports an efficient way of save/loading large array data.
I tried the below way by storing a raw memory chunk, but it doesn't work. It seems it only stores the memory address rather than the content of the memory address, and I suspect it will have serialize/deserialize problem when the scene file is opened in another platform (operating system).

save()
{
    maxon::BaseArray<Vector> arrayData;
    BaseContainer dataBC;

    Int dataCount = dataBC->GetInt32(XX_COUNT, 0);

    Vector* rawData = NewMem(Vector, arrayData.GetCount()) iferr_return;
    MemCopy((void*)rawData, (void*)arrayData.GetFirst(), Int(sizeof(Vector) * arrayData.GetCount()));
    GeData data(rawData, VOIDVALUE);

    dataBC.SetData(XX_ITEM, data);

    DeleteMem(rawData);
}

load()
{
    maxon::BaseArray<Vector> arrayData;
    Int32 dataCount = dataBC->GetInt32(XX_COUNT, 0);
    arrayData.resize(dataCount);

    const GeData& data = dataBC->GetData(XX_ITEM);
    Vector* rawData = (Vector *)data.GetVoid();
    for (Int32 idx = 0; idx < dataCount; ++idx)
    {
        arrayData[idx] = rawData[idx];
    }
}

So could you please help me to find out the right efficient way of saving/reading an array with a large size of vectors to BaseContainer?

Thank you very much!

@m_adam, Thank you!

Yes, Message(GeListNode* node, Int32 type, void* data) works for me.

I'm wondering shall my plugin just return true after processing MSG_DESCRIPTION_CHECKDRAGANDDROP in the Message() function (set the value of DescriptionCheckDragAndDrop::_result) or still call SUPER::Message(node, type, data); at the end?
It looks to me that calling SUPER::Message(node, type, data); at the end still works.
But the example in MSG_DESCRIPTION_CHECKDRAGANDDROP Message doesn't call SUPER::Message(node, type, data);.

Thanks!

@m_adam, Thank you very much, this works for me!

Hi,
Could you please help me find out how to define the link parameter in res file which only accepts Alembic tag? (And the Alembic tag should also converted from a vertex color tag before the object was backed as Alembic)

I'm developing a plugin, and there is a link parameter, previously, in the res file, I used this to make the parameter only accept a vertex color tag.

LINK xxx { OPEN; ACCEPT { Tvertexcolor; } }

I'd like to change this link to only accept an Alembic tag which is converted from a vertex color tag.
I got the "the Alembic tag which is converted from a vertex color tag" by this:
There is an object with a vertex color tag, then the object is baked as Alembic by using the "Bake as Alembic" menu item popped by right click on the object.
Then the backed Alembic file is imported automatically, and the original vertex color tag will become an Alembic tag.

I tried

LINK xxx { OPEN; ACCEPT { Talembic; } }

However, this somehow broke the res file, and made all other parameters disappear.

LINK xxx { OPEN; ACCEPT { 1036433; } }

By replacing Talembic with 1036433 (this is the value defined for Talembic in cinema.framework/source/ge_prepass.h), it does give me a link parameter accepts Alembic tags (I don't know why the Talembic doesn't work, but the actual number works here), but it doesn't limit to the Alembic tags converted from vertex color tags (i.e. all kinds of Alembic tags are accepted).

Thanks!

Hi,
Could you please help me find out how to read data from a Talembic tag?

There is an object with a vertex color tag, then the object is baked as Alembic by using the "Bake as Alembic" menu item popped by right click on the object.
Then the backed Alembic file is imported automatically. However, the original vertex color tag becomes an Alembic tag.

Can you please help me find out how to read the vertex color data from the new Alembic tag?
Thank you very much!

Thank you very much for all your detailed explanation, @ferdinand!

Thank you, @ferdinand.
No worries at all, I know you must be very busy, just take your time. I appreciate all the help!
Cheers!

The most common "pro" solution to that is caching. E.g., that you write yourself a vertex color cache in your case.

I'm wondering the example you mentioned here, do you mean create a hidden vertex color tag to cache the data?

Thanks for your reply, @ferdinand

Never user pointers to long term keep track of scene elements. Something not being nullptr does not mean you point to valid data. The node you point to could be long deleted, and then you point to garbage and access attempts will then result in access violations and a crash. Either use a BaseLink to store a reference to a scene element, or use a weak pointer. I.e., a pointer which becomes invalid when the pointed data is being deleted. You can for example see here how to use a maxon::WeakRawPtr.

True, I didn't really use the pointer to long term keep track of the linked vertex color tag. Although the plugin remembers the vertex color tag's pointer, but it's just used to compare if the vertex tag link parameter changes. i.e. before reading data from the vertex color tag, the plugin always read the vertex color tag link parameter.

The solution to this can be registering a plugin ID, e.g., ID_FOO_PLUGIN_IS_COMPUTE_PASS. When you then clone your document, or execute the passes on an existing document, you write under that ID for example a bool into the data container of the document. Your tags Execute(tag, ...) then gets the document from tag and checks for that flag being present, to stop what it does that causes the infinite update loop.

Thank you very much, this works! Glad to learn this trick!

You can of course also jump to a previous point, but then you do not have to sim from NOW to FUTURE but from 0 to PREVIOUS

Thanks!

The most common "pro" solution to that is caching.

Yes, the linked vertex color tag's data is cached to avoid reading its data again and again as long as the vertex color tag doesn't change.

And for the question 3) I asked in the previous reply. I found after I use the trick to avoid infinite update loop, the problem is gone, owner of the cloned object is an instance of Opoint again. Do you know what the reason could be?

Thank you!