Solved SceneHook and object caches

@ferdinand
I have been playing with your script to walk the cache of different hierarchy scenarios I have built.
I now have a better understanding of what to expect from the GetCache and GetDeformCache.
However, I am still missing one bit of information.

For purpose of explanation, let's assume the main idea is to draw a line from the first point of an object to the first point of the "modified" object.
Where modification is done via a deformer or subdivision surface, or combination of both.
To draw that line I thus need the coordinates of the "original" object, and the coordinates of the modified one.

Scenario1:

+ Sphere (active)
  + Twist

Assume I have a polygon object "Sphere", and a Twist deformer as child.
I can get the deformcache from Sphere, perform a DoRecursion to obtain the deformed polygon object, and access its points.

Scenario2:

+ Subdivision Surface
   + Cube (active)

Here I get the cache of the subdivision surface and perform a DoRecursion to get obtain the "deformed" polygon object. Using the term "deformed object" might be a bit misleading, so let's use "generated object" instead.

In both scenarios I could then draw the line from the original coordinate to the modified coordinate.

Now, let's assume I have an option (checkbox):

• when checkbox on, I want to only draw the line when the object is active (=selected in OM)
• when checkbox off, the line is always drawn, independent of the active state of the object

In both scenarios the BIT_ACTIVE flag is only set on the original object. In both cache as in deformcache the flag is always false.
However, in case of scenario 1, I can perform a GetCacheParent on the obtained modified object, which will give me the original object, from which I can check the BIT_ACTIVE.
In case of scenario 2, performing a GetCacheParent will get me the Subdivision Surface.

How to have a common solution to find out if the original object of a cached object (from GetCache or from GetDeformCache) is active?

Hi @C4DS,

well, in scenario two the sds IS your cache parent, so this is kind of to be expected. I understand your line of thinking, that the Cube is somehow the meat of this of this generator/input object pair, but in the end it is just another scenario than a deformer deformed object pair. You said it yourself, deformation is not the right term for SDS.

Anyways, we will talk about it on Monday and someone else or maybe I have a light-bulb moment then. But for now I do not see a built in functionality to do that (you can of course cobble your own logic together by fetching the control-objects, but this probably going to be a bit messy).

Have a nice weekend and cheers,
Ferdinand

@ferdinand said in SceneHook and object caches:

well, in scenario two the sds IS your cache parent, so this is kind of to be expected

Yes, indeed. I didn't want to imply that was not the expected cache parent.
I only meant to say that going that route I wasn't able to reach the input object, to get it's active state.

Correct, building my own logic will quickly turn into something messy, but I am afraid there isn't another way.
I 'll think about it some more ... have a nice weekend.

I spent some time looking for a way to obtain the cache of a particular object.
Not sure if this will work for every possible scenario, but for now I am trying following concept:

1. start from the selected (input) object
2. traverse the scene up, doing so I built up a "tree-address" for the object, and keep track of the parent-most Subdivision Surface.
3. I get the cache of the parent-most SDS, and traverse the cache tree down, using the obtained tree-address to reach the cache object.

This technique will probably fail when a generator, like cloner/array/... is located in the tree between SDS and input object. Since then the tree address of the input will not match with the tree of the cache.

The other issue is that when selecting polygons/edges/points on the input object the cache doesn't get rebuilt ... so if the goal is to do something with selected and unselected polygons/edges/points the cache doesn't get updated with the change of selection of the input object.

Hi @C4DS,

so we talked a bit about it and there is unfortunately no way to do this with built in functionalities of the SDK. I do not fully understand your solution in all detail, but you seem to have to come to the right conclusion that this will have its limits for array-like generators where the caches can get very complex. This ambiguity of what is then "original" is ultimately also why Cinema does/can not offer this functionality.

I cannot tell you anymore than that and depending on what you are trying to do, a general shift of design might be necessary when you run into major problems.

Cheers,
Ferdinand

@ferdinand said in SceneHook and object caches:

so we talked a bit about it and there is unfortunately no way to do this ...

Thanks for having taken the time to further investigate and discuss.

... depending on what you are trying to do, a general shift of design might be necessary when you run into major problems.

I wouldn't mind a shift of design, unfortunately at this point in time I am out of ideas how to proceed.
Maybe I am too focused on trying to reach my goal using the available cache. If there would be any other possibility to obtain the information I need to use ... I am all ears.

