Detect change of geometry

On 01/12/2017 at 05:21, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   R19 
Platform:      
Language(s) :     C++  ;

---------
Continued on the problem of initializing a tag with information from the object it has been assigned to:
https://plugincafe.maxon.net/topic/731/13893_tag-plugin

The above thread provided some information related to MSG_POLYGONS_CHANGED and while I was close to a solution, further testing resulting in even more questions.

What I noticed so far:
- moving a tag from one object to another -> MSG_POLYGONS_CHANGED is sent twice to the tag
- selecting edges and apply connect -> MSG_POLYGONS_CHANGED is sent twice to the tag
- apply a subdivide on the full object or selected polygons -> MSG_POLYGONS_CHANGED is sent 3 times
- using knife tool to cut some polygons -> MSG_POLYGONS_CHANGED is sent once

As mentioned in the above thread, the second message is the important one in case when using "connect", since it's only at that point that the internal structure is (almost) finalized and ready to be used for initialization. (At time of first message the internal structure is still being "modeled" so not good to be used).
So, my original solution was to initialize the tag on the second message, but then subdivide or knife tool came along and ruined that.

Seems I cannot find anything consistent to detect a change of geometry. Very frustrating indeed.

On 04/12/2017 at 08:32, xxxxxxxx wrote:

I will discuss this topic with a developer. But this will take some time, so stay tuned.

Until then, leaving any optimization purposes aside, would it hurt, if you initialized the tag on every MSG_POLYGONS_CHANGED?

On 04/12/2017 at 08:37, xxxxxxxx wrote:

In short, yes.
As discussed in the other thread (mentioned in the original post) this MSG_POLYGONS_CHANGED can be sent before the actual structural changes of the object has been completed. In test cases I detected that ngons were present, while the action of changing the geometry would not introduce ngons. After the second message comes in, no ngons are present.

But doing an initialization on every message will cause some of these initializations to trigger "warnings" since ngons are detected.
Not sure how I will process these warnings, but in general it would be best to avoid this intermediate state in the first place.

Looking forward what this topic will provide as feedback from developers. Please, take your time.
And thanks in advance.

On 04/12/2017 at 08:39, xxxxxxxx wrote:

Sorry, forgot about your ngon issues. I'll emphasize this in discussion with development.

On 06/12/2017 at 07:08, xxxxxxxx wrote:

I discussed your request with a developer.
Not easy, as you already figured out. Internally we just need the polygon count from MSG_POLYGONS_CHANGED.

We came up with an idea for your situation:
In MSG_POLYGONS_CHANGED just store a flag, that you may need to re-initialize.
Then in Execute() valid point, polygon and ngon counts are available, do the initialization based on the above flag.
Use SpecialEventAdd() to postpone any needed warnings to a MessageData.

On 06/12/2017 at 07:43, xxxxxxxx wrote:

It was definitely worth trying out.
Unfortunately, while being real close to a valid solution. There is still something missing.

When I drag-n-drop any tag to the object the MSG_POLYGONS_CHANGED is also sent to my tag, resulting in a false positive. When I simply assign a tag to the object then only MSG_MENUPREPARE is sent. But the problem is a user can simply drag a tag from one object to another, or even simply re-organizing the tags on the object ... resulting in the "geometry-might-have-changed" flag being set.

There needs to be additional filtering in order to avoid these false positives.
I could keep track of the order and types of the tag, in order to detect a change.

Simply keeping track of points, polygons and ngons is not sufficient because a modification in geometry might potentially result in the same values.
Unless it's technically not possible to merge and split polygons in a single step?

EDIT:
You mention internally you only need the polygon count from MSG_POLYGONS_CHANGED.
But depending the tool used to change the geometry this message is sent more than once, with different polygon counts. There needs to be some additional checks to know which message is the right one to process, not?

On 07/12/2017 at 09:04, xxxxxxxx wrote:

You mention internally you only need the polygon count from MSG_POLYGONS_CHANGED.
But depending the tool used to change the geometry this message is sent more than once, with different polygon counts. There needs to be some additional checks to know which message is the right one to process, not?

No, not really. The number of polygons (or points with MSG_POINTS_CHANGED) delivered with the message is correct. So for us all messages are right ones.

On 08/12/2017 at 03:17, xxxxxxxx wrote:

Hi Andreas,
I am not sure how to respond to this latest remark. Do you mean that the fact there are multiple messages sent (with different polygon counts) is only happening within plugins?

Anyway.
Thanks again for the suggestions you guys made about the detection.
While I was about to wrap up, having figured out how to deal with this geometry-change, I started playing with the plugin.
While trying to get the plugin to crash by doing some unusual stuff, in order to fix those things I overlooked, I ended up with no polygon count change, no point count change, but change of ngon.
Basically, a geometry change not being triggered (since same number of points and polygons).

Scenario to reproduce:
Take a simple cube with 6 faces, in polygon mode select 2 adjacent faces and perform a "melt".
The 2 faces will form an ngon, but still 8 points, 6 polygons -> no trigger.

On 08/12/2017 at 04:52, xxxxxxxx wrote:

EDIT
Please ignore this post, as I am working out a solution.
I'm simply going to leaving the text as is for posperity.
/EDIT

Next problem!
I have saved a scene file with my tag assigned to a cube made editable.
When I load the scene file, the tag gets MSG_POLYGON_CHANGED and thus I perform a re-initialize, since geometry "has" changed.
I would prefer to filter this out, since re-initializing will result in a change of what was originally stored.
What mechanism can I use to only start checking on MSG_POLYGON_CHANGED after the document was fully loaded?

I can check on MSG_DOCUMENTINFO_TYPE_LOAD and only start detecting any geometry change after this message came along. But then I will also need to check for MSG_DOCUMENTINFO_MERGE ... maybe others as well?