Russian Qt Forum

Добрый день

Очередная попытка поговорить об "архитектуре", вероятность плодотворного обсуждения мала, но все же не ноль, попробуем  :)

"Хотелка" показана в аттаче. Это простой плагин который создает стандартные формы, и у него есть интересные опции: в каждом вертексе создать сферу и/или каждое ребро заменить на цилиндр. Ни на какую архитектуру плагин не претендует, он тупенько льет доп примитивы в геометрию, напр если увеличить деталировку исходного кубика, то быстро получим мульены вертексов и фейсов за счет сфер и цилиндров. Также опции этих дополнений сжирают добрую половину UI плагина (а какой тип/размер/цвет сферы? и.т.п.). И вообще, а почему только сфера? А слабО кубик или ваще произвольный объект?

Очевидно идейно/концептуально было бы использовать ссылку на единичный размножаемый объект(ы). Также очевидно что вместо тупенькой генерации N сфер гораздо лучше было бы рисовать одну сферу N раз. Короче, "даешь виртуальные объекты!". Ладно, попытаемся формализоваться

Виртуальный объект (ВО) ссылается на оригинал, собственного UI не имеет. "Какие-то" параметры ВО котролируются/задаются создателем (ну хотя бы позиция). Однако ВО рисуется/рендерится так же как и реальный объект. Плюс обязательная возможность экспорта - напр записать в файл все ВО как реальные. Обычно интересует большое число ВО, пяток-десяток юзер и копи-пастой сделает.

Пока хватит. Какие примерные структуры данных Вы можете предложить для реализации ВО?

Спасибо

C++ (Qt)
struct Shape {};
struct Color {};
struct Position {};
 
struct Style
{
    Shape shape;
    Color color;
};
 
struct VObject
{
    Style*   style;
    Position position;
};

Мда, не густо :) Я это перепишу как я Вас понял, что не так - поправьте

C++ (Qt)
// "Реальный" объект который юзер может добавить/удалить в сцену.
// Имеет UI, рисуется в окнах, предъявляется в списке объектов
struct CSceneGeomObject {
  Transform   m_transform;   // набор матриц (позиция, поворот в сцене и.т.п)
  Geometry    m_geom;        // вертексы, фейсы и др (что рисовать) 
  Material    m_material;       // цвет, текстуры и др (как выглядит)
  .....                                  //  очень много всякого другого
};
 
// "Виртуальный" объект = ссылка на реальный + что меняем
// "диффы" як каже молодь
struct CVObject {
  CSceneGeomObject * m_reference;  // может лучше уникальный id? (имеется)
  Matrix m_globalMatrix;                  // ну наверно размещать ВО в сцене надо всегда
  .....                                  // а тут хз, вариантов что менять может быть много
};
 

Заметим что ВО может ссылаться и на объект др типа, напр источник света, который не имеет ни геометрии ни материала, зато имеет массу др опций. Автоматычная расстановка большого числа лампочек - старая и популярная задача.

Ну ладно, если все так, то первый вопрос - а что у нас с пресловутым "владением"? Кто ответит за создание, хранение и удаление ВО?

Не так давно все уши с этим владением прожужжали. А когда его действительно надо обсуждать - молчок, да еще и вызывающий голый указатель..

Мой основной посыл был в использовании стилей (как, например, в текстовых процессорах). Если сейчас молодь называет стили "диффами", пусть будут диффы.


Полагаю, что за создание, хранение и удаление ВО должен ответить класс АвтоматычныйРасстановщикБольшогоЧислаЛампочек или его соратники.


Чтобы обсуждать, надо знать контекст (одно/многопоточность; гарантии существования стиля дольше, чем ВО; изменяемость/константность стиля и т.п.), а Вы этого не любите :). Потому и голый указатель, он всё стерпит, ему скрывать нечего, никого не ограничивает, всем всегда рад :).

Выходит я Вас не понял. Напрашивается вариант: ссылка на оригинал + что меняем (diiference). Термин "текстовый процессор" слышал давно, но ни с чем конкретным он не ассоциируется. Какие такие "стили"? Фонты, что ли?  ???

А что это за класс? Что он делает (ф-ционал)? Вообще Ваш подход к проектированию меня пугает. Типа - ну там, может, напишем какой-то класс...

Вы ввели какой-то свой термин "стиль" о котором я без понятия - и требуете для него контекст, та где ж я его возьму  :)