The goal I am trying to reach might have been lost with all the technical details, so let me recap it with an example here:
Let's say I have a regular polygon cube with 6 faces, 8 points.
I put this cube into a subdivision-surface, resulting in the cube being smoothed, modifying the points' coordinates.
What I would like to achieve is to know the modified coordinates of the 8 points.

So, traversing the cache of the SDS and getting the particular cached object is one thing ...
But since the SDS will subdivide the input object, the resulting cube (in the cache) will have more than 6 faces, 8 points.
Second step is then to find out which original point index matches which point index in the modified object.

Cinema4D does seem to have a way to know that relation.
With the example of the cube under an SDS, enable islone editing, switch to point mode and select any of the 8 points of the cube.
Cinema4D will display to original point as selected, but also the modified point.
The one point has the original coordinates, the other has the modified coordinates.

My goal is thus to find a similar way to obtain the modified coordinates of a point.

Hi @C4DS,

sorry, I was probably a bit cryptic when I talked about a "shift in design". The reason why I was so cryptic is that such design decisions formally fall out of the scope of support (see Forum Guidelines: Scope of Support). It is not because we are lazy, but such decisions often come with a certain vagueness and uncertainty which makes is either very hard or impossible to give reliable answers. So please take my following ideas with a grain of salt.

I would look at it from the standpoint of reducing complexity. The major problems seems to be the ambiguity of caches. One way to circumvent this could be moving from a SceneHook to a ObjectData plugin. The idea would be to write a thin wrapper around Cinema's SDS object. In GVO you could just collapse all the input objects into a single polygon object and then just return that collapsed object as a child of a SDS-object. In Draw you could then just evaluate this very simple cache of your object (the input would already be taken care of due to the collapsing), i.e. you could directly draw your vertex-to-vertex relations. This would of course come with a considerable amount of overhead due to the collapsing.

Another approach could be to try to introduce tags as markers which will allow the user to guide your plugin what is considered to be the original. I cannot say you anymore than this without doing it myself (which falls out of the scope of support). The small insight would be here that for humans that decision what is the "original" might often be trivial.

For the SDS/subdivision vertex-to-vertex relations: My first instinct was that Cinema's subdivisions do not change anything about the index order of the source vertices (i.e., the vertices object that is going to be subdivided) due to the unnecessary overhead that would be introduced by inserting the new topological connected points in the index neighborhood of an "old" vertex. A quick test seems to confirm that, both for the SDS object as well as the "subdivide" command. If you want more clarity on this subject, I would have to ask you to open a new topic on that, so that we can keep topics in a single subject order.

The selected vertices are all of index 8, the object in the middle was the source for the objects on the left and right.

Thank you for your understanding and cheers,
Ferdinand

No worries, I didn't want to imply that support should help in design decisions.
Not having a complete knowledge of every possibility with the current SDK, I was only wondering if other aspect of the SDK could lead to a solution.
The only problem here is: if one doesn't know what is possible, it's difficult to know what questions to ask.

Anyway, at this point in time I am giving up.
The inbuilt isoline editing seemed to indicate a solution is possible, at least natively.
From the detailed information provided so far, I can only understand there is no solution for 3rd party plugins.

As for your remark regarding the vertex-to-vertex relation of objects and their subdivided counterpart, you are correct. But that is only the case for vertices. Edge and polygon indeces can obviously not be reused.
But as you suggested, I will open a different topic to further discuss this - when needed.

Now, I am not sure what to do with this topic.
I could set it to "solved", but there actually is no solution.

Hi @C4DS,

sorry, I actually read your message on Monday, but due to "stuff" I managed to forget answering. I understand your predicament, but unfortunately I cannot say you anymore what I have already said. Technically speaking there is no general solution for your original-cache problem. Practically you might find a way to do it when you can tightly define the circumstances under which it does happen. But again, design decisions, scope of support, etc.

Regarding the state of this thread. Since we are not able to give you a definite answer and you seem still unclear yourself about how to proceed, i.e., if you want to pick up the topic again, you can leave it open if you want to. After 14 days of inactivity we will however ask you for a confirmation if this is still ongoing.

Cheers,
Ferdinand

Hi @C4DS,

with some delay comes here a request for closing this. If you want to keep it open for now, you can push it one more cycle ahead, but at some point I will insist on closing it without further activity. Thank you for your your understanding.

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

Cheers,
Ferdinand