не приписывай. Никогда такого не говорил.
У него есть свои достоинства и свои недостатки (с точки зрения естественности изображения)



не очень понимаю но. При физическом увеличении размеров экрана, особенно с одновременным увеличением угла зрения, эффект присутствия улучшиться.



Глаз(+мозг) очень своеобразный инструмент.
Что-то мне подсказывает, что при выполнении точного равенства углов ничего путного не выйдет.
Приведу простой пример:
Рисуем линии, перпендикулярные зрению (параллельно нижней стороне экрана) и уходящие 'в даль'.
Вариант построения - рисуются полностью параллельные линии. Глаз 'не принимает'.
Вариант два: линии, которые находятся дальше получают коррекцию - центр дальше по оси наблюдения, края ближе.
Результат то-же - глаз 'не принимает'. Странно! ... с точки зрения геометрии все правильно, так почему же неприятие???
Вариант три: ... делается АНТИкоррекция - центр линии ближе, края загибаются 'в даль'. И ... глаз воспринимает сие 'шедевр' значительно лучше, даже лучше полностью параллельных линий.
(криво об'яснил, sorry, надеюсь поймешь )



Особенность конструкции ушей - не различается перед/зад.
Право-лево берется нормально, а перед/зад можно понять только по незначительному изменению тембра(спектра) звука.
Игрался с этим на Vortex(1,2), да и в жизни замечал - если не смотришь, то никогда не определишь впереди/сзади если строго по оси.



как 'что будет' - кинь ЛС или на почту.

serj_
Понял - для этого исползуют R-буфер(расстояние по трём координатам, не только по Z), но используют его для сферических(вогнутых типа как у авиа тренажёров) экранов. Проецирование по Z-буферу само вносит искажения(расстяжения по краям), а положение наблюдателя в точке виртуальной камеры это компенсирует(сжатие по краям).

У меня кванты на носу, до воскресенья минимум не будет. Голова не тем занята
Прогу на ПС положу наверное

2Kola т.е. через год (другой вариант - в следующем году)
Нуууу ... как "напишется", поглядим....

serj_ Если сопьюсь перед праздниками - в следующем году. А может быть и в этом, но только завтра или никогда в 2003-м. 31-го делать ничего не буду.

Скорее уж - 'хочу, но не смогу'
.... лучше, не 'комкай' - сделай когда будет насторение и обсудим.
Интересно же.
(если тебе интерено)

http://people.overclockers.ru/Kola/files
Вот что получилось. Да, для шотов из гамеза работает так себе . Гораздо лучше для малоцветных рисунков. Хорошо сглаживает линии 30-60 градусов, остальное так себе. Возможно нужно использовать какие-то нелинейные функции смешения. Поставляется вместе с исходниками на Дельфе. Если кто-то не поймёт алгоритм - я объясню. Если обработать тот шот из Phantasy Star, что я здесь положил то результат будет аналогичен приведёному.
Этот метод идеально сглаживает 45 градусные лесенки(хотя они меньше всего нуждаются в этом, не считая 0-90 градусных) сглаживает. Он использует четыре соседних пикселя. В принципе можно сглаживать лесенки любых наклонов, но потребуется большие матрицы и нехилая математическая база.

З.Ы. Хочу моник с разрешением 1920*1440 и приличным refresh'ем

слушай, чего я делаю неправильно?
Я взял http://overclockers.ru/images/lab/2003/ ... nreal2.jpg и изменений не заметил.
Правда, Фотошопом не смотрел.
... или метод работает только на малоцветных(грубых, резких) картинках?

Впрочем .... пригляделся - на результирующей картинке чуть 'размытее', т.е. действие выполняется.
Можно как-нибудь регулировать 'силу' алгоритма?

Не, действует. Сила и так стоит вроде на максимуме(вру можно ещё прибавить немного без сильного замыливания). jpg лучше не фильтровать - там сами по себе края убитые. И вообще чем больше цветоразностныйскачок на границе тем лучше виден эффект. Поразглядывай лесенки на результирующей и исходной - лучше попереключаться туда-сюда(чтобы картинки на одном месте были) там в некоторых местах, где приблизительно 25-65 градусов наклона виден эффект. Алгоритм такой конечно врядли кому пригодится. Как мне кажется, можно его улучшить, используя здоровые матрицы(для каждой точки учитывая много соседей тобишь) - но это бАльшие вычисления во всех смыслах. Посмотри исходники.

П.С. Нарисуй в Paint'е простых линий и многоугольников на белом или чёрном фоне - там хорошо видно.
П.П.С. Конечно идеальное решение - моник с разрешением хотя бы 150dpi

сделай. Так - мало. (лучше с возможностью выбора)

на том примере меня раздражают стыки полигонов.
Да, jpg не подарок, но 'всеж' (реальный пример же)

да, конечно. .... но для этого надо 'вглядываться', увы.

ну так .... попробуй развить идею, чтоль.

большие вычисления в аппаратном выражении не всегда суперсложны.

чур меня! .... я и в своих путаюсь!!
(а тут еще праздники........)

Уверен, даже пробовать глупо.
Тут другое - тестировать всеже надо-бы .... ну не на совсем 'синтетике'.

Тут 2 фактора:
1) таких никогда не будет. Когда вышел 'самый крутой' монитор от Sony с решеткой 0.22 думали - ща все будут такие .... а 'фиг'!
2) слишком маленькое зерно плохочитаемо. Даже на той-же Sony изображение (текст) очень четкий, но уже _СЛИШКОМ_ мелкий.
0.25-0.28 это оптимальный размер.
Умеличивать стоимость монитора в 100 раз только для 2х уменьшения дискретности и только для 3D .... ну, ты понял.

p.s.
Похоже, ты все-же путаешь понятия. Дискретность шага изображения и ширина минимальной линии - это не одно и то-же.
Если устранить дискретность шага, то вполне устроят современные мониторы.

serj_
Да, я имел в виду не реальное разрешение, а виртуальное. Т.е. пусть сам моник анитиалиазит недостаточным размером точки - я только за. А вот плохочитаемость изображения в высоких разрешениях можно легко править масшабом в мастдае.
Сглаживание сделаю посильнее(с возможностью выбора), но это будет предел - далее только искажения замыливания. Но не сегодня, хотя там пара строк.
По поводу больших матриц - меня не производительность пугает, а просто расчёт алгоритма. Я как-то взялся посчитать для полной матрицы 3x3 с 8-соседями(здесь используется 4) долго ломал голову, но мало чего достиг . Тут математика хорошего надо, а я физик Ну я попробую.

2Kola
я тут сделал пару глупостей, нельзя было на том примере смотреть - jpg 'слизал' края (что еще и не страшно), а вот второе плохо --- картинка была получена уменьшением оригинала в N-раз.
Как я понял, твой алгоритм крайне болезненно относится к подобным 'неправильностям' ...
Короче, сделал новый screenshot http://cp.people.overclockers.ru/cgi-bi ... me=U2S.RAR
Потести на нем.

(теперь эффект очень заметен!)

serj_ Ох как ты заблуждаешься. Не путай ориентированную на весьма(ВЕСЬМА) опредленное DPI Windows с божьим даром. И не думай что ничего принципиально другого сделать нельзя. Ды ты и сам возьми любую программу понимающую векторный шрифт (типа того же ворда или акробата) и запусти на мониторе с большим DPI. Результат замечателен. Уж поверь, я проверил на 19" митсубишевской трубке в 1600*1200*85 (да и 2048*1536*65). А то что интерфейс шелла и стандартных контролов нечитаемым становится - это проблемы БГ и к сожалению пользователей его системы. Я вот слышал об пользовательских интерфейсах на основе постскрипта и IBM-овских 200 DPI ЖК мониторах - и представляю себе такой пользовательский интерфейс на таком мониторе! Но не в этой жизни явно

А оно того стоит, и не только для 3D.
Kola Только текст - действительно никаких проблем. Но все остальное Плывет и мельчает. И все из за дизайна в точка, а не физических размерах.

serj_ Да хорошо заметен. Можно ещё поэкспериментировать с пороговой функцией, но мало даст. Ты заметил, что чем ближе линия к 45 тем качественнее сглаживается. Для меньших углов я писал, что нужно делать - займусь, но тут работа навалилась, блин. Посмотри исходники, если хочешь, хоть и без пояснений, но ведь строчек 20-ть всего по делу. Если надо объяснить алгоритм - могу.

да, но 45 и сглаживать не надо.



Сам же понимаешь ... буду аки слон в посудной лавке - ты уж сам.

Кстати, интересное наблюдение и это может дать реальный шанс применению твоего метода .... надеюсь.
Если не знать где края, то, теоретически, идет тривиальное размазывание ... но,(НО!) края и стыки можно вычислить.
Если идет смена цвета(яркости & etc) в пределах текстуры, то обязательно есть хоть небольшое размазывание (ну, причину ты знаешь:) ), а на краях идет обрубание. Т.е. если детектировать такие места и их и только их тщательно размазывать, то кое-что может выйти.
Именно потому нелбзя приметь твой метод на картинках с сжатием размера или jpeg.
Прости, если глупость сказал.

serj_
Края вычислить - нечего делать. Просто ищется градиент цвета. Это по сути действие фильтра Find Edge(он правда используется в фотожопе немного размазанный) - первая производная по компонентам. Но дело в том, что сглаживать нужно только лесенки - и это непросто. Возможно это алгоритм будет проще выглядеть, если использовать имено производную. Я попробую.

