Здравствуйте, Stanislav V. Zudin, Вы писали:

LVE>>Нашёл одну из первых версий LikeView

SVZ>Занятная игрушка.
Спасибо.

SVZ>Стресс-тесты делал?
SVZ>Скажем, пару миллионов примитивов без анимации нарисовать сможет?
В некотором смысле — да.
У сложных объектов — сделал буферизацию.
У сетки и хендлов — быстрый растровый вывод.
Так что это зависит от уровня рукожопости.

SVZ>Что-то подобное рисовать можно?
Без проблем. Была бы только объектная модель.

SVZ>При работе с тяжелой графикой приходится оперировать с несколькими представлениями одних и тех данных. Скажем, пользователь редактирует объекты, которые лежат в структурах данных в, так сказать, исходном виде, при этом поиск выполняется в 2Д-(или 3Д-)хеше, а рисуются те же объекты, но в триангулированном виде, которые хранятся в виде массива вершин. И таких представлений могут быть десятки — зависит от решаемых задач.
Да. С графами работа отлажена через списки зависимых компонентов.

SVZ>Если в собственном движке все эти представления данных хорошо укладываются и выводятся одни из других, то как с этим обстоят дела в универсальных движках?
SVZ>Вот в твоей архитектуре это учитывается? Её можно будет применить для рисования через OpenGL/DirectX?
Думаю, что здесь будет проблема с HitTest.

SVZ>Кстати, поделюсь опытом. В одном из проектов мой предшественник , которого покусал Александреску, применил Визитёра для работы с данными.
SVZ>Всё было сделано так, как ты мечтал — никакого комбинаторного взрыва , все операции над объектами проходят через единственный метод, а в зависимости от визитёра, подсунутого в этот метод, мы получаем и поиск, и рисование, и формирование тултипов, и перебор объектов с какими-то трансформациями...
SVZ>Но вот проблема в том, что такой приём хорош для лабораторной работы в институте. А в реальной жизни, когда число объектов выросло до пары тысяч вся программа встала колом. Потому что перебор через Визитёр вырождался в O(N^2). А уж отлаживать такой код — проще повеситься. Нам стоило немалых усилий, чтобы выпилить этот шлак и заставить работать как надо.



Тогда я тоже поделюсь опытом.
Во многих подобных иерархиях для компонента делают привязку на родителя или владельца.
Это отнимает внимание программиста на связку компонентов, не говоря уже про небольшой расход памяти.
А когда делаешь многостраничный вывод холста — то эти связки только мешают.

Тогда я поступил просто: Я делаю стек текущих компонентов в классе Контекста.
Экземпляр контекста я передаю в методы компонента при всяких иерархических обходах модели.
Получается так — с какой бы стороны я не зашёл в компонент, его метод знает историю обхода.

Здравствуйте, Stanislav V. Zudin, Вы писали:

LVE>>Нашёл одну из первых версий LikeView

SVZ>Занятная игрушка.
Спасибо.

SVZ>Стресс-тесты делал?
SVZ>Скажем, пару миллионов примитивов без анимации нарисовать сможет?
В некотором смысле — да.
У сложных объектов — сделал буферизацию.
У сетки и хендлов — быстрый растровый вывод.
Так что это зависит от уровня рукожопости.

SVZ>Что-то подобное рисовать можно?
Без проблем. Была бы только объектная модель.
Для примера — нажмите Ctrl+D — это дебажная отрисовка.

SVZ>При работе с тяжелой графикой приходится оперировать с несколькими представлениями одних и тех данных. Скажем, пользователь редактирует объекты, которые лежат в структурах данных в, так сказать, исходном виде, при этом поиск выполняется в 2Д-(или 3Д-)хеше, а рисуются те же объекты, но в триангулированном виде, которые хранятся в виде массива вершин. И таких представлений могут быть десятки — зависит от решаемых задач.
Да. С графами работа отлажена через списки зависимых компонентов.

SVZ>Если в собственном движке все эти представления данных хорошо укладываются и выводятся одни из других, то как с этим обстоят дела в универсальных движках?
SVZ>Вот в твоей архитектуре это учитывается? Её можно будет применить для рисования через OpenGL/DirectX?
Думаю, что здесь будет проблема с HitTest.

SVZ>Кстати, поделюсь опытом. В одном из проектов мой предшественник , которого покусал Александреску, применил Визитёра для работы с данными.
SVZ>Всё было сделано так, как ты мечтал — никакого комбинаторного взрыва , все операции над объектами проходят через единственный метод, а в зависимости от визитёра, подсунутого в этот метод, мы получаем и поиск, и рисование, и формирование тултипов, и перебор объектов с какими-то трансформациями...
SVZ>Но вот проблема в том, что такой приём хорош для лабораторной работы в институте. А в реальной жизни, когда число объектов выросло до пары тысяч вся программа встала колом. Потому что перебор через Визитёр вырождался в O(N^2). А уж отлаживать такой код — проще повеситься. Нам стоило немалых усилий, чтобы выпилить этот шлак и заставить работать как надо.



Тогда я тоже поделюсь опытом.
Во многих подобных иерархиях для компонента делают привязку на родителя или владельца.
Это отнимает внимание программиста на связку компонентов, не говоря уже про небольшой расход памяти.
А когда делаешь многостраничный вывод холста — то эти связки только мешают.

Тогда я поступил просто: Я делаю стек текущих компонентов в классе Контекста.
Экземпляр контекста я передаю в методы компонента при всяких иерархических обходах модели.
Получается так — с какой бы стороны я не зашёл в компонент, его метод знает историю обхода.