Тени с учетом карты высот
vec4 shadowCoord = shadowMatrix * vec4(eyePosition + eyeNormal * height * 0.3, 1.0);
Таким образом, мы создаем фейковую точку, расположенную выше реальной поверхности, и тень для нее будет рассчитываться как если бы поверхность была действительно рельефной. Эффект особенно заметен на краях тени, углах и скруглениях – там, где при обычном расчете теневых координат была бы сплошная тень, появляются освещенные участки:
Главный недостаток метода – расчет теневых координат происходит пофрагментно, а не повершинно, но на современном железе это не слишком большая жертва.
Не знаю, использовалась ли такая техника раньше, и как она называется – может быть, что-то вроде height-corrected shadow mapping?
Уроки по Dagon

Также недавно я получил в свое распоряжение руль, и, соответственно, добавил поддержку рулей в Dagon (вернее сказать, улучшил уже существовавшую обертку над API ввода SDL2). Пример Dagon с машиной уже работает с рулями – надеюсь скоро выложить видео.
Планы на будущее следующие: в ближайшее время собираюсь довести до ума поддержку PBR-материалов, после чего выпустить Dagon 0.7 с новым HDR-рендером. Дальше, скорее всего, буду смотреть в сторону deferred rendering, поскольку на прямом рендере стало уже сложно получать современную картинку.
Почему не Go?
Go – это выражение идеологии, согласно которой у программиста нужно отнять все “слишком мощные и опасные” инструменты, чтобы исключить для него возможность выстрелить себе в ногу. Go не способствует полету программистской мысли, вместо этого он вынуждает программиста тратить время на решение проблем, которых в других языках попросту нет.
Go игнорирует весь опыт и успехи языкотворчества последних 30 лет. Отсутствие шаблонов, нормального ООП, перегрузки функций и операторов, арифметики указателей – все это не имеет ничего общего с идеей простоты, о которой любят говорить евангелисты Go. Это реакционизм, желание закрыть глаза и не видеть современных задач, решение которых требует современных инструментов. Язык застрял в 70-х – технологии должны стремиться к простоте, но не к опрощению.
Go использует сборщик мусора. В D он тоже есть, но там можно написать свои собственные шаблонные New и Delete и писать в стиле C++, просто игнорируя сборщик мусора. Если вы попытаетесь сделать что-то подобное в Go, вам будут мешать все силы ада. Линус Торвальдс как-то сказал, что язык не может считаться системным, если он пытается скрыть от программиста механизм выделения памяти (“Any compiler or language that likes to hide things like memory allocations behind your back just isn’t a good choice for a kernel”). Он, правда, имел в виду C++, но тем не менее.
В Go неэффективная костыльная совместимость с C. Не знаю, как для других, но для меня C.int и C.char – это вырвиглазный ужас. Я уже не говорю о том, что вызов внешней функции в Go влечет переключение контекстов – учитывая, что ни один нормальный проект не обходится без библиотечных вызовов, тут уж просто без комментариев.
Наконец, Go почему-то не разрешает ставить открывающую операторную скобку на новой строке – это как-то связано с отказом от обязательной точки с запятой в конце утверждения. Для кого-то, наверное, это не проблема – это один из общепринятых стилей, но я лично люблю ставить скобку на новой строке, и не понимаю, почему обязан изменять своей привычке.
Подводя итог: хайп вокруг этого языка мне совершенно не понятен. Я не знаю, в каких именно областях хорош Go – какую ни возьми, везде найдется более подходящий язык. Для игр он точно не подходит. Go обычно позиционируется как современная замена C, но когда заходит речь о реальных задачах, которые решаются при помощи C, евангелисты Go кричат, что они не входят в область применения языка. Так чем же она ограничена, эта область? Консольными утилитами? Если выбирать между Go и C, то я уж лучше выберу C.