Автор просил сразу создать тему для обсуждения, поскольку вопросы наверняка появятся.

Спасибо за отличную статью.
Очень интересная идея... все вроде логично и даже правильно, но неужели все там за бугром настолько тупы? Или это им и нафиг не надо, мол пусть покупают карты помощнее=подороже...
Кстати говоря некоторые подобные идеи реализованы в большинстве графических пакетах, но в 3Д ничего существенно не меняли уже лет 5.

Все круто, только начальный посыл неверный:


Есть мнение, что с FSAA будет 25 FPS... Если только мы не говорим о SSAA на GeForce1 [/quote]

Купи себе телевизор с диагональю 29 дюймов, выставь разрешение 800х600 32 бита и наслаждайся...

1. вопрос к автору - нельзя ли переписать демонстрационный пример под directx? получишь прямой доступ к видеопамяти и т.д.
2. imho: данный метод необходим только для SSAA (GeForce). при ротации пикселов в сетке (Voodoo5, Radeon) как раз и происходит что-то подобное, но с более низкой точностью.

Там что-то криво - предложение с целью не должно представлять собой ссылку на 5-й пункт статьи.

Как мне кажется, автор не понимает о чём пишет , несмотря на несколько грамотных мыслей статья читается грусно ......

Ребят! Не будем обсуждать достоинства/недостатки статьи!!!
Надо подумать как реализовать идею в жизнь!
А может стоит альтернативные драйвера написать? =)
Ну или поковырять и исправить родные дрова!?

fsaa реализуется аппаратно. imho драйверами делу не поможешь.

Как я понял учитывается только влияние цвета соседних клеток по вертикали и горионтали. А цвет клеток по диагонали разве не играет роли и не должен учитываться?

Чем обусловлены столь странные ограничения тестового примера? Используется нечто, кроме линейного буфера видеокарты?

Эффективно применять АА можно, если пользоваться не тупыми глобальными методами как было замечено,
(которые зато не требуют затрат програмирования движка или игры! - вот в чем все дело)
а вставить учет АА в игровой движок или DirectX аналогичным образом, чтобы можно было программировать места где применять АА.

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

Там где нет острых линий - не нужен никакой FS - AA.
Поэтому такие места совершенно легко выделяются.

Сделать можно следующее:
писать письма в микрософт или/и создателям движков.

Чтобы они создавали адаптироанные для АА уровни.
Если это нужно народу конечно.

Статья написана плохо по понятности.
__________________________________________

пример большей проблемы:
Гораздо больше недостает подергивание изображения из за плохой аппроксимации мелких изображений в дискретные пикселы, и непланость картинки из-за переменной производительности(особенно).

Правда кармак обещал в свое мдуме 3 зафиксировать частоту на 60 герцах,
это хорошо, хотя выбор определенного числа- не понятен

Du Volon

не согласен. fsaa нужен не только для сглаживания острых краев. он еще очень неплохо убирает границы mip уровней.


imho это экономически невыгодно никому кроме конечных пользователей.

хх

thanks!

По теме:


говорится о ускорителях на момент генерации идеи и написания статьи - GF4.
'Краевое сглаживание' GF5/R9*** не является FSsAA и должно рассматриваться _отдельно_.



если будешь делать - могу дать алгоритмы и source программы.



Ничего 'что-то подобное' не может быть, прости. Здесь совершенно другая идеалогия. Впрочем .... внешне это может выглядеть и очень похоже.



Судя по отсутствии регистрации эта фраза не нуждается в ответе.



Ну смотри .... вокруг (любой) точки есть 8, с которыми она соприкасается.
Если при растеризации оказалось, что она смещена в некоторую сторону, то эта информация(смещение) сохраняется в ее описании. При втором проходе берется информация о всех 8-и точках, окружающих нужную, и выполняется взаимовычисления. Правда, если учесть тот факт, что при 'обсчете' точек в предыдущей строке и точек в этой строке, но раньше, уже было выполнено 'усреднение', то надобность в пересчете всех восьми каждый раз отпадает.
Короче ... да нее, там и по диагонали все хорошо, в этом методе нет разници 'по диагонали' или нет.



Используется (прямой) линейный буфер и особенность установки разрешения 800*600*32.
Предвижу вопрос - да, на ATI переделать можно.



Я не против! ... тут вот в чем дело - игры делают, чтобы их можно было продать и заработать деньги. Усложнять алгоритм для небольшого улучшения картинки ни один программер не будет. Ответ стандартен 'Мне и так есть что делать!!'. Так что ... 'не будет'.



Знаешь ... я очень не люблю 'тупых' решений, но у FSsAA есть и положительные свойства. То, что мы видем в GF5/R*** - 'краевое сглаживание' - ... короче, 'не выход'. Как это не будет звучать странно, но я за FSsAA! ....
... если скрестить sAA с простым FSsAA, то можно получить очень хорошую картинку с 1.5-2-кратным падением скорости. Да, это неприятно (1.5-2), но для получения схожего режима надо ставить максимум для 'краевого сглаживания'
(что здорово режет скорость), да и все равно качество будет 'не подарок'.



Видел бы ты первоначальный вариант ....
И ... еслиб я начал все разжевывать, получилось бы 20 метров простыней, и все-равно никто ничего не понял. Тема сложная.



Ну ... sAA с этим вроде-бы должна справляться.
А про заметность - да, этот дефект стоит первый по 'вредности' для движущихся об'ектов и особенно, если это фон.
Когда идешь вдоль стены и полоска на ней начинает скакать и переливаться ....



не могу не согласться.

2Du Volon
Про качество .... знаешь, бежать перед паровозом может и почетно, но хлопотно.

Cначала я обрадовался - вот она, первая ласточка, есть еще один человек кроме меня кто размышлял о том - как же так, кино по ТВ выглядит намного красивее чем любая 3Д игра на самом распоследнем видеоаксклераторе при разрешени >=1600... но прочитав до конца сильно разочаровался. Основная ошибка ( недопонимание автора) - теорема Котельникова. Для того чтобы получить изображение разрешением 400 на 200 необходимо устройство вывода разрешением 800 на 600. То есть мы просто не имеем права выводить вертикальную линию шириной меньше 2-х пикселов! Конечно я упрощаю , более формально надо обрезать пространственные частоты выше 1/2 частоты разрешения экрана. Визуально картинка сильно "замылится", но зато изображение будет полностью лишено артефактов дискретизации - как по телевизору. Пример - профессиональные программы 3D графики имеют параметр вроде "размер пиксела". По умолчанию он установлен больше 1 = 1.3 в 3D MAX , но только начиная с 2 мы получаем идеальное изображение. Вопрос - так почему же никто не реализовал это в игровых ускорителях ? К сожалению есть очень много факторов.
Первый - психологический. Человеческий глаз устроен так что имеет "автофокус" - мозг анализирует мелкие детали изображение и подстраивает хрусталик так чтоб сигнал от мелких деталей( контуров) был больше. Но что делать если все изображение не имеет таких деталей ? Мозг в шоке - не знает что делать, доходит до того что думает - попала грязь на роговицу - надо включить слезные железы - промыть. А может причина в том что болезнетворные микробы атаковали роговицу ? на всякий случай послать отряд клеток - защитников для отражении болезни глаза ?. Конечно это мои домыслы но факты говорят за это, именно это и есть причина нашего отторжения нерезкого изображения, "красные глаза", слезотечение при длительной работе с монитором или телевизором.
В результате покупатели берут "неправильные" видеокатры - "погляди, какая четкая детальная картинка ! не то что на этом". По своему они правы, статический текст можно вывести и не обрезая верхние пространственные частоты, фокусировка глаза значительно облегчится. Но как только дело дойдет до движущегося изображения - все ошибки, неплохо описаные в статье, вновь заставят подумать о качестве видеокарты и профессионализме разработчиков. Исправит все это только значительное увеличение разрешения мониторов, мне кажется лет через 10.
Второй фактор - гамма коррекция. Говорить можно много, но применительно к проблеме - те величины которые записаны в видеобуфере это не яркость точки. Это некая нелинейная функция - яркость в степени 1/гамма, для большинства CRT мониторов gamma~2.2. То есть нельзя просто усреднить точки с помощью дешевого сумматора и сдвигателя, надо перевезти в линейное пространство, потом суммировать, потом опять вернуть в пространство напряжений монитора. Вы скажете - какая глупость, надо записывать в линейном пространстве и преобразовывать на лету в RAMDAC . Проблема в том что 8 бит недостаточно для отображения качественной картинки в линейном пространстве. Многие современные ускорители имеют такую функцию , попробуйте выставить в панели управления Radeon 8500 гамму 1, получите белесое изображение, даже если вы перерисуете картинку в новом пространстве в области темных участков изображения заметна сильная полосатость. Это связано с тем что человеческий глаз имеет нелинейную чувствительность, точно не помню кажется логарифмическую, при измененнии яркости в 10 раз мы ощущаем изменение в 2.5. Возможно следующее поколение видеокарт сделает наконец то буфер 16 бит на компонент а еще лучще с плавающей запятой, в этом случае проблема будет решена.
Третий фактор - конечно же инертность разработчиков. Есть великолепно зарекомендовавшая себя Geometric Engine Кларка в далекие 80-е , вариации которой мы и покупаем. Идея настолько проста и эффективна, написаны сотни алгоритмов на базе ее, что рука не подымается сделать массовый переход на что ниб более современное. Всяческие трюкачества вроде аппаатной проверки буфера теней и новомодные шейдеры позволяют довольно дешевыми средствами продлить существование еще долго. Посмотрите на демонстрационные программы с шерстяными бубликами и "настоящим" рельефом http://www.ati.com/developer/demos.html ! И это все взять и выбрость в пользу аппаратного трассировщика лучей с тайловой архитектурой ? Не в эой жизни, увы.
Четвертый -
Кстати демократы и центристы разных "народных сортов" так за 10 лет и не завезли самый завалящий микропроцессор общего применения, а Эльбрус можно сказать похоронен навсегда. Тут АтлонXP и Radeon не заставишь поставить - как же, правильный компьютер это пентиум ( чтоб Пентковскому икнулось ). 150 мгц аналог SUN - это что, верх демократической мысли ? А ведь еще надо OS, программы, игры... вот и осталось нам хныкать в форумах и копить деньги на оптероны радеоны да на дум3.

serj_

да без проблем. сам то писал на чем? на асме? если так, то надо сам код обработки из 16-ти битного кода в 32-й битный переделать. больше проблем не вижу. и работать будет на чем угодно.
мыло: rbws@mail.ru

Народники выбрали следующее -
буржуи пуст изобретают, а мы "позаимствуем",
(благо мы идеологически сильны, а они "пусть будут полезные" для народных людей).
Чего стараться ?

"система располагает" к такому виду эффективности. ("А мы хитрее политически!")

А Буржуи продолжали наивно двигать свои процессоры,
а наши ограничивать зарплату разработчиков на уровне слесаря - "остальное излишне". Результат понятен.

____________________

Не тема такая сложная, а у плохого мастера инструмента всегда виноват.
стараться лучше надо или не мнить про тему по крайней мере, по быстрому разобравшись.

2Du Volon
ты чо разошелся?

Я ответил на представленные вопросы.

про эльбрус и что как делалось, и как бы не повторить.

Или ты " хитрее политически" ?