Smart Merge - Scene Merging With Undesirable Results

Unity Engine
1

Hi guys,

We have recently set up Smart Merge on our Perforce server and it is functional but we have discovered that some of the behaviour of the tool is undesirable and were wondering if there was something built into the tool to get around the following:

We have a scene as a test which contains a single object (a cube) centred on the world origin.

If one user moves the cube from (0, 0, 0) to (1, 0, 0), and another user moves the cube to (0, 0, 1), then the result of the merge is (1, 0, 1). This is extremely undesirable as it matches neither scene. I would expect the merge to be able to detect this and flag that the positions are both different and force the user performing the merge to choose one rather than accumulating the values into what is essentially a new setting.

We have the same issues with lights, for example starting with a light with RGB values of (0, 0, 0), one user changes to (255, 0, 0) and another (0, 0, 255) as the colour of the light. We would expect the merge to catch this as a conflict as the scenes are different but what actually happens is that the red light and the blue light are merged, resulting in a purple light in the merged scene.

Is there any way around this? Instead of treating a Vector3 as a structure in its own right, it compares the components of the Vector3 which is no good when merging scene files.

Any advice on this would be appreciated.

Cheers,

John

2

This is not how it is supposed to work. Let me just verify the issue and I’ll get back to you.

1 Like
3

@jdrewsen - Hi, just wondered if you had managed to check this issue out yet? Any further advice would be appreciated.

Cheers,

John

4

Hi John… I’ve caught the flu and will look at it when I have recovered.

5

There is a file next to the UnityYAMLMerge executable called mergerules.txt

Under the section called [exclusions] you can add fields that are to be excluded from normal merging because they should be treated like a group. Just like the case you describe.

You can add a line like:
exclude *.Transform.m_LocalPosition

To tell the tool that positions should be treated like a group and create conflicts if separate sub fields are changed (e.g. the x y z position fields of the m_LocalPosition).

Same can be done for the RGB values.

Both should probably be added to the default mergerules.txt file as shipped by Unity.

6

I second this motion.

Looking at the exclusion syntax, is there a way to extend this behavior to all Vector and Color classes rather than explicitly listing every occurrence? Is this what

excludeIfContains *.MonoBehaviour.* x y z
excludeIfContains *.MonoBehaviour.* r g b

is trying to address, if only for our MonoBehaviours?

Thanks,
Chris

7

Not currently because the yaml format doesn’t specify the type of the field in the monobehaviour. I do see the value of having it so will think about how to solve that.