Multiple "Undo properties" in Undo stack

[Peter.Chaushev]

With the release of update 2 (v4.20.01) on Feb 18th the following fixes were introduced:
- applying material to object faces prior to activating V-Ray is now undoable
- quickly tweaking any material property slider in the Asset Editor no longer causes issues
- creating a material no longer prevents undoing prior actions

This does not yet completely resolve the problem. Changes to V-Ray material parameters still log extra actions in the SketchUp Undo stack. A solution for this is currently prioritized.
Thank you all for your comments!

[GD3DESIGN]

The bug is growing....first time its happened like this... I couldn't undo some edits I'd made to this mesh...when I hit clt+z it would create a new material in asset editor. (I only had 2 materials in scene before hitting undo...)

[georgi.georgiev]

Hi GD3DESIGN

Does this occur with specific project / model?

If you are able to reproduce this consistently, could you please share the model with us (support@chaosgroup.com) and / or provide a step-by-step description how to reproduce the behavior?
Additionally, are you using any 3rd party plugins for modeling?

[konstantin_chaos]

Hi guys,

I've just uploaded a new stable nightly build.
https://nightlies.chaosgroup.com/mai...table/20200416

Here's the announcement thread where you can see the most important changes listed:
https://forums.chaosgroup.com/forum/...lable-20200416

The Undo should work in a much more reliable way now.
I'm afraid that we might never make it perfect since the number of things we have control over in SU is limited.

Please give this build a try and let me know what you think.

Regards,
Konstantin

[summerson1990]

Hi guys,

I've just uploaded a new stable nightly build.
https://nightlies.chaosgroup.com/mai...table/20200416

Here's the announcement thread where you can see the most important changes listed:
https://forums.chaosgroup.com/forum/...lable-20200416

The Undo should work in a much more reliable way now.
I'm afraid that we might never make it perfect since the number of things we have control over in SU is limited.

Please give this build a try and let me know what you think.

Regards,
Konstantin

"I'm afraid that we might never make it perfect since the number of things we have control over in SU is limited." Could you please explain why? Why you and Trimble can't communicate in order to fix all the conflicts exists? We (users) could vote if need, if they don't let you do something you need. And what for this current nightly build release. Did you note that now we've got a problem with "Redo" function, it doesn't work, I can undo actions and can't redo them.

[noel.warren]

Could you please explain why?

This is a slightly oversimplified explanation but:

SketchUp Ruby API:
- Any change made to the SketchUp model using the Ruby api will add to the undo stack.
- Changes can be grouped into "operations"
- Operations can be merged into whatever change is at the top of the undo stack. These are called "transparent operations".
- There is no way to inspect the undo stack
- Observer events are not refined enough to be able to track the undo stack state

As for our integration, we have one key requirement:
Any change to a vray asset requires its change to be serialized to the model. The reason we want to serialize to the model to to allow users to copy/paste/save materials and components components and have them include their properties. Unfortunately we currently handle a material undo as just a change to the material causing us to update our asset and re-serialize (adding to the undo stack and breaking reado).

There is still room for improvement on our side but we're limmited by what the current SketchUp API exposes.

Why you and Trimble can't communicate in order to fix all the conflicts exists?

Discussions about the SketchUp API improvements/limitations/bugs are public and vibrant. Undo stack headaches affect many extension developers. It is likely we'll be emphasising the importance of the undo stack over the coming months.

Did you note that now we've got a problem with "Redo" function, it doesn't work, I can undo actions and can't redo them.

We're aware of this problem but to be honest I was under the impression that this was not new. I will discuss it with our QA team.
To be clear, it is not that redo doesn't work. It is that undoing a material change will cause us to re-serialize and add to the stack (making a redo not possible).

[jiminy-billy-bob]

Unfortunately we currently handle a material undo as just a change to the material causing us to update our asset and re-serialize

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?

[konstantin_chaos]

Hi guys,

Here is another build that you can test:
https://nightlies.chaosgroup.com/mai...table/20200422

The announcement post:
https://forums.chaosgroup.com/forum/...lable-20200422

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

[jiminy-billy-bob]

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.

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)

[konstantin_chaos]

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.

[jiminy-billy-bob]

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?

[noel.warren]

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.