here’s more news from the bug tracking department. Well, actually not so new, as this issue has been brought up before, but as the last post related to this problem dates back to October '06, I thought I’d post this again:
There is (still) a bug in CloneImportExport that causes nodes in cloned scene graph branches to share the same objects for their transformations if the transformations have identical values. That is, if you would clone a scene graph hierarchy that looks like this:
- Node1 (Translation1 [0, 0, 0])
- Node2 (Translation2 [0, 0, 0])
...then the vectors used for Translation1 and Translation2 would point to the same objects in memory in the cloned hierarchy. So, if you would change the values of Transformation1 (e.g. shift it by (1, 0, 0)), they would also change in Transformation2 (e.g. resulting in a shift of (2, 0, 0) of the Geometry).
This bug obviously results from the use of a HashMap in CloneImportExport that is used to get the clone objects. When loading a clone of the stored object (or scene graph branch), the cloned Savables are stored in a HashMap when they are created, and re-used when an equal object is needed. As long as this equality is checked by using the equals(Object) and hashCode() methods of the objects, objects that are equal according to these methods will in fact be identical in the cloned scene graph hierarchy.
I'm not sure, but maybe this issue can be fixed by using IdentityHashMaps instead of the regular HashMaps for the fields oldToNew and newToOld in CloneImportExport. I'll check on that...