Why do you need to re-serialize in this case? Is syncing your internal state with whatever is saved in the model attributes not enough?
Hi guys,
Here is another build that you can test:
The announcement post:
The following changes have been introduced:
- Material manipulations are now registered as separate transactions and are no longer undone together with the last model alteration
- Material manipulations no longer prevent Redo to be performed
- Undoing a material rename and then trying to manually rename to the same thing no longer causes material copies to appear
Jiminy-billy-bob, you are correct about the attributes.
We did realize that right after Noel posted his explanation.
On the other hand syncing the V-Ray state and the attributes that get updated by the Undo is still an issue.
The reason is that SU observers don’t fire (onMaterialUndoRedo for example) in some situations which can lead to things falling out of sync.
Another edge case is material deletion…
Regards,
Konstantin
Why not sync everything when onTransactionUndo/Redo gets fired? Is it not reliable either?
Is it too expensive? I could understand that when parsing the whole scene hierarchy, but the materials collection is a flat array so parsing it is blazing fast. If the issue is updating all materials in RT, then you could maybe compare the new values with your internal state and only update what’s needed?(like what React does)
The onTransactionUndo is more reliable but syncing all the materials every time it does fire is something I don’t like.
Implementing such workarounds becomes an issue sooner or later.
Is it a workaround though?
I see it as considering the SketchUp model as the single source of truth and syncing whenever possible, instead of maintaining two separate states and hoping nothing make them fall out of sync.
This is the approach we are taking with Skatter v2. Whenever there is an undo or redo, we resync everything. It’s fast enough not to be noticeable by the user.
What kind of issue do you think could arise?
Our current infrastructure simply does not allow us to take this approach with keeping our scene state in sync with that of the SketchUp model. A number of improvements are planned that will put us in a better position to consider this a possible solution to better handling the SketchUp undo stack.
That said, I’d watch out for the onTransactionUndoRedo observer method. I have seen it fire too many times (so throttling is advised if performance matters), misfire (ie, empty transaction) and not fire at all.