Для копирования можно решить задачу через ID.
В скопированной структуре все ID копий дополняем суффиксом "_Copy" (например), попутно запоняя мапу <ID : pointer>.
Затем пробегаемся по ним ещё раз и подставляем соответствующие новым ID значения указателей.

ЗЫ. "я так делал, оно работаеть"

Я что имею в виду: например у нас есть объекты А, B, C. Пусть B и C - дети А, тогда имеем такой псевдо-код:

A{name = "Item.A", m_parent = NULL, childs = {B,C} };
B{name = "Item.B", m_parent = &A, childs = {B,C} };
C{name = "Item.C", m_parent = &A, childs = {NULL} };

Теперь мы скопипастили наш А (допустим), после вставки у нас стало:

// это оригиналы:
A{name = "Item.A", m_parent = NULL, childs = {B,C} };
B{name = "Item.B", m_parent = &A, childs = {B,C} };
C{name = "Item.C", m_parent = &A, childs = {NULL} };

// а это копии:
A1 {name = "Item.A", m_parent = NULL, childs = {B,C} };
B1 {name = "Item.B", m_parent = &A, childs = {B,C} };
C1 {name = "Item.C", m_parent = &A, childs = {NULL} };

То есть копии до сих пор ссылаются на оригиналы, тем самым херя всю иерархию. И надо бы это сделать "правильно", в этом задача?

Если рекурсия, то еще проще можно.
Поскольку в метод клонирования передается новый родитель, сразу назначаем его "детям".
Соответстенно родитель знает, каких детей он склонировал, он же должен занести их в свой список "детей" и так по цепочке

Ну все как обычно, вы недоговоариваете. Для простоты возьмем один айтем (А). Им владеет айтем Б. И он "смотрит" на айтем В.
Копируем айтем А1. Что должно произойти?

Вы все время смешиваете два вида сущностей в одно целое.

Есть данные D1, D2, D3, временем жизни которых что-то управляет (или другими словами владеет). Это может быть общий менеджер данных или узлы контейнера (списка, дерева или др.).

Узлами контейнера N1, N2 и т.п. уникально владеет (управляет временем жизни) сам контейнер. Узлы одного контейнера не являются одновременно узлами другого.
Что касается данных D, то реализуется связь [1..1], то есть одному элементу данных Di всегда соответствует один узел Ni.
Если предполагается, что узлы управляют временем жизни данных (владеют), то можно говорить о композиции (уникальной агрегации) данных узлами.
Если предполагается, что узлы не управляют временем жизни данных (данными владеет некий внешний менеджер), то можно говорить об ассоциации данных узлам.
Но, и в том и другом случае при копировании узлов, данные тоже копируются.

Что-такое данные и какими свойствами они обладают - обобщенные (shared), неявно обобщенные (copy-on-write), единичные или в виде контейнера (мультипликативность) и т.п. решается в контексте конкретной задачи.

Например, есть данные MyStruct
- если не требуется обобщение данных, то в качестве D используем MyStruct, ::std::unique_ptr<MyStruct> или др.
- если требуется обобщение данных, то в качестве D используем SharedWrapper<MyStruct>, QSharedPointer<MyStruct>, ::std::shared_ptr<MyStruct> или др.
- если требуется неявное обобщение данных, то в качестве D используем ImplicitSharedWrapper<MyStruct> или др.

Второе, не следует смешивать две совершенно разных вещи - контейнер Tree и отношение Parent-Child.

Отношение Parent-Child подразумевает, что Parent управляет временем жизни (владеет) Child, при этом Child композитно агрегируется в Parent (уникально владеет).
Parent может содержать 0, 1 .. N элементов Child в любом представлении (упорядоченно/не упорядочено, в виде отображения или еще чего нибудь).
Обычно подразумевается, что Child имеет ассоциативную связь с Parent, хотя это не обязательно.
Удаление Parent влечет за собой удаление всех Child. Копирование Parent - копирование всех Child.

Отношение Parent-Child может быть реализовано без всякого обобщающего контейнера Tree.

В случае наличия контейнера Tree, он полностью владеет своими узлами, и, как частный случай возможной реализации, отношение узлов N в контейнере Tree может быть реализовано в виде отношения Parent-Child.
При этом сам контейнер композитно агрегирует корневой Parent (обычно называют root).

Конкретная реализация "дерева" не обязательно построена на зависимости "парент-чайлд".
Можно, например, "дерево" внутри реализовать с помощью обычного отображения {key, value}, где в качестве ключа использовать пару {номер уровня, номер позиции на уровне}. Внешний интерфейс при этом ни чем не будет отличаться от "дерева", реализованного с помощью "парент-чайлд".


"Владение" в рамках объектно ориентированной модели правильнее называть ассоциативной связью агрегации. Если в объектной модели не определить кто-кого-каким способом агрегирует (другими словами, кто-кем-как владеет), с учетом правил непротиворечивости самой модели, то никогда не получится корректное программное решение.

