Russian Qt Forum
Март 29, 2024, 01:54 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: Перестройка дерева и данные  (Прочитано 5950 раз)
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« : Август 23, 2018, 04:39 »

Добрый день

Есть дерево объектов, может быть сколь угодно ветвистым, хотя обычно 3-4 уровня. Дерево отображается в UI напр
Цитировать
...
Object A (level 0)
   Object B (level 1)   
   Object C (level 1)   
       Object D (level 2)   
   Object E (level 1)   
...
Юзер может перестраивать дерево как угодно, удалять объекты и вставлять новые.

По запросу юзера выполняются достаточно сложные расчеты траектории движения для одного из нодов дерева (напр A) и всех его чайлдов. Результаты сохраняются, т.е. теперь есть анимации для нодов A, B, C. D, E которые могут быстро проигрываться. Все хорошо.

И вот теперь (данные анимации сохранены) юзер начинает перестраивать дерево. Напр вставляет новый нод F между B и С, а затем может и удалит (или отлинкует) нод C. Чего он хочет ясно - чтобы анимация для C теперь применялась к новому ноду F, это нормальная, законная потребность. И вот тут начинается путаница - а что к чему применять? Ну если старое и новое дерево совпадают... ну а если нет? Хорошо бы сделать это переназначение явным - но как? (т.е. что рисовать в новом UI). Подкиньте идеек (можно смелых  Улыбающийся)

Спасибо
Записан
ssoft
Программист
*****
Offline Offline

Сообщений: 574


Просмотр профиля
« Ответ #1 : Август 23, 2018, 08:00 »

День добрый.

Пока есть такое предложение - хранить (ещё или только) относительные траектории движения чайлдов относительно парента.
Если хранить только относительные траектории, то при вставке/замене/удалении ничего делать не придется. Но графический движок должен мочь это воспроизводить.
Либо пересчитывать траектории вниз по дереву от места модификации (сразу, или при сохранении, или при воспроизведении).
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #2 : Август 23, 2018, 08:24 »

Пока есть такое предложение - хранить (ещё или только) относительные траектории движения чайлдов относительно парента.
А так и есть - сохраняются "локальные" трансформы

Если хранить только относительные траектории, то при вставке/замене/удалении ничего делать не придется. Но графический движок должен мочь это воспроизводить.
Ну как "не придется"... Вот макс упрощенный пример. Пусть анимация сохранена для
Цитировать
Object A (level 0)
   Object B (level 1)   
И теперь юзер втулил С
Цитировать
Object A (level 0)
   Object С (level 1)   
   Object B (level 1)   
К чему применить анимацию сохраненную для B: по-прежнему к B или уже к C ?

Либо пересчитывать траектории вниз по дереву от места модификации (сразу, или при сохранении, или при воспроизведении).
Ни о каком пересчете речь не идет (он может длиться часы). Только как разбросать - переназначить (без этого не обойтись)
Записан
Ivan
Гость
« Ответ #3 : Август 23, 2018, 09:03 »

Я так понимаю, что Вы имеете ввиду поведение объекта по умолчанию?

Надо сделать по умолчанию отсутствие трансформа. Т.е. новый объект не обрабатывается, пока юзер сам не укажет с какого объекта скопировать трансформы.

Записан
ssoft
Программист
*****
Offline Offline

Сообщений: 574


Просмотр профиля
« Ответ #4 : Август 23, 2018, 10:53 »

Ну как "не придется"... Вот макс упрощенный пример. Пусть анимация сохранена для
Код:
Object A (level 0)
   Object B (level 1)   
И теперь юзер втулил С
Код:
Object A (level 0)
   Object С (level 1)   
   Object B (level 1)   
К чему применить анимацию сохраненную для B: по-прежнему к B или уже к C ?

Подразумевается ли какое-либо влияние Object C на Oblect B ?

Если да, то целесообразно Object C делать родителем Object B.

Если нет, то
  * если происходит вставка Object C, то он и должен настраивается. Object B не должен меняться.
  * если происходит замена Object B на Object C, то Object C должен иметь настройки Object B
  * удаление Object должно происходить с его настройками.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #5 : Август 23, 2018, 13:07 »

Надо сделать по умолчанию отсутствие трансформа. Т.е. новый объект не обрабатывается, пока юзер сам не укажет с какого объекта скопировать трансформы.
Хорошо бы (явное указание всегда лучше), но как это сделать? Каким образом юзер должен (пере) назначить? Какое UI ему для этого нужно ?

Подразумевается ли какое-либо влияние Object C на Oblect B ?
Нет

Если нет, то
  * если происходит вставка Object C, то он и должен настраивается. Object B не должен меняться.
  * если происходит замена Object B на Object C, то Object C должен иметь настройки Object B
  * удаление Object должно происходить с его настройками.
"Замены" как таковой нет, юзер может вставить + удалить. Поэтому и удалять сохраненные данные (др словами анимацию, настройки) не нужно, проще хранить их все в корневом ноде(ах). В остальном это примерно тот же путь по которому пошел я - данные назначаются неявно (implicit) по индексу на текущем уровне иерархии. Напр объект B при создании имел индекс 1 (первый на уровне 1). Стало быть этот слот данных назначается на тот объект который сейчас первый на уровне 1 (Object C в примере выше).

Ну как-то я не в восторге от такого решения
Записан
ssoft
Программист
*****
Offline Offline

Сообщений: 574


Просмотр профиля
« Ответ #6 : Август 23, 2018, 15:02 »

"Замены" как таковой нет, юзер может вставить + удалить. Поэтому и удалять сохраненные данные (др словами анимацию, настройки) не нужно, проще хранить их все в корневом ноде(ах). В остальном это примерно тот же путь по которому пошел я - данные назначаются неявно (implicit) по индексу на текущем уровне иерархии. Напр объект B при создании имел индекс 1 (первый на уровне 1). Стало быть этот слот данных назначается на тот объект который сейчас первый на уровне 1 (Object C в примере выше).

Ну как-то я не в восторге от такого решения

ИМХО, для пользователя удобнее произвести замену узла, чем помнить нюансы удаления/вставки с какими-то ни было правилами. Например в QtDesigner для этого имеются команды "Morph into ..." или "Promote to ...".
Пользователи - они такие, ничего не любят запоминать). К тому же хранение информации в корневой ноде по индексу влечет за собой, как минимум, необходимость переиндексации, а по факту еще массу неудобств при дальнейшей модификации и сопровождении ПО.
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #7 : Август 23, 2018, 16:10 »

ИМХО, для пользователя удобнее произвести замену узла, чем помнить нюансы удаления/вставки с какими-то ни было правилами. Например в QtDesigner для этого имеются команды "Morph into ..." или "Promote to ...".
Пользователи - они такие, ничего не любят запоминать).
Ну 3D объект - не готовый класс, сначала нужно добавить файл модели в проект, тогда появятся объекты этого файла, поэтому выскочить попапкой не выйдет. Плюс еще заботы - объект может быть вкл/выкл, т.е. активен/неактивен.

К тому же хранение информации в корневой ноде по индексу влечет за собой, как минимум, необходимость переиндексации, а по факту еще массу неудобств при дальнейшей модификации и сопровождении ПО.
Согласен. Как улучшить?
Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.057 секунд. Запросов: 22.