на расстоянии 24 юнита от излучающей поверхности спавнится фейковый поинтлайт с яркостью 0.05 от исходной яркости этой поверхности.
Цитата:
FiEctro писал: Пол и стены пересвечены, а потолок чёрный.
пересвечены потому что яркость не настроена. Потом подгоню и еще раз сравним. В принципе, прямой радиосити тоже несложно делается - надо просто наспавнить вместо патчей - кучу таких же маленьких лампочек. А результат сохранять сразу в лайтмапу, вместо патчей. Это даст оптимизацию по памяти. Не возникнет ситуации, когда памяти хватило на прямой свет, а на индиректе всё вылетело на последних секундах рассчёта.
Единственный минус такого подхода, в отличие от Instant Radiosity - каждый баунс по времени считается столько же, сколько и первый. С другой стороны, кол-во лампочек на каждой итерации должно уменьшаться. Правда это не получится так красиво уложить как СЛАУ с патчами. Ну посмотрим.
Добавлено 10-08-2020 в 16:48:
Ну в этой задаче самое главное что - иметь конвейер, который ложится на архитектуру GPU. То есть мы в принципе не можем уйти от схемы лампа-свет. Никаких ухищрений с патчами-интерполяциями тут быть не может, это не ляжет на видеокарту никак в реалтайме.
Добавлено 10-08-2020 в 16:50:
Ну и да, лампочки должны быть параметрическими, без чёткого разделения на типы, проще говоря - без лишних условий. Т.е. вот эти вот light_point, light_spot, light_sun не должны присутствовать.
Готовность движка достигла 50%-ной отметки. Я намеренно опускаю все прошлые попытки и эксперименты, к которым я так или иначе возвращался на протяжении прошедших десяти лет. Частично об этом можно почитать в этой теме.
Скажу только лишь, что изначально мы с Ксероксом рассуждали примерно в одном направлении - GoldSource отличный движок, но многое в нём устарело, мешает груз совместимости со устаревшими форматами, в частности текстурами в вадах. Надо просто взять и отрезать всё лишнее и получится совершенно свой, простой и удобный движок. Я отказался от этой идеи еще в 2016-м году, а Ксер проследовал по этому пути до контса и у него получилась Волатила. Насколько эта концепция удачна - судить пользователям. А я решил двигаться дальше, рассудив, что на движке неплохо бы делать игры, с детализацией уровня сталкера, метро и тому подобного. Ну то есть там не должно быть технологий, которые при сильном наполнении, наоборот, начинают тормозить разработку и отрисовку. Путь, этот, как вы понимаете, был непростым и небыстрым. Часть технологий была обкатана еще на рендерере второй паранои. Разработка движка фактически началась с первого марта 2019-го года, продолжалась месяц, потом была стопнута, поскольку мне необходимо было выпустить финальные ревизионные билды для Xash3D, XashXT и P2.
Всё это отняло три месяца - апрель, май и июнь. Собственно полноценная работа началась вот с этого момента.
Т.е. движок в разработке уже 13 месяцев. Очевидно мне понадобится еще столько же времени, чтобы выпустить первую публичную пре-альфу (разумеется промежуточные версии будут доступны раньше). Давайте посмотрим, что было сделано за это время и что только предстоит еще сделать:
1. Движок полностью переписан на С++
2. Новая концепция пользовательской части (client.dll больше не будет)
3. Разработана новая уникальная система материалов без строгого языка их описания и с возможностью для пользователя, создавать абсолютно любой рендерер, не затрагивая, собственно движок (признаться этот момент волновал меня больше всего).
4. Разработана концепция единого формата хранения моделей\уровней\спрайтов, где каждый из типов потенциально наследует свойства соседа, если это вдруг понадобится и обладает широчайшими возможностями по встраиванию одних моделей в другие.
5. Разработан новый формат для хранения 2D-графики - шрифты, элементы меню, худа.
6. Полностью переписано меню, появилась возможность формирования собственных меню из скрипта.
7. компиляторы уровней и статического освещения. С учётом вышенаписанного - высокополигональные модели не должны замедлять компиляцию.
8. Новый рендерер с data-driven архитектурой.
9. Очень сильно переписана игровая часть движка, в плане архитектуры и концепции, но сами энтити пока что остались прежние.
Теперь, что еще осталось сделать в будущих 50%.
1. финализация единого формата хранения геометрии. Тут еще довольно много работы на самом деле, т.к. необходимо всё это корректно увязать в любых комбинациях, но к этому предрасполагает сам структура его организации. Надо просто быть внимательным.
2. финализация компилятора освещения, добавить радиосити, возможно сделать опционально запекание сферических гауссовых лайтмап или любой другой модерновой техники, благо формат позволяет добавить практически любой алгоритм такого плана за считанные часы.
3. финализация рендерера - добавление недостающих элементов, мультипроходности, мультирендеринга в текстуру и вывод контроля за этим в пользовательскую часть. Дополнение и расширение концепции.
4. Физика. Ну главным образом конечно коллизия. Коллизия будет построена еще на этапе компиляции. Солвер в сущности уже не так важен. Да и не возлагаю я на эту физику каких-то особых надежд, ну пусть бочки катаются, а персонажы ставят ноги точно на поверхность.
Потом можно будет постепенно добавить еще каких-то глупостей.
5. Организация пользовательской части. Ну скорее всего будет вынесена в скрипт-машину, чтобы избавить пользователя от общения с языками общего назначения. Этот момент пока еще не продуман толком.
6. Сеть. Частично завязано на скрипт-машину, т.к. в ней будут хранится описания полей, которые передаются по сути. Аналогично и предиктинг удобнее реализовывать, опираясь на мета-информацию. Бакэнд менять смысла нет.
7. Универсальный МешВьювер. Здесь проще, т.к. формат единый.
8. Собственный редактор уровней\окружения. Поправде говоря этот пункт выпадает за время разработки движка и идёт отдельной задачей. Так что вместо него будет на первое время просто плагин к Джеку.
Так же следует отметить, что движок отличает сверхвысокая совместимость со всеми старыми играми, под которые вы так любили кубать - ку1, ку2, ку3, хл1, дуум3. Но совместимость эта не находится в движке, наоборот он про нее ничего не знает. Совместимость достигается формированием пользовательских настроек и материалов. Разумеется, каждый волен настроить и создать для себя уникальную рабочую среду и вести разработку в дальнейшем именно в ней.
Это и есть ключевая особенность будущего движка.
>> Скажу только лишь, что изначально мы с Ксероксом рассуждали примерно в одном направлении - GoldSource отличный движок, но многое в нём устарело, мешает груз совместимости со устаревшими форматами, в частности текстурами в вадах. Надо просто взять и отрезать всё лишнее и получится совершенно свой, простой и удобный движок. Я отказался от этой идеи еще в 2016-м году, а Ксер проследовал по этому пути до контса и у него получилась Волатила. Насколько эта концепция удачна - судить пользователям.
Я не раз предлагал разбить ядро на модули. Чтобы он поддерживал как старый ксаш так и новый. И переключаться между ними так же как между модами, и позволять пользователям писать свои (например форки). Само ядро не должно быть ориентировано ни на какие форматы или игровой код.
Всё остальное пользовательские модули, которые можно ложить прямо в корень ксаша ввиде дллок:
xash.dll, xashnt.dll, albatrosfork.dll, beiskaarja.dll
FiEctro писал: Чтобы он поддерживал как старый ксаш так и новый
что ты имеешь в виду под поддержкой старого ксаша?
Поддержка и так останется, но на этапе разработки. Бинарная совместимость не нужна. Я больше скажу - благодаря моей концепции системы материалов, вы даже Волатилу сможете сэмулировать, если это кому-то потребуется.