updating tyflow more smart

[Eloi Andaluz]

Now, when enabling/disabling viewport helpers, like falloff gizmos, Tyflow needs to reevaluate everything, will be good if enabling/disabling viewport guidance doesnt trigger a reevaluation of the flow.

[tyFlow]

This isn't actually a tyFlow problem, but instead a larger problem/bug with 3dsmax's messaging system.

For example, when you change a parameter of any object in the scene, you cause a modification of its parameter block and the parameter block sends a REFMSG_CHANGE notification to its dependents, with a PART_ALL flag attached. In plain english, this means it's telling all of the objects that depend on it "I have changed, so perform the necessary updates to yourselves in response". This is normally good...for example if you change the width of a plane you are scattering particles on, you'd want the particle system to update as a response.

However, you and I both know that enabling/disabling the display of a decay gizmo on a wind spacewarp, for example, is a purely decorative change that has no effect on a simulation...but the messages sent through the messaging system do not know or even convey that. tyFlow has no way of knowing whether enabling the gizmo should change the spacewarp's effects, and so it just updates the whole sim the same way it would if you changed the force strength.

There are 3 potential solutions to this:

1) I add a bandaid to tyFlow, where I hard-code in the detection of wind spacewarp gizmo display changes and do not reset the simulation when they're detected. This is not really a solution since there are a thousand other options in other spacemarps/modifiers/objects/texmaps/etc which may all be decorative options that shouldn't trigger a reset, and it would be impossible to detect and hard-code bandaids for them all.

2) 3dsmax improves their messaging system and parameter block modules so that individual settings in parameter blocks can tag themselves as being decorative or not, and thus messages sent when they're changed would reflect that (probably never going to happen).

3) I add an option in tyFlow to not reset the simulation when a change to an input object is detected (this is already on the todo list). This would mean if you made changes to input objects that affect the flow (like resize a distribution object) you'd have to manually reset the sim before the previously-simulated frames would reflect that, but it would also help sim caches be less fickle and constantly resetting overall.

Hopefully that makes sense.

[insertmesh]

This isn't actually a tyFlow problem, but instead a larger problem/bug with 3dsmax's messaging system.

For example, when you change a parameter of any object in the scene, you cause a modification of its parameter block and the parameter block sends a REFMSG_CHANGE notification to its dependents, with a PART_ALL flag attached. In plain english, this means it's telling all of the objects that depend on it "I have changed, so perform the necessary updates to yourselves in response". This is normally good...for example if you change the width of a plane you are scattering particles on, you'd want the particle system to update as a response.

However, you and I both know that enabling/disabling the display of a decay gizmo on a wind spacewarp, for example, is a purely decorative change that has no effect on a simulation...but the messages sent through the messaging system do not know or even convey that. tyFlow has no way of knowing whether enabling the gizmo should change the spacewarp's effects, and so it just updates the whole sim the same way it would if you changed the force strength.

There are 3 potential solutions to this:

1) I add a bandaid to tyFlow, where I hard-code in the detection of wind spacewarp gizmo display changes and do not reset the simulation when they're detected. This is not really a solution since there are a thousand other options in other spacemarps/modifiers/objects/texmaps/etc which may all be decorative options that shouldn't trigger a reset, and it would be impossible to detect and hard-code bandaids for them all.

2) 3dsmax improves their messaging system and parameter block modules so that individual settings in parameter blocks can tag themselves as being decorative or not, and thus messages sent when they're changed would reflect that (probably never going to happen).

3) I add an option in tyFlow to not reset the simulation when a change to an input object is detected (this is already on the todo list). This would mean if you made changes to input objects that affect the flow (like resize a distribution object) you'd have to manually reset the sim before the previously-simulated frames would reflect that, but it would also help sim caches be less fickle and constantly resetting overall.

Hopefully that makes sense.

Thanks for the explanation!
I´d also opt for number 3. Should probably be part of a subset of "pro"-tuning features, because having that on as default would inevitably cause a lot of user errors....