Ребят, спешу поделиться информацией, которую наконец удалось найти по теме создания ssbump-текстур. Объясню в кратце что это такое, чтобы не было лишних вопросов. Те кто давно в курсе - ничего нового не узнают.

Как известно, Valve гордится тем, что реализовала систему самозатенения в движке OrangeBox образца 2007 года. Работает она только на шейдере LightmappedGeneric, но все равно является более чем "вкусной". Суть ее заключается в том, что эффект рельефа помимо привычной карты нормалей дополняется картой высот, и она видна как при обычном освещении, так и при работе фонарика (отбрасываются тени, чего не наблюдается при бампе). И запечатывается все это в одну текстуру (карта высот - в альфа-канале). Все бы ничего, но у нее есть особенность - карта нормалей хранится в особом виде, засчет которого накладывается дополнительная информация о тенях (то чем заведует например ambient occlusion на моделях), и все это (ВНИМАНИЕ!) работает даже быстрее, чем обычная карта нормалей засчет предварительного расчета некоторых операций, которые раньше делал шейдер. Соответственно главным вопросом было - как создать такую текстуру Честно говоря не проверял на практике, будет ли работать обычная карта нормалей с картой высот в альфа-канале, может быть.. Но эффект от нее 100% будет куда меньше, а вкусностей хочется.

Ну вот и настал момент (турум-пум-пум) - вот оно: http://forums.facepunchstudios.com/...ad.php?t=529746
По этой ссылке можно попасть на тутор по созданию текстур ssbump и скачать прогу, с использованием которой это делается. Хотя ссылку на прогу дать могу и я) Скачиваем отсюда: http://www.xnormal.net/Downloads.aspx Прога знатная нужно сказать, судя по описанным возможностям. В кратце - кухонный комбайн по созданию различных карт нормалей, occlusion, карт высот, конечно же на основе моделей.

В качестве затравки приведу изображение Valve и одну из их текстур ssbump. Пример использования:
"LightmappedGeneric"
{

"<dx90"
{
"$fallbackmaterial" "nature/rockwall_cave02a_dx8"
}

"$basetexture" "nature/rockwall_cave02a"
"$surfaceprop" "concrete"
"$bumpmap" "Nature/rockwall_cave_02a_height-ssbump"
"$ssbump" "1"
"$normalmapalphaenvmapmask" 1
"$envmaptint" "[ .2 .2 .2 ]"
"$envmap" "cubemaps/cubemap_cave01"
"%keywords" "ep2"
"$seamless_scale" 0.005

"LightmappedGeneric_hdr_dx9"
{
"$envmaptint" "[ .2 .2 .2 ]"
"$envmap" "cubemaps/cubemap_cave01"
}

}

Не знаю..Для меня большинство новоиспечнных фишек както не радует.Потому что для ксс,дэв-матча() , додс-а и т.п. игр не предусмотрено.Двигло старое,это огорчает что они "двигаются" вверх, а на старые игры забили.Выпуская фиксы для игр,а не обновляя их по человечески.

"$bumpmap" "Nature/rockwall_cave_02a_height-ssbump"
"$ssbump" "1"
"$normalmapalphaenvmapmask" 1
"$envmaptint" "[ .2 .2 .2 ]"

Stone, а точно карта высот в альфе у карты нормалей? Ведь выделенные зеленым ключи как раз используют альфу карты нормалей как какрту отражений (specular map). По моему все проще - самозатенение делается путем вревращения самой карты нормалей в новый вид + ключ "$ssbump" "1"

Т.е. в простейшем виде получается что то типа:
"LightmappedGeneric"
{
"$basetexture" "nature/rockwall_cave02a"
"$bumpmap" "Nature/rockwall_cave_02a_height-ssbump"
"$ssbump" "1"
"$surfaceprop" "concrete"
}

Дык)

Решение было давно.

Но вообще, это как-то не тру - рассчитывать окклюжн оффлайново)) Челябинские шейдеры настолько суровы...

Кстати, Ураган прав, в альфе энв-маска лежит, а не хайтмапа.

manJak
Ну я помню до сих пор тутор как карты нормалей делать с помощью фотика.. Но вручную обрабатывать каналы - не тру)

А с альфой - угу, пасиб за корректировку. На то что это карта высот очень наводит вид этого альфа-канала. Собственно ИМХО они заюзали карту высот для данного случая в качестве маски отражений - типа наиболее высокие области должны лучше отражать, то что глубже - сидеть себе тихо и не высовываться)

Ох, мир усложняется

Это к лучшему, Лекс Реализовали б они такую штуку для Моделек - вот вкусно-то было бы!

то ли дело раньше, один диффуз на 256 цветов и все довольны были


хорошо бы) ну и так неплохо то что есть фонг, rim lighting и "advanced material rendering" )

Кстати, в составе сдк есть прога height2ssbump, с ней никто не разбирался? Я пытался ей tga файл с картой высот скормить, но или делаю чего неправильно, или она просто нерабочая(

Ыыы) Действительно есть
Но правда не работает)
Противно что даже usage не выдает.. Но это поправимо - я поковырял экзешник и вот что нашел:
-D Write out the filtered result as filterd.tga
-f NUM Set smoothing filter radius (0=no filter, default = 10)
-A Generate ambient occlusion in the alpha channel
-n Generate a conventional normal map
options:
-r NUM Set the number of rays (default = 250. more rays take more time).
format is 'height2ssbump filename.tga bumpscale'
-ssbump.tga -bump.tga filtered.tga

Перепробовал различные варианты - молчит зараза Может у кого получится..

Нашел доку официальную о "фичевости" ssbump'а, которую все найти снова не мог, и плюс еще очень интересную их публикацию о реализации пост-процессинг эффектов в Эп2 и Портале:
http://www.valvesoftware.com/public...rmalMapping.pdf
http://www.valvesoftware.com/public...heOrangeBox.pdf

P.S. Кто-нибудь может дать ссылку на описание настройки Rim lighting'а? Честно говоря пока вообще себе слабо представляю как он работает и что делает0_о

Хым. Пролистал, но надо будет почитать) Спасибо.


Тут кой-чего есть по этому. Вообще этот рим лайтинг - ни что иное как эффект Френеля - поверхность отражает сильнее под острыми углами. Определяет это IOR материала, но в VertexlitGeneric можно регулировать коэффициенты коэффициента Френеля. Для этого служит $phongfresnelranges. Дефолт - "[0.0 0.5 1.0]" (оставляет коэфф. без изменений). Первое значение - множитель для нуля градусов между нормалью и взглядом, последнее - для 90, ну и второе - для 45 градусов.
А теперь желательно забыть всё что я "объяснил" сходить в википедию.

А с тулзятиной этой попробую поковыряться)

зы: Крик душы: Я как посмотрел код их моушынблюра, чуть со стула не сполз. Они парили мозг журналистам (и нам, соответственно) аккумуляционными буферами, а в итоге размывают картинку по вектору. Короче, в очередной раз убедился, что переделка МБ - дело стоящее))

Ссылка не работает
Но ничего, я знаю что ты хотел дать - у меня оно есть в закладках..
Получается интересно, что для rim освещения есть отдельный параметр, экспоненту задающий, а углы Френеля для Фонга и для него одни и те же? Или тоже разные 0_о

А про моушн - тут я не спец, вот что скажу) Понравилось описание того, как он адаптивно применяется только для нужных частей экрана.. По ходу реальную скорость перемещения чего-либо никто не считает? 0_о Т.е. допустим ситуация - несется что-то мимо тебя - оно будет в моушн блуре? При таком подходе нет.. (правда я что называется "полистал", может там и про это написано - времени ноль вообще...)

В ссылку коварно затесалось <br />.. О_О


Похоже на то. Но, тут такое дело: в старом (первоэпизодовском) шейдере экспоненты рима и фонга были одним целым. В оранжбоксе их разделили, но $phongfresnelranges по-прежнему общий.
На всякий случай прикрепил материальчик, в котором я со всем этим игрался. Выглядел он так. =)


Именно. Учитываются только угловая и линейная (по вертикали) скорости камеры... Горизонтальную можно в консоли включить, но всё равно это всё неправильно) Ведь всё размывается вне зависимости от расстояния до камеры. Скай в том числе - а ведь он не движется относительно камеры вообще, ибо условно бесконечно удалён. =) Я потому и взялся за по-объектный блюр, но пока только шейдеры в RenderMonkey спроектировал))
Нудаладно, не буду особо голову забивать)

Скай ещё как вращается относительно камеры о_О

Вращаться вращается, но не смещается линейно)

Смазываться должно то, что движется относительно тебя. Согласен, здесь неверно сделано, что смазывание лишь при движении камеры действует, но оно очень правдоподобно. Разберись подробнее. А про смазывание объектов в движении - минус Вальвам.