Проект с кодовым названием Cursed Earth

[v1s0r]

К сожалению, не могу пока поучаствовать в обсуждении оперативно, а тем более в разработке - решаю проблемы с новым компом ^)))

2levdev: попробуй, как и сказал Altair, взять значение высоты из моб и прибавить к высоте ландшафта. Именно прибавить, а то я просто тупо перезаписываю значение. И не забудь убрать хак из функции get_height, там где + 1.0f)))

Скоро вернусь и замутим ещё какую-нибудь мега фичу)))
Кстати, почти готов первый комплект обещанных мной документов про анимационную систему. Скоро отдам вам на ревью.

[levdev]

К сожалению, не могу пока поучаствовать в обсуждении оперативно, а тем более в разработке - решаю проблемы с новым компом ^)))

2levdev: попробуй, как и сказал Altair, взять значение высоты из моб и прибавить к высоте ландшафта. Именно прибавить, а то я просто тупо перезаписываю значение. И не забудь убрать хак из функции get_height, там где + 1.0f)))

Скоро вернусь и замутим ещё какую-нибудь мега фичу)))
Кстати, почти готов первый комплект обещанных мной документов про анимационную систему. Скоро отдам вам на ревью.
[right][snapback]40179[/snapback][/right]

В свободное время сделаю, тоже тут редко появляюсь...
На меня упал "сайт по ключ" и две верстке...

[v1s0r]

Готово описание формата fig.
Кому интересно или нужно - см. в этой теме (программирование, формат .fig).

[v1s0r]

Готов релиз проекта версии 1.2

Что нового:

1. Немного повысил производительность.
С помощью mapviewer теперь можно загрузить портал (zone19). Мне удалось полетать на 8-10 fps на моём старом компе. Единственное но - при низкой камере. Тут уже никуда не денешься... Работы буду продолжать и продолжать ещё очень долго...

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

3. Часть геометрии перенёс в видеопамять, освободив немного системной. В планах перенести часть вычислений на GPU, разгрузив CPU (обновление всех объектов с анимацией сейчас сжирает ~50 fps).

4. Парсер командной строки переписал и перёс в движок. Источник вдохновления - прекрасный optparse из стандартной библиотеки Python. Читать справку по -h сейчас удобно и легко. Это важно, т.к. игра будет поддерживать только коммандную строку. Вся системно-зависимая работа, в частности реестр, будет из стартера. Он же будет формировать итоговую командную строку для запуска игры.

[Durane]

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

[right][snapback]40200[/snapback][/right]

сортировка нужна для этого

1. делается две очереди. В одну на рендер попадают обычные объекты, а во вторую прозрачные.

2. рисуешь первую очередь (можно отсортировать от камеры по удалению и будет оптимизация филрейта по ZBuffer)

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

[v1s0r]

сортировка нужна для этого

1. делается две очереди. В одну на рендер попадают обычные объекты, а во вторую прозрачные.

2. рисуешь первую очередь (можно отсортировать от камеры по удалению и будет  оптимизация филрейта по ZBuffer)

3. Рисуешь поверх очередь прозрачных объектов. Обязательно отсортируй от дальнего к ближнему объекту.
[right][snapback]40201[/snapback][/right]

Спасибо за попытку, но это неприемлемо. Вот почему.

Нет никакой возможности правильно отсортировать объекты. Часто объект представлен одним мешем.
Представь 2 дерева, стоящих рядом. Мы отсортировали их кроны, но некоторые ветки дальнего девера находятся ближе веток ближнего дерева. Результат - некорректная картинка.

Т.е. нужно бить объекты на треугольники, сортировать их все (!) и отсылать на рендер.

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

На самом деле здесь не нужно ничего сортировать и делать многопроходные алгоритмы, ключ - мультисемплинг. Странно, что сразу к этому не пришёл, впервые с этим столкнулся на таком уровне. Сегодня первая победа на win32. Качество как в ПЗ. Добиваюсь того же на lin и в выходные будет релиз. Очень надеюсь решить ещё все проблемы с расположением объектов на сцене. Мы потихоньку идём к счастию ^)

[ALtair]

Спасибо за попытку, но это неприемлемо.

