Comments 43
Странно. Последнее изображение противоречит тексту. Написано, что чем ближе линия к середине пикселя, но при этом 2 пикселя ровно посередине (координаты 2:1 и 3:1) явно светлее своих «пар» (2:0 и 3:2 соответственно), хотя их центры и находятся гораздо ближе к линии
Простите за занудство. Но мне потребовалось 4 раза перечитать предложение, чтобы понять о чем вы. Так правильнее:
Написано, что чем ближе линия к середине пикселя, тем темнее, но при этом 2 пикселя ровно посередине (координаты 2:1 и 3:1) явно светлее своих «пар» (2:0 и 3:2 соответственно), хотя их центры и находятся гораздо ближе к линии
Написано, что чем ближе линия к середине пикселя, тем темнее, но при этом 2 пикселя ровно посередине (координаты 2:1 и 3:1) явно светлее своих «пар» (2:0 и 3:2 соответственно), хотя их центры и находятся гораздо ближе к линии
Опечатка в тексте, сейчас исправлю.
Линия пересекает боковые центры этих пикселей (нижний и верхний), а не центр пикселя (геометрический).
В прекрасном университете ИТМО лабораторная по компьютерной графике писалась на ASM, а задание было нарисовать свою фамилию начертанием «от руки». Все, кто хотят вызубрить эти алгоритмы — Welcome to IFMO!:)
Не для слабонервных
Про самую первую картинку: мне на 100% нравится вариант слева — глаза не устают.
Жуть, Брезенхем с плавающей точкой, извращение. Это целочисленный алгоритм, на кой черт там float. В той же вики есть пример на C++, целочисленный.
Разумеется, но приведённый выше читается легче. Во время подготовки статьи я нашёл море разных оптимизаций, но не могу же я их все привести?
Один из бонусов алгоритма Брензенхема состоит в том, что он целочисленный. Я понимаю, что сейчас это уже не актуально, но печально глядеть на то, как люди коверкают сущности.
Это все еще актуально. см мою недавнюю историю.
В статье не указанно, в чём преимущество алгороитма Брезенхема. А именно: в цикле рисования не используется умножение и деление, что было очень актуально, когда процессоры были большие и медленые.
Спасибо за алгоритм сглаженной линии. Брезенхем для сеток давно использовал уже. Не хватает примеров в 100% масштабе. По увеличенным понятно, как оно должно выглядеть, но, иногда, в 100% масштабе выглядит все не так, как представляется.
(y1 — у0)/(x1 — x0)
А если x1=x0?
Тогда деление на ноль. Кроме вертикальной линии, есть ещё три других особых ситуаций: горизонтальная линия, диагональ под 45 градусов и точка. Их можно обрабатывать в начале и рисовать другими способами.
Тогда memset или цикл с присваиванием, что к тому же быстрее.
(y1 — у0)/(x1 — x0)
А если x1=x0?
Извините
(y1 — у0)/(x1 — x0)
А если x1=x0?
Нужно наверное еще гамму учитывать — код цвета пикселя вроде как нелинейно связан с его яркостью. Линии будут менять визуально толщину в зависимости от наклона.
Кроме того, по этому алгоритму концы отрезка получаются неправильные — скошенные по вертикали. Через это непонятно что будет на стыках двух отрезков.
Короче я бы все-таки взял какую-нибудь готовую библиотеку для рисования вектора, нетривиальная это задача.
Кроме того, по этому алгоритму концы отрезка получаются неправильные — скошенные по вертикали. Через это непонятно что будет на стыках двух отрезков.
Короче я бы все-таки взял какую-нибудь готовую библиотеку для рисования вектора, нетривиальная это задача.
Если вы не из параллельной вселенной, где все сидят за векторными мониторами
Я из параллельной вселенной, где на векторныегипертекстовые мониторы выводятся (исключительно ради обратной совместимости!) эти ваши растровые изображения — в виде совокупности закрашенных квадратных фигур со сторонами, параллельными краям монитора.
Бррр. Расточительный расход экранной площади.
Я из параллельной вселенной, где на векторные
Бррр. Расточительный расход экранной площади.
Поглядите на эту полоску: /. Если придвинуться поближе к монитору, то можно увидеть пиксельные ступеньки, которые пытаются притвориться векторной линией.
Те у кого ретина, разглядеть не смогут как ни придвигайся. ))
Sign up to leave a comment.
Брезенхем и У на страже диагоналей