Швидкий антиаліазний малюнок ліній

Лінійний алгоритм Брезенхема - це спосіб малювання прямих, використовуючи лише швидкі цілі операції (додавання, віднімання та множення на 2). Однак він генерує в’язані лінії. Чи існує аналогічно швидкий спосіб намалювати протиалізійні лінії?

antialiasing pixel-graphics line-drawing

— Позначити
джерело

Пару запитань ... ти займаєшся логікою малювання на процесорі чи графічному процесорі? Крім того, ви шукаєте алгоритми на основі цілих чи плаваючої точки?

— Алан Вулф

@AlanWolfe, цілі алгоритми на процесорі - те саме середовище, для якого був розроблений алгоритм Bresenham.

— Марк

en.wikipedia.org/wiki/Xiaolin_Wu%27s_line_algorithm є класичним, хоча сторінка wikipedia досить напівфабрикатна, і я не маю доступу до папери. Це здається ледачим запитанням, оскільки це досить легко знайти, зробивши якийсь основний гуглінг.

— yuriks

Думаючи лише вголос, я вважаю, що слід легко адаптувати Бресенхема для малювання ліній товщиною в кілька пікселів. Тоді ви можете зробити антиализацию, обчисливши відстань кожного піксельного центру від математичної ідеальної лінії та застосувавши деяку функцію випадання.

— Натан Рід

Я не можу позначити коментар як правильний.

— Марк

Чи існує аналогічно швидкий спосіб намалювати протиалізійні лінії?

Ні, тому що за визначенням антизадана лінія торкається більшої кількості пікселів. Такі алгоритми будуть повільнішими.

У програмному растеризаторі повсюдним способом малювання антиалійних ліній є алгоритм ліній Xiaolin Wu . Це не важко реалізувати, і все одно за цим посиланням є незвично якісний псевдокод.

У апаратній растровій трубі лінійку примітиву розширюють на квадратичний простір екрану за замовчуванням (або наданий користувачем) геометрію шейдера, а потім малюють у вигляді двох трикутників, які потім можуть бути антисексуальними звичайними способами.

У Raytracer є найрізноманітніші варіанти. Варто подумати про те, як ви насправді хочете намалювати 1D об’єкт. Може, як циліндр (ву-тіні!). Зауважте, що це вводить питання перспективи / скорочення, які можуть (а можуть і не бути) такими, якими ви хочете. Не існує чіткого узагальнення. Тоді, очевидно, що б ви не робили, ви просто переглядаєте це.

— imallett
джерело

"і в будь-якому випадку на цьому посиланні є незвично якісний псевдокод", я не згоден. Цей псевдо-код, ймовірно, не є належним втіленням алгоритму Ву, хоча він, здається, був використаний у незліченних місцях в Інтернеті. Оригінальний алгоритм Ву просунувся з обох кінців всередину до центру і був фактично швидшим, ніж Брезенхем, тому що він виконує приблизно вдвічі більше операцій, хоча записує на більше пікселів. Я говорю про власне алгоритм Ву, а не про той, який розміщено у пов'язаній статті Вікіпедії.

— Восьминіг

@ Октопод [Висловлює розпливчастий скептицизм, особливо щодо швидшого біта, але не вистачає контексту для спростування або підтвердження - якщо це так, джерела, виправлення та редагування, звичайно, вітаються.]

— imallett

Залежить від того, що ви розраховуєте. Якщо ви малюєте з обох кінців всередину, то алгоритм Ву виконує половину обчислень, але вдвічі більше, ніж пише піксель. Дивіться таблицю 1 у статті Ву, пов’язаній у Вікіпедії. Отже, якщо записи пікселів коштують дорого, як це буває при записі в TFT через послідовне з'єднання, то алгоритм Ву дорожчий, ніж Брезенхемський. (Слід визнати, я не бачу, чому алгоритм Брезенама також не може використовувати симетрію.)

— Jan-Åke Larsson

Але я погоджуюся з @Octopus, навіть приймаючи "малювати з одного кінця в інший", псевдокод є алгоритмом Ву, лише якщо ціла арифметика використовується в усьому. Код, який я бачу в Інтернеті, використовує арифметику з плаваючою комою, що є суттєвою зміною. У статті Ву алгоритм використовує лише цілу арифметику (або фактично арифметику з фіксованою точкою).

— Jan-Åke Larsson