Омг. Подход, описанный Durane'ом используется во всех современных графических движках и во всех поголовно играх класса выше ССС.

Т.е. нужно бить объекты на треугольники, сортировать их все (!) и отсылать на рендер.
Нечто подобное я сделал - получил более менее приличный результат, но о количестве вычислений и о fps умолчу.

Собстно ожидаемый результат. Треугольники никто (или почти никто) не сортирует. Если и сортируют, то на этапе "компиляции" уровня, в редакторе, во время его сохранения и только для отдельных участков сцены, которые постоянно обращены к наблюдателю одной стороной.

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

Гхм. Мультисэмплинг тут ваще при чем? Мультисемплинг - это технология антиальязинга, т.е. технология, позволяющая избавиться от лесенок в картинке и сгладить их. Никакого отношения к прозрачности оно не имеет вообще.
Ссылки на тему:
http://en.wikipedia.org/wiki/Multisampling
http://en.wikipedia.org/wiki/Supersampling
http://en.wikipedia.org/wiki/Antialiasing

[v1s0r]

Имеет и ещё какое...

http://www.codesampler.com/oglsrc/oglsrc_14.htm
Alpha Blending with Multisample Transparency


Добавил: v1s0r [mergetime]1269893496[/mergetime]

Собстно ожидаемый результат. Треугольники никто (или почти никто) не сортирует. Если и сортируют, то на этапе "компиляции" уровня, в редакторе, во время его сохранения и только для отдельных участков сцены, которые постоянно обращены к наблюдателю одной стороной.

Ты хочешь сказать, что те же деревья нужно всегда ориентировать "правильной" стороной к наблюдателю? Если поделишься опытом от ei model view - буду очень благодарен...

[ALtair]

Имеет и ещё какое...
http://www.codesampler.com/oglsrc/oglsrc_14.htm
Alpha Blending with Multisample Transparency

Потрясающе %) Ты дал ссылку на какой-то левый пример, на каком-то левом сайте, который у меня на компьютере при запуске выдает картинку БЕЗ полупрозрачности, т.е. кубик полностью НЕпрозрачный. Причем тыкание на кнопку "B", которая в теории должна переключать режимы, ни к чему не приводит вообще (предвещая вопрос, у меня GF 8800GT).

Если же говорить вообще о технологии Alpha-to-coverage, то это как бы совсем не то, о чем шла речь выше. По сути A-to-C - это advanced alpha-test. Эта технология позволяет добиться мягких сглаженных краев на текстурах, на которых используется 1-bit alpha, т.е. на текстурах с _маской прозрачности_. Да, в ПЗ почти повсеместно именно такие текстуры, однако хочу заметить, что во времена ПЗ никаких alpha_to_coverage не было.

К тому же эта хрень для нормальной человеческой работы требует видео-карты 7+ поколения (nVidia GF 7xxx, ATI X1xxx). На видео-картах прошлого поколения оно работает только в виде хаков, а позапрошлого - вообще не работает.

Ну и подытожу тем, что с помощью этой штуки ты не сможешь отрисовать стеклышко под водой. Стеклышко с водой тебе все равно придется сортировать и рисовать по очереди.

В теории есть технологии, позволяющие рисовать полупрозрачные объекты не сортируя. Называется это все обычно Order-independent transparency (http://en.wikipedia.org/wiki/Order_indep...ansparency). Как можно заметить на странице википедии в списке предложенных кандидатов по решению проблемы отрисовки полупрозрачных объектов без сортировки никакого Alpha-to-coverage нету.

Ты хочешь сказать, что те же деревья нужно всегда ориентировать "правильной" стороной к наблюдателю? Если поделишься опытом от ei model view - буду очень благодарен...
[right][snapback]40205[/snapback][/right]

Нет, речь шла не о том, что нужно объекты поворачивать к камере. Речь шла о том, что сортировать треугольники имеет смысл тогда, когда ты заранее знаешь, что у тебя объект или группа объектов при отрисовке не будет требовать пересортировки этих треугольников при изменении позиции или направления взгляда наблюдателя. И еще раз повторюсь, треугольники никто не сортирует.

[IDoL]

2Altair
Я, возможно, буду глупо выглядеть, но все же спрошу.
Если перебор треугольников не стоит использовать, то что же стоит?
Дважды перерисовывать тоже не выход (и результаты рендера порой получаются не самые лучшие).
Тоесть в кроне дерева(один объект), состоящей из "веток с листьями"(треугольники с текстурами с альфа), происходит множественное перекрытие треугольников.
Первое, что приходит на ум - сперва рисовать треугольники находящиеся дальше от камеры. Для этого нам надо сортировать треугольники веток - не годится.
Таким образом метод предложенный Durane не годится.
Для перебора моделей с прозрачностью он бы сработал, если бы не наложение [частично прозрачных] треугольников внутри объекта.
(Вообще я не совсем понимаю как решать с прозрачностью объект или нет - пробегать все текстуры при загрузке и смотреть их на предмет альфа?)

К технологиям Order-independent transparency, я так понимаю, Вы относитесь с некоторым скепсисом.
Так что же можно использовать при рендере крон деревьев - изначально определенным образом отсортированом множестве наложеных друг на друга частично прозрачных треугольников?

[ALtair]

Дважды перерисовывать тоже не выход.

Смысла в двойной отрисовке я вообще не вижу.

Тоесть в кроне дерева [skip] происходит множественное перекрытие треугольников. [skip] Для этого нам надо сортировать треугольники  веток [skip]
Таким образом метод предложенный Durane не годится.
Для перебора моделей с прозрачностью он бы сработал, если бы не наложение [частично прозрачных] треугольников внутри объекта.

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

Есть такая поговорка в программистских кругах: "90% результата достигается за 10% времени, а остальные 90% времени тратится на достижение оставшихся 10% результата". То же самое применимо и к алгоритмам. Сортируя только объекты можно добиться относительно "качественной" картинки с высокой производительностью но с осознанной скидкой на мелкие артефакты, видимые на отдельных редких объектиках.

(Вообще я не совсем понимаю как решать с прозрачностью объект или нет - пробегать все текстуры при загрузке и смотреть их на предмет альфа?)

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

К технологиям Order-independent transparency, я так понимаю, Вы относитесь с некоторым скепсисом.

Это не я отношусь со скепсисом Просто нормальный OIT реализуется только на DX11. А на младших DX'ах он реализуется либо с ограничениями, либо через анус. Чисто для справки, в UE3 его нет, объекты сортируются по удаленности от камеры, треугольники на объектах НЕ сортируются, из примитивов сортируются только квады партиклов, ибо это относительно "просто" и их обычно не много. Но опять же, сортировка партиклов происходит только в пределах одного эмиттера. Если в сцене присутствует партикл-система с двумя эмиттерами или две разных партикл-системы, то они будут рисоваться одна целиком поверх другой в зависимости от того, чей "центр" ближе к камере.

З.Ы. Или может UE3 вам тоже не авторитет? :lol:

[IDoL]

Нет почему же. UE3 вполне авторитет. Не хотел чтобы мое сообщение показалось агрессивным. Значит OIT не используем.

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

На данный момент вопрос стоит именно как сделать чтобы одна ветка была видна через другую ветку в одном объекте

2 отрисовки - это рисование сперва с отключенной записью в Z-буфер а потом второе рисование уже с ней fps падает(однако перерисовка исключительно для прозрачных объектов не будет приводить к сильной просадке производительности). Кроме того с этой системой свои проблемы.

Я, возможно, чегото неправильно понимаю - прозрачность находится в текстурах ПЗ, верно? Прозрачность может быть в любой точке текстуры практически любого объекта. Тоесть для определения прозрачен ли объект нам необходимо определить существуют ли области с прозрачностью в текстуре данного объекта.
А для этого нам надо пройти по всем пикселам растра(или по пикселам растра которые содержатся на каждом треугольнике модели) и посмотреть альфа там 1 или 0. Или же у текстуры есть какой флаг обозначающий "в текстуре прозрачность!"? Можно конечно составить списки для текстур. Это ускорит загрузку, но это не лучшая практика - хардкод, что делать с новыми текстурами и пр.

Добавил: IDoL [mergetime]1269950892[/mergetime]
Если есть возможность, было бы здорово узнать какой алгоритм используется в ModelViewer для рисования веток дерева.

[ALtair]

На данный момент вопрос стоит именно как сделать чтобы одна ветка была видна через другую ветку в одном объекте

Я тут уже в третьем сообщении подряд распинаюсь на тему того, что такой вопрос не нужно ставить.

2 отрисовки - это рисование сперва с отключенной записью в Z-буфер а потом второе рисование уже с ней

В таком режиме у тебя второй проход рендеринга должен полностью затереть первый. Еще больше стало непонятно, нафига оно надо %)

Я, возможно, чегото неправильно понимаю - прозрачность находится в текстурах ПЗ, верно? Прозрачность может быть в любой точке текстуры практически любого объекта.

Или же у текстуры есть какой флаг обозначающий "в текстуре прозрачность!"?

Вообще-то у текстуры есть формат. Если текстура записана в формате, в котором присутствует alpha-компонента (DXTn, ARGB8, etc), то сразу можно сделать вывод о том, что объекты с этой текстурой нужно "сортировать". Сегодня, к примеру, у художников одно видение объекта и на текстурке нету никаких областей с нулевой альфой, а завтра приходит новый арт-директор и говорит "тут надо все перерисовать, вот тут будут дырки, тут будут арочки, а тут у нас должен быть вензель". Естественно никто вензель, арочку и прочие дырки геометрией рисовать не будет, сделают полупрозрачную текстурку... И вот если закладываться на какие-то "списки", то мы тут же получим баг А если закладываться на формат - все будет продолжать нормально работать. Если же художник решит, что на объекте не должно быть полупрозрачности и она на нем не нужна вовсе, он положит на него текстурку в формате R5G6B5, в котором альфа-компоненты нет. Но тут есть проблема - прозрачность можно задать отдельно глобально для объекта установкой соответствующих стейтов девайса, настраивая правильный блендинг (для D3D гуглить D3DRS_DIFFUSEMATERIALSOURCE, D3DMCS_MATERIAL, D3DTA_DIFFUSE + D3DTA_TEXTURE + D3DTOP_MODULATE). Тут в силу вступает как раз понятие "материала", о котором ниже.

Тоесть для определения прозрачен ли объект нам необходимо определить существуют ли области с прозрачностью в текстуре данного объекта.

Обычно, как я говорил уже выше, это определяется исходя из свойств "материала", с которым рисуется данный объект. Конфигурировать пайплайн кастомно под каждый объект - это застрелиться можно. Поэтому обычно выделяют несколько типовых "конфигураций", которые и называют в общем смысле "материалами" (это актуально для FFP). Так вот при отрисовке сцены у тебя есть набор типовых "конфигураций", к примеру, из 5-10 штук. Все объекты бьются на списки в соответствии с тем, какой "конфигурацией" они должны быть отрисованы. В состав же "конфигурации" обычно входит в том числе и установка флажка на Alpha test или alpha blend. При переходе к программируемому пайплайну "материалом" становится сущность-агрегатор шейдера, набора текстур и шейдерных "констант".

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

Никакого %) У меня в ModelViewer ничего никуда не сортируется, так же как и в ZoneView (редактор карт который), ибо оно в девелоперских тулзах не нужно. "Качество картинки" тут вовсе не стоит во главе угла. При рендеринге я включаю и Alpha test и Alpha blend. Все пикселы, альфа которых ниже пороговой отбрасываются, а для всех, у которых выше - используется альфабленд.

[IDoL]

Почему вопрос о видимоости всех веток в любой момент времени не стоит ставить я не понимаю - они ведь должны быть видны. Они видны и в EI и в ModelViewer
Девелоперские тулзы будут разрабатываться на том же движке, следовательно надо чтобы во вьюверах все выглядело как в игре(ну возможно без освещения и пр)

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

Я был уверен что у текстур ПЗ одинаковый формат... пойду разбираться дальше.

Было очень интересно, спасибо.

[IDoL]

Все же не понимаю каким образом в EIModelViewer рисуется модель кроны дерева(например nafltr60 tree02).
Видно все листья с любой стороны дерева с несколькими перекрывающимися ветками... А вот границы (градиент от цвета фона до цвета пиксела текстуры) между видимой и невидимой частью текстуры аналогичны таким же в CE.

Никакого %) У меня в ModelViewer ничего никуда не сортируется, так же как и в ZoneView (редактор карт который), ибо оно в девелоперских тулзах не нужно. "Качество картинки" тут вовсе не стоит во главе угла. При рендеринге я включаю и Alpha test и Alpha blend. Все пикселы, альфа которых ниже пороговой отбрасываются, а для всех, у которых выше - используется альфабленд.
[right][snapback]40210[/snapback][/right]

Перечитал еще раз - как находятся пикселы у которых альфа ниже пороговой?
И куда они отбрасываются - их значение не записывается в Z-буфер?
Я так понимаю что проблема в том что из-за Z-буфера у нас просто не рисуются перекрываемые ветки - если в пикселах с прозрачностью не изменять значения Z-буфера они будут прорисовываться как и должны. Но для этого же нам необходимо выполнять проход по отрисованым пикселам? Или меня не туда понесло...

[ALtair]

Почему вопрос о видимоости всех веток в любой момент времени не стоит ставить я не понимаю - они ведь должны быть видны. Они видны и в EI и в ModelViewer

Ну я наверное не так выразился. Я имел ввиду, что не стОит пытаться сортировать полигоны для того, чтобы были видны ветки. В том же ModelView все видно и без всяких сортировок. Где-то что-то в CE не учтено. Что именно - не знаю, ибо в код такой мне страшно заглядывать, о чем я уже писал выше.

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

Ну, это будет работать только в том случае, если рисовать каждый отдельный ОБЪЕКТ сразу по 2 раза. И то это будет работать только и исключительно для этого объекта. Это костыль мегаужасный.

Перечитал еще раз - как находятся пикселы у которых альфа ниже пороговой?

В D3D задается помимо флага D3DRS_ALPHATESTENABLE еще и такие параметры как D3DRS_ALPHAREF и D3DRS_ALPHAFUNC. В качестве функции можно задать всякие "больше", "меньше", "больше или равно", "равно" и т.д. Сравниваться значение альфы рисуемого объекта будет соответственно с тем значением, которое задано в качестве ALPHAREF. Если задать ALPHAREF = 0x3F и ALPHAFUNC = D3DCMP_GREATEREQUAL, то все пикселы растеризуемого объекта, у которых альфа-компонента результирующего цвета будет меньше 63 просто не будут в результате растеризованы (т.е. отрисованы). Т.е. показываться на экране будут только те пикселы, у которых альфа больше или равна 63 (это в диапазоне [0;255]).

И куда они отбрасываются - их значение не записывается в Z-буфер?

Z-buffer в общем-то тут вообще не при чем, однако в целом ответ на поставленный вопрос - да. И еще добавлю, что значение этих пикселов не будет записано не только в Z-Buffer, но и в Color-Buffer. Как будто и не было пиксела вовсе.

Добавил: ALtair [mergetime]1269960393[/mergetime]
И да, есть подозрение, что в CE тупо не включен альфа-тест

[IDoL]

Да, я уверен что это именно то
Значит я правильно понял
Надо смотреть что тут в OpenGL.

Спасибо за наводку!

[v1s0r]

Ну всё встало на свои места...
Текстуры для некоторых объектов в формате dxt1, где небольшой альфа канал. Он, фактически, даёт ответ на вопрос "есть" или "нет". В CE был включено альфа смешивание, но не альфа тест.
Технология billboarding))) 2Altair: можно было бы избежать написания ненужных тем выше, если бы ты сразу сказал...
Эффект абсолютно такой же, как и с FSAA, но без потери fps... супер


Добавил: v1s0r [mergetime]1269973015[/mergetime]
п.с. спасибо!

[Guest]

А почему просто не использовать метод предложенный мною и использовать альфамаску. Все деревья в ПЗ сделаны по alphatest без использования alphablending.

[ALtair]

Эффект абсолютно такой же, как и с FSAA, но без потери fps... супер

FSAA там только сбоку прилеплен, и суть технологии вовсе не в нем, давайте уж называть вещи своими именами. FSAA (MSAA и SSAA) - это технология сглаживания экранных лесенок, не более. И не важно, сглаживает ли оно альфа-бортик или цветовые границы геометрии. А то, о чем говоришь ты - это Alpha-to-Coverage.