BaseLink crash and tracking PolygonObjects/InstanceObjects in cache

ECHekman

Im trying to dynamically track all the objects in the active BaseDocument, including the cached InstanceObjects and BaseObjects that are created by cloner objects.
I have a function that scrapes the BaseDocument contents and keeps a list of all the relevant objects as BaseLinks. This list is updated every time there is a change in the BaseDocument.

This is working very well with most scenes, and I can track all the InstanceObjects and (cached/deformed)PolygonObjects in the scene.
However, I found that in certain scenes, BaseLink::GetLink will crash on PolygonObjects taken from some cloner cache's. I suspect it has something to do with mograph cache?

I also found that pointers to these PolygonObjects that crash GetLink, will work initially, but then suddenly stop working and return 0 on GetType.

Am i doing something wrong here? Or did i find a bug? Are there better ways to do what im trying to do?

m_adam

Hi @ECHekman unfortunately without code I can't see what's wrong so if you can share it it will be appreciated.

However, keep in mind that only the generator is the owner of its cache meaning this generator can decide whenever it wants to rebuild it (even within a thread).

I'm not sure of your final goal, but for render engine, for example, their approach is to have their own scene representation of the current scene and they are doing like:

listen to EVMSG_CHANGE to know when something changed.
traverse the scene, and track new/deleted obj or see if something changed with obj dirty bit.
See Why are GUIDs not Globally unique for keeping track of objects, and Dirty States for dirty bits.
If something changed, retrieve the cache and translate it into their Polygonal Representation
Store this custom copy into their Custom scene Representation.

Finally please for your next topic, use the Cinema 4D category if they are related directly to Cinema 4D development.
Hope this message helps you,
Cheers,
Maxime.

ferdinand

Hi,

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

Cheers,
Ferdinand