Для отношения "парент-чайлд" общепринятая объектная модель определена однозначно, как описано мной ранее.
Это, можно сказать, определение этого отношения. Другая модель уже не реализует отношение "парент-чайлд", а реализует что-то ещё.


Неявное обобщение (implicit-shared) используется в частности для реализации механизма copy-on-write, когда фактическое копирование данных происходит в момент обращения к ним для изменения. То есть фактически используется обобщение данных, но реализуется поведение уникального владения (композитного агрегирования).


В этом описании реализуемая модель может выглядеть так:
- Существует общий менеджер ресурсов в виде неупорядоченного их множества. Именно этот менеджер "уникально владеет" (композитно агрегирует) ресурсами.
- Существует набор деревьев "by hierarchy", "by master material" и т.п., содержащий в узлах данные с ассоциативным связями (ссылками или не владеющими указателями) на ресурсы.

Либо без общего менеджера ресурсов:
- Существует набор деревьев "by hierarchy", "by master material" и т.п., содержащий в узлах данные, которые "совместно владеют" (обобщенно агрегируют) ресурсы.

То есть в деревья складываются не сами ресурсы, а данные, которые определяют вид ассоциативных связей с ресурсами.
При этом и в том и другом случае данные могут обладать еще и дополнительными уникальными атрибутами, если это необходимо.
Само понятие "дерева" следует реализовать в виде шаблона, узлы которого композитно агрегируют (уникально владеют) данными. Тип данных является параметром шаблона.

Понятие отношений (ассоциаций) в объектно-ориентированном моделировании имеют четкие определения, в том числе и агрегация (https://www.uml-diagrams.org/aggregation.html?context=class-diagrams), как частный случай. Это отношение показывает кто-кого-когда-как удаляет. Требование к непротиворечивости модели определяет, могут ли определенные отношения сосуществовать вместе.

Для решения одной и той же задачи можно построить несколько непротиворечивых моделей отношений. Выбрать одну из них по каким-либо критериям - задача программиста. Именно поэтому возникает столько вопросов по нюансам каждой из задачи.


Как легко Вы смешиваете несмешиваемое .

Визуализация в виде дерева не является каким либо отношением, это всего лишь удобное представление. Можно реализовать 100500 разных представлений для одной и той же модели данных. Представление является только отражением модели данных, даже если данные агрегировали внутрь конкретного представления. Данные первичны, представление вторично.

Да, удаление/копирование парента применяется ко всем его чайлдам, и в рамках понятий объектно ориентированной модели - это обязательно означает, что "парент владеет чайлдом".

В представленном конкретном случае, сами объекты сцены не участвуют ни в каких отношениях "парент-чайл", хотя Вы упорно пытаетесь их заставить  . В отношениях участвуют промежуточные данные, содержащие ассоциативные связи с этими объектами, а не сами объекты.


Случай, когда объектами владеет сцена, является частным (могут быт и другие решения). И конкретно в данном случае, действительно сцена является контейнером (агрегатором) объектов сцены. Именно через API класса сцены происходит добавление/удаление и т.п., другими словами - управление временем жизни объектов сцены. Сцена реально "владеет" своими объектами. Удаление объекта из сцены сделает все ссылки на него невалидными, поэтому требуется писать дополнительный по управлению этими ссылками (удаление из деревьев и т.п.). Напротив, удаление ссылки никаким образом не влияет на сам объект.


Если экземпляром объекта типа Bone "кость" владеет сцена, то помещайте в деревья экземпляры объектов типа LinkToBone, с линком к Bone. Не хотите, чтобы сцена владела "костями", помещайте в деревья экземпляры объектов типа SharedBone.


Граф - это очень емкое понятие. Любые отношения образуют граф. Способов реализации - миллион. Оптимальной реализации на все случаи жизни - нет.
Частных случаев под определенный класс задач - масса. Наиболее известные простые - односвязный и двухсвязный список.
Более сложные из темы 3D - отношения между вершинами/ребрами/гранями/объемами. Различных реализаций тоже много.
Запихнуть все в единую реализацию графа - не очень здравая мысль. Как минимум, получится не оптимально.


  Грамотность тут ни при чем. Дерево, по своей сути, тоже является контейнером (агрегатором) общего назначения подобно ::std::list, ::std::map и др. Просто видов деревьев достаточно много, поэтому они не входят в std.
Вам нужна конкретная реализация дерева, но для разных случаев "by hierarchy", "by master material" и т.п. Поэтому template самое оно  .

Любой из контейнеров можно легко реализовать без шаблонов, прямо на void*. Но чтобы так не делать, собственно, и разработали язык шаблонов.


Так тоже будет работать), только медленнее. Если вдруг многопоточка - конкурентный доступ к theReferenceHash. Любой поиск связи - обращение к QHash. В 3D, где важны микросекунды - это может быть существенно.
Что будет в качестве ключа BaseClass *, void *, Handle не важно, если не используется reinterpret_cast или static_cast. Красиво/не красиво - дело вкуса. Главное, чтобы работало как нужно и удовлетворяло требованиям по производительности и др.