I have a scene track input (GeoSphere02 position) in a KCM. MagmaFlow is open, AUTO is on. If I move the GeoSphere, the KCM updates and everything is pleasantly slow and interactive.
If I close the MagmaFlow, the KCM (even though Auto Update is on) does not update. Moving the GeoSphere is fast, but isn’t updating the PRT Loader.
If I open the MagmaFlow back up, the GeoSphere still doesn’t force an update, even though the inputs in the Input Node Settings are updating correctly.
If I hit UPDATE, then the KCM updates, and continues to do so as it originally did.
So something is happening in between closing the MagmaFlow and hitting UPDATE that’s making it not work properly.
When the Editor is open and you hit Update, a WHEN callback is registered for the dependency objects to allow for interactive tweaking on the same frame without Time Slider change, so moving the object will refresh the KCM.
Once you close the Editor, the callbacks are deleted and the only way to get an update is the move the Time Slider - if the object controlling the track is keyframed, the KCM will correctly update it.
Callbacks are a Necessary Evil and I don’t want to keep them around longer than absolutely needed.
Hmmm… What about the case where the MagmaSlow is open, and AUTO is on, but UPDATE isn’t hit? Could you add the callback when the MagmaFlow window opens and AUTO is on?
It’s mostly crappy because the MagmaFlow eats up real estate, so I keep closing it so I can see what the effect is in the quad views.
I fixed the callbacks to register on Editor Open (without pressing UPDATE). Opening the Editor will also cause an update which was not the case so far. Will be in the next build.
I could probably look into adding a button to force the callbacks (“Interactive Mode” ?) from the KCM UI in the Mod. Panel without the Editor open, but if you enable for a dozen of KCMs and forget to disable, the scene could get slow. Optionally, enabling in one KCM could turn off Interactive Mode in all others, or if there are any set to update interactively, prompt about disabling them. But I have to look closer whether this all makes sense technically. Looking at the code, it might not be trivial.
Btw, you can minimize the Editor to keep the updates going AND save real estate.
The button would be ideal. You’d have to label it “Interactive (slow) Mode” as most people assume Interactive means fast, when it usually means the opposite.
Now if there was a way to tell from the modifier stack what KCM’s had that active, then you’d be fine… But as it is now you’d have to remember/find the slow ones.
Another idea… Might be dumb… Could you have a new modifier that forced the KCM’s to update? Like a “KCM WYSIWYG Modifier” that enabled the callback? You could then see it in the modifier stack and turn it on/off.
The last idea would not work easily, since it would have to go down the stack and collect all info about dependent objects from all KCMs. That is not easy.
Originally I wanted to do the interactive updates using real node dependencies (a node tab in the KCM where all dependencies would be stored, forever).
It caused such severe crashes I had to abandon the idea. It looks like the notification system was bombarding the KCM with update requests.
I got it to work, but the code looks very much like a hack. Will try to clean it up in the future.
Next will look at adding buttons to disable all such callbacks in the scene.
*Two persistent global arrays are created in memory - one contains all modifiers registered for Interactive mode, one contains all nodes that drive modifiers. These arrays are populated when you check the Interactive mode (all dependent nodes for the current modifier are collected and appended if not there already, and so is the modifier). When you uncheck the Int. mode, the modifier and all its dependent nodes are removed from the lists.
*When you check the button OR when a KCM is loaded due to scene load, the callback monitoring the array of nodes is reregistered. Since the persistent global array also loads with the scene and keeps track of all objects, this causes a scene saved with interactive updates on in any KCMs to restore the mode automagically.
*When you press the button to disable all updates in the scene, the two arrays are cleared, the callback removed and all checkbuttons in all modifiers of the KCM class are unchecked.
*The drawback of this approach is that instead of multiple callbacks, one per modifier, we now have a single callback where any registered node will cause ALL KCMs enabled for updating to refresh. So it might scale worse, but it is much easier to manage. I will see if I can limit the updates to only the modifiers that actually depend on the changed node.
The Editor will create its own callbacks on the fly and remove them as before. They are independent and automatic.
I’m getting some crashes after failed gc when moving my GeoSphere around. I’ll hold off on making repo cases until I get the next beta, which sounds like it will simplify things for me a lot.
When you have checked “Load Single Frame Only”, all particles are cached and NOT updated. We consider this a feature since it used to be broken (single frame was reloaded again and again) and we had to fix it to make things fast again.
Thus, if you want a single frame only to load on every frame, you would have to enable “Limit To Custom Range” and set the Start and End Range to the frame you want reloaded. Dragging the Time Slider will force a reload of the particle system on every frame and thus cause a full update. This is of course bad if you have 10 single frames with different frame numbers loaded in one PRT Loader. But we’d rather not make the Load Single Frame Only update on every frame as a “fix” of the PRT Loader.
That being said, I could make the callback press the Update button of PRT Loaders. But this would be VERY slow depending on loading mode and count and I’d rather not do that.
No, I just wanted to make sure that I understood the case correctly. For my scene, since I’m not using PRT Sequences, I wanted to make sure that that wasn’t creating some special case for your new callback changes.
I just added handleAt:#redrawViews in hopes to reduce the number of update calls made by the callbacks.
I also rewrote the system once again to use a single array where each node is stored together with a subarray of modifiers to update. Thus changing one node will only update the modifiers it is connected to and not all KCMs registered for interactivity.
Still, using callbacks is dangerous. Only time will show if this approach is usable in practice. I might also look into adding a timeout to skip updates if the update call came certain number of milliseconds after the previous one. This would make the interactivity slightly less fluid, but would probably reduce danger of gc() and other problems.
Let me clarify… I have PRT that is static. When I hit UPDATE, moving the GeoSphere will force an update. But scrubbing Time Slider (where the GeoSphere’s position is animated) isn’t updating.
If the PRT is set to “Load Single Frame Only” (if that is what you mean with “static”), the PRT Loader is not updated when the time slider is scrubbed. And since the PRT Loader is responsible for running the modifiers, no KCMs update. This is in VIEWPORT only. If you render, it will update whatever KCMs it has with all animated connections to node parameters etc.
At this point, we could consider this a bug and let the PRT Loader update its KCMs without reloading from disk (if that’s possible, I think it is). My work on Interactive Updates does NOT fix this behavior since I cannot make the PRT Loader update when it is set not to (“Load Single Frame Only” has the same meaning as “Don’t Update”).
I just wanted to make sure that you understood what I was seeing as it’s probably not a typical case. Though an intermediate cache would be awesome, especially when you are only loading viewport quantity particles.
It’s not a huge deal if that’s not how it works by default, but I thought if I DID want to make a viewport preview of the PRT Loader / KCM’s, I’d need a way to do that…
I’m off for the weekend, but I might try seeing what happens if there’s something in the modifier stack between the base object and the KCM’s.