Термин "текстовый процессор" можно ассоциировать с Microsoft Word или LibreOffice Writer, например. Более полный список можно посмотреть тут (https://en.wikipedia.org/wiki/List_of_word_processors). В текстовых процессорах стили используются для определения свойств абзацев, списков и т.п. Чем отличается выбор фигуры для индикации вершины графической модели от выбора маркера для пункта маркированного списка в тексте? Как по мне, так принцип один и тот же.


Не бойтесь, я сто раз так делал :). Но Вы так делать не будете, так что это неважно.


Другого я и не ожидал. Поэтому и оставил вызывающий голый указатель :).

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

Другое дело где (или как) выбранный объект-ссылка будет размножаться? Вот юзер открыл UI нового класса что Вы предложили, выбрал ссылку (обязон) и... какой рез-т ожидается?

Эти шарики и трубочки вообще зачем нужны? После того, как плагин нагенерил их, что пользователь может с ними делать? Если изменится геометрия исходной модели (кубика), что с этими шариками должно происходить?

Ну да, да
За истекшие четверть века в принципе ничего не изменилось, рассуждения бухгалтерской тетки столь же популярны :)

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

Выход плагина может подвергаться различным преобразованиям, напр его можно всяко деформировать, напр гнуть. При этом "шарики и трубочки" будут также гнуться, т.к. они - часть модели. Это может быть желательно или нет.

Ну вот,  опять все свалилось в "наводящие"  :'(

Значить "стиль" всё таки присутствует :).


Вот вместо этой кучи опций и предлагается пара кнопок выбора: для вершин использовать вон тот шарик (из сцены или ещё откуда), а для рёбер вот этот прутик.


Пользователь может взаимодействовать с отдельно взятым шариком? Или он может влиять на геометрию модели, а шарики должны подстраиваться под её изменения?


Ну почему же, в первом же ответе был предложен конкретный вариант. Но опять всё свалилось в то, что он Вам не подходит :). И почему так получается...

А о каких вертексах и ребрах Вы говорите? Это плагин их имеет, потому что ему задается тип создаваемой стандартной модели. А класс-создатель что Вы (вяло) предложили - откуда он их возьмет?

Это все входит в проектирование, готовых ответов нет.

Я знаю почему, типично "вересячья" техника

- городится полный бред (вот типа "стилей"). Автор конечно возражает "да это ж бред" - возможно лучше этого не делать

- городится еще бред, предыдущий пункт повторяется N раз в зависимости от энтузиазма обсуждающих

- наступает фаза "справедливого возмущения". Типа "Вам уже предложили столько решений, а Вам все не так!". "Да ему никогда не угодишь" и.т.п.

Так вот, есди нет ни мыслей ни интереса - идите кушайте свое std, не засоряйте эфир. Спасибо за понимание

Мда уж...

Пожалуй, просто напомню основной вопрос из первого сообщения темы:


Отличная речь, вероятность плодотворного обсуждения резко увеличилась :).

Ну она и так была близка к техническому нулю, так что я ничего не потерял  :)

Ну почему же :). На этом уроке мы узнали, с чем можно ассоциировать термин "текстовый процессор", что такое "стили", что это не только фонты. Что можно упростить UI плагина. Правда, до архитектуры плагина вряд ли когда доберёмся. Он так и будет тупенько лить геометрию.

Реализовал, и в последнее время много с этим работаю. Для интереса расскажу как у меня получилось.

Ну "новая сущность" (виртуальный объект ВО) неизбежна. И с ней (самой по себе) все ясно, эта структура уже мелькала выше

C++ (Qt)
// "Виртуальный" объект = ссылка на реальный + что меняем
struct CVObject {
  TUniqueID m_reference;  // id "реального" объекта
  Matrix m_globalMatrix;    // размещать ВО в сцене надо всегда
  .....                                // и.т.д
  QScopedPointer<Material> m_material; // напр возможно ВО имеет свой материал
  ...
};

Основной вопрос был - а как работать с ВО, напр как их рисовать в окнах если их "нет в сцене" как таковых.

Я решил что создатель ВО их же и хранит, напр
И умеет "экспортировать" их указатели

C++ (Qt)
void CEmitter::ExportVO( QMap<TUniqueID, QVector<QWeakPointer<CVObject>>> & mapVO ); 

Использование связки shared+weak здесь необязательно, просто "в масть"

Теперь как работает рисование. Оно получает на вход контейнер реальных объектов и ничего не знает о виртуальных. Поэтому сначала надо пробежаться по всем объектам, если среди них есть "генераторы ВО" то вылить ВО в мапу, напр
Метод рисования (Draw1Object) смотрит в мапу и знает что для данного объекта возможно существует еще N его "виртуальных копий" и рисует их всех, при этом удобно оптимизируя (напр базовую геометрию можно грузить один раз).

Вот собсно и все, ничего заумного в теме не было  :)