Маленькая идейка(не индейка!) появилась. На CRT мониках(не знаю на всех ли - на моём смотрел) в более-менее больших разрешениях одна точка на однородном фоне выглядит как кружёк. Так вот что, если на стадии рендеринга просто проверять расстояние от центра пикселя до края полигона, если этот край проходит по этому пикселю. А по этому расстоянию по известной функции определять захваченную полигоном часть пикселя. Помоему это проще, чем расчитывать попадание для, скажем, четырёх точек. Прикидывал в Paintе - выглядит ничего. Плюс ко всему - в идеале соответсвует SuperкакеготамFAA inf*inf. Наверное напишу програмку вывода треугольников двумя методами.

P/S/ Вспомнил - SuperSampling называется
P/P/S/ На уровне догадок - в пиксельном конвеере реализовать можно легко.

Добавлено спустя 3 минуты, 27 секунд:
serj_ Сейчас подумал - это очень похоже на твою идею. Только я все вывернул наоборот. Да...

... и что с ним делать? см. ниже


sAA получает параметр 'смещение пиксела от центра сетки', твой - схожий параметр. (разные способы получения этого 'параметра', но это не столь важно)
Второй и, наверно, не менее важный вопрос - ЧТО делать с этим смещением?
Я предложил использовать экстрополяцию(или интерполяцию?) яркостей.
Т.к. sAA (в этой редакции) не говорит о направлении этого смещения (к родному полигону или наружу), то появляются соответствующие дефекты. Думаю, описывать не надо, поймешь.
Т.е., хорошо бы иметь следующие данные:
- смещение от центра
- направление
- куда направлено смещение - К или ОТ родного полигона.
И второе - ЧТО с этими данными делать то??
Просто умно 'размазывать'? .... сейчас тихо вспоминается анизотропная фильтрация ....
И вот еще что - (?НАВЕРНО?)нельзя применять этот метод при построении изображения (фаза наложения слоев). Я ориентировался на пост-фильтр(скорее всего в RAMDAC).

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

serj_ Ну я и говорю о том, что направление не важно(не очень важно), если рассматривать пиксел как кружок или какую-нибудь другую функцию(типа функцию-шапочку) в полярных координатах с центром в центре пиксела, зависящую только от радиальной компоненты, не угловой, то вполне прилично получается. При SSAA пиксель имеет фиксированный набор значений "заполнения" полигоном, здесь нет, как и в твоём способе. Вообще высказанное мной реализуется через твой способ(как я его помню) очень легко - расстояние есть sqr(x^2+y^2), где x и y - смещение от центра.

Ах да - насчёт что делать. Ну если известно расстояние от центра круга(или размазанного круга, или чего угодно с центральной симметрией с центром в центре пиксела) до хорды вдоль нормали к этой хорде, то почитать сколько хорда отрезала очень просто. Сколько отрезала - столько и закрасили.

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

Прогу к сожалению не видел, т.к. видео не nVidia. Шотов тоже получить вроде нельзя. Хотя, пожалуй схожу посмотрю не у себя. А что с кодами? Можно их посмотреть?

Т.е. ты предлагаешь заимствовать цвет соседнего пиксела в зависимости от смещения от центра сетки? (прости, если я тебя не понял!)
Тогда - обязательно надо знать где его родной полигон.
Рассмотрим 2 варианта для случая - точка смещена строго по оси --- чуть влево от центра сетки.
1) родной полигон был слева - проблем нет, все пройдет
2) родной полигон был справа. Произойдет закрашивание этого пиксела неправильным цветом! (т.е. размазывание)
Если знать, что родной полигон _справа_, то смещение точки даже влево от центра должно генерировать неизмененный цвет (in-grid).
Вот почему я говорил о крайней желательности знать где родной полигон.
В следующей редакции sAA я собирался хранить в Delta и признак родной-чужой.




Это все так .... пока не стал сохранять ее в память для постпроцессора(RAMDAC) - там все обрежется 'по-черному'.
... или ты хочеш AA делать еще на этапе наложения текстур?
Тогда ... ой....
Хочешь, напиши тест - выйдет 'не очень'. Я что-то делал и сразу отверг.



Спроси Rainbow, он что-то хотел ....
Я могу и тебе выслать source .... жаль, что вебкамеры нет, то былоб интересно посмотреть твою реакцию ...
Там чистый ASM и заковыристо. Это не защита от взлома ... ... просто пытался оптимизировать скорость.

p.s.
На ATI ее не удалось 'в лоб' перенастроить - у нее нет VESA3 и проблемы с установкой разрешения. Все это чертово DOS-разгильдяйство с стандартами.

Ну я погорячился наверное. Действительно смотря на каком уровне создания изображения вставлять. Я больше подразумевал непосредственно рендеринг. Всётаки попробую что-нибудь написать, правда много навалилось как-то в последнее время. Порой приходится заставлять себя полентяйничать.
Насчёт проги - без проблем посмотрю