Как стать автором
Обновить

Комментарии 2

Для бесплатных редакторов в web такой подход работает. Но… Все алгоритмы, которые добавляют синтетические точки пересечений с рассчитанными в числах координатами (на промежуточных стадиях вычислений) по большому счету ламерские. Если в сложной закрашенной фигуре при таком подходе сделать очень сильный zoom вблизи рассчитанной точки пересечения ребер, то мы сможем увидеть не закрашенные щели или прорисовку узких фрагментов одной фигуры поверх другой. Это происходит из-за того, что многие решения уравнений (особенно с кривыми Безье) нельзя представить числами с фиксированной (и сравнительно небольшой) разрядностью без потери точности. И эта потеря точности вылезает наружу при сильных zoom-ах. Чтобы победить это, нужно откладывать все вычисления точных координат промежуточных точек до самого последнего этапа, когда будет делаться окончательная отрисовка (растеризация в пикселы). Но тогда промежуточные вычисления и анализ становятся намного более сложными — придется применять ряд подходов, которые используются в системах машинной математики. Например — рациональные числа вместо float, операции над векторами или кватернионы, и т.п. Просто решения через вычисления в float уравнений из школьной алгебры и геометрии будут давать артефакты при сильных zoom-ах (видимые даже в браузерах типа IE при загрузке в них SVG полученных через такие промежуточные вычисления).
Хорошее замечание!

1) Думаю, что и для не бесплатных такой подход тоже работает (Flash Pro). Ибо так уж важны ли очень большие зумы для игровой 2D графики?
2) Подозреваю, что во многом поэтому во Flash существует gaps (т.е. округление всех координат до 1/20=0.05 пикселя). Аналогичное округление приходится делать и мне в NanoFL (до 1/100 = 0.01). А примитивы, схлопнувшиеся до точки — просто отбрасывать. Таким образом, сильно уменьшается вероятность того, что где-то окажется не закрашенная область — ибо мне гарантируются минимальные размеры любой области сильно больше точности вычислений (которая определяется длиной float в лучшем случае и заданной точностью вычислений в худшем (для итеративных численных методов)).
3) Буду рад, если вы приложите ссылку на такой SVG файл. Дело в том, что как раз сейчас я занимаюсь плагином SVG для NanoFL. Среди 200 протестированных файлов мне не удавалось обнаружить артефактов «на глаз». Есть, правда, файл accessible.svg, про который я думал, что там ошибка. Оказалось, что это так и задумано для целей тестирования. Вот картинка:
image
Зарегистрируйтесь на Хабре, чтобы оставить комментарий