Copy transformations data when we clone node

[akortunov]

Fixes bug #5163.

In the master branch we do not copy NodeUserData when we make a copy of node (despite we are supposed to do it by design), so userdata nodes are shared and animation transformations can affect all instances of given node.

So the suggested solution is to copy NodeUserData as well.

Notes:

1. I know that dynamic casts are bad, but the time spent to casts here is much lesser than the time spent to clone NodeUserData nodes (basically, we have one for every NiNode in scene and preloaded objects).
2. Savegame loading becomes slightly slower (it may take a several milliseconds more time depending on scene). In other cases there should not be much difference since we ususally clone objects during preloading.
3. A different possible approach is to use the osg::CopyOp::DEEP_COPY_OBJECTS, but in this case we will copy everything that is derived from osg::Object

[AnyOldName3]

As mentioned in the issue report, I've opened a thread on the OSG forum to check if the DEEP_COPY_USERDATA flag is actually doing what it's supposed to. That might mean that OSG either gets another flag for our use case, or the existing flags get changed to do what we want.

[akortunov]

Well, Robert replied - current OSG behaviour is a bug.
But even if we send a patch to OSG, we still will have to support upstream 3.4.x.

[Capostrophic]

A compromise: keep a workaround now, add a comment that it should be removed after the minimum OSG version is increased to whatever version the bug is fixed in, ???, profit.

[AnyOldName3]

I'd rather fence off the workaround behind an #if OSG_VERSION_LESS_THAN(3, 6, 5) check. It's fairly easy to search for these macros if/when we bump our minimum OSG version (as they should be the same everywhere, unlike a comment), and it stops the engine doing unnecessary work.

[akortunov]

I'd rather fence off the workaround behind an #if OSG_VERSION_LESS_THAN(3, 6, 5) check.

So the 3.6.5 already has the patch for this issue, or at least we know that 3.6.5 certainly will have the fix?

[AnyOldName3]

Robert's said he'll accept a PR for it, so unless 3.6.5 is released before he gets back to me about my follow up questions, it'll have the fix.

[akortunov]

A half of year has passed, and there is still no difference.
I suggest to use my current approach for now, and add a version check later if OSG really get a patch.

[psi29a]

Fence off for 3.6.6 with additional comment to check that it indeed go into 3.6.6?
I'm worried that it will be forgotten about. :(

[akortunov]

Fence off for 3.6.6 with additional comment to check that it indeed go into 3.6.6?

I suppose that the non-existent patch should really get into the 3.6.6 first, and only then the version check can be added.

[akortunov]

Using a workaround for now since OSG devs treat existing behaviour as intended.