Рефакторинг звукового движка, ч. 2 - XashNT
Из предыдущей части, думаю очевидно, что оставлять систему в таком состоянии было нельзя.
Рефакторинг звукового движка, ч. 1 - ретроспектива
Итак, новый звуковой движок уже написан и опробован в деле. Как вы помните, я стараюсь сначала сделать, а потом уже рассказывать, что было сделано. Поскольку XashNT строится на базе Xash3D, то неудивительно что все подсистемы ему достались по наследству, но поскольку современным требованиям они не отвечают, их все надо было переписать, имея работоспособный движок на каждом этапе рефакторинга. На данный момент от легаси-кода осталось совсем немногое: низкоуровневая часть сетевого кода (которая отправляет сетевые пакеты) и сломанный механизм записи-воспроизведения демок. Этим я займусь вероятно уже в следующем году, т.к. на данный момент в приоритете улучшение рендерера (динамический свет) и написание просмотровщика ресурсов, редактора...
Портирование системы частиц Aurora, ч.3 - Архитектура
Портирование системы частиц Aurora, ч.3 - Архитектура
Портирование системы частиц Aurora, ч.2 - Spirit Of Half-Life
Портирование системы частиц Aurora, ч.2 - Spirit Of Half-Life
Портирование системы частиц Aurora, ч.1 - ретроспектива
Портирование системы частиц Aurora, ч.1 - ретроспектива
Система материалов, часть 7
У всех, кто осилил хотя бы просто дочитать предыдущую часть, даже не особо вникая в написанное, неизбежно возникнет закономерный вопрос - как же так, нам обещали простейшую систему, с которой сможет разобраться любой художник, а вместо этого по сути представили чуть ли не полноценный язык программирования с какой-то своей логикой и особенностями. Тут не то что художник, не каждый программист сходу разберётся.
Система материалов, часть 6
Кроме доступа к глобальным настройкам и текущим параметрам рендеринга вы так же можете получить доступ к произвольным переменным внутри энтить, т.е. из HeadShot. С учётом того, что эти переменные будут сперва пересланы на клиент, а затем проброшены в систему материалов и через юниформ попадут в шейдер. Обращаю ваше внимание, что всё это делается без какой-либо модификации исходного кода движка.
Система материалов, часть 5
Теперь когда мы достаточно осветили теоретическую часть вопроса, можно поговорить и конкретной реализации того, как устроена система материалов в XashNT.
Система материалов, часть 4
Я изначально ставил перед собой задачу дать пользователю возможность организовать рендер по собственному усмотрению, разумеется в пределах тех инструментов что предоставляет движок. Но с прицелом на возможную доработку рендера в любой момент, на случай если в движке появятся какие-то новые инструменты и возможности.
Система материалов, часть 3
Тут надо сделать небольшое лирическое отступление и поговорить про организацию, непосредственно рендерера. Практически все имплементации рендеринга, которые доступны в опенсорсе предполагают архитектуру, при которой со стороны системы описания материалов приходят какие-то настройки, которые рендерер самостоятельно копирует в юниформы, затем так же самостоятельно грузит в шейдеры и наконец начинает процесс отрисовки в строго заданном порядке, который даже для forward рендеринга обычно разбит на какие-то нелогичные абстракции, что изначально ещё можно было объяснить наличием фиксированного конвейера, а потом пожалуй просто стало устоявшимся стереотипом. Любопытно, что и для проприетарных, закрытых движков, эта ситуация тоже сохраняется...