Так же мне хотелось бы заложить поддержку на уровне движка деформируемого и разрушаемого окружения. Ну тут достаточно просто, это лишь часть задачи. Очевидно, что берётся исходная модель, к которой применяются некоторые действия. Причём эти действия необязательно связаны деформацией, главное отличие - это изменение какой-либо информации в модели. Например модели с лайтмапами. В исходной модели информации о лайтмапах нет, всё необходимое записано в карту. Но вертексы там уже иные, либо как в случае последних экспериментов, он развернуты в фан-вертексы. либо если делать по уму, то остаются стрипами, но всё равно добавляется информация о развёртке лайтмапы. То есть вертексы уже не оригинальные. В случае с деформацией, они дополнительно еще и сдвинуты согласно физическим законам. Как это реализовать? В нужный момент, во время игры или на старте делается копия модели, но не полная, а только та часть, которая поменялась, ну в данном случае это вертексы. Т.е. создаётся некая мета-модель со ссылкой на референс. А чтобы не путаться и держать всё в юниформе - она просто помещается в тотже единый массив из всех моделей. Конечно её можно будет сохранить в сейв, если понадобится. Аналогичным образом происходит и разрушение - модель делится на свои обломки, которые гененрируют целую пачку новых мета-моделей, на каждую назначается своя энтить с физикой твёрдого тела. Конечно с BSP такую штуку не проделаешь, но вот со студиомоделями - вполне себе.
точнее говоря, с BSP тоже можно, но бессмысленно, там ведь основной смысл в PVS, видимость. Такое на лету не пересчитаешь.
Добавлено 07-10-2019 в 12:04:
Еще один важный шаг к генеричности надо сделать - убрать из движка любую информацию про worldmodel. Ему не надо знать, что какая-то модель это мир. Для движка все модели должны быть равноправны. Что в свою очередь позволяет потенциально иметь несколько миров, загруженных одновременно и быстро переключаться между ними. И всё это можно реализовать в рамках пользовательской библиотеки.
В сущности у движка привязка к миру сводится лишь к построению overview, но это я уберу, сделаю членом класса модели.
А ну и естественно при таких параметрах нам понадобится хороший такой лимит на эти модели. Тысяч на 16 я думаю. А энтить на 65к. Но лимит на энтити всё равно в игровой части, там их можно будет сколько угодно замутить. Вот только с кол-вом клиентов пока не определился. Их по прежнему остается 32 штуки. Ну да ладно, клиентами я займусь, когда буду сетевую модель переделывать, до этого еще долико.
Так товарищи. Все необходимые подготовительные работы выполнены, я уже избавился от client.dll и подготовил базу для рендерера, частичную, но основные уточнения уже будут непосредственно по ходу разработки, т.к. у меня еще мысль не оформилась, такое только на практике делается, особенно если учесть что для меня это совершенно новый тип рендерера, и поскольку я сам его придумал, то подсмотреть реализацию негде. По остальным саб-системам решение принято, там ничего особо интересного нет, да и движок выбирают за картинку. Так что наступает самая ответственная часть проекта - собственно рендеринг. Посмотрим что у меня получится, ну и в процессе постараюсь вас радовать скриншотами.
А есть ли разница?
Я например в канале пробовал и так, и так - результат одинаковый. А если нет разницы, но видосики при этом требуют больше времени для обработки - то может ну его?
Ну что же написал загрузчик вертексов в видеопамять. Там такая тема, что каждый вертекс должен точно соответствовать кол-ву своих переменных. Нельзя просто завести вертекс, в котором будут все атрибуты на все случаи жизни и использовать его для разных типов данных - будет ощутимо тормозить. Поэтому неплохо бы формировать эти вертексы исходя из данных, которые реально будут использоваться. Но проблема в том, что этих вариантов у меня уже накопилось достаточно немало и прописывать каждый вертекс отдельно во первых трудоёмко, во вторых очень легко запутаться, а в третьих мне еще и две версии надо иметь для старого железа и для нового.
Поэтому я разработал универсальный загрузчик. Здесь кстати, наглядно проявилось то, во что превращается крестовый код, если активно использовать все возможности. Понять что там происходит стороннему человеку уже практически невозможно, это взрыв мозга.
Продолжаю имплементацию материалов. Сейчас именно тот самый момент, от которого зависит насколько будет удобно прописывать материалы по умолчанию. Надо подумать как лучшы сделать. Неявные хинты, дефолтный материал, или еще что-нибудь.
Дядя Миша
Добавь в свой модельвьювер сразу возможность создавать и просматривать эти самые материалы в реальном времени, и дефолтные меши кроме самих моделей, кубик, сфера, цилиндр, конус, плоскость.
В блокноте врядли кто то будет ковыряться.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Дядя Миша
А с отказом от ворлда, возможны ли будут "компилируемые префабы", ну или что-то вроде независимых кусков карты, которые можно вставить в другие карты и обращаться как к единому целому, так и к её составляющим?
Цитата:
Понять что там происходит стороннему человеку уже практически невозможно, это взрыв мозга.
А сам сможешь понять что писал, если, например, через год взглянешь на код?
FiEctro писал: Добавь в свой модельвьювер сразу возможность создавать и просматривать
да почему же именно в модельвьювер?
Тогда уж в материал-эдитор?
Цитата:
thambs писал: А с отказом от ворлда, возможны ли будут "компилируемые префабы", ну или что-то вроде независимых кусков карты, которые можно вставить в другие карты и обращаться как к единому целому, так и к её составляющим?
Отказ от мира не означает, что его не будет. Это означает следующее:
1. явной мировой модели может и не быть и рендерер для этого не надо вводить явным образом в особое состояние, типа установки флажка RF_DRAW_WORLD. Как это реализовано сейчас: перед рендерингом вью-кэш ищет модельку с валидным PVS. Далее он проверяет что текущая позиция камеры попадает в ббокс этой модели и использует её для отсечения видимости.
2. мировых моделей может быть несколько штук, но их конечно надо будет разнести в пространстве. Ну или в игровом коде включать-отключать. Это уже на усмотрение мод-мейкера. Трасса по модели - это часть имплементации самой модели. Правда в классической трассе есть понятие мира, но трасса находится полностью в игровом коде, так что это легко поправить при необходимости.
То есть как это можно использовать: ну компилируемые префабы, да, бесшовная подгрузка уровней, обход каких-то лимитов или скажем просто лепить мир из повторяющихся кусочков. То есть тут масса вариантов может быть.
Цитата:
thambs писал: А сам сможешь понять что писал, если, например, через год взглянешь на код?
Смогу, но мне для этого потребуется какое-то время.
Дядя Миша писал: да почему же именно в модельвьювер?
Тогда уж в материал-эдитор?
Это дополнительный софт писать, да и к тому же можно будет сразу на моделях посмотреть как выглядит тот или иной материал.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Всё что было написано заранее, подготовлено, зачищено, так или иначе свелось к логическому упору, к самому главному моменту - настала пора заменить старый модельменеджер, который оперирует model_t на новый, который CModelBase. Это самая фундаментальная часть движка, на которой базируется абсолютно всё. Так что эта замена потребует порядочно времени, плюс у нового еще не все патчи дописаны, к примеру он умеет грузить только брашевые модели и ничего более. Так что в ближайшие недели новостей не будет. Но когда замена осуществиться - будет уже гораздо веселее, т.к. это самая масштабная часть операции по работе над ядром. Там уже глядишь и скриншоты пойдут, а может и демки.
| IP: 
07-10-2019 09:04
А если нет разницы, но видосики при этом требуют больше времени для обработки - то может ну его?
