MS>Я несколько не о том. Не о формате данных, а о принципах организации данных. SVG и SL предполагают рисование сцены слой за слоем, многократно перезакрашивая по одному и тому же месту. В случае сложной анимации это становится очень медленно. Flash "уплощает" геометрию и использует спепциальную модель данных для этого. Это уплощение выполняется при создании файла, поскольку является довольно дорогой операцией. В run-time этого лучше не делать. MS>http://antigrain.com/stuff/compound_paths.png
Привет, Максим. А как обстоят дела с compound paths в OpenVG?
На настоящий момент я их там не увидел.
Ещё, если не сложно, для общего развития можешь проконсультировать по вопросу?
Существуют ли вообще алгоритмы перевода данных из SVG представления в compound paths и обратно и насколко они дорогие?
Здравствуйте, Cyberax, Вы писали:
C>Мне вот интересно как у современных акселераторов с точностью. В них везде используются float'ы, так что иногда артефакты получаются. В играх это не так важно, но вот для изображений полиграфической точности уже может быть проблема.
Какие именно артефакты? Например, недокрашенные или перекрашенные пикселы на стыках возникают, если только сетка имеет T-junctions, но здесь и двойная точность не поможет. Так же может быть проблема при очень большом зуме, когда линии начинают скакать. Но это уже как бы и не артефакты, а просто ограничение по точности.
AVK>>Во взрослом WPF таки не софтварно. А насчет SL не знаю пока ничего, он еще в очень сырой стадии. C>Кстати, в WPF можно интегрировать трехмерные сцены?
Кстати, забыл спросить — а что такое "взрослый WPF" и где его можно посмотреть? Только на Висте?
Еще раз попрошу, безотносительно к accelerated или нет, проверить вот этот пример на самом что ни на есть взрослом WPF и привести screenshot. http://www.rsdn.ru/Forum/Message.aspx?mid=2475048&only=1
Здравствуйте, minorlogic, Вы писали:
M>1. Всю сцену трасировать как один полигон с информацией о цвете и Z ordering.
Это как? один полигон в SVG может иметь один стиль закраски.
M>2. Spans накапливать в промежуточном буфере для каждой линии scanline, без отрисовки , затем сортировать scanline и рисовать опять же за один проход.
В AGG, в compound rasterizer я именно так и делаю. Теоретически возможно избежать швов в SVG, если, например, растеризовать целую группу (<g>) в один проход. Но вопрос о том, можно ли это сделать или нельзя, является нетривиальным. Например, если в группе есть хоть один полупрозрачный элемент (или подгруппа), то уже нельзя. Или даже некая comp-op, отличная от alpah-blend, то тоже нельзя. Этих "вторичных половых признаков" там много и некоторые из них являются неявными. В общем, перед принятием решения нужно выполнить серьезный анализ данных. Иными словами, нет явной информации о том, что надо растаризовать в один проход, а что — послойно. Кроме того, нет явной информации о смежности областей. Растеризатор с этим справляется нормально, приходится только дважды обрабатывать одни и те же ребра, а вот для тесселятора дублирующиеся ребра могут быть серьезной проблемой.
M>И второй вопрос , как тогда в FLASH обеспечивается плавная анимация ? то есть можно ли получить произвольное к-во кадров или все уже побито на кадры и предобработано ?
Там есть понятие "key frame" и есть простой линейный морфинг для геометрии, аффинных матриц, цветов, градиентов и т.д. См, например, http://www.ncsoft.com/ — типичный геометрический морфинг при наезде на пункты меню.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, korzhik, Вы писали:
K>Привет, Максим. А как обстоят дела с compound paths в OpenVG? K>На настоящий момент я их там не увидел.
Никак. Они больше года жевали сопли по поводу нашего предложения, после чего решили не включать. Хотя API являся бы почти прямым отображением на модель данных compound paths. В общем, "смелые люди, но всего боятся".
K>Ещё, если не сложно, для общего развития можешь проконсультировать по вопросу? K>Существуют ли вообще алгоритмы перевода данных из SVG представления в compound paths и обратно и насколко они дорогие?
Восстановить замкнутые контуры из compound paths возможно и достаточно легко. Просто в точке разветвления берется первое попавшееся ребро с таким же стилем и так до тех пор пока контур не замкнется. При рисовании с правилом even/odd получается все правильно. Да, все контуры с одним и тем же стилем надо рисовать за один проход, чтобы получить правильные дыры.
Обратная задача гораздо сложнее. Она очень похожа на Constructive Solid Geometry. У меня есть кое-какие соображения, но серьезно я над этим пока не думал.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Ты ошибаешься. Оптимизировать рисование плоских многоцветных сцен не просто необходимо, а жизненно необходимо.
У тебя есть каки нибудь аргументы? Или нужно верить на слово?
MS> Впрочем, это долго объяснять, можешь просто поверить на слово
Нет, не поверю. Я точно знаю, что взрослый WPF использует Direct3D для вывода, а артефакты точно такие же.
MS>, что до тех пор, пока в приведенном примере присутствует явно видимые швы, никакого аппаратного ускорения не используется, а используется банальный софтварный растеризатор.
Растеризатор софтварный конечно, с этим вроде никто и не спорил. Аппаратное там наложение и блендинг.
MS> А для него перекрашивать много раз сцену это не просто дорого, а очень дорого.
Он ее не перекрашивает много раз, он просто формирует текстуру. Один раз.
MS> В общем, имеются сильные сомнения, что в обозримом будущем будет задействовано аппаратное ускорение для векторной графики.
Для векторной графики никакого аппаратного ускорения и нет. Только это не имеет никакого отношения к замедлению производительности от многократного наложения.
... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>
Здравствуйте, Cyberax, Вы писали:
C>Мне вот интересно как у современных акселераторов с точностью. В них везде используются float'ы, так что иногда артефакты получаются. В играх это не так важно, но вот для изображений полиграфической точности уже может быть проблема.
ХЗ, возможно проблемы и есть.
AVK>>Во взрослом WPF таки не софтварно. А насчет SL не знаю пока ничего, он еще в очень сырой стадии. C>Кстати, в WPF можно интегрировать трехмерные сцены?
В WPF можно не то что интегрировать, там можно, к примеру, на грань трехмерной фигуры налепить обычные контролы.
... << RSDN@Home 1.2.0 alpha rev. 675 on Windows Vista 6.0.6000.0>>
Здравствуйте, McSeem2, Вы писали:
MS>Кстати, забыл спросить — а что такое "взрослый WPF"
Собственно то, что называется WPF и является частью NetFX 3.
MS> и где его можно посмотреть?
Начиная с XP SP2. Но видеоакселератор нужен не самый дохлый.
MS>Еще раз попрошу, безотносительно к accelerated или нет, проверить вот этот пример на самом что ни на есть взрослом WPF и привести screenshot. http://www.rsdn.ru/Forum/Message.aspx?mid=2475048&only=1
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, minorlogic, Вы писали:
M>>1. Всю сцену трасировать как один полигон с информацией о цвете и Z ordering.
MS>Это как? один полигон в SVG может иметь один стиль закраски.
Стиль закраски это even odd, non zero ? если это тогда нет проблем.
Алгоритм рисовальщика работает по слоям , если я прав. Сначала один объект или группа , затем другой и т.д. Мы просто для каждого слоя храним текущие параметры отрисовки.
В Active Edge Table мы храним для каждого ребра указатель на текущие параметры слоя, то есть сколько было слоев по алгоритму "рисовальщика" , столько заводим данных по текущему winding и т.п. для слоя.
Плюс этого подхода в том что сортировка не на каждую линию сканирования идет, ну и прооптимизировать можно много чего.
И конечно скорость отрисовки на порядок быстрее должна быть , по сравнению с отрисовкой по частям.
Здравствуйте, AndrewVK, Вы писали:
MS>>Ты ошибаешься. Оптимизировать рисование плоских многоцветных сцен не просто необходимо, а жизненно необходимо.
AVK>У тебя есть каки нибудь аргументы? Или нужно верить на слово?
Конечно есть. Если за одно и то же время можно нарисовать сцену вдвое сложнее, то это эквивалентно увеличению тактовой частоты вдвое. Имеешь право не верить, но в области, где я работаю, это очень важно.
AVK>Нет, не поверю. Я точно знаю, что взрослый WPF использует Direct3D для вывода, а артефакты точно такие же. AVK>Растеризатор софтварный конечно, с этим вроде никто и не спорил. Аппаратное там наложение и блендинг.
Нууу, тоже мне рокет саенс. Это не фейерверк, это полюция. Под нормальным аппаратным ускорением можно подразумевать софтварную триангуляцию и рендеринг внутри видеокарты. Только при таких условиях и FSAA возможно рисование без швов.
AVK>Он ее не перекрашивает много раз, он просто формирует текстуру. Один раз.
Для каждого полигона одну текстуру, ага. Которую, заметим, требуется софтварно растеризовать. И чтобы сформировать сцену из 50 полигонов, надо закачать в видеокарту 50 текстур. А поскольку размер текстуры определяется через bounding box, который, в свою очередь может быть размером с окно, то получается 50-кратный перерасход при пересылке данных. Тебя обманули — это не аппаратное ускорение, это называется встроенный аппаратный вечный тормоз.
AVK>Для векторной графики никакого аппаратного ускорения и нет. Только это не имеет никакого отношения к замедлению производительности от многократного наложения.
Именно, что имеет. См. выше, про загрузку текстур. При такой технологии, модель данных типа Flash (многоцветных плоских compound paths) сэкономила бы подавляющую долю трафика через шину в случае анимации. Но они используют модель данных, примитивную как каменный топор.
Ну и потом — а что можно делать с этими текстурами внутри видеокарты? — масштабировать нельзя, вращать тоже нельзя, ибо чревато потерей четкости. Можно только двигать, причем с дискретностью ровно в пиксел. А если надо подвинуть на пол-пиксела или чуть смасштабировать, извольте растеризовать по-новой. А сколько видеопамяти при этом займет даже простейшая сцена?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, minorlogic, Вы писали:
MS>>Это как? один полигон в SVG может иметь один стиль закраски.
M>Стиль закраски это even odd, non zero ? если это тогда нет проблем.
Под стилем я подразумеваю цвет, градиент, такстуру и т.д.
M>Алгоритм рисовальщика работает по слоям , если я прав. Сначала один объект или группа , затем другой и т.д. Мы просто для каждого слоя храним текущие параметры отрисовки.
M>В Active Edge Table мы храним для каждого ребра указатель на текущие параметры слоя, то есть сколько было слоев по алгоритму "рисовальщика" , столько заводим данных по текущему winding и т.п. для слоя. M>Плюс этого подхода в том что сортировка не на каждую линию сканирования идет, ну и прооптимизировать можно много чего. M>И конечно скорость отрисовки на порядок быстрее должна быть , по сравнению с отрисовкой по частям.
Именно так. Но для этого необходима информация о том, что вот эту группу полигонов (с разными стилями!) можно использовать как единое целое для растеризации или тесселяции. Ни в SVG, ни в SL такой информации в явном виде нет, а вычислять по вторичным половым признакам — это сложно и ненадежно. Нужно хотя бы иметь уверенность в том, что "вот эта группа полигонов представляет собой плоскую многоцветную сцену". Поэтому я и говорю, что примитивная модель данных является морально устаревшей и неэффективной.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, minorlogic, Вы писали:
MS>>>Это как? один полигон в SVG может иметь один стиль закраски.
M>>Стиль закраски это even odd, non zero ? если это тогда нет проблем.
MS>Под стилем я подразумеваю цвет, градиент, такстуру и т.д.
M>>Алгоритм рисовальщика работает по слоям , если я прав. Сначала один объект или группа , затем другой и т.д. Мы просто для каждого слоя храним текущие параметры отрисовки.
M>>В Active Edge Table мы храним для каждого ребра указатель на текущие параметры слоя, то есть сколько было слоев по алгоритму "рисовальщика" , столько заводим данных по текущему winding и т.п. для слоя. M>>Плюс этого подхода в том что сортировка не на каждую линию сканирования идет, ну и прооптимизировать можно много чего. M>>И конечно скорость отрисовки на порядок быстрее должна быть , по сравнению с отрисовкой по частям.
MS>Именно так. Но для этого необходима информация о том, что вот эту группу полигонов (с разными стилями!) можно использовать как единое целое для растеризации или тесселяции. Ни в SVG, ни в SL такой информации в явном виде нет, а вычислять по вторичным половым признакам — это сложно и ненадежно. Нужно хотя бы иметь уверенность в том, что "вот эта группа полигонов представляет собой плоскую многоцветную сцену". Поэтому я и говорю, что примитивная модель данных является морально устаревшей и неэффективной.
Или смотрю не туда или туплю. Но мы то можем все эти данные хранить там же в данных для слоя. Слоем может быть каждый отдельный полигон или малтиполигон и т.п. И уже на этапе сканирования scanline пользуем всю информацию по цветам , прозрачности , градиенте , текстуре и т.п.
Может приведешь пример , чтобы сразу было видно в чем сложность, иначе неделю спать не буду ... буду в голове перемалывать.
Здравствуйте, McSeem2, Вы писали:
C>>Мне вот интересно как у современных акселераторов с точностью. В них везде используются float'ы, так что иногда артефакты получаются. В играх это не так важно, но вот для изображений полиграфической точности уже может быть проблема. MS>Какие именно артефакты? Например, недокрашенные или перекрашенные пикселы на стыках возникают, если только сетка имеет T-junctions, но здесь и двойная точность не поможет. Так же может быть проблема при очень большом зуме, когда линии начинают скакать. Но это уже как бы и не артефакты, а просто ограничение по точности.
У меня была проблема с тем, что координаты на сцене задавались в диапазоне от [-1,1]. И при переводе "в пиксели" оно ехало на мелких деталях из-за ошибок округления (пользуясь случаем, хочу передать привет Владимиру Юровицкому).
Мне это было не очень критично — так как при выводе на принтер точности вполне хватало (еще бы, 1200dpi...).
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Во взрослом WPF таки не софтварно. А насчет SL не знаю пока ничего, он еще в очень сырой стадии. C>>Кстати, в WPF можно интегрировать трехмерные сцены? AVK>В WPF можно не то что интегрировать, там можно, к примеру, на грань трехмерной фигуры налепить обычные контролы.
Это, на самом деле, весьма бесполезная вещь. В реальных сложных 3D-приложениях делают свой rendering pipeline, оптимизированый под нужды движка. Ну а для простых приложений, ИМХО, лучше использовать хороший 2D.
Я имел в виду немного другое — можно ли в контекст WPF встраивать контексты рендеринга, например, для OpenGL? Или хотя бы использовать контрол в качестве поверхности для DX?
Здравствуйте, Cyberax, Вы писали:
C>Я имел в виду немного другое — можно ли в контекст WPF встраивать контексты рендеринга, например, для OpenGL? Или хотя бы использовать контрол в качестве поверхности для DX?
Да, и можно ли использовать для контекста WPF _свой_ контекст рисования? Например, сделать на WPF интерфейс для компьютера внутри игры или рисовать WPF на принтер?
Здравствуйте, minorlogic, Вы писали:
M>Или смотрю не туда или туплю. Но мы то можем все эти данные хранить там же в данных для слоя. Слоем может быть каждый отдельный полигон или малтиполигон и т.п. И уже на этапе сканирования scanline пользуем всю информацию по цветам , прозрачности , градиенте , текстуре и т.п.
M>Может приведешь пример , чтобы сразу было видно в чем сложность, иначе неделю спать не буду ... буду в голове перемалывать.
http://antigrain.com/stuff/compound_paths.png
Вот простейшая сцена из трех кружочков. Если все три непрозрачные, то во всех трех вариантах представления даных, мы должны получить тот же результат. Но если мы сделаем красный кружочек полупрозрачным, то в случае layered scene мы получим результат, отличный от двух других вариантов. В первом варианте черз него будет просвечивать синий, а в двух других — белый фон. А компаундный растеризатор, так же как и тесселятор устроен таким образом, что он принципиально уплощает геометрию (в одной точке один стиль) — иначе просто смысла в нем нет. То есть, результат его работы будет идентичен во всех трех случаях, вне зависимости от прозрачности элементов. Но если мы расчитываем на результат layred scene, то обязаны смотреть — если красный кружок полупрозрачный, то мы обязаны нарисовать это все слой за слоем, обычным образом. Если же все непрозрачное, мы имеем право соптмиировать и растеризовать всю сцену за один проход. Иными словами, если все элементы слоеной сцены непрозрачны, то мы имеем право выполнить уплощение геометрии. Если же есть прозрачный элемент, то через него должно быть видно то, что находится под ним в сцене, а не под сценой. Кроме прозрачности таких критериев еще вагон — когда можно, а когда нельзя так делать. Но явной информации не дано. Вообще, проблема похожа на проблему "group opacity" в том же SVG. А во Flash я точно знаю, что compound shape всегда является плоским слоем и спокойно растеризую в один проход. См. agg-2.4/examples/flash_rasterizer.cpp.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, minorlogic, Вы писали:
M>>Или смотрю не туда или туплю. Но мы то можем все эти данные хранить там же в данных для слоя. Слоем может быть каждый отдельный полигон или малтиполигон и т.п. И уже на этапе сканирования scanline пользуем всю информацию по цветам , прозрачности , градиенте , текстуре и т.п.
M>>Может приведешь пример , чтобы сразу было видно в чем сложность, иначе неделю спать не буду ... буду в голове перемалывать.
MS>http://antigrain.com/stuff/compound_paths.png MS>Вот простейшая сцена из трех кружочков. Если все три непрозрачные, то во всех трех вариантах представления даных, мы должны получить тот же результат. Но если мы сделаем красный кружочек полупрозрачным, то в случае layered scene мы получим результат, отличный от двух других вариантов. В первом варианте черз него будет просвечивать синий, а в двух других — белый фон. А компаундный растеризатор, так же как и тесселятор устроен таким образом, что он принципиально уплощает геометрию (в одной точке один стиль) — иначе просто смысла в нем нет. То есть, результат его работы будет идентичен во всех трех случаях, вне зависимости от прозрачности элементов. Но если мы расчитываем на результат layred scene, то обязаны смотреть — если красный кружок полупрозрачный, то мы обязаны нарисовать это все слой за слоем, обычным образом. Если же все непрозрачное, мы имеем право соптмиировать и растеризовать всю сцену за один проход. Иными словами, если все элементы слоеной сцены непрозрачны, то мы имеем право выполнить уплощение геометрии. Если же есть прозрачный элемент, то через него должно быть видно то, что находится под ним в сцене, а не под сценой. Кроме прозрачности таких критериев еще вагон — когда можно, а когда нельзя так делать. Но явной информации не дано. Вообще, проблема похожа на проблему "group opacity" в том же SVG. А во Flash я точно знаю, что compound shape всегда является плоским слоем и спокойно растеризую в один проход. См. agg-2.4/examples/flash_rasterizer.cpp.
Понял , но зачем же нам растеризовать "плоский слой" если мы в один проход можем растеризовать все слои ?
Если объекты полупрозрачны , то нам по любому придется рисовать по одному месту несколько раз (или хакнуть простые варианты). И в варианте рисования всей сцены, мы конечно при отрисовке скан лайна примерно так рассуждаем.
1. встретили первый спан , рисуем
2. встретили второй спан, если он из этого же слоя , выполняем winding rule.
3. если слой чужой, выбираем
а) если спан поверх текущего , значит рисуем его.
б) если спан ниже нашего, продолжаем рисовать текущий спан.
с) если кто то из спанов полупрозрачен , комбинируем слои с учетом Z ordering , а это необходимо делать в любом случае.
Тогда каждый пиксел вс равно рисуется только один раз.
Невидимые полигоны/пикселы не рисуются а просто скипаются.
когда требуется комбинация слоев , выполняем ее сразу для целого пиксела со всеми слоями и по возможности оптимизируем (откидываем лишнее).
Здравствуйте, McSeem2, Вы писали:
MS> То есть, результат его работы будет идентичен во всех трех случаях, вне зависимости от прозрачности элементов. Но если мы расчитываем на результат layred scene, то обязаны смотреть — если красный кружок полупрозрачный, то мы обязаны нарисовать это все слой за слоем, обычным образом.
А почему бы для полупрозрачных областей не предвычислять их цвет?
Здравствуйте, Cyberax, Вы писали:
C>У меня была проблема с тем, что координаты на сцене задавались в диапазоне от [-1,1]. И при переводе "в пиксели" оно ехало на мелких деталях из-за ошибок округления (пользуясь случаем, хочу передать привет Владимиру Юровицкому).
C>Мне это было не очень критично — так как при выводе на принтер точности вполне хватало (еще бы, 1200dpi...).
Флоаты имеют 7 десятичных значащих цифр вне зависимости от порядка. Ну пусть мы огрубим и возьмем 6. Уж 6 достоверных десятичных цифр мы точно имеем. 1200dpi * 10" = 12000, то есть необходимы 5 значащих цифр для представления координат с точностью до пиксела (на самом деле, ближе к четырем). Значит в 6 значащих цифрах мы можем представить координаты с точностью в 0.1 пиксела. Десятикнратный зум должен обеспечивать точность в пиксел и только на стократном точности явно не хватит. В принципе, для прецизионной картографии точности флоатов реально не хватает.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
C>>А почему бы для полупрозрачных областей не предвычислять их цвет? MS>Если цвет сплошной, то конечно. А если там градиент или текстура?
Интересный вопрос...
А если попробовать и их предвычислить? Определенные виды градиентов можно заранее скомбинировать. Хотя согласен, в общем случае вряд ли получится.
