[Tracker] Update_transforms issues

[Xtarsia]

Terrain3D version

1.0 dev c8519b8

System information

4.3.stable

Is the issue reproducable in the demo?

Yes

Issues

• - Update should only be called for sculpting brushes Fix update_transforms issues #585
• - Undo doesn't work properly. Probably needs to duplicate an array. Dictionary.duplicate(true) is probably not duplicating the arrays within, even though it's supposed to.
  • If foliating w/ manual height, sculpting to snap to terrain, undo will remove sculpt and foliage is still on ground. If going to initial and redoing, foliage goes to manual height. What should be the same undo data set is giving different results depending on if going forward or backwards in the undo history.
• - Every operation creates two copies of modified regions for Undo & redo. Moving from start to end in the undo history will show different images than moving end to start. Create our own undo queue so the last redo image is the current undo image.
• - When update_instances is called, the height offset is removed for the entire instancer cell. Should only adjust transforms in brush area Fix update_transforms issues #585
• - Multiple meshassets use other height values than their own (Mesh instancer default height can reference incorrect asset values. #544, and discord), which can be triggered by swapping IDs.

Future:

• The manually "painted" offset should also be maintained during update. problematic as update is called at the end up of operate() after heightmap has already been altered. Should retain current offset from terrain height and adjust it like Terrain3DObjects does, rather than resetting it to meshasset offset height ( out of scope for this PR)

[TokisanGames]

Related #544

Also Terrain3DObjects retains the current offset from terrain height while adjusting, whereas update_transforms erases the current offset and uses the mesh asset offset. It would be better if the latter did the former.

[TokisanGames]

Re Undo/redo issues

When placing something above ground @ 111, then sculpting @ 108, then undoing the sculpt it doesn't go back to 111. I've confirmed that data is storing properly in the undo and redo slices. However, when the undo is applied, update_transforms is called (from the edited_area signal), readjusting the stored 111 to 108 so it looks like the undo didn't work.

Also I was confused about undo/redo storing so many copies (eg 3 operations on one region makes 7 versions of a region: 1 active, 3 undos, 3 redos), however this is correct because we're storing partial updates, not full snapshots. Full snapshots means redos and undos could be the same image at each undo history level. Partial updates means each could contain any combination of the available regions and though each undo or redo might contain the same region, it could contain any number of others, so undos and redos won't always be the same.