H-3D
Я полностью переписал код компилятора моделей, в том числе расчёта касательного пространства. Команда tsgen больше не нужна и была вырезана.
Да, думаю, таких артефактов больше не будет.
Если скинешь smd, def и текстуры этой модели - сразу же и проверю.
Skaarj эта тестовая карта называется "дефолтная коробка с 21 моделькой аликс". Что с ней не так? Задача - показать возможности по отрисовке модельной детализации на стресс-тесте по поликаунту.
Добавлено 25-02-2015 в 03:47:
Эта тема для wip скринов, главным образом технического плана. Для арканосов будет другая тема, но всему своё время.
До меня дошла информация, что на одном популярном украинском форуме Дядя Миша приводит движок Volatile в пример как проект, который бесконечно перезапускается, т.к., мол, автору кажется, что в новой версии он сделает лучше, но воз и ныне там. А вот, мол, джекхаммер был сделан сразу же круто.
Так как ДМ действительно знает об истории разработки моих движков больше среднестатистического посетителя хлфх.ру, я счёл необходимым дать пояснения.
1) Первая версия движка Volatile, тогда ещё 2D, была написана мной на Visual Basic в 2002 году. С той версией, что вы могли видеть, скажем, в Wolfram, у неё общее только название. В дальнейшем я много лет изучал эту хитрую "науку" написания движков. Но т.к. в этом деле практика куда важнее, чем теория, то все свои эксперименты я немедленно облекал в некую форму движка. Который, по иронии судьбы, получал всё то же название "Volatile". Что можно сказать о версиях движка, где я изучал код первой кваки, потом третьей, где была куча копипасты? Да ничего. Разумеется, эти версии забрасывались, как только я разбирался с ядром. Они редко умели что-то рисовать, помимо консольки. И вы их, разумеется, не видели. С дядей Мишей я делился исключительно в образовательных целях (как для себя, так и для него). Последняя версия Volatile3D II - это по сути была тоже "образовательная" версия, где я ещё много чего освоил (физику, динамические тени, ботов и многое другое). После чего я подвёл жирную черту, чего раньше никогда не делал, и заявил, что новая версия движка соберёт всё, чему я научился за последние 13 лет. В ней не будет откровений, каких-то сверх-оригинальных решений по методу Кармака-Ксерокса, но все старые решения будут причёсаны, отлажены и оптимизированы. Это можно рассматривать как работу по переписыванию начисто проекта, по которому за многие годы скопилась куча черновиков. Процесс долгий, ответственный, но тем не менее необходимый. Потому что именно тогда можно будет сказать, что проект Volatile доведён до логического конца. А потом можно будет заняться и чем-то принципиально новым - хоть дефферред-шейдингом, хоть мегатекстурой, хоть динамическим рейтрейсером.
Поэтому пример с Volatile, приведённый ДМ, крайне неудачный. А то, что отдельные товарищи ведутся и верят в подобное очернительство - так это легко объяснимо, ведь я сам никогда не считал нужным рассказывать о том, как именно планирую и веду свою работу. К тому же эти товарищи мгновенно узнают себя - ведь большинство именно так и поступает, начиная и бросая один проект за другим, теряя интерес и пугаясь трудностей. А нет ничего приятнее, чем поверить в то, что твои пороки есть и у кого-то другого.
Короче, не зацикливайтесь на каких-то "старых версиях", смотрите только публичные. А их ровно две - Volatile3D (Extrasensoric, 2009) и Volatile3D II (OIFD, Wolfram, 2012). Те, у кого эти версии не вызывают отторжения - ждите "итоговую версию", которая по идее должна учесть все их недостатки, о которых у меня было достаточно времени узнать.
2) В случае с Jackhammer всё было точно так же, как и с Volatile. Разница лишь в том, что ДМ не знает о предыдущих моих редакторах столько же, сколько о предыдущих движках. 3D-редакторами я занялся чуть позже, году эдак в 2008. Делал кастом-билд ку3радианта, который вы видели в Volatile SDK. Пробовал писать и самостоятельные редакторы. Как минимум два 3D-редактора я написал по работе (они были связаны с молекулами, однако воплощали все основные принципы 3D-редактирования). Но т.к. редактор устроен на порядок проще, чем движок, к подведению черты я логически подошёл раньше. И джекхаммер, как и новая волатила, воплотил все мои знания в этой области. Разница в том, что его вы увидели, а волатилу пока нет. Но всему своё время, повторюсь, движки устроены намного сложнее. А насколько эффективно с моей стороны удаётся "подводить черту" - вы можете судить уже по джекхаммеру. Выглядит ли он как профессиональный продукт, или же как очередная экспериментальная поделка на коленке? Решать, конечно же, вам, равно как и делать выводы о продуктивности такой схемы совершенствования навыков и разработки программных продуктов.
Нужна срочно YOBA-API для волатилы, а то мне уже осто_б_нило писать костыли для обхода вальвовских багов, хаков и идиотизмов. Таким макаром я вообще игрострой брошу...
Сегодня я немного расскажу о системе освещения в Новой Волатиле (ТМ).
Как вы уже знаете, в ней присутствует статическое radiosity, в том числе для неподвижных динамических источников света. Освещение моделей в халфе бралось из лайтмапы под ногами монстра (или игрока), и поэтому также включало в себя компонент отражённого света. Однако в волатиле для более точного пространственного учёта света используется метод light grid. В целом он подобен подходу Quake3, однако был усовершенствован мной для поддержки двух вещей - динамических стилей (читай, моргающих и выключаемых лампочек) и отражённого света. Расскажу вкратце о последнем.
Каждая ячейка сетки light grid содержит три вещи - фоновый компонент света, направленный компонент света и усреднённая нормаль (для применения направленного компонента и делюкс-маппинга). Если существуют источники света, напрямую освещающие ячейку, то направление и компоненты света берутся из прямого освещения. Непрямое (radiosity) при этом используется для модификации цветовых компонентов, т.к. нам желательно учитывать изменение окраски света при отражении от разнообразных поверхностей. Если же ячейка не освещена ни одним прямым источником света, то освещение берётся только из радиосити-патчей.
Внимание на скриншоты. Здесь отключен фоновый компонент, а направленный увеличен так, чтобы быть максимально заметным. Слева - освещение модели с учётом прямого света, справа - с учётом только отражённого.
Как видите, у стенки вектор направления на свет меняется, и по сути это именно направление отражения света. Теперь вернём множитель направленного света в 1:
Понятно, что непрямое направленное освещение даёт существенно меньший вклад в направленное освещение модели. Включим фоновый компонент:
Отметим ещё такой момент: при непрямом освещении отключается бликовый компонент (см. например, на волосы, плечи и ботинки). Очевидно, что отражённый свет достаточно слабый, чтобы не давать яркие блики.
Остаётся добавить, что вышеописанная система применяется для статического освещения. Динамическое вычисляется, что называется, "налиту", включая бамп и тени. Хотя, разумеется, учитывает статический компонент отражённого света, если он есть.
P.S.: я знаю, что у нас на форуме некоторые товарищи люто, бешано надрачивают на высокий фпс, а тут всего 100. Фпс ограничен искусственно в целях получения большей плавности игры. Реальный фпс можно оценить по таймингам frontend и backend (а именно максимальному из них). Это время в миллисекундах, затрачиваемое на отрисовку кадра.
| IP: 
02-02-2015 13:59
