HLFX.Ru Forum - XashNT: блог разработчика

Страницы (2): [1] 2 »
Показать все 3608 сообщений этой темы на одной странице

HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Наши проекты (https://hlfx.ru/forum/forumdisplay.php?forumid=1)
-- XashNT: блог разработчика (https://hlfx.ru/forum/showthread.php?threadid=5297)

Отправлено Дядя Миша 03-07-2019 в 11:44:

XashNT: блог разработчика

Разработка движка так или иначе носит характер ключевых звеньев, цепляющихся одно за другое. Одна из фундаментальнейших вещей это организация уровня. Всё остальное так или иначе строится вокруг нее. И от этого естественно вплотную зависит конечный результат. Посмотрим. У меня уже был неудачный опыт в 2015-м году, но ведь на тот момент я во всём этом разбирался гораздо хуже. Это вторая итерация, задача имеет следующий вид:
1. построить формат уровня, отвечающий современным требованиям. То есть как минимум он должен спокойно переваривать детализацию уровня Metro Exodus, ну или что-то в этом духе. Но при этом уметь компилировать и старые-добрые карты, типа ad_sepulcher. Вообщем необходимо достигнуть баланса между брашами и моделями, чтобы каждый для себя мог выбрать оптимальный способ построения левелов. Кому-то нравится делать уровни моделями? Пожалуйста, из брашей будут использоваться только триггеры и водичка. Ну и скайбокс конечно. Нравится кубать брашами - аналогично нет проблем. То есть вот такое на первый взгляд противоречивое требование. Это задел на потенциальное расширение аудитории движка в будущем.
2. Компиляция должна проходить быстро. Чтобы как минимум избежать справедливых упрёков в том, что иные движки вообще начисто её лишены. Сами понимаете если у нас будут уровни, где 5-6 миллионов полигонов в кадре, тут уже старые методы не конают. И уж конечно ни в коем случае не ждать пока лайтмаппер неделю освещает уровни как в Сталкере, я почему-то подозреваю, что в Метро от лайтмап отказались именно из-за калечной запекалки. Никому не охота ждать неделю, например. И кстати это одна из причин, по которой сталкера так долго делали. Ну не единственная конечно. Но компиляция здорово крадёт время у разработчиков.
Ну для начала я полагаю достаточно, поскольку это довольно сложные требования. Посмотрим что из этого получится, в этой теме я буду писать о проделанной работе, а вы будете говорить "автор молодец за нее".

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-07-2019 в 13:30:

Поскольку ожидается большая порция экспериментов связанных с изменением формата карт, моделей и прочего, я решил написать универсальный базовый класс-абстракцию, от которого будут наследоваться все типы моделей. В теории это позволит иметь зоопарк форматов, но у меня несколько иная цель. Кстати говоря этот же механизм может быть использован для бесшовной подгрузки новых уровней.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 04-07-2019 в 14:31:

Цитата:

Дядя Миша писал:
я решил написать универсальный базовый класс-абстракцию, от которого будут наследоваться все типы моделей

Движок будет на Java, как Майнкрафт?

Отправлено XaeroX 04-07-2019 в 16:23:

Crystallize
Ты действительно этого хочешь?

__________________

Отправлено FiEctro 04-07-2019 в 16:31:

Ну вот, а говорите я ваши движки обсираю. Сразу видно прогресс, а то так бы до пенсии на кубсп и сидели.

Цитата:

Дядя Миша писал:
2. Компиляция должна проходить быстро. Чтобы как минимум избежать справедливых упрёков в том, что иные движки вообще начисто её лишены.

Не лишены, и далеко не быстрая, но фишка в том что во время разработки можно загрузить голую модель без компиляции. Вообще в современных движках под компиляцией подразумевается уже финальная обработка локации когда всё готово, а не пересобирать карту каждый раз чтобы передвинуть какой нибудь патч трек.

Цитата:

Дядя Миша писал:
Кстати говоря этот же механизм может быть использован для бесшовной подгрузки новых уровней.

Могу немного подкинуть идей. В том же унити есть такая фигня как сцена, это просто описание где и какие игровые объекты находятся в 3д пространстве, и с каким настройками. Их можно загружать/выгружать как тебе удобно.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!

Отправлено Дядя Миша 04-07-2019 в 17:17:

Цитата:

FiEctro писал:
а не пересобирать карту каждый раз чтобы передвинуть какой нибудь патч трек.

но для этого и не надо пересобирать карту...

Цитата:

FiEctro писал:
это просто описание где и какие игровые объекты находятся в 3д пространстве, и с каким настройками

уровень можно делать незамкнутой моделькой, но тогда не будет виза. Это основная проблема. Я могу нагенерить лод-брашей, основываясь на контурах моделей (невидимых), и эти брашы решат две задачи - коллизию и виз.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 04-07-2019 в 18:21:

Цитата:

FiEctro писал:
Сразу видно прогресс, а то так бы до пенсии на кубсп и сидели

Ты сильно не переживай, в Волатиле такого "прогресса" не будет. Убивать Юнити и уеч придётся кому-то другому.

Цитата:

Дядя Миша писал:
но для этого и не надо пересобирать карту...

Только не рассказывай ему про -onlyents.

__________________

Отправлено FiEctro 05-07-2019 в 05:50:

Цитата:

XaeroX писал:
Только не рассказывай ему про -onlyents.

Как бы это тоже компилятор делает

Отправлено nemyax 05-07-2019 в 21:28:

Цитата:

Дядя Миша писал:
я решил написать универсальный базовый класс-абстракцию, от которого будут наследоваться все типы моделей. В теории это позволит иметь зоопарк форматов, но у меня несколько иная цель

Какая же?

Отправлено FiEctro 06-07-2019 в 07:54:

nemyax
Наши цели ясны, задачи определены, за работу, товарищи!

Отправлено Дядя Миша 20-07-2019 в 08:18:

В какой-то мере вышеозвученная идея реализована в том же даркплейсе, но поскольку он на чистом Си, там конечно нет никаких виртуальных методов, там указатели на функции. Идея в том, чтобы не просто сделать такие загрузчики, а чтобы разместить в наследуемых классах абсолютно все методы взаимодействия с загруженными ресурсами, выведя за скобки лишь описания текстур и материалов. То есть вот у нас стандартные методы, LoadModel, DrawModel, CollideModel и через них осуществляется взаимодействие. А внутри может быть как BSP, там и студиомоделька. Што немаловажно, подобный подход, позволит, например иметь в качестве мира эту студиомодель. Или загружать одновременно следующий уровень, не выгружая преведущего, а в момент чейджлевела, просто поменять местами указатели. Ну и разумеется зоопарк форматов. Но повторюсь, зоопарк мне больше нужен для изолированного тестирования новых фичей, чтобы не вносить изменения в уже отлаженную ветку одного формата, а сделать рядом аналогичный и спокойно сравнивать регрессии. Есть у подхода и два минуса, точнее даже не совсем минусы, а потенциальные UB. Во первых как это подружить с кэшированной информацией для каждого эдикта, во вторых - отрисовка полупрозрачных объектов, которая как известно требует сортировки. Впрочем эти две проблемы остаются в любом случае, независимо от архитектуры.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 20-07-2019 в 09:35:

На данный момент я так понимаю, XashNT еще только в стадии проектирования?

Отправлено Дядя Миша 20-07-2019 в 09:43:

На данный момент XashNT под угрозой срыва. Буквально час назад выяснилось, что на умирающем винте всё-таки повредились бэкапы и часть текущих исходников. Бэкапы повреждены с начала февраля, а в исходниках client.h и cl_frame.cpp. Не знаю удастся ли это восстановить. Все три резервные копии повреждены, архивы не восстанавливаются.

Добавлено 20-07-2019 в 12:43:

Но покрайней мере остальные части движка компилируются, только ядро не собирается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 20-07-2019 в 11:42:

Дядя Миша
Понятно, что поздняк и советы постороннего, но попробовал бы бакапиться на bitbucket-е. Там есть приватные репозитории забесплатно. Я пользуюсь, нравится.

Отправлено Дядя Миша 20-07-2019 в 13:32:

проблема в том, что бэкапов минимум шесть источников и абсолютно повезде битые архивы. И как битые - наглухо. Они солидные и без информации для восстановления, когда-то очень давно, в 2007-м году, я поленился прописать этот ключик. Я пытаюсь спасти эти архивы с абсолютно любого диска и абсолютно везде они битые. Одному богу известно когда это вообще началось, ведь диск умирает достаточно давно. Но есть и хорошая новость - client.h и cl_frame.cpp всё таки удалось спасти в целости со старого диска с рабочего компьютера с отформатированного раздела. Таким образом я восстановил работоспособность актуальной копии исходников. А плохая новость заключается в том, что потеряны абсолютно все бэкапы новый ветки, начиная с февраля этого года.

Добавлено 20-07-2019 в 16:32:

Ура. Удалось спасти еще два бэкапа за 24-е и 25-е марта этого года. Если учесть, что апрель-май были отданы работе над параноей, то это почти-что средняя точка, для отладки пригодится. Ну хотя бы не пустое место.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 20-07-2019 в 14:05:

Напомнило вот эту душераздирающую историю: http://www.anim8or.com/smf/index.php/topic,5743.0.html
Там всё кончилось хорошо, он переписал свои потеряшки.

Отправлено Дядя Миша 20-07-2019 в 14:32:

Проблема заключалась в том, что все мои архивы-бэкапы оказлись битыми. И вот это конечно было совсем уму нерастяжимо. Они как NAN расползлись по всем хранилищам. А ведь я был уверен что у меня есть актуальные бэкапы на фрэшке, но увы. Впрочем спасённого достаточно для полноценного продолжения работы. В промежуточных бэкапах не было ничерта интересного.

Добавлено 20-07-2019 в 17:26:

Если я немного туманно написал: текущий прогресс полностью сохранён. Утеряна только б0льшая часть бэкапов в промежутке между февралём-апрелем.

Добавлено 20-07-2019 в 17:28:

Мне это напомнило начало разработки Xash3D. Тогда я точно так же потерял стартовые бэкапы с февраля по июнь. Правда там у меня ничего не полетело. Я их сам удалил, подумал что не пригодятся. Так и оказалось.

Добавлено 20-07-2019 в 17:32:

Ну чтож, выводы из случившегося сделаны. Написан скрипт для тестирования всех бэкапов на валидность, а к скрипту создания бэкапа добавлен параметр сохранения информации для восстановления.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 21-07-2019 в 14:54:

Ну чтож. Не всё так просто, как казалось бы. Испорчены еще cl_view.cpp и cl_gameui.cpp.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Lev 21-07-2019 в 16:24:

Дядя Миша gui? Может оно и к лучшему, и в NT не будет дурацкоко won меню? Или я не о том подумал?)

Отправлено Дядя Миша 21-07-2019 в 17:28:

Я уже всё восстановил, иначе бы ядро не скомпилилось.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 25-07-2019 в 08:44:

Потихоньку переписываю вообще всё. Заворачиваю в синглтоны и атд по смыслу. В движке накопилось очень много мест для шареного кода, эти места лучше всего реализовать в виде закрытых классов. Конечно будь я помоложе, я бы всё это разломал на отдельные дллки, но прав был тот чувак с геймдева, который когда-то сказал мне, пока ты молод и неопытен, тебе хочется всё разделить на модули. А когда ты уже искушенный, для тебя оптимальмым является единый экзешник и никакого DLL Hell. Сейчас, спустя 13 лет, я понимаю, насколько же он был прав.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 25-07-2019 в 08:50:

Цитата:

Дядя Миша писал:
Сейчас, спустя 13 лет, я понимаю, насколько же он был прав.

Он был совершенно не прав. Возможно, он это уже понял. А может быть, и нет, кто его знает.

Цитата:

Дядя Миша писал:
оптимальмым является единый экзешник и никакого DLL Hell

Модули могут быть статически линкуемыми, это не существенно.
Но у статических модулей есть серьёзная проблема - не срабатывает автоматическая инициализация глобальных объектов, из-за чего, как пример, не работает авторегистрация компонентов фабрики. Опытные и искушённые, конечно же, будут регистрировать вручную (они же опытные) или предложат какую-нибудь фичу из Boost (они же искушённые), но что мы говорим таким способам решения простых задач? НЕ СЕГОДНЯ. И переводим lib в dll.

__________________

Отправлено Дядя Миша 25-07-2019 в 09:37:

Цитата:

XaeroX писал:
Но у статических модулей есть серьёзная проблема - не срабатывает автоматическая инициализация глобальных объектов

да я помню. Поэтому я не использую статические либы. Ну не считая third_party конечно жы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 27-07-2019 в 21:50:

Lev +1.

Дядя Миша переноси гуй движка на mainui_cpp. Раз уж и так всё на плюыс переводишь.

А дллки это всё же удобно. Конечно, когда есть цель сделать какой-то модуль опциональным или заменяемым.

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 28-07-2019 в 15:44:

Переписываю загрузчик и менеджер текстур. Фактически - полдвижка. Где-то на этой точке необратимо дропнется потдержка восьмибитных текстур и прочей экзотики, типа впечатывания номера билда в массив пикселей.
Останется только три базовых формата - bmp, tga и dds. Причём, как водится, первые два - для разработки, а последний уже для финальной сборки. Впрочем, в том же крайэнджине в качестве формата источника юзают TIFF, но насколько я помню TIFF это вообще мета-контейнер, а не формат.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 29-07-2019 в 11:15:

Дядя Миша
На каком контенте тестируешь?

Цитата:

Дядя Миша писал:
необратимо дропнется потдержка восьмибитных текстур и прочей экзотики

Халфовских вадов?

Отправлено XaeroX 29-07-2019 в 11:23:

Цитата:

Дядя Миша писал:
типа впечатывания номера билда в массив пикселей.

Только сейчас заметил. Но ведь это же была одна из ключевых фич движка...

__________________

Отправлено Дядя Миша 29-07-2019 в 12:11:

Цитата:

nemyax писал:
Халфовских вадов?

ну да и их тожы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 08-08-2019 в 18:16:

В процессе перекраивания API и отрезания ненужного в рамках новой парадигмы, после очередного тестового запуска вдруг выскочила давно забытая надпись.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 08-08-2019 в 19:42:

>You use is too old version

Ты использовать слишком старая версия!

Добавлено 08-08-2019 в 22:42:

Не мучай трубы.

__________________
Xash3D FWGS форк

Отправлено nemyax 09-08-2019 в 06:40:

Иисус, ваш терапевт имеет лот, чтобы ответить для!
Английский язык через канпелятор не прогонишь

Отправлено Дядя Миша 09-08-2019 в 08:09:

Если вы хотите мой совет - дайте это дерьмо вверх!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 09-08-2019 в 21:30:

Пришло время избавиться от структурки entvars_t. Ну это которая pev->
Эта зараза пронизывает всю серверную часть движка, поэтому процесс будет непростым.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 09-08-2019 в 21:34:

>https://hlfx.ru/forum/attachment.ph...=&postid=182326
там блуум от неба или?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 09-08-2019 в 21:38:

годреи это. Да они есть в финальной версии XashXT, сюда по наследству попали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 10-08-2019 в 12:54:

Цитата:

Дядя Миша писал:
Пришло время избавиться от структурки entvars_t.

А что будет взамен? Чтобы и на клиенте и на сервере была одна и та же структура для синхронизации?

Отправлено a1batross 10-08-2019 в 14:34:

Ku2zoff но на клиенте нет entvars_t. Да и энтварсы не для синхронизации. Для этого entity_state_t, а вот что с ним Дядя Миша решит делать...

Добавлено 10-08-2019 в 17:34:

string_t я надеюсь тоже под нож?

__________________
Xash3D FWGS форк

Отправлено XaeroX 10-08-2019 в 14:39:

Цитата:

a1batross писал:
string_t я надеюсь тоже под нож?

Ага, заменить на std::string!

__________________

Отправлено thambs 10-08-2019 в 14:46:

XaeroX
А чем он плох? (без троллинга, действительно любопытно).

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено a1batross 10-08-2019 в 14:53:

XaeroX как вариант. Хотя что-то мне подсказывает, что Дядя Миша наврядли что-то использует из STL.

Добавлено 10-08-2019 в 17:53:

thambs string_t-то? Ну, в первую очередь, это рудимент от кваки, где виртуальная машина работала со строками довольно бедно и фактически лишь давала идентифактор. Может я тут где-то ошибаюсь.

Valve запихнули проблему ещё дальше, сделав из string_t просто разницу указателей. В итоге литералы у нас идут в MAKE_STRING, а генерируемые строки в ALLOC_STRING.

__________________
Xash3D FWGS форк

Отправлено XaeroX 10-08-2019 в 15:00:

Цитата:

thambs писал:
А чем он плох?

Навскидку: динамическая реаллокация, оверхед по памяти, лёгкость пессимизации при замене string_t, который привычно передаётся по значению, потенциальная непредсказуемость поведения из-за мути в стандарте (SOO, COW).

Добавлено 10-08-2019 в 22:00:

Цитата:

a1batross писал:
Ну, в первую очередь, это рудимент от кваки

Один дурак сказал, и все начали повторять про рудимент...

Цитата:

a1batross писал:
В итоге литералы у нас идут в MAKE_STRING, а генерируемые строки в ALLOC_STRING.

Тут пожалуй единственная проблема - неудачное название MAKE_STRING, оно нелогичное и запутывающее.
Кстати, ку3шный аллокатор строк умеет детектировать самые популярные литералы, например, и не аллокать для них память.

__________________

Отправлено Дядя Миша 10-08-2019 в 16:26:

Цитата:

Ku2zoff писал:
Чтобы и на клиенте и на сервере была одна и та же структура для синхронизации?

Можно сделать чтобы клиент и сервер были в одной дллке, точнее говоря, описание энтить.

Цитата:

a1batross писал:
string_t я надеюсь тоже под нож?

Нет, там теперь сетевая таблица уникальных строк. И туда же до кучи пути к моделям, звукам, чтоб не хранить в отдельных массивах.

Цитата:

a1batross писал:
Valve запихнули проблему ещё дальше, сделав из string_t просто разницу указателей

оно и в кваке так было.

Добавлено 10-08-2019 в 19:26:

Цитата:

a1batross писал:
Для этого entity_state_t, а вот что с ним Дядя Миша решит делать...

Эту пакость обязательно надо убрать, она весь движок на себе держит и ограничивает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 10-08-2019 в 18:54:

XaeroX ну черт его знает. В условиях отсутствия ВМ я не вижу смысла так работать со строками.

Я на самом деле и не против. Просто string_t должен быть явно помечен как платформозависимый и вообще не давать возможности разработчику записывать его в файл(о_О), передавать по сети(что только в воспаленное сознание не придёт), сравнивать его численное значение с другими, помимо равенства наверное, да и вообще не иметь доступа к нему именно как идентификатору.

Именно он был и есть самой большой проблемой при порте на 64-битные указатели.

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 10-08-2019 в 19:08:

Цитата:

a1batross писал:
В условиях отсутствия ВМ я не вижу смысла так работать со строками.

Вообще-то стрингтабля идеально для игровых движков подходит, независимо от наличия в них какой-то пользовательской виртуальной машины. Потому что мы имеем дело с кучей константных строк, которые очень часто сравниваются друг с другом и имеют множество дубликатов. Т.е. идея поместить их в единый уникальный массив напрашивается сама-собой. Энтити постоянно запрашивают поиск по таргетнейму, класснейму, да мало ли почему. И всегда выгоднее сравнивать идентификатор строки, чем каждый раз запускать strcmp. И соответственно этот же массив передаётся на клиент, в том же порядке, чтобы строки были доступны и там. Аналогично, когда мы передаём пользовательскую мессагу, нам необязательно каждый раз слать настоящую строку - достаточно послать её идентификатор, а движок автоматически синхронизирует строки на клиентской части (если строка новая и уникальная).

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 12-08-2019 в 20:45:

Потихоньку переношу из entvars_t в CBaseEntity. Их там более ста штук, вот такая тупая работа и отымает чёртову уйму времени. Попутно жы еще пишу разные новые механизмы, типа парсера новых кейвалуев, поиска по строкам в DATAMAP и прочего. Ну и стараюсь убрать эту порочную практику, когда для новых энтить вовсю использовались переменные из entvars_t подходящие по типу, чтобы не возится с описанием IMPLEMENT_SAVERESTORE и прочей гадости. Помоему это Лаури первым придумал, этот фантазёр.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 12-08-2019 в 20:55:

Дядя Миша
это из-за этого всякие полезные параметры называются неочевидными ключами вроде netname и подобного?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 12-08-2019 в 21:25:

Именно так, да. В халфе довольно сложная возня с объявлением сейв-рестора, чтобы в новой энтите сохранить хотя бы одну переменную, надо скопипастить довольно большой кусок кода и там поперименовывать всё. А потом еще и в KeyValue добавить лишнее условие, народ (и я в том числе), предпочитали брать уже готовые переменные. Вот в кваке там с этим было хорошо, объявил переменную с точкой и она у тебя уже и из настроек сразу читается и в сейв пишется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 12-08-2019 в 21:32:

Дядя Миша
А ты как теперь делаешь эту систему, там какая-то сериализация или?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 12-08-2019 в 21:54:

Там с 12-го года другая сериализация, похожая на ту что в сорсе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FreeSlave 13-08-2019 в 01:15:

Цитата:

Дядя Миша писал:
Ну и стараюсь убрать эту порочную практику, когда для новых энтить вовсю использовались переменные из entvars_t подходящие по типу, чтобы не возится с описанием IMPLEMENT_SAVERESTORE и прочей гадости. Помоему это Лаури первым придумал, этот фантазёр.

Этим занимались сами Valve. body у gibshooter в качестве количества сабмоделей, netname у монстров в качестве названия сквада, message в самых разных смыслах и т.д.

__________________
I'm on github
I'm on opendesktop.org

Отправлено XaeroX 13-08-2019 в 06:17:

Мне кажется, энтварсы очень удобная штука. Они позволяют шарить основные параметры энтитей между разными библиотеками, и в том числе с ботами и скриптовой системой (в волатиле это например Lua). А переиспользуются они в целях экономии памяти, и в этом с точки дизайна нет ничего плохого. Единственное что я делаю - добавляю в класс простенькие геттеры/сеттеры, чтобы по ходу кода потом не гадать, что же тут значит pev->body.

__________________

Отправлено Дядя Миша 13-08-2019 в 06:37:

энтварсы для разработчика это UB в первую очередь, потому что нет никакого соглашения какие переменные смотрит движок, какие он меняет, на какие реагирует, на какие возможно будет реагировать в дальнейшем.
В квейке была виртуальная машинка и там было совсем другое дело.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 13-08-2019 в 06:53:

Дядя Миша
Движок реагирует на очень небольшое число энтварсов, и как правило, они имеют вполне чёткое предназначение, типа classname или origin. Но я согласен, работу движка с энтварсами надо минимизировать, они нужны пользовательским дллкам, и конечно же скриптовой системе, которая ничего не знает про pvPrivateData.

__________________

Отправлено Дядя Миша 13-08-2019 в 07:30:

Цитата:

XaeroX писал:
Движок реагирует на очень небольшое число энтварсов, и как правило, они имеют вполне чёткое предназначение, типа classname или origin.

я тебе про то, что в халфе получилось. Там как минимум половина энтварсов просматривается движком без чёткой логики со пользовательской стороны. Скажем pev->flags используется частично. Некоторые флаги движок не смотрит, причём они даже по диапазонам не разделены. Ну как повизёт.
Удачный интерфейс - это явный каллбэк, а не вот такой вот просмотр приватдаты по тихому. А в той же кваке движок мог даже пользовательские переменные искать из вирт.машины, она же как решето в этом смысле. И менять он их тоже мог. Нет в таком подходе ничего хорошего.

C++ Source Code:

1	struct edict_s

3	int flags; // edict->flags

4	float freetime; // sv.time when the object was freed

5	int serialnumber; // increment each time when entity was freed

6	link_t area; // linked to a division node or leaf

7	void* pvPrivateData; // alloced, freed and used by DLLs

};

мой эдикт вот так выглядит сейчас. Единственное поле, которое смотрит движок - это flags. В остальные он не лезет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 13-08-2019 в 07:45:

Дядя Миша
А если ты потом захочешь скрипты прикрутить, ну или блупринты какие-нибудь, как ты туда инфу о классах протащишь?
Не знаю, как в новом УЕ, а в старом классы были на UnrealScript и к ним был доступ через специальный экспорт, где перечислялись "внешние" поля. Но на плюсах ты так легко не сделаешь, по идее.

__________________

Отправлено Дядя Миша 13-08-2019 в 07:58:

Цитата:

XaeroX писал:
как ты туда инфу о классах протащишь?

ну посмотри как в третьем дууме сделано. Там скрипт является продолжением класса, объявленного в движке и наследует его поля. Очень оригинально, я такого больше нигде не видел.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 13-08-2019 в 08:11:

Цитата:

Дядя Миша писал:
Очень оригинально, я такого больше нигде не видел.

Емнип, классы UnrealScript тоже наследовались от базовых движковых.

__________________

Отправлено Дядя Миша 13-08-2019 в 11:41:

Я Unreal никогда толком не ковырял, так ничего сказать не могу.

Добавлено 13-08-2019 в 14:41:

Думаю настала пора полностью отказаться от лайтмапы, в NT будет только динамическое освещение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 13-08-2019 в 11:44:

Дядя Миша
А на каком варианте для индиректа ты решил остановиться? А вообще жаль, лайтмэпы дюже православны.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 13-08-2019 в 12:07:

Цитата:

Дядя Миша писал:
в NT будет только динамическое освещение.

Главное, чтобы оно не выглядело хуже лайтмапового.

__________________

Отправлено nemyax 13-08-2019 в 12:12:

Вместо рада будет расчёт каких-то специфических данных для динамики?

Отправлено Дядя Миша 13-08-2019 в 12:59:

Цитата:

thambs писал:
А на каком варианте для индиректа ты решил остановиться?

Здесь остаётся простор для экспериментов. Пока еще не определился.

Цитата:

thambs писал:
А вообще жаль, лайтмэпы дюже православны.

Для халфовских простых уровней - несомненно. А когда начинаешь делать уровни модельками - это такая головная боль получается. В моделях полно мелких деталей, как их освещать? повертексно? Пол-модели повертексно, пол-модели лайтмапой? и рисовать тоже по маленьким кусочкам? Потом надо будешь еще заново придумать как освещать персов. Затыкать весь уровень лайтпробами или что-то типа того. И сверху один хрен еще написать слой динамического освещения, для всяких фонариков и спышек. И компилятор, который запекает лайтмапы без швов. Еще и каждый раз ждать, пока оно там запечётся часами. Вот так вот посмотришь на всё это и никакого желания опять связываться. Лайтмапа хороша когда требования игроков не выходят за рамки графона от ку3. То есть такие условности повезде. Ну там двери тени не отбрасывают, от игрока пятнышко. Мне Элбер уже весь мозг выел - надо говорит тень от игрока. Я вот думаю тень от того, тень от этого, а нахрена там тогда вообще лайтмапа, если вам нужны деномические тени?

Добавлено 13-08-2019 в 15:58:

Цитата:

nemyax писал:
Вместо рада будет расчёт каких-то специфических данных для динамики?

Посмотрим. До этого относительно долико еще.

Добавлено 13-08-2019 в 15:59:

Цитата:

XaeroX писал:
Главное, чтобы оно не выглядело хуже лайтмапового.

Да вот смотрел вчера видос про UE4 и не мог понять лайтмапа это или фуллдинамика. Оказалось всё-таки второе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 13-08-2019 в 13:30:

Цитата:

Дядя Миша писал:
Да вот смотрел вчера видос про UE4 и не мог понять лайтмапа это или фуллдинамика. Оказалось всё-таки второе.

Ну так то ли UE4, то ли расеюшка, где щи лаптем хлебают.

Лайтмапа, как ни крути, отработана десятилетиями, и с ней нужно постараться сделать некрасиво. А с динамикой - в два счёта. Ну или красиво, но с тормозами, как в униджине.

__________________

Отправлено Дядя Миша 13-08-2019 в 13:47:

Так я ж наоборот говорю, в наше время фуллдинамик быстрее лайтмапы будет. Если конечно пытаться сделать нечто похожее на динамику.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 13-08-2019 в 13:58:

Цитата:

Дядя Миша писал:
Лайтмапа хороша когда требования игроков не выходят за рамки графона от ку3.

И тем не менее лайтмапа использовалась в the last of us, uncharted 4, doom 2016

Отправлено XaeroX 13-08-2019 в 14:17:

Цитата:

Дядя Миша писал:
в наше время фуллдинамик быстрее лайтмапы будет

Это с учётом времени компиляции или без?

__________________

Отправлено FiEctro 13-08-2019 в 14:27:

На риватнт ни то ни другое точно не запустится, особенно если ДДС в несжатые текстуры распаковывать

Отправлено XaeroX 13-08-2019 в 14:54:

FiEctro
Ну вот опять ты ложные слухи распускаешь. А потом жалуешься, что тебя в аське в игнор добавляют.

__________________

Отправлено Дядя Миша 13-08-2019 в 14:58:

ncuxonaT ну про дуум это ты уже сам придумал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 13-08-2019 в 15:21:

Дядя Миша http://advances.realtimerendering.c...016_idTech6.pdf
слайд 20
Diffuse indirect lighting: Lightmap for static geometry, irradiance volumes for dynamics

Отправлено Дядя Миша 13-08-2019 в 15:27:

ncuxonaT ты помоему еще вчера жаловался, что времени нет ни на что, а сегодня оно уже есть

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 13-08-2019 в 21:24:

Дядя Миша может, я последовал совету

Отправлено Дядя Миша 14-08-2019 в 07:38:

Я выше уже написал почему не хочу связываться с лайтмапами.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 14-08-2019 в 07:43:

Дядя Миша
Потому что не можешь сделать нормальные лайтмапы для моделей?

__________________

Отправлено Дядя Миша 14-08-2019 в 08:19:

XaeroX нормальная лайтмапа - это которая в реалтайме считается каждый кадр

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 14-08-2019 в 08:34:

Дядя Миша
The fastest way to compute is to precompute.

__________________

Отправлено Дядя Миша 16-08-2019 в 11:40:

Я вот чем больше изучаю другие движки тем больше склоняюсь к тому, что вот это разделение на клиентские и серверные энтити - это невероятная дурь и она не нужна абсолютно. Ничего кроме неудобства, дублирования кода и повышенного потребления памяти она не создает.
Движок никогда не работает в таком режиме, когда бы его два набора энтить оказались разделены реальным сетевым соединением, это всегда две разные копии игры на удалённых машинах, ну или хотя бы на одной, но через микрософтовский лупбэк. То есть нет никакого резона держать в рамках одной сессии два набора энтить. Это очень порочная практика, которая порождает массу проблем на самом деле, но мы уже настолько к ним привыкли, что даже не можем себе представить, что может быть как-то иначе. Ну например чисто серверная энтить по дефолту не имеет предиктинга. В лучшем случае он достается только игроку, хотя по идее должен быть у всех энтить абсолютно. То есть у нас либо один и тот же файл компилируется дважды, на клиенте и на сервере, либо вообще для клиента приходится городить какой-то отдельный урезаный огород, который бы выполнял функцию предиктинга. Если функционал серверной энтити поменяется - значит клиентскую тоже надо пересобрать как минимум. Наиболее отвратный пример такого подхода - голдсорсовский предиктинг оружия. Насколько я знаю его так никто и не освоил, в лучшем случае копипастой с похожего оружия. Народ просто не понимает что там и куда копировать, чтобы это работало. При том что наилучшие результаты предиктинга вообще-то достигаются при полной идентичности клиент-серверного кода, а единственное что меняется - это время с серверного на клиентское. Второй негативный момент - два набора энтить потребляют в несколько раз больше памяти. Зависит от организации этого набора. Может и в два, а может и в полтора. И на клиенте у нас всегда несовпадающий функционал, из-за чего даже трассу приходится дублировать. Причём это справедливо, даже если ты не просто пишешь новые энтити, а что-то делаешь в движке. Если ты что-то сделал на серверной части, у тебя сразу головная боль - надо чтобы на клиенте это тоже работало. Но два набора это не предел. Теперь когда мы передали энтити на клиент нам еще надо их нарисовать. Для чего выделяется очередной список либо из клиентских, либо из особых рендер_энтить. Что в свою очередь порождает проблему слабой контролируемости рендерера из сервера. Ну вы помните как скорость движения конвейера в рендерколор запихнули. И соответственно в движке ответный хак. Хотя оптимальным выходом была был виртуальная функция в классе энтити, ну что-то типа ChangeRendererParams и там для этой энтити бы применялись какие-то настройки. Аналогично и с отрисовкой. Иметь в классе энтити еще один виртуальный метод типа DrawModel. И там уже прекрасно себе настраивать кости или еще что-то специфичное выполнять. И всё это в рамках одной библиотеки. Зачем дизайнеру игрового кода вообще забивать себе голову клиент-серверной архитектурой, особенно если разрабатывается сингл?
А для сетевой модели в класс добавляются пара виртуальных же функций, типа ReadFromSnapshot и WriteToSnapshot, по аналогии с сейв-рестором. И оно там себе само прекрасно пишет и читает, минуя промежуточные стадии вроде entity_state_t. baseline при таком подходе создаётся вообще автоматически - клиент точно так же спавнит карту и читает на ней все энтити и к моменту прихода первой дельты у него уже есть с чем её сравнивать. То есть baseline вообще не надо никуда передавать. Чисто клиентские энтити в эту систему укладываются даже лучше чем в классическую. Нам достаточно будет добавить что-то типа настроечного флага FCAP_CLIENT_ENTITY и всё. В сингле её проспавнит сервер, в мультике - клиент, и в обоих случаях у нас будет с ней нормальная коллизия с предиктингом. Да, её нельзя удалять с карты, она будет занимать слот, но она будет его занимать в любом случае, если мы хотим её сохранить в сейв например. Просто она будет занимать какой-то отдельный массив, а при записи демки, к примеру. нам всё равно придется заново переслать эти энтити на клиент. То есть все вот эти уловки с отдельными массивами для специфических энтить, они только усложняют и запутывают всё дело, из-за неудачно выбранной архитектуры однажды.
Еще момент - двойной набор энтить предполагает и двойную её обработку, как на клиенте, так и на сервере. Причём фпс при таком подходе будет падать экспоненциально с ростом кол-ва энтить, как вы понимаете, при условии что на клиенте присутствует тот же предиктинг с коллизиями. Вообщем нет положительных сторон. Но мы уже привыкли что их два набора и не можем себе представить что возможно как-то иначе. Стереотип короче говоря.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 16-08-2019 в 12:34:

Цитата:

Дядя Миша писал:
Причём фпс при таком подходе будет падать экспоненциально с ростом кол-ва энтить

Почему не линейно?

__________________

Отправлено Дядя Миша 16-08-2019 в 13:20:

XaeroX ну хотя бы потому что фпс всегда падает экспоненциально 1/х - это экспонента.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 17-08-2019 в 09:50:

Чтобы не было недопонимания: я любую нелинейную функцию называю экспонентой, а уж парабола там или гипербола в данном случае непринципиально.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 17-08-2019 в 10:55:

Дядя Миша
А зачем? Вот почитает тебя какой ни будь Гуль, например, — и у него окончательно крышу сорвёт, уже не только в плоскую землю уверует, а число pi опровергать начнёт. Спросят, а кто же виноват, кто его так с ума свёл? А вот он! Это всё Дядя Миша, сидит в кустах с хитрой ухмылкой.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 17-08-2019 в 11:14:

Цитата:

thambs писал:
Вот почитает тебя какой ни будь Гуль

А ты - для чего?

__________________

Отправлено Дядя Миша 17-08-2019 в 16:39:

Цитата:

thambs писал:
А зачем?

в данном контексте речь шла о линейности\нелинейности. А уж как правильно называется та или иная загогулина я навскидку вспомнить не смог. Вы так возмутились как будто я переодическую функцию назвал экспонентой.

И вообще. Если кто-то чем-то недоволен, он может выразить своё возмущение прямо мне на яндекс.кошелёк в денежном эквиваленте.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 18-08-2019 в 16:45:

Дядя Миша а исходит ли это в принципе из клиент-серверной архитектуры?

Всегда на что-то отдается больше предпочтение и соответственно проектируется. Хорошо, у нас единые энтити и на клиенте, и на сервере. Это будет работать в сингле, но что делать с мультиплеером? Делаем под мультиплеер и в итоге получаем все предиктинги и прочие лагокомпенсации, потому что игровой мир клиента не равен миру сервера.

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 18-08-2019 в 16:48:

Это для мультиплеера даже более оптимально, чем традиционная модель, я бы сказал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 18-08-2019 в 20:25:

Дядя Миша Код станет меньше и понятней?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 18-08-2019 в 20:44:

я вот склоняюсь к тому, чтобы наружу вынести только скрипты, ну типо прогс.дат как в квейке или что-то вроде этого. А остальное всё в движок упрятать и пусть оно там уже будет. Никому это неинтересно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 19-08-2019 в 14:26:

Цитата:

Дядя Миша писал:
Наиболее отвратный пример такого подхода - голдсорсовский предиктинг оружия. Насколько я знаю его так никто и не освоил, в лучшем случае копипастой с похожего оружия. Народ просто не понимает что там и куда копировать, чтобы это работало.

Дико плюсую, это как раз одна из самый геморойных частей кода HLSDK, очень долго с ней ковырялся.
А, ещё дико бесит прописывание "заглушек" на клиенте для методов серверных базовых классов. Думаю, потом просто неиспользуемые на клиенте методы изолирую от компиляции через #ifndef CLIENT_DLL, не знаю что еще с этим ужасом делать.

Отправлено Дядя Миша 19-08-2019 в 14:36:

Я напомню, что обновлённый голдсорс делался на базе QW, который был физически разделён на клиент и сервер. Вот оттуда все ушы и растут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 20-08-2019 в 12:30:

Цитата:

Дядя Миша писал:
склоняюсь к тому, чтобы наружу вынести только скрипты

На чём скрипты?

Отправлено Дядя Миша 20-08-2019 в 15:36:

Пока что всё под вопросом. Остановил разработку, надо подумать как лучше сделать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 20-08-2019 в 15:48:

Дядя Миша
Но скрипты это очень хорошая и правильная идея, в любом формате, хоть на хацкеле.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 20-08-2019 в 15:52:

На хаскеле, это было бы очень круто!

__________________

Отправлено nemyax 20-08-2019 в 16:00:

Как говорится, Maybe. Кстати, почему нет, для скриптинга-то. Только вряд ли найдётся компактный интерпретатор.

Отправлено Дядя Миша 03-09-2019 в 08:24:

Халфовская игровая дллка, это эталонный пример анти-паттерна конечно.
Это надо всем начинающим пограмистам показывать как не надо делать.
В кваке был целостный эдикт и непрерывный массив, что хотя и увеличивало потребление памяти с одной стороны, но с другой гарантировало нам, что мы никогда не промахнёмся по адресу, можем ссылаться на мёртвые эдикты и так далее. В халфе, мало того что разрушили эту концепцию, казалось бы с благой целью, так еще и долгое время не могли определиться что послужит базовым указателем на сущность. entvars_t? edict_t? CBaseEntity?
В итоге мы имеем три сущности и три преобразования-апкаста туда и сюда, которые вообще не несут абсолютно никакого смысла, только запутывают.
Плюс еще те переменные, что входят в состав entvars_t неявно модифицируются\читаются движком и об этом нигде ничего не написано. Отдельного упоминания заслуживают флаги, часть флагов явно задаёт поведение движка, а часть существует только в игровом коде.
В сорсе на первый взгляд попытались это привести в порядок, но на деле только осложнили ситуацию. Там теперь всё в каллбэках, чтобы сделать типичный вызов движковой функции надо писать класс-заглушку с каллбэком и от нее наследовать какую-то чертовщину. То есть вот мы к примеру хотим отправить сетевое сообщение всем клиентам. Мы уже не можем написть MSG_ALL, нам надо городить специальный класс, который пропускает сообщение для всех клиентов в каллбэке. Пример избыточной гибкости, которая может пригодится примерно никогда.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 03-09-2019 в 08:35:

Цитата:

Дядя Миша писал:
долгое время не могли определиться что послужит базовым указателем на сущность. entvars_t? edict_t? CBaseEntity?

В халфе чётко определились. Базовая сущность это edict_t. У него есть "скриптовые" поля entvars_t, которые (в теории) могут быть доступны виртуальной машинке. Да, в халфе ВМ не реализовали, но я в HLFX0.7 упражнялся и оценил это разделение в полной мере. Что касается CBaseEntity, то это класс, целиком инкапсулированный в дллке и невидимый извне. Это логическая обвёртка, которая движку не нужна. Важный плюс такой архитектуры - движок может быть скомпилен MSVC, а дллки, скажем, GCC. И она - после ряда неархитектурных фиксов - будет загружаться и работать. В Волатиле оно так и происходит: мы хоть и заставляем пользователя что-то там компилировать, но по крайней мере не требуем строгую "модель" и версию компилятора.

Цитата:

Дядя Миша писал:
и об этом нигде ничего не написано.

Это не пример антипаттерна, это пример плохой документации.

Цитата:

Дядя Миша писал:
В сорсе на первый взгляд попытались это привести в порядок, но на деле только осложнили ситуацию.

Ну код-то по факту стал читабельнее? Не надо лезть в код движка и/или документацию и смотреть, что делает магическая константа MSG_ALL?
Чем больше людей работают над кодом, тем важнее такая избыточность, и тем дольше этот самый код пишется в принципе. Поэтому зависимость "число человек - число реализованных фич" не линейная.

__________________

Отправлено Дядя Миша 03-09-2019 в 15:44:

Цитата:

XaeroX писал:
Базовая сущность это edict_t. У него есть "скриптовые" поля entvars_t, которые (в теории) могут быть доступны виртуальной машинке.

Это если бы они так планировали сделать изначально. А им entvars достались в наследство. И edict_t ни разу не базовая сущность. Она была таковой в кваке, где виртуальная машинка управлялась именно с эдиктами.
В халфе эдикт нужен только для того, чтобы движок примерно понимал с чем ему иметь дело, ему даже не столько сам эдикт нужен, сколько его номер в массиве.

Цитата:

XaeroX писал:
Ну код-то по факту стал читабельнее?

я бы так не сказал. Проще написать MSG_ALL, чем каждый раз копипастить этот класс с каллбэком. Кстати говоря, как такие вещи по научному называются? Когда весь класс создаётся только ради одной виртуальной функции.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-09-2019 в 10:26:

Замутил АТД для string_t для удобства. Теперь не надо писать каждый раз эти идиотские ALLOC_STRING, STRING, теперь как в виртуальной машинке

pev->targetname = "player";

и была же охота вальвовцам копипастить одно и тоже сотни раз.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 04-09-2019 в 11:00:

std::string, надеюсь, а не велосипед?

__________________

Отправлено Дядя Миша 04-09-2019 в 11:11:

я не пользую STL

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 04-09-2019 в 11:43:

Дядя Миша
Какой смысл писать на С++ и не пользовать STL?
STL уже давно часть языка.

__________________

Отправлено Дядя Миша 04-09-2019 в 12:03:

XaeroX вывези ваську

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-09-2019 в 20:14:

Долбанные энтварсы, когда же они уже закончатся. Этот рефакторинг я навсегда запомню как самое бессмыссленное и в то же время необходимое действие.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-09-2019 в 12:30:

Цитата:

Дядя Миша писал:
Долбанные энтварсы, когда же они уже закончатся. Этот рефакторинг я навсегда запомню как самое бессмыссленное и в то же время необходимое действие.

Ничего! Мастера это не остановило когда он сортировал delta.lst. Ты теперь достойный продолжатель его великого ~~деда~~ дела!

Отправлено Дядя Миша 06-09-2019 в 12:58:

Мастер от своей сортировки ничего не получил. А у меня рефакторинг архитектуры. Потом еще от entity_state_t избавляццо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 06-09-2019 в 13:10:

Дядя Миша
Ну зачем ты так. Мастер получил красивый и отрефакторенный delta.lst.

__________________

Отправлено Дядя Миша 07-09-2019 в 14:09:

C++ Source Code:

1	typedef struct entvars_s

3	int rendermode;

4	float renderamt;

5	vec3 rendercolor;

6	int renderfx;

7	} entvars_t;

Вообщем всё что осталось на текущий момент. Планирую сегодня избавиться полностью, а дальше самое интересное начнётся.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 07-09-2019 в 14:21:

Дядя Миша
Неправильно! Должно быть вот так отсортировано:

C++ Source Code:

1	typedef struct entvars_s

3	float renderamt;

4	vec3 rendercolor;

5	int renderfx;

6	int rendermode;

7	} entvars_t;

__________________

Отправлено Дядя Миша 07-09-2019 в 14:38:

Сам говорит дела, времени нет, сам строчки сортирует, уму нерастяжымо

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 07-09-2019 в 14:46:

Дядя Миша
Я ему помочь стараюсь - а он недоволен.

__________________

Отправлено Дядя Миша 07-09-2019 в 15:59:

XaeroX если бы ты еще пинговался, так тебе бы цены не было

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 08-09-2019 в 10:03:

Определился. Будет две "пользовательские" библиотеки, в кавычках, потому что я пока еще не решил, буду ли раскрывать их сорцы всем желающим.
Progs.dll и GameUI.dll. В первой будут находится все энтити единый клиент-серверный массив, он же используется для рендеринга и в самих энтитях будет метод Draw ну или что-то вроде этого. И GameUI.dll где клиентский худ и главное меню. Их нет смысла разделять, это по сути один хрен.
а в ядре остаётся абстрактный бакэнд, работа с файловой, сетью, форматами моделей и звуков.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 08-09-2019 в 10:07:

Дядя Миша
А с vm что решил?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 08-09-2019 в 10:26:

Цитата:

Дядя Миша писал:
В первой будут находится все энтити единый клиент-серверный массив, он же используется для рендеринга и в самих энтитях будет метод Draw ну или что-то вроде этого

Вот этот подход, он очень развращает. Человек перестаёт мыслить клиент-серверно, постепенно деградирует, в его модах половина эффектов начинает работать исключительно у локального игрока, а заканчивается всё поиском класса камеры в чужих сорцах.

__________________

Отправлено Дядя Миша 08-09-2019 в 11:36:

Цитата:

thambs писал:
А с vm что решил?

VM попозжы. Но скорее всего она будет. Потому что очень многие вещи энтитями делать невдобно, хотя и реально. Это какой-то артхаус получается, вот мне правильно Ксер подсказал.
У нас мульти_ватчер это кондиция, а мульти_свитчер это свитч-кейсы. И вот мы на этом пытаемся собрать логический код. Там где хватило бы нескольких строчек в скрипте.

Цитата:

XaeroX писал:
Человек перестаёт мыслить клиент-серверно, постепенно деградирует

У нас клиент-серверно даже Мастер мыслить не мог, всё удивлялся, почему он на сервере квары настроит, а нелокальный игрок их невидит.
Надо наоборот, чтобы это было прозрачно для пользователя. Чтобы он не гадал почему у него что-то не передалось, а он забыл в дельте строчку прописать. Меня самого это всегда бесило. Там скопируй, тут скопируй, в дельте пропиши, найди свободную переменную, да идите вы нафиг с такими приколами. Почему юзер должен таким бакэндом заниматься?

В сорсе не лучше, там еще хуже. Сперва объяви перемменную как CNetworkVar, потом из этих переменных создай табличку отправки на клиент, потом на клиенте построй точно такую же таблику, потом вручную прими все переменные, проинтерполируй по вкусу. На кого это рассчитано?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 08-09-2019 в 12:40:

Цитата:

XaeroX писал:
Человек перестаёт мыслить клиент-серверно, постепенно деградирует, в его модах половина эффектов начинает работать исключительно у локального игрока

Разве при аццуцтвии клиент-серверного разделения оно не будет работать у всех одинаково?

Отправлено XaeroX 08-09-2019 в 12:47:

nemyax
Оно будет работать там, где оно имеется. Создали объект на сервере - имеем его на сервере. Создали на клиенте - имеем его на клиенте. А для синхронизации уже нужны приседания. Дядя Миша, видимо, хочет эти приседания заранее предусмотреть и всё-всё синхронизировать автоматически, при этом максимально экономя трафик. Пока звучит как утопия. Но будем посмотреть.

__________________

Отправлено Дядя Миша 08-09-2019 в 13:09:

Насчёт экономии трафика я ничего не говорил. Я исхожу из того очевидного, но упорно игнорируемого соображения, что ситуации, в которой нам может понадобиться два комплекта энтить попросту не существует. Если сервер в режиме дедика - это один комплект энтить. Если клиент подключился к удалённому серверу - это один комплект энтить.
Таким образом для любого сетевого подключения нам требуется один комплект энтить. Чтобы это понять необязательно даже глубоко разбираться в теме. И два комплекта нам почему-то требуются в случае локальной игры, т.е. там где они точно так же не нужны. А поскольку локальная игра, это еще и синглплеер, мы имеем бесполезный перерасход памяти на два набора энтить. Какой в этом смысл? Да никакого абсолютно.
Это такая же пакость, навроде SQB, однажды сделали неоптимально и потом тащили аж до третьей кваки. Но там еще дальше пошли - там и карту зачем-то два раза начали загружать, отдельно для коллизии и для рендеринга. Опять таки смысла никакого.
Я вам так скажу это основная беда движкописателей - взять какой-то форк за основу и на этой основе просто наворачивать тени мягкие, физику и так далее. Осознать, что архитектура требует пересмотра никто не может и не хочет. Даже Ксерокс.

Добавлено 08-09-2019 в 16:09:

ЗЫ. конечно если в игре предполагается 600-900 эдиктов, то как бы и пофигу. А вот 20-30 тысяч уже не получится при таком раскладе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 08-09-2019 в 13:12:

Дядя Миша

Цитата:

И вот мы на этом пытаемся собрать логический код. Там где хватило бы нескольких строчек в скрипте.

Именно так и получается. Причём если делать в джеке, то из этих связок энтить получается write only каша, на которую если через неделю взглянешь, то вспомнить что там куда и кого активирует становится решительно невозможно. Я из-за этого всё это в отдельные .ent-файлы оформлял, но и там опять же то что на DSLе выразилось бы в пару строчек разрастается на пару десятков. А казалось бы, столько возни ради простой конструкции вроде префаба лифта с защитой от дурака. А с поездами ещё замороченней, особенно если их несколько на линии.

Добавлено 08-09-2019 в 16:12:

Цитата:

Дядя Миша писал:
Progs.dll ... GameUI.dll ... Draw

В CamelCase

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 08-09-2019 в 13:15:

Да надо просто как в том же Doom3 сделать глобальные скрипты, локальные скрипты, ну что-то вроде этого. Ну то потом всё, это архитектуру не затрагивает никоим образом, скорее приятное дополнение.

Цитата:

thambs писал:
В CamelCase?

А! Безотносительно!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 09-09-2019 в 16:41:

Ну штож, новый механизм уже вполне себе вырисовывается. Для простоты и удобства я сделал его частью механизма сейв-рестора. Точнее говоря от сейв-рестора там только табличка глобальных деклараций, ну которая DECLARE_DATA_DESC(); Но дело в том, что эта табличка сама-по себе не обязывает хранить в ней непременно данные для сериализации. Это просто такая универсальная табличка, где можно хранить всё что угодно, а различать по выставленным флагам.

Сейчас, для примера, чтобы передать на клиент оригин и углы, не надо больше ничего копировать в AddToFullPack, не надо сортировать строчки в delta.lst и не надо писать ответный код на клиенте (для entity_state_t разумеется, а для кастомной дельты, как в Сорсе - надо). Достаточно просто добавить в DATADESC вот такие штуки:

DEFINE_DELTA( m_vecAbsOrigin, FIELD_POSITION_VECTOR ),
DEFINE_DELTA( m_vecAbsAngles, FIELD_ANGLES ),

и всё. Не надо по особому помечать переменные, создавать новые таблицы, подключать какие-то каллбэки для прокси и прочую чертовщинку. Я полагаю это самый оптимальный вариант. Разумеется это автоматически учитывает наследие классов и посылает для каждого класса всё объявленное, ну собсно, как и с сейвами.

Добавлено 09-09-2019 в 19:41:

Больше скажу. Этот механизм позволяет даже передавать указатели на функции по сети.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 09-09-2019 в 16:43:

Цитата:

Дядя Миша писал:
Этот механизм позволяет даже передавать указатели на функции по сети.

Ну што ж, несмотря на утрату delta.lst и возможности сортировать в ней строчки, нашему Мастеру будет чем заняться!

__________________

Отправлено Дядя Миша 09-09-2019 в 17:00:

Вот вам для примера как тот же оригин посылается в сорсе:

Сперва он объявляется хитрым образом:

C++ Source Code:

CNetworkVector( m_vecOrigin );

Причём для разных типов данных - свои названия. Для углов к примеру CNetworkQAngle, есть еще какие-то CNetworkVectorForDerived, CNetworkVar, CNetworkHandle (для EHANDLE). Затем нам надо создать новую таблицу, специально для передаваемых переменных.

C++ Source Code:

1	// This table encodes the CBaseEntity data.

2	IMPLEMENT_SERVERCLASS_ST_NOBASE( CBaseEntity, DT_BaseEntity )

3	SendPropDataTable( "AnimTimeMustBeFirst", 0, &REFERENCE_SEND_TABLE(DT_AnimTimeMustBeFirst), SendProxy_ClientSideAnimation ),

4	SendPropInt (SENDINFO(m_flSimulationTime), SIMULATION_TIME_WINDOW_BITS, SPROP_UNSIGNED\|SPROP_CHANGES_OFTEN\|SPROP_ENCODED_AGAINST_TICKCOUNT, SendProxy_SimulationTime),

6	SendPropVector (SENDINFO(m_vecOrigin), -1, SPROP_NOSCALE\|SPROP_CHANGES_OFTEN, 0.0f, HIGH_DEFAULT, SendProxy_Origin ),

Вот это вот DT_BaseEntity тоже надо объявить, чёб движок мог его к себе утянуть и проанализировать. Дальше тут как видите еще и куча флажков-подсказок, типа меняется часто, не скейлить. Как будет всего этого мало, есть еще каллбэк SendProxy_Origin. Ну впрочем можно и без него.
Дальше интереснее. На клиенте m_vecOrigin объявлен как самый обычный Vector. А рядом -

C++ Source Code:

CInterpolatedVar< Vector >		m_iv_vecOrigin;

Но не всё так просто. Вот на клиенте ответная табличка:

C++ Source Code:

1	BEGIN_RECV_TABLE_NOBASE(C_BaseEntity, DT_BaseEntity)

2	RecvPropDataTable( "AnimTimeMustBeFirst", 0, 0, &REFERENCE_RECV_TABLE(DT_AnimTimeMustBeFirst) ),

3	RecvPropInt( RECVINFO(m_flSimulationTime), 0, RecvProxy_SimulationTime ),

5	RecvPropVector( RECVINFO_NAME( m_vecNetworkOrigin, m_vecOrigin ) ),

Дальше нам надо в конструкторе связать интерполятор с переменной:

C++ Source Code:

AddVar( &m_vecOrigin, &m_iv_vecOrigin, LATCH_SIMULATION_VAR );

То есть еще и интерполяцией надо вручную заниматься. Это всё хорошо, пока большинство переменных уже заранее прописано и голова вроде не болит. Вообщем на порядок сложнее чем в голдсорсе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 09-09-2019 в 19:09:

Зачем кому-то в сети указатель на функцию в чужой памяти?

Отправлено Дядя Миша 09-09-2019 в 19:51:

Для предихтинга жеж. Хотя хз. Может и не понадобится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 09-09-2019 в 22:14:

Дядя Миша

Цитата:

указатель на функцию в чужой памяти

Это вообще законно? Вплане, не потенциальное UB?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 10-09-2019 в 05:00:

thambs
Разыменуешь — бида. Но сравнивать-то с адресами из той же памяти можно без последствий.

Отправлено Дядя Миша 10-09-2019 в 06:03:

А кто сказал, что я буду посылать по сети именно указатель? Это вы сами придумали. Указатель сперва превращается в уникальное имя Class::Function, потом это имя добавляется в общий пул строк, который автоматически синхронизируется по сети, потом я посылаю идентификатор этой строки два байта, принимаю на клиенте, превращаю обратно в строку и по строке ищу указатель на функцию.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 10-09-2019 в 06:05:

Цитата:

Дядя Миша писал:
А кто сказал, что я буду посылать по сети именно указатель?

Потому что это очень свежая и оригинальная идея. До такого никто в мире не додумался, а ты бы реализовал!

__________________

Отправлено SNMetamorph 10-09-2019 в 08:20:

Цитата:

Дядя Миша писал:
Больше скажу. Этот механизм позволяет даже передавать указатели на функции по сети.

Отправлено Дядя Миша 10-09-2019 в 08:44:

Сейв-рестор вынесу целиком в игровую часть, движку он не нужен.
Собсно, смысл в том, чтобы движок не знал ни о каких эдиктах, это вообще не его дело. Не тот уровень абстракции.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 10-09-2019 в 08:47:

Цитата:

Дядя Миша писал:
движку он не нужен.

Клиентская часть? Всякие хардкодед-мессаги для восстановления всяких разных скринфейдов?

__________________

Отправлено nemyax 10-09-2019 в 08:57:

Дядя Миша
Ну прям микродвижок, навроде микроядра ОС.

Отправлено FiEctro 10-09-2019 в 08:59:

nemyax
При том не кроссплатформенный

Я так понимаю, Дядя Миша из Ксаша решил сделать первый квейк.

Отправлено nemyax 10-09-2019 в 09:02:

FiEctro
Первый квейк кокрастоке клиент-серверный монолитный.

Отправлено XaeroX 10-09-2019 в 09:58:

Цитата:

FiEctro писал:
Я так понимаю, Дядя Миша из Ксаша решил сделать первый квейк.

Скорее, Юнити. Движок будет уметь самое основное, а все утехи навроде сейврестора и дельта-компрессии будут вынесены в дллки, ~~которые, возможно, будут продаваться в xash-store за тридцать рублей~~.

__________________

Отправлено FiEctro 10-09-2019 в 10:27:

XaeroX
Тогда это неплохо.

Отправлено Дядя Миша 10-09-2019 в 11:15:

Цитата:

XaeroX писал:
Клиентская часть? Всякие хардкодед-мессаги для восстановления всяких разных скринфейдов?

Насчёт клиента я пока не думал. Да в сущности какая разница. После чтения из .sav файла оно всё равно так же по сети общим порядком идёт на клиент.

Цитата:

nemyax писал:
Ну прям микродвижок

Сущности к движку никакого отношения не имеют на самом-то деле. Сущности это конкретика, а ядро оно про абстракцию.

Цитата:

FiEctro писал:
Дядя Миша из Ксаша решил сделать первый квейк.

ну разве что по названию пользовательской дллки. Я долго думал как её лучше назвать, ничего не придумал и плюнул.

Добавлено 10-09-2019 в 14:15:

Цитата:

XaeroX писал:
Движок будет уметь самое основное

Я бы сказал базовое:
Консоль, сетевая подсистема, звуковая подсистема, менеджер ресурсов, докачка ресурсов, рендеринг моделей с заданными параметрами, менеджер декалей, система материалов, механизм смены уровней, менеджер текстур и лайтмап, файловая подсистема, поддержка модов, сетевая таблица строк.

Ну вообщем всё, что и положено иметь в ядре. Ну и да, разумеется ядро оперирует клиентскими сущностями в плане установления сетевой коммуникации. Но и только.
Примерно так я всё это вижу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 10-09-2019 в 11:24:

Цитата:

Дядя Миша писал:
Я долго думал как её лучше назвать, ничего не придумал и плюнул.

Tier1.dll же ради сам знаешь чего

Отправлено XaeroX 10-09-2019 в 11:29:

Цитата:

Дядя Миша писал:
механизм смены уровней

Это тот же самый сейврестор с парой дополнительных фишек, разве нет?

__________________

Отправлено Ku2zoff 10-09-2019 в 13:57:

Цитата:

Дядя Миша писал:
После чтения из .sav файла оно всё равно так же по сети общим порядком идёт на клиент.

Главное, чтобы был полноценный "клиентский" сейв. То есть все звуки, партикли, декали и всякое всякое чтоб сохранялось и восстанавливалось. Мне, например, очень понравилась демонстрация сейв/рестора темпэнтить для обычной халфы, хотя в ней, как таковой нет смыла. На то они и темп энтити. А вот что из этого в итоге получилось у меня: сохраняемые треки с позицией воспроизведения во фмоде, сохраняемые спрайтовые декали из инвазиона... Да, какая это была в своё время боль, что они исчезали после загрузки. Осталось это всё использовать в моём проекте, который я никак не могу закончить.

Отправлено Дядя Миша 10-09-2019 в 14:32:

Цитата:

nemyax писал:
Tier1.dll же ради сам знаешь чего

эту хрень логичнее вынести в паблик и собирать вместе с каждой библиотекой. Попытка выстроить из них какие-то уровни только портит архитектуру. Я уже когда-то так делал, ничерта хорошего не вышло. Больше не хочу. Вот например есть у меня виртальная файловая система. Раньше бы я её действительно зопехал в какой-нибудь tier1.dll. А сейчас я её оформил как АТД одним хидером и воще не парюсь. Так намного удобнее. Если что-то близкое к CRT не тянет за собой специфичных движковых функций, то и нет никакого смысла оформлять это как очередной интерфейс.

Цитата:

XaeroX писал:
Это тот же самый сейврестор с парой дополнительных фишек, разве нет?

Нет, механизм смены уровней ортогонален сейв-рестору. Я имею в виду механизм очереди команд, когда мы ставим задачу загрузить уровень или загрузить сейв, она добавляется в очередь, потом сама вызывает завершение текущей сессии, со следующего кадра, пропускает его и еще на следующем собсно идёт загрузка нового уровня или там сейва. Потому что вызывать такие вещи из Cbuf_Execute стрёмно.

Цитата:

Ku2zoff писал:
Главное, чтобы был полноценный "клиентский" сейв.

Ну в ксаше и так декали-звуки сохранялись. А темп-энтитей не будет, я ж объяснял уже. Они не нужны просто. В халфе темп-энтити были такая калечная замена нормальным партиклям. А там где они представляли собой что-то более существенное, тем более нет смысла делать их клиентскими. Ну например те же обломки от ящика. Ну впрочем я этот механизм еще не до конца продумал, там несколько вариантов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Chyvachok 10-09-2019 в 14:44:

Кстати интересно как с лимитами будет здесь? А то а халве если честно с ними совсем туго, и на количество оружия и на кол во моделей и вылезти за них очень легко чтобы половина энтитей стала не видимой или игра вообще вылетела. В других движках оно не так жестко, взять хотя бы тот же Unreal Engine к примеру помню проходил сингл моды на анрил торнамент вроде Operation Na Pali и других там в настройках можно отключить к примеру исчезновение кусков мяса, вон в брутал думе тоже не только кровищя но и магазины с гильзами остаются, и ничего, работает и не лагает даже на старом железе, а в халве чуть что и можно вылет словить.

Да и на кол во моделей и спрайтов лимит тоже не удобно, если всего много добавлено как к примеру взять ХЛВЕ то приходится кучу моделей соединять в одну с кучей бодигруп, со спрайтами тоже самое.

Отправлено Дядя Миша 10-09-2019 в 15:14:

Ну вот всё это как раз и делается для того (в том числе), чтобы наращивать лимиты из игровой дллки, не затрагивая ядро.

Добавлено 10-09-2019 в 18:14:

Если вам хочется порассуждать за тиеричность, то самый нижний уровень - это собсно ядро, бакэнд всякий, туда пользователю соваться вообще нет смысла. Средний уровень - это игровая дллка с энтитями, логикой, монстрами. И верхний уровень - скрипты.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 10-09-2019 в 15:31:

Дядя Миша
А партиклы вообще-то не мешало бы. Довольно некрасиво выглядит ситуация когда сохранился, например, под дышалкой с паром. Загрузился, а пар снуля начинает идти, будто только включили его.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 10-09-2019 в 17:34:

ну их для этого сохранять необязательно. Время промотать вперёд, чёб они вышли на готовность и всё. Я уже когда-то такое делал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 11-09-2019 в 09:33:

Дядя Миша
Вершинную анимацию поддержишь на модельках?

Отправлено thambs 11-09-2019 в 13:46:

Дядя Миша
А так что бы сетевая игра могла работать через пару десятков НАТов без выделенного сервера с белым ip, оно возможно?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Ku2zoff 11-09-2019 в 13:51:

thambs видимо да, т.к. ребяты из FWGS замутили возможность запускать сервер на ведроиде через ви-фи. Не знаю, работает ли оно через сотовую связь, т.к. там по-умолчанию все исходящие порты закрыты самим ОпСоСом.

Отправлено Дядя Миша 11-09-2019 в 17:32:

Завершил перенос сейв-рестора в игровую дллку. Движок, соответственно, вызывает только сами методы LoadGame, SaveGame и ChangeLevel, с передачей имён уровня или .sav файла. В этом действии, как вы понимаете заключён глубокий смысл. Можно будет сделать несколько вариантов progs.dll в зависимости от лицензии и цены на покупку. То есть совсем без сейва и без чейнджлевела - это одна цена, с сейвом и чейнджлевелом, по типу кушного - другая цена и со сглаженным чейнджлевелом - максимальная.
Так же можно будет приложить исходник пустой игровой библиотеки, ну сделать там класс камеры и пару энтить. В дефолте. Или скажем физика будет различаться в разных ценовых категориях. Так что тут большое поле для возможностей.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 12-09-2019 в 03:30:

Цитата:

Дядя Миша писал:
со сглаженным чейнджлевелом - максимальная.

Да нет в нём давно неко кова смысла. Уровни сейчас делают настолько большими, что ченжлевел теперь актуален только между миссиями/юнитами. А там можно и на загрузочную картинку полюбоваться.

__________________

Отправлено Дядя Миша 12-09-2019 в 08:25:

Цитата:

XaeroX писал:
Уровни сейчас делают настолько большими

Я имею в виду не столько загрузочную картинку, сколько сохранение состояния между уровнями. Ушёл-вернулся, всё на месте. А это и для сталкера актуально.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 12-09-2019 в 08:37:

XaeroX

Цитата:

на загрузочную картинку

А как-же иллюзия бесшовности? Локации-то да большие, но если их соединяет обычный колидор или тоннель, то стоит-ли показывать картинку?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 12-09-2019 в 08:52:

Цитата:

thambs писал:
Локации-то да большие, но если их соединяет обычный колидор или тоннель

Я имел в виду, что всё это зачастую можно сделать на одной карте. А вот если телепортация в другой сектор базы - тогда картинка вполне ок. Ну вот в PW мы так решили делать.

__________________

Отправлено nemyax 12-09-2019 в 09:08:

Цитата:

thambs писал:
если их соединяет обычный колидор или тоннель, то стоит-ли показывать картинку?

Можно показать анимашку преодоления препятствия, как в бетманах.

Отправлено FiEctro 12-09-2019 в 09:26:

Цитата:

Дядя Миша писал:
Можно будет сделать несколько вариантов progs.dll в зависимости от лицензии и цены на покупку. То есть совсем без сейва и без чейнджлевела - это одна цена, с сейвом и чейнджлевелом, по типу кушного - другая цена и со сглаженным чейнджлевелом - максимальная.

А отсортированный delta.lst будет дороже неотсортированного?

Отправлено XaeroX 12-09-2019 в 10:30:

Цитата:

FiEctro писал:
А отсортированный delta.lst будет дороже неотсортированного?

Наоборот, неотсортированный будет дороже. Ведь его ещё только предстоит отсортировать и получить массу удовольствия от процесса!

__________________

Отправлено Дядя Миша 12-09-2019 в 10:41:

Цитата:

thambs писал:
А как-же иллюзия бесшовности?

да эта картинка на выбор девелопера, можно показывать, можно нет.

Цитата:

FiEctro писал:
А отсортированный delta.lst будет дороже неотсортированного?

не будет у меня дельты.лст.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 12-09-2019 в 10:55:

Дядя Миша
Ну так DEFINE_DELTA в коде всё равно сортировать можно! Или там от порядка зависеть не будет?

__________________

Отправлено Дядя Миша 12-09-2019 в 13:23:

Цитата:

XaeroX писал:
Или там от порядка зависеть не будет?

ну изначально да, порядок конечно влияет. А как будет дальше я не знаю, мож дельта-калькулятор сделаю, который сам их отсортирует ~~от ближних к дальним~~.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-09-2019 в 14:00:

Цитата:

Дядя Миша писал:
не будет у меня дельты.лст.

А за донат

Отправлено Дядя Миша 12-09-2019 в 15:40:

FiEctro ну положишь в папку с игрой, ктож тебе запретит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 13-09-2019 в 13:27:

Цитата:

XaeroX писал:
всё это зачастую можно сделать на одной карте

Я вот сейчас играю в Гопнику 2, потому что ничего толком на старой видюхе не работает. И думаю, а возможно ли на ксаше воссоздать одну из локаций этой игры? Уровень детализации примерно одинаковый с халфой, Готику в своё время ругали за устаревшую графику.

Отправлено Дядя Миша 13-09-2019 в 15:13:

Апробовал новый алгоритм дельта-компрессии. Ну что, хорошая штука, удобная. Если ничего не менялось, то ничего и не обновляется. Лимита Max Visibile Entities тут тоже не будет, принудительное обновление каждые 64 секвенции не требуются. Из чего отпадает надобность в клиентских энтитях. Если такая энтить не модифицируется, то и на размер пакета она никак не влияет. А вот с темп-энтитями сложнее. Эти вещи как правило используются для раскидывания мелкого короткоживущего мусора, который нет смысла сохранять в сейв. Если мусор живёт долго, под него логичнее выделить нормальный эдикт. А хрень типа гильз от патронов не попадает ни туда ни сюда. Потому что с одной стороны это не партикля, а с другой эдикты под такое отдавать жалко. Но эту задачку можно разрешить, если научить систему партиклов рендерить не только спрайты, но и модельки.
Думаю это самый оптимальный вариант.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 13-09-2019 в 15:29:

Дядя Миша так вроде логично, что эмиттеру должно быть пофиг, что раскидывать - или один полигон спрайта или несколько для модельки

__________________
-Brain is dead-

Отправлено Дядя Миша 13-09-2019 в 15:46:

Да вот не скажи. В том же сталкере гильзы спрайтовые сделали. Кто-то решил не заморачиваться.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-09-2019 в 16:50:

Да любая развитая ~~RenderSystem~~ система частиц умеет в модельки.

Отправлено thambs 16-09-2019 в 16:52:

Дядя Миша
Ну если гильзы будут пропадать между сэйвами и ченджлевелами это не очень красиво. В хл, те же пропадающие гибсы смотрятся мерзко.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Chyvachok 16-09-2019 в 19:14:

Кстати интересно, "размер камеры" будет зашит в движке, или в игровой длл-ке? Этот z_linear или как его там, а то в халве он маловат если честно, как пример если модель оружия от 1 лица соответствует размерам мира то она может в экран иногда залазить, особенно если позиция оружия находится близко к экрану.

Отправлено Дядя Миша 16-09-2019 в 19:32:

Z_NEAR ты наверное имел в виду.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 16-09-2019 в 19:35:

Цитата:

Chyvachok писал:
если модель оружия от 1 лица соответствует размерам мира то она может в экран иногда залазить

Это настраивается weapon_fov

__________________
-Brain is dead-

Отправлено Дядя Миша 18-09-2019 в 19:27:

Вот и дошла очередь до Pmove. Теперь его можно вернуть в класс игрока.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 18-09-2019 в 19:36:

А что такое пмове?

Отправлено Дядя Миша 19-09-2019 в 06:05:

Player Movement

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 19-09-2019 в 08:46:

Раньше игрока двигали только обстоятельства, а теперь он сам вызывает своё движение?

Отправлено thambs 19-09-2019 в 12:22:

Дядя Миша
А там тоже будут фиксированные хуллы, или как-то ещё решил сделать?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 19-09-2019 в 15:22:

thambs ну пока что формат остается близким к HLBSP из практических соображений - когда я закончу формирование игровой либы, я наверное пройду под ней разные там халф-лайфы, моды рейда, надо убедиться что ничего не испортилось. А так формат карт будет новый, что-то такое симбиотическое из сталкера\метро\ку3\хл. Еще не определился.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 21-09-2019 в 06:28:

Перенёс движение игрока и лагкомпенсатор в дллку. API должно быть как можно тоньше и использовать по возможности только атомарные типы.
Это гарантия от того, что в будущем его придётся расширять.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 21-09-2019 в 06:32:

Дядя Миша
А что мешает перенести движок целиком в дллку, как в халфе, открыть его сорцы и загружать из папки dlls мода? Это, имхо, решает абсолютно все вопросы с апи.

__________________

Отправлено Дядя Миша 21-09-2019 в 09:17:

Цитата:

XaeroX писал:
А что мешает перенести движок целиком в дллку

Так это обсалютно два разных уровня абстракции, я же писал выше.
Энтити и то как они перемещаются по миру движок абсолютно не касается.
Задача движка - отрисовать все модельки из точки зрения камеры.
Вот загрузить эти модельки и расставить по местам - это уже задача игрового кода. Ну и сетью тоже движок ведает, пакеты посылает, принимает, следит за надёжностью доставки, сжимает их.
Что тут непонятного?

ЗЫ. наконец-то доделал старую фишку - рекурсивный поиск граунд-энтитей для пушабли. Теперь если двигается нижняя пушабля (ну там на поезде или игроком), то весь стак передвигается вместе с ней. Ну разумеется будут и нормальные физические тела. Я просто обратил внимание что в некоторых случаях народ предпочитает использовать именно тупую физику, чтобы уменьшить кол-во непредсказуемых действий игрока.

Добавлено 21-09-2019 в 12:17:

ЗЗЫ. Идея в том, что мы не можем заранее предугадать организацию объектов, т.к. они целиком и полностью зависят от игры. А если у нас к примеру тетрис? Движок ведает такой абстракцией как подключённый клиент, но для движка это просто уникальный ID, к которому привязан. ну допустим стим-профиль. А что он там делает в игре - это всё на совести игрового кода. Есть вещи которые для всех игр одинаковы - это модели, звуки, вообщем ресурсы. И естественно это нижний слой абстракции.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 21-09-2019 в 12:07:

Цитата:

Дядя Миша писал:
Задача движка - отрисовать все модельки из точки зрения камеры.

Разве это не задача рендера о_О и для этого же в XT был заведен кастомный рендер-интерфейс. Теперь его не будеть чтоль?

Про pmove хоррошая новость, помню как я задолбался скакать из файла в файл, когда делал кушную физику для игрока

__________________
-Brain is dead-

Отправлено XaeroX 21-09-2019 в 12:32:

Цитата:

Дядя Миша писал:
Задача движка - отрисовать все модельки из точки зрения камеры.

А если я хочу сам решать, как мне рисовать модельки и из какой точки зрения? Тут выйдет облом?

__________________

Отправлено Дядя Миша 21-09-2019 в 13:51:

Цитата:

KiQ писал:
Разве это не задача рендера о_О

Ну так рендер ведь тоже в движке.

Цитата:

KiQ писал:
для этого же в XT был заведен кастомный рендер-интерфейс. Теперь его не будеть чтоль?

Он там был заведён исходя из того что оригинальная графика немножко устарела. Да и то, можно подумать хоть кто-то им воспользовался кроме меня. Нет, не будет конечно.

Цитата:

XaeroX писал:
А если я хочу сам решать, как мне рисовать модельки и из какой точки зрения?

ну так точка зрения и задается в игровой библиотеке, равно как и положение моделей в пространстве. А если речь про кастомный рендеринг, то это всё равно никто и никогда не использует. Если уж делать подобные вещи - это нужна система плагинов и каждый плагин под каждый формат моделей, соответственно. Ну как в Джеке

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 21-09-2019 в 14:27:

Дядя Миша как никто не воспользовался? Был же custom build от товарища) Тут дело такое, есть например базовые вещи, скажем нормал-мэппинг, тени, отражения там. А есть специфические вещи, например я для мультиплеерного билда, который мы с купахтомасом гоняли, кодил на клиенте эффект реальной линзы для вьюмоделек с прицелом (ну там арбалет, револьвер). У меня это было привязано к имени текстуры в модельке (модельки я перекомпилировал, соответсвенно). И вот в отрисовке вьюмодельки я проверял на наличие этой текстуры и рендерил в нее фреймбуфер мира, понимаешь, да) Может и не самый правильный подход, но без кастомного рендера такого в принципе не сделаешь. Если, например, такое будет можно тонко провернуть с помощью шейдеров и скриптов - то будет замечательно или тот же моушен-блюр, хотя я знаю, ты его не любишь)

Добавлено 21-09-2019 в 17:27:

То, что в новом XT шейдеры были переведены на glsl это огромный шаг, кстати, я их понемногу ковырял, пока в жизни не начались проблемы и времени на это перестало быть)

__________________
-Brain is dead-

Отправлено Дядя Миша 21-09-2019 в 17:41:

Ну такие вещи быстрее всего будут доступны через систему материалов.
Рендеринг вообще дело мало кому нужное. Это в первую очередь загрузка треугольников и вертексов в VBO. Вам это всё точно не нужно. Вам надо чёб можно было кастомные шейдеры и свои параметры в них.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 21-09-2019 в 17:43:

Цитата:

Дядя Миша писал:
Вам надо чёб можно было кастомные шейдеры и свои параметры в них.

Ещё OIT важная штука.

__________________

Отправлено Дядя Миша 21-09-2019 в 18:01:

OIT в продакшене не юзают - тормозно

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 21-09-2019 в 18:37:

Дядя Миша
Ну хотя бы сортировка, с возможностью гибкой настройки.

__________________

Отправлено nemyax 21-09-2019 в 19:33:

Дядя Миша
Уровни-то как надо будет делать? Моделить?

Отправлено Дядя Миша 21-09-2019 в 19:59:

ну конечно надо, чтож за игра без уровней

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 21-09-2019 в 20:00:

Ну так моделить или кубать?

Отправлено KiQ 22-09-2019 в 06:25:

Я за то, чтобы кубать)) ну по крайней мере основную геометрию. Вот честно, нигде не видел более удобной работы с текстурированием, именно в плане маппинга, чем в VHE/Джеке. Ну знаете это, когда референсный плэйн выделяешь и потом правой кнопкой мацаешь, и текстура с такими же параметрами вставляется, скейл там, UV и прочее. Там какой-то шаманизм с текстурной матрицей видимо, я так до конца и не разобрался, но удобно прям вообще)

__________________
-Brain is dead-

Отправлено Дядя Миша 22-09-2019 в 06:47:

nemyax на усмотрение разработчика

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 22-09-2019 в 08:07:

Цитата:

KiQ писал:
Вот честно, нигде не видел более удобной работы с текстурированием, именно в плане маппинга, чем в VHE/Джеке.

Ты пробовал текстурировать скалы?

__________________

Отправлено KiQ 22-09-2019 в 09:38:

XaeroX сложный ландшафт логично делать моделью) я говорил про основную геометрию. Да и в любом случае, лоу-поли скалы удобнее текстурить в джеке, чем долбаться с разверткой в том же блендере. Просто для того, чтобы по-быстрому накидать уровень любой 3d-моделлер слишком избыточен

__________________
-Brain is dead-

Отправлено Дядя Миша 22-09-2019 в 13:55:

Ну чтоже. Вот мы вплотную и подобрались к самой главной, так сказать фундаментальной проблеме всего движка. К формату его уровней. Это краеугольный камень всего. От этого зависит как на уровне взаимодействуют монстры, как отсекается видимость, насколько надёжна физика и насколько быстро всё это рендерится. Ни один из существующих форматов, близких по духу к кушным движкам не отвечает поставленным требованиям. Возможно кто-то просто не задавался таким вопросом или наоборот считает, что там всё в порядке. Я на это отвечу следующим образом: если сознательно ограничить свою фантазию колидорами из кваки - то конечно жы проблем нет.

Перечислю здесь основные проблемы, применительно к форматам уровней Quake1 и Quake3 (я их выбрал как базовые, которые знаменовали смену поколений). Но сперва обозначу общие проблемы, которые нас подстерегают в 2019-м году, если мы решили строить наши уровни вокруг BSP-дерева:

1. Очевидно, что BSP-деревом можно описать любую солидную структуру. Для ускорения поиска и пересечения. Но есть проблема. Чем больше полигонов в структуре - тем больше дерево. В какой-то момент возникает ситуация, когда нережущие алгоритмы управляются на порядок лучше режущих. К тому же BSP существует в варианте, который ничего не разрезает и там оно не сказать что блещет производительностью. К тому же само его построение с уникальными полигонами на ноде может занять чертовски много времени. Ну с этим можно бороться сделав какие-то изначальные допущения. Сам алгоритм особо не покрутишь.

2. Из преведущего пункта очевидно вытекает, что наилучшим образом с BSP дружат браши - замкнутные конвексные структуры, которые по своей сути обладают одним интересным свойством - их легко редактировать, легко текстурировать и они хорошо держат точность, чтобы на базе такой геометрии можно было строить абсолютно замкнутые уровни и генерировать порталы видимости в автоматическом режиме, а не заниматься расстановкой функ_окклюдеров. Но есть у брашей и серъезные минусы. В силу специфики их текстурирования, из брашей практически нереально построить tri-strip объекты для ускорения отрисовки. Невозможно склеить вертексы, когда на каждой стороне браша какая-то своя отдельная текстура. В моделях такое практически не встречается, хотя разумеется и возможно. Ну просто там изначально другой подход к текстурированию. Из чего вытекает следующее правило - много брашевой детализированной геометрии будет тормозить независимо от того как мы её оптимизируем. Невозможность использования стрипов снижает конечную производительность от 1/3 до 1/2 от возможной скорости. Из чего сам собой напрашивается вывод - использовать брашевую геометрию только для грубых набросков, не увлекаться.

3. BSP обладает приятной возможностью создать офлайн-массив видимости, т.е. заранее знать из какого сектора уровня какой будет виден. Не в последнюю очередь благодаря автоматической генерации порталов. Собственно это вообще единственный способ иметь такую видимость. Все остальные способы базируются на уже отрендеренных полигонах и на PC имеют лаг, связанный с получением данных непосредственно из видеокарты (на приставках ЧСХ лага нет, там другая архитектура). Это обходится либо созданием упрощённого софт-рендера, который работает в отдельном потоке, либо забиванием на оптимизацию, как в юнитях разных. Но всё это имеет смысл только коридорной геометрии. На открытых пространствах толку никакого, как вы понимаете.
Очевидно что полагаться на один PVS нельзя, требуются дополнительные способы.

4. Возможность трассировки полигонов без построения каких-то дополнительных ускоряющих структур. Очень сильно завязано на детализацию, как вы понимаете. Плюс сам факт разрезания полигонов не полезен для рендеринга. Но можно решить построением нескольких деревьев и разных наборов видимых сурфейсов, хотя это и приводит к увеличению размера карты. Можно построить чисто аксиальное дерево, однако в плане увеличения производительности от него немного толку.

5. Надо так же отметить, что вышеописанные проблемы при отказе от BSP, вообщем-то никуда не деваются, а некоторые становятся вообще принципиально неразрешимы, типа рассчёта PVS. Отказ от брашей нецелесообразен, поскольку дизайнеру часто требуется создавать какие-то зоны, водные пространства, триггеры, навмешы. Брашы для этих целей подходят идеально. Как там народ делает триггеры в движках без брашей остается только догадываться.

Добавлено 22-09-2019 в 16:55:

Теперь по списку проблем в уже известных форматах.
Применительно к Quake1:

1. Слишком подробное дерево. Это хорошо для реализации сверхбыстрой точечной трассы, но плохо для визуализации, если мы собираемся использовать дерево. Впрочем для рендеринга можно использовать другие собирательные структуры, ну скажем нечто вроде суперлифов, которые включают в себя основные лифы с видимостью и детальные лифы с такой же видимостью.
2. Фиксированные хуллы. На основе информации, имеющейся в карте возможно построить коллизию для произвольных фигур, но есть одна проблемка - туда не попадут клипбрашы. Восстановление клипбрашей из соответствующих деревьев тоже не будет точным, поскольку для разных хуллов деформированная геометрия уже выглядит не так как для точечного (ну вы это могли видеть, включив визуализацию хуллов).
3. Raw-лайтмапы. Ну это легко исправить, немного доработав формат. Минус таких лайтмап в том, что они провоцируют появление швов на сложной геометрии, состоящей из треугольников. Если кубать строго квадратными брашами, то никакой проблемы нет. Но брашевый ландшафт из треугольников провоцирует появление швов на лайтмапах, несмотря на все метды противодействия им.
4. Нету ареапорталов. Ну здесь я даже не знаю, так ли уж они актуальны в наше время. Мне кажется этот подход уже устарел и не нужен. Он только усложняет получение информации видимости в различных частях рендерера, т.к. необходима синхронизация состояний, плюс лишняя нагрузка на сеть.

Применительно к Quake3:
1. Брашы вместо клипнодов. Может показаться странным, но по некоторым причинам код трассировки брашей неоднозначен. Есть там такая проблемка, при которой с одной стороны браша игрок проникает в него на эпсилон, а с другой наоборот - не достает. Решается через параметр overbounce, который отталкивает игрока в PM_FlyMove. Как в ку2, так и в ку3. Я не знаю, может вальва в сорсе и решила эту проблему (там не юзается овербаунс), но в Doom3, Кармак от греха вообще не использует коллизию по брашам, они там только для определения контентсов.

2. Упрощённое дерево. Баланс между избыточностью и скоростью. Для рассчёта PVS и рендеринга дерево оптимально, для трассировки производительностью не блещет, из-за чего возможно лайтмапы считаются достаточно медленно. Впрочем это можно решить, построив в лайтмаппере какую-то кастомную трассу.

3. Типы поверхностей. Нет юниформности, мы должны с каждым видом действовать по своему. С брашами так,с патчами эдак, с фларесами иначе. В качестве эксперимента может это было и неплохо, но вообще это очень неудобно. После компиляции мы не должны знать что это было раньше патч или модель, для нас это должен быть просто полигон. Впрочем допустимы некоторые хинты, которые позволят загружать группы полигонов в VBO единым целым, например, если из них реально построить стрипы (для патчей или моделей). Ну вообщем достаточно неоднозначная вещь.

4. карта не содержит в себе информацию о рёбрах, которая могла бы нам пригодится, ну например для физики, или Ксероксу для создания теневых объемов

Подводя итоги, хочется обратить ваше внимание, что ни тот ни другой из форматов в чистом виде нам не подходит. И модификация в любом случае будет достаточно серъезным делом. Основной вопрос заключается в том, какой из форматов взять за исходную точку для дальнейших доработок.
Собственно оба подходят в равной степени, надо решить нелёгкий вопрос, что будет быстрее в плане имплементации, что займет меньше времени.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 22-09-2019 в 14:16:

Да неко кой!

Отправлено Дядя Миша 22-09-2019 в 14:24:

ncuxonaT ответ неверный. Имплементация любого другого формата займет еще больше времени.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 22-09-2019 в 14:37:

Помню, в серьёзном сэме были огромные пространства и при этом отличная производительность. Или это только за счёт того, что на тех пространствах нихренашеньки кроме монстров не было?

Отправлено Дядя Миша 22-09-2019 в 15:09:

Пространства сами по себе значения не имеют. Имеет значение только поликаунт. Вон в первом дууме ставят на карту сто тысяч монстров и это всего-навсего 200 тысяч треугольников, монстры-то спрайтовые!
Вот и не тормозит. Вспомнил забавную штуку, вот как раз связанную с пространствами. Есть такая единственная игра для Unigine - называется Cradle. При старте мы спавнимся в своей хижине. Хижина жутко интерактивная. Там все предметы настоящие. Это значит что в любом комоде, мало того, что можно выдвинуть любой ящик, так еще и в этих ящиках лежат настоящие итемы, которые можно брать. Ну вообщем внутри хижины поликаунт зашкаливает просто. А я тогда рассуждал в точности как ты - уж если в индоре такие тормоза, то в аутдор вообще соваться без резона. Но я набрался храбрости, выглянул и офигел. Потому что гигантский аутдор (5-7 кв.км) ВООБЩЕ не тормозил, а чему тормозить, если это был пустой ландшафт?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 22-09-2019 в 16:33:

Цитата:

Quake1

Дикие разрезы, выпадающие полигоны и дыры в клипбрашах. Настоящий комшмар мэппинга — уйма времени уходит на то что бы не было видимых щелей и косяков, и невидимых препятствий и дыр. И, естественно, чем геометрия детальней и чем сильнее отличается от аксиальной, тем больше вылезает проблем. Даже p2st хоть и дают результат лучше всего, но всё равно требуют повышенной внимательности к таким деталям.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 22-09-2019 в 17:44:

Цитата:

Дядя Миша писал:
если сознательно ограничить свою фантазию колидорами из кваки - то конечно жы проблем нет.

Ничем не ограниченная фантазия во все времена приводила к эпичным провалам.

Цитата:

Дядя Миша писал:
Чем больше полигонов в структуре - тем больше дерево.

Это не совсем верно. Ку3шное дерево зависит только от структурных полигонов, но не детальных.

Цитата:

Дядя Миша писал:
из брашей практически нереально построить tri-strip объекты для ускорения отрисовки.

Никогда не понимал этой фанатичной сакрализации три-стрипов, по крайней мере со времён первого GeForce, т.е. появления TnL-кэша.

Цитата:

Дядя Миша писал:
На открытых пространствах толку никакого, как вы понимаете.
Очевидно что полагаться на один PVS нельзя, требуются дополнительные способы.

Поиграй в те же TES4, TES4 или Фоллауты. Там мухи отдельно, котлеты отдельно. В смысле, есть ландшафт с чем-то вроде ROAM и лодами, а есть калидоры с PVS, а между ними - загрузки с прогрессбаром. И людей это уже 10 лет как вполне устраивает.

Цитата:

Дядя Миша писал:
Как там народ делает триггеры в движках без брашей остается только догадываться.

Я в 2001 году делал триггеры под первый UE без брашей. Как-нибудь напишу мемуары об этом.

Цитата:

Дядя Миша писал:
Нету ареапорталов. Ну здесь я даже не знаю, так ли уж они актуальны в наше время. Мне кажется этот подход уже устарел и не нужен. Он только усложняет получение информации видимости в различных частях рендерера, т.к. необходима синхронизация состояний, плюс лишняя нагрузка на сеть.

Вот здесь - долго смеялся.

Цитата:

Дядя Миша писал:
карта не содержит в себе информацию о рёбрах, которая могла бы нам пригодится, ну например для физики, или Ксероксу для создания теневых объемов

Пригодиться они могут примерно как ворона эстонцу из анекдота.
А всерьёз писать про теневые объёмы в 2019 году просто неприлично.

Цитата:

nemyax писал:
в серьёзном сэме были огромные пространства и при этом отличная производительность.

Там полигонов было, по ощущениям, меньше чем в первой халфе, на все эти огромные пространства.

Цитата:

Дядя Миша писал:
Вон в первом дууме ставят на карту сто тысяч монстров и это всего-навсего 200 тысяч треугольников, монстры-то спрайтовые!

Там ИИ примитивный, вот и не тормозит. Сделай в халфе 100 тысяч монстров ВООБЩЕ без модельки - и офигеешь от тормозов сервера.

__________________

Отправлено thambs 22-09-2019 в 18:18:

Цитата:

ИИ примитивный

Ну зато бегают хотя-бы, а не стоят на месте притопывая ножкой.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 22-09-2019 в 18:25:

thambs
Там и pathfinding примитивный, чего бы им не бегать? Это вам не CheckLocalMove с триангуляцией плюс нодеграф.

__________________

Отправлено Дядя Миша 22-09-2019 в 18:58:

Цитата:

XaeroX писал:
Ку3шное дерево зависит только от структурных полигонов, но не детальных.

это и так подразумевается.

Цитата:

XaeroX писал:
Никогда не понимал этой фанатичной сакрализации три-стрипов

Да вон ЧАЭС без стрипов с лайтмапой - ФПС вдвое упал.

Цитата:

XaeroX писал:
Там ИИ примитивный, вот и не тормозит

Да понятно что ИИ. Но я про полигоны.

Добавлено 22-09-2019 в 21:46:

ИИ там кстати как в квейке. Но в 2Д.

Добавлено 22-09-2019 в 21:58:

Я тут пытаюсь решить задачку с материалами. Кутришные шейдеры очевидно устарели и не конают. К тому же там все типы встроенные.
Можно просто скопипастить материалы из паранои, но встанет вопрос - а как подключать кастомные glsl. И передавать в них параметры.
В параное без вариантов. Но в NT надо сделать подгрузку кастомных GLSL шейдеров. И тогда уже мутить что угодно со спокойной душой.
Была у меня такая любопытная имплементация кажется в 2015-м году. Для NT как раз и делалась.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 23-09-2019 в 07:49:

Расскажу немного о новой концепции материалов. Она не совсем новая, я её придумал еще в 2015-м году, но тогда посчитал излишним к реализации, поскольку разработка NT застопорилась, а для паранои она бы была черезчур сложной. В чём основная идея?
Материалы у нас, как вы знаете основываются в первую очередь на возможностях рендерера. До появления программируемого конвейера вполне логичным было бы просто охватить все возможные комбинации и стадии фиксированного конвейера и задавать рендеринг довольно простым языком, который Кармак реализовал еще в Quake3. Впоследствии, когда появился бамп и Cg, эта система была пересмотрена в сторону упрощения, но всё равно не избавилась от духа FFP. В настоящее время её использование носит негативный характер. Там где требуется создать простой материал она избыточна, а там где материал кастомный что либо реализовать затруднительно. Собственно, этот момент отразился уже в Wolfenstein 2009, там дуумтришную систему материалов полностью перепахали в сторону гибкости и использования шейдеров. В чём заключается моя идея?
Нам не надо пытаться описать в материале принципы рендеринга, это реализуется в GLSL, в стандартных или пользовательских шейдерах.
Всё что нам надо - это настроить переменные и юниформы, однако как вы понимаете, прописывать каждый раз пачку переменных для каждого материала каждой текстуры - сомнительное удовольствие. На помощь приходят шаблоны с предустановленными дефолтными параметрами.
Однако и тут возникает вопрос - надо ли нам каждый раз прописывать пути к каждой текстуре, ведь мы не сможем указать эти пути явным образом в шаблоне? Явным образом нет, но мы можем построить наш путь из переменных значений, таких как <wadname>, <modelname>, <mapname>. Приведу пример шаблона и материала, построенного с его использованием. Это ни в коем случае не окончательный вариант синтаксиса, один из текущих:

C++ Source Code:

1	template<world>

3	image u_ColorMap = "textures/<wadname>/<mipname>.tga";

4	image u_NormalMap = "textures/<wadname>/<mipname>_norm.tga";

5	image u_GlossMap = "textures/<wadname>/<mipname>_gloss.tga";

6	image u_DetailMap = "$matdesc/detailMap";

7	image u_DepthMap = "$screendepth";

8	image u_DeluxeMap = "$deluxemap";

9	image u_LightMap = "$lightmap";

10	image u_GlowMap;

11	matdef material = "metal";

12	float u_Smoothness = 0.35f;

13	float u_ReflectScale;

14	float u_RefractScale;

15	float u_AberrationScale;

16	float u_ReliefScale;

17	vec2 u_detailScale = "$matdesc/detailScale";

20	shader<world>

22	vertex = "glsl/<progname>_vp.glsl";

23	fragment = "glsl/<progname>_fp.glsl";

24	template = world;

27	"ps_metal00"

29	template world;

Здесь image создаёт юниформ-сэмплер для GLSL и грузит текстуру в случае наличия дефолтного пути, который формируется из переменных, заключённых в треугольные скобки. Текстуры со знаком доллара - это внутренние, которые движок подставляет по смыслу. ну разумеется, каждому полигону достанется именно своя лайтмапа, а не какая-то абстрактная. $screendepth будет содержать копию экрана глубины, полученную перед рендерингом меша, содержащего в себе именно этот материал. vec2 u_detailScale = "$matdesc/detailScale"; возьмёт дефолтные значения из materials.def. Сам materials.def не расширяемый, его параметры определеные заранее, ну вы его видели в параное. Там всякие звуки-партиклы при попадании пули в стенку, звуки шагов, декали, физические свойства материала. Ну и возможность задавать некоторые физичные параметры разом для всего шаблона, ну скажем smoothness или detailScale, хотя можно и просто прописать константу. Впрочем, еще раз скажу - это ни в коем случае не окончательный вариант, это просто для понимания как будет выглядеть система.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 23-09-2019 в 08:31:

Дядя Миша
Допустим чувак захочет реализовать подсветку досягаемого объекта под кросс-хером. Как ему поможет такая система материалов? Ведь для конкретного объекта не выставишь униформ.

Добавлено 23-09-2019 в 11:31:

Хотя по идее в униформ можно толкнуть ID объекта.

Отправлено Дядя Миша 23-09-2019 в 09:16:

nemyax всё зависит от тех переменных, которые мы передаём в шейдер. Я же не сказал, что можно будет прописать только константы.
Будет привязка как к глобальным, так и к локальным переменным.
Но синтаксис я пока еще не продумал.
Опять же, можно наделать много шаблонов на все случаи жизни и использовать их в разных материалах, на ходу перегружая те или иные параметры. В основе системы лежат два простых соображения:
1. чтобы не надо было каждый раз прописывать одно и тоже для кучи материалов или в крайнем случае это был минимальный набор данных.
2. чтобы любой из заданных параметров было возможно перегрузить. В том числе - создать новый параметр, который в шаблоне вообще отсутствует.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 23-09-2019 в 09:56:

Я бы вместо треугольных скобок сделал квадратные, а то и вообще без всяких скобок, просто писать в верхнем регистре: WADNAME, MIPNAME.

Отправлено Дядя Миша 23-09-2019 в 10:01:

ни в коем случае квадратные. Шаблоны вот именно так и обозначают через треугольные.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 23-09-2019 в 10:02:

Crystallize
Угловые скобки — признак того, что перед тобой шаблон. Капсят по традиции, когда определили макрос. А квадратные скобки используются для доступа по индексу.

Отправлено Дядя Миша 23-09-2019 в 10:11:

Я вообще когда пишу очередную скриптовую систему стараюсь всегда придерживаться синтаксиса С\С++, чтобы было интуитивно понятно при первом же изучении. Тех, кто изобретает свой синтаксис ждёт аддельный котёл в аду, например авторов петона.

Добавлено 23-09-2019 в 13:11:

Ну вот что это за дрянь к примеру:

C++ Source Code:

def b2midcp(p0, m, p2):

"cp to get b2 line from p0 to p2 passing thru m"

return 2.0*m-0.5*(p0+p2)

все глаза вытикли

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 23-09-2019 в 10:14:

Цитата:

Дядя Миша писал:
Тех, кто изобретает свой синтаксис ждёт аддельный котёл в аду, например авторов петона.

Главный порок синтаксиса петона — индентация без вариантов, а не то, что он не сишный. Петон в конце концов не преподносится как производный от си, так что тут взятки гладки.

Отправлено Дядя Миша 23-09-2019 в 10:21:

В моём представлении любой скриптовой язык это в первую очередь песочница и безопасная работа с памятью. Зачем там изобретать новый синтаксис мне вообще непонятно. Я могу понять какие-то небольшие отличия, обусловленные возможностями языка. Но всё переиначивать это маразм.

Добавлено 23-09-2019 в 13:21:

Народ живёт стереотипами, ему почему-то кажется, что это его святой долг - выдумать совершенно новый непохожий синтаксис. В связи с этим вспоминается, как Лебедев устроил конкурс на самую лучшую панель кнопок для лифта и куча идиотов прислала ему совершенно дикие варианты. Вот тоже самое абсолютно. Сишный синтаксис в первую очередь ценен своей максимальной наглядностью и удобочитаемостью. Первый признак мудака - это когда начинают заменять фигурные скбоки, то вообще их выкинут как в петоне, то пропишут словами begin\end или на квадратные заменят. Вот зачем спрашивается? А низачем, чтобы люди страдали. Thambs например. Он жы любит страдать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 23-09-2019 в 10:22:

Цитата:

Дядя Миша писал:
Зачем там изобретать новый синтаксис мне вообще непонятно

Потому что набор идей в основе языка другой и сишный синтаксис (который вообще говоря не прописан в уголовном кодексе как обязательный) не подходил. Хорошо ли или плохо реализован этот набор, это другой вопрос =)

Отправлено Дядя Миша 23-09-2019 в 10:26:

Я вам больше скажу - никто и никогда не проводил психовизуальное тестирование восприятия разного синтаксиса человеческим глазом. А если бы провели, то очень быстро убедились, что отличные от С\С++ варианты максимально затрудняют восприятие, особенно в тепичном блокноте без подсветки.

Добавлено 23-09-2019 в 13:25:

Цитата:

nemyax писал:
Потому что набор идей в основе языка другой

Другой набор идей был в старом васике, который исполнял код, прыгая по нему при помощи goto и там еще строки надо было вручную нумеровать, да.
У меня на спектруме такой был.

Добавлено 23-09-2019 в 13:26:

Есть всего два варианта: со стеком или без. Остальное - косметика.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 23-09-2019 в 11:33:

Дядя Миша
Ну смотри.
- Типы расслабленные, значит половина сишного синтаксиса уже отпадает, в том числе способ объявления функций.
- Встроенные составные типы: кортежы, списки, словареги. Нужен синтаксис.
- Присутствуют всякие фишки из функциональщины типа анализаторов списка, лямда-функций и зайчатошного паттерн-матчинга. Раньше, чем Страус начал скотчем приматывать их к плюсам.
И так далее. Так что по-любому от сей мало что осталось бы. Ну если бы занимались именно художественной резьбой по сям.

Отправлено Дядя Миша 23-09-2019 в 11:46:

nemyax объясни мне пожалуйста каким образом наличие кортежей запрещает использовать фигурные скобки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 23-09-2019 в 12:04:

Никаким. Конкретно это — обычная щепотка маразма. Фигурные скобки действительно не помешали бы. А инициализировать словарики можно было бы и по-другому.

Добавлено 23-09-2019 в 15:04:

Вообще говоря, ну если нужен сиподобный скриптовой язык, вон же Squirrel.

Отправлено Crystallize 23-09-2019 в 12:35:

Цитата:

Дядя Миша писал:
ни в коем случае квадратные. Шаблоны вот именно так и обозначают через треугольные.

Люди которые будут в конечном счёте использовать эту систему, скорее всего не будут программистами и не будут иметь привычки к сишному синтаксису. Мапперам и художникам тоже нужно будет задавать какие-то материалы. Мне просто кажется что для обычного человека идея задавания некоего поля с типом сущности где можно уже перебирать конкретные сущности - эта идее более наглядно выражается квадратными скобками, астерисками по обоим краям, или верхним регистром. Треугольные скобки - они в чём-то на кавычки похожи.
Может ты и прав, впрочем.

Ты тут затронул две крупные темы, это очевидность сишного синтаксиса и про дизайн тоже.

Те "идиоты" которые Лебедеву слали всякие странные эскизы, они поняли дизайн как что-то что должно быть оригинально, интересно, круто, и зрелищно. Я могу их понять, потому что если дизайнить всё как айфон то от скуки выть захочется.

Отправлено nemyax 23-09-2019 в 12:49:

Цитата:

Crystallize писал:
Люди которые будут в конечном счёте использовать эту систему, скорее всего не будут программистами и не будут иметь привычки к сишному синтаксису

Раз уж они полезли в код, то пусть будут готовы встретить смыслы там, где не ожидали, или не такие, как ожидали. Где они были, когда создавался си? А щас уже поздняк метаться.

Отправлено KiQ 23-09-2019 в 13:42:

Crystallize ну лебедев вообще заново пирдумал букву "М" за сто лярмов, чо уж там

Добавлено 23-09-2019 в 16:35:

Цитата:

Дядя Миша писал:
таких как <wadname>

Here we go again

Добавлено 23-09-2019 в 16:35:

Цитата:

KiQ писал:
Где они были, когда создавался си?

В планах)

Добавлено 23-09-2019 в 16:42:

Если брать систему материалов в таком варианте, то логично завести файлик типа mats.def, где и делать все привязки, а сами материалы соответственно прописывать в каждый файл отдельно. Но вообще это имхо уже ненужное нагромождение. Просто сканировать папку materials и загружать все материалы. Тут ведь проблема скорее не в том, как в движке это реализовать, а как на этапе маппинга задать материал геометрии. Ну, скажем, если мы делаем что-то моделькой, то ID материала указывается в блендере/максе или где там кто моделлит. Если мы кубаем - то тут уже сложнее. Идет привязка к имени текстуры, ну это все знают, разные там префиксы и прочее. А вот унифицировать это все пока что по идее никаг

__________________
-Brain is dead-

Отправлено Дядя Миша 23-09-2019 в 13:58:

Цитата:

Crystallize писал:
эта идее более наглядно выражается квадратными скобками

вот как раз наоборот квадратные скобки меньше бросаются в глаза их легко перепутать, вспоминайте чортовы FGD, где постоянно забывали на этот счёт.

Добавлено 23-09-2019 в 16:58:

Вообще очень тяжело писать код, когда в голове еще не выстроилась система. Я когда так пишу у меня код страдает чудовищной избыточностью, потом лишнее удалять приходится.

Цитата:

KiQ писал:
то логично завести файлик типа mats.def, где и делать все привязки,

шаблонов может быть сколько угодно, я их придумал объявлять в хидерах. Ну конечно это необязательно, можно и в mat-файле.
Определённое имя имеет только materials.def, но это совсем другие данные.
То что находится там используется в основном физикой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 23-09-2019 в 14:35:

Цитата:

Дядя Миша писал:
Вообще очень тяжело писать код

Вы хотите поговорить об этом?

А вообще говорю, тут основная проблема с точки зрения потенциального разработчика игры - не в движке, а в инструментарии. Ну то есть, если например вы с Ксероксом наладите диалог, и в джеке появится плагин ориентированнный именно на NT - то это будет прям бум-круто. А если пользоваться тем инструментарием, что пока доступен, то многих это отпугнет в принципе (порог вхождения и все такое), для остальных создаст определенные неудопства в разработке. То есть, ту дело в чем. Как я понял из озвученных задумок, планируется основательно перелопатить движок и либы. Но это закономерно приводит вот к чему, у каждого движка есть определенная сформированная экосистема. Скажем, кто-то до сих делает уровни под дуум, или кубает под халфу и т.д. В случае с NT получается так, что люди, еще вчера кубавшие под халфу, получают по сути движок на две головы выше, но со схожими принципами. И очень важно, чтобы инструментарий соответствовал. Есть уже компиляторы карт, моделей, и другие Xash Tools, но вот в плане маппинга, учитывая общую идею и общее направление мысли, как движок будет развиваиться, тут нужно думать в этом плане. Потому что как бы движок не был хорош, для игроделов все в итоге решает инструментарий, понимаешь да?

__________________
-Brain is dead-

Отправлено nemyax 23-09-2019 в 14:40:

KiQ
Но ЧАЭС-то из модельки сделался уровнем. Значит и для NT, наверное, можно будет так же. А уж для создания моделек инструментария хоть объешься.

Отправлено Дядя Миша 23-09-2019 в 14:43:

Цитата:

KiQ писал:
А вообще говорю, тут основная проблема с точки зрения потенциального разработчика игры - не в движке, а в инструментарии

Ну я надеюсь, что к моменту окончания работ над NT Ксер откроет SDK Джека. А если нет, то будем принимать меры.

Цитата:

nemyax писал:
Но ЧАЭС-то из модельки сделался уровнем

Вообще это неправильно. Сталкер так не делает. Он эту ЧАЭС на куски режет повсякому.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 23-09-2019 в 14:45:

nemyax ну я вот моделить не умею от словасовсем. И опять же, ты не уловил видимо. Я говорил про экосистему вокруг движка и инструментарий, который для него специально сделан, понимаешь да. Те ксаш-тулзы и т.д. А вот для маппинга с учетом новой концепции по сути ничего из существующих решений толком не подходит

Добавлено 23-09-2019 в 17:45:

Цитата:

Дядя Миша писал:
Ну я надеюсь, что к моменту окончания работ над NT Ксер откроет SDK Джека. А если нет, то будем принимать меры.

Ну я про это собственно и говорил

__________________
-Brain is dead-

Отправлено Дядя Миша 23-09-2019 в 15:03:

Да ну какая там может быть новая концепция? Статичные модели по прежнему расставляются через точечные энтити, а вокруг уровня - всё тот же скайбокс. Я совершенно нехочу это менять. Если кому-то это не нравится, для них всегда юнити там разные, унреалы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 23-09-2019 в 15:09:

Цитата:

Дядя Миша писал:
Статичные модели по прежнему расставляются через точечные энтити

Но динамически тенят и анимируются на месте, правильно?

Отправлено Crystallize 23-09-2019 в 15:41:

Цитата:

nemyax писал:
Раз уж они полезли в код, то пусть будут готовы встретить смыслы там, где не ожидали, или не такие, как ожидали. Где они были, когда создавался си? А щас уже поздняк метаться.

А это код? Я думал это как VMT в сорсе.

Отправлено Дядя Миша 23-09-2019 в 17:37:

Пока что сделал так:

Тимплейт в хидере template.h:

C++ Source Code:

1	template <worldSolidMaterial>

3	image u_ColorMap = "textures/<wadname>/<mipname>.tga";

4	image u_DetailMap = "materials.def::detailmap";

5	vec2 u_DetailScale = "materials.def::detailScale";

6	float u_Smoothness = "0.35";

Описание материала:

C++ Source Code:

1	#include "scripts\template.h"

3	"fifties_wall1y" worldSolidMaterial

Синтаксис тимплейтов вопросов не вызывает, т.к. их немного, их писать нетрудно. Но для каждого материала предполагается вот так и писать пару: имя текстуры - имя шаблона. В визуальном редакторе проблем не будет, но меня интерисует насколько это ненапряжно при ручном редактировании. Еще предположим вариант, когда материал полностью наследует свои свойства от шаблона. Тогда вероятно надо предусмотреть короткую запись, ну что-то типа

C++ Source Code:

"fifties_wall1y" worldSolidMaterial;

Что думаете? Как вариант можно усложнить синтаксис и добавить явные слова, ну скажем

C++ Source Code:

"fifties_wall1y" using worldSolidMaterial

но навряд ли в этом есть смысл. Подобные вещи делаются в первую очередь для юзера, а не для парсера. Парсер-то разберётся.

Добавлено 23-09-2019 в 20:35:

Полез ради интереса в Wolfenstein 2009, а там такое

C++ Source Code:

1	textures/decals/floating_trash

3	TextureTransform

5	Translate { Global::Time.x * .018 Global::Time.x * 0 }

  NoShadows

8	NoOverlays

9	NoFragment

  NoTFix

11	MaterialType NoImpact

12	Contents NonSolid

13	Technique DSAddGBuffer%r_gBufferMode%_AlphaTest_TextureTransform_Depth

14	Image NormalMap textures\decals\trash_decal_street_local

15	Image DiffuseMap textures\decals\trash_decal_street_d

16	Image SpecularMap textures\decals\trash_decal_street_s

17	Image MaskMap textures\decals\trash_decal_street_d

18	AlphaTest 0.40

19	Vector Specular 64 .1 1 0

20	vertexcolor

22	textures/decals/pebbles_01

24	EditorImage textures/decals/pebbles_01_d

25	Image DiffuseMap textures/decals/pebbles_01_d

26	Image NormalMap textures/decals/pebbles_01_local

27	Image SpecularMap textures/decals/pebbles_01_s

28	Vector Specular 16 0 1 0

29	AlphaTest .1

30	noOverlays

31	VertexColor

32	PolygonOffset 1 1

  NoTFix

34	Contents Nonsolid

  NoShadows

36	nofragment

37	Vector DetailNormalControls 3 3 2 0

ЧСХ, я ведь тоже сделал похожий механизм для доступа к глобальным переменным - через globals::
У дураков мысли действительно сходятся.

Добавлено 23-09-2019 в 20:37:

Но до шаблонов они не додумались

Это ожидаемо. Программистам же не надо забивать сотни тысяч материалов, а художники итак всё стерпят.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 23-09-2019 в 18:08:

Цитата:

Дядя Миша писал:
Но до шаблонов они не додумались

Те конфиги вполне могут оказаться выводом какого-нибудь генератора.

Отправлено KiQ 23-09-2019 в 20:34:

Цитата:

Дядя Миша писал:
Пока что сделал так:

Впрочем, ничего нового, и это хорошо!)

__________________
-Brain is dead-

Отправлено XaeroX 24-09-2019 в 07:05:

Цитата:

Дядя Миша писал:
worldSolidMaterial

Правильнее - lightmappedGeneric.

Цитата:

Дядя Миша писал:
А если нет, то будем принимать меры.

Конечно, будете. Перейдёте на Volatile, вот и весь сказ.

__________________

Отправлено Дядя Миша 24-09-2019 в 12:45:

Цитата:

XaeroX писал:
Перейдёте на Volatile, вот и весь сказ.

Хужы. Заставлю тебя пить пиго, пока падстул неупадъож!

Работы продвигаются медленно не в посл. очередь из-за старой архитектуры, которую нельзя просто ломать разом, чёб было легче следить за регрессиями. Ну вот скажем взять материалы. Я написал их парсинг, но подключить я их не могу - для этого надо писать новый рендерер в движке, а рендерер я написать не могу, потому что для этого надо финализировать новый менеджер моделей, а менеджер моделей я не могу финализировать, потому что старый торчит в игровой код и его там активно используют, ну это только полдела, вторая часть используется в самом движке, например пмувом, то есть надо пмув вынести в игровую дллку. Я вроде бы вынес, но его еще надо тестировать на предмет регрессий. Вот казалось бы, какое отношение физика игрока имеет к системе рендер-материалов?
Так и работаем. Хорошо хоть от энтварсов избавился.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 24-09-2019 в 13:51:

Так падажите, материал от шейдера не будет зависеть? Просто прибит гвоздями к движку?

Отправлено Дядя Миша 24-09-2019 в 15:03:

FiEctro эм, наоборот. В материале указывается шейдер для использования совместно с ним. Ну или указывается в шаблоне, чтоб каждый раз не писать его заново.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 25-09-2019 в 06:16:

Не помню, говорил я вам или нет, но в расширенном формате студиомоделей (который с развесовкой), есть одна очень любопытная штука - он способен сохранять KeyValue. Entity string если хотите. А новая архитектура пишется в том числе и с таким рассчётом, чтобы на месте мира могла бы любая модель, не только bsp. Так что потенциально вполне возможно будет делать мир моделькой, а кубать в блендере.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 25-09-2019 в 06:53:

Дядя Миша
К чему привязаны ключзначения? К целой модельке или к костям? Могут ли кости в модельковом мире играть роль энтитей?

Отправлено Дядя Миша 25-09-2019 в 07:29:

nemyax один к секвенциям, другой глобальный. Впрочем это не так уж и важно, когда мы имеем дело с кей-валуями, привязать можно всё что угодно.

Добавлено 25-09-2019 в 10:29:

А кости в роли энтитей - такое уже было в третьем дууме. Только смысла в нём немного. Разве что расчленёнка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 25-09-2019 в 07:46:

Цитата:

Дядя Миша писал:
Только смысла в нём немного. Разве что расчленёнка.

Если мы говорим за мир, то при чём тут расчленёнка. Я подумал про кость как генеричный объект. Ведь так называемая кость — по сути своей координатное пространство с некоторыми свойствами (и при необходимости с какой-нибудь приписанной геометрией). Если свойства можно задавать произвольно, то вот тебе и энтить. С геометрией — что-то типа брашевой, без — точечная.

Отправлено Дядя Миша 25-09-2019 в 08:51:

Ну вообще-то во первых в модельке существует лимит на 128 костей, а во вторых у брашевого мира никаких костей и вовсе нет. Да я думаю, если написать такой плагин к блендеру, который бы умел парсить стандартные кей-валуи, то никаких проблем бы не было. Он бы просто расставлял по миру-модельке различные энтити, в том числе и брашевые конечно. Поскольку возможность подгружать маленькие брашевые модельки тоже сохраняется.
Ну как в кваке аптечки были, к примеру. Так оно и здесь будет. Эта принципиальная возможность иметь в качестве модели мир открывает множество интересных комбинаций на самом деле.

Добавлено 25-09-2019 в 11:51:

Собственно при разработки второй паранои я уделил большое внимание тому, чтобы уравнять в правах модели и брашы. На статические модели декали ложаться как браши, один в один. Прикрутил к ним коллизию не хуже чем у брашей. Наконец дал им лайтмапу, правда пока с оговоркой - отражённый свет в индоре не учитывается. Но это я исправлю в NT. Таким образом у нас осталась только одна проблема - определение видимости.
Возможно я использую какой-то иной подход как для брашей, так и для моделей, т.к. методов всяких придумали очень много, надо будет подробно изучить этот вопрос.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 25-09-2019 в 13:36:

Дядя Миша
А для ворлдмодели(ей) есть такое понятие, как снаружи и внутри, или она(и) не обазательна(ы) быть замкнутой(ами)?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 25-09-2019 в 17:00:

thambs снаружи\внутри используется только для генерации порталов в BSP. Ну еще можно проверять что игрок в нулевом лифе и выполнять всякие оптимизации, например отключать зеркала на карте.
Больше оно нигде не используется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 26-09-2019 в 10:07:

Рендеринг скорее всего тоже будет в игровой дллке. Не полностью конечно, а та часть, которая отвечает за отрисовку энтить. Так что поидее у каждой энтити будет виртуальный метод Render из которого и будет производится отрисовка с нормальным доступом ко всем членам класса. Как минимум это будет работать в сингле, даже если кто-то забудет прописать строчки в дельту. Правда надо будет еще придумать как подружить отложку с зеркалами-порталами. Если бы все объекты были непрозрачные, это не представляло бы никакого труда.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 26-09-2019 в 10:31:

Цитата:

Дядя Миша писал:
FiEctro эм, наоборот. В материале указывается шейдер для использования совместно с ним. Ну или указывается в шаблоне, чтоб каждый раз не писать его заново.

Свои шейдеры писать можно будет?

Отправлено Дядя Миша 26-09-2019 в 12:44:

FiEctro да, в этом и задумка.

Добавлено 26-09-2019 в 14:25:

И еще. Я попробую восстановить функционал Quake3 на своей системе. Ну конечно не так, как там сделано, у меня не будет этих настроек, жестко прописанных. Но сами эффекты вполне реально будет замутить. Это будет тест на гибкость.

Добавлено 26-09-2019 в 14:26:

Можно будет даже скреатить такой специальный шаблон quake3shader и в нём намутить всё

Добавлено 26-09-2019 в 15:44:

ума не приложу что с мультипроходностью делать. Или полностью отказываться. Ну для водички-то отражения сделать будет можно, это ладно.
А вот насчёт мониторов-порталов-камер, это прямо таки под вопросом.

Отложка сама по себе не мешает организовывать мультипроходность, хотя конечно и жрёт видеопамяти очень много, кратно числу проходов, если мы хотим иметь рекурсивные отражения, например. Но, это как вы понимаете, легко отрегулировать в настройках, много видеопамяти - используем.
А вот как быть с прозрачными объектами, это прямо трогедия. Точнее если мы не будем их освещать. то половина трагедии, а вот если будем, это вообще кошмар какой-то. Я даже хз что делать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 26-09-2019 в 12:50:

Дядя Миша пили форвард+

Отправлено XaeroX 26-09-2019 в 13:00:

ncuxonaT
Чем форвард+ отличается от форвард-?

__________________

Отправлено thambs 26-09-2019 в 13:08:

Дядя Миша
Порталы может-то и не нужны, а вот без мониторов и камер плохо будет.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено ncuxonaT 26-09-2019 в 13:13:

XaeroX разбиением на тайлы со списками лайтов, декалей, лайтпроб и прочего в скрин спейсе или, еще лучше, в клип спейсе.

Отправлено Дядя Миша 26-09-2019 в 13:45:

ncuxonaT опять какие-то сетки. Хотя это может оказаться полезным, скажем на этапе расположения лайтпроб.

Добавлено 26-09-2019 в 16:45:

Цитата:

thambs писал:
Порталы может-то и не нужны, а вот без мониторов и камер плохо будет.

зеркала в скринспейсе еще худо-бедно можно нарисовать. А вот с камерами вообще швах. Ну да ладно, изучаю проблему. Проблема классическая про два стула, в перекладке на компьютерную термнологию память vs время.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 26-09-2019 в 15:14:

Дядя Миша то есть это тот самый прикол из-за которого в современных играх перестали делать зеркала, даже наподобие Спирита? Не говоря уже об отражении в них игрока.

Отправлено XaeroX 26-09-2019 в 15:53:

Crystallize
Честные зеркала перестали делать, потому что они удваивают работу рендерера и в общем случае в 2 раза снижают фпс. На абсолютно ровном месте. Не все готовы это терпеть.

__________________

Отправлено Дядя Миша 26-09-2019 в 17:02:

Цитата:

Crystallize писал:
то есть это тот самый прикол из-за которого в современных играх перестали делать зеркала

Ну не то чтобы прям совсем поэтому. Вон в новом метро сделали.
Эффективные менеджеры теперь всем рулят. В основном.

Цитата:

XaeroX писал:
Не все готовы это терпеть.

так квар на это дело. Для тех кто готов - on, для тех кто неготов off.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 26-09-2019 в 17:17:

Цитата:

Дядя Миша писал:
Вон в новом метро сделали.

где это там зеркала?

Отправлено Дядя Миша 26-09-2019 в 17:51:

Я тут вот еще думаю, может быть есть смысл изобрести какую-то новую технику. Раз существующие меня не устраивают.

Добавлено 26-09-2019 в 20:51:

ncuxonaT на речке

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 26-09-2019 в 18:09:

Дядя Миша так то скрин спейс

Отправлено Дядя Миша 26-09-2019 в 18:18:

ncuxonaT нме Элбер скидывал новые интервью с разрабами. И они там говорят - да, настоящие зеркала. Может надо настройки намаксимум поставить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 26-09-2019 в 18:19:

Цитата:

Дядя Миша писал:
И они там говорят - да, настоящие зеркала.

Так и ты всем говори!

__________________

Отправлено ncuxonaT 26-09-2019 в 18:49:

Дядя Миша они поди про RTX говорили

Отправлено Дядя Миша 27-09-2019 в 15:54:

В халфе вот эта гадость в input.cpp, ну где куча кнопок InKeyUp, InKeyDown.
Ну в халфе понятно оно из кваки, а там не заморачивались. Но в сорсе-то наверное переписали? Хрен там плавал! Так и тянут код из первокваки.
Уму нерастяжимо. Ну ладно написал менеджер для всего этого дела.
Теперь хоть выглядит семпотично.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 28-09-2019 в 11:51:

Сделал авто-регистрацию статически объявленных кваров. Больше не надо каждый раз писать CVAR_REGISTER (&some_variable);

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 28-09-2019 в 18:02:

Цитата:

Дядя Миша писал:
В халфе вот эта гадость в input.cpp, ну где куча кнопок InKeyUp, InKeyDown.

Ты можешь подготовить движок к тому чтобы хождение по стенам можно было сделать? Как я понимаю это уже сейчас надо закладывать.
И ещё я помню кто-то на форуме срашивал как заставить учёных гуфнуться с обрыва.

Отправлено Дядя Миша 28-09-2019 в 19:16:

Цитата:

Crystallize писал:
Ты можешь подготовить движок к тому чтобы хождение по стенам можно было сделать?

это всегда можно было сделать. Никому не было нужно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-09-2019 в 12:55:

Ну что жы, потихонечку начинает вырисовываться новая архитектура.
Конечно сейчас она в какой-то степени повторяет оригинальный код, т.к. перенос с одновременным переосмыслением это вообще невозможное дело, в плане тестирования. Но чуть позже, когда всё устаканится, там уже явным образом будет видно, как можно упростить код. Причём это касается всех частей движка. Сейчас такое интересное время, когда старый код трудится параллельно с новым и каждый работает примерно на половину своего функционала. Ну это как новый дом строят поверх старого.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ghoul [BB] 29-09-2019 в 17:34:

Цитата:

Crystallize писал:
Ты можешь подготовить движок к тому чтобы хождение по стенам можно было сделать?

Зачем тебе ходить по стенам?
На потолке спать стало неудобно?

__________________
Ты топчешь мир своими ботинками,
Не замечая куда наступаешь,
А время от тебя уходит цветными картинками,
Но ты даже этого не понимаешь.

Компрометирую данные своей учётной записи.
ЛОГИН: Ghoul [BB]
ПАРОЛЬ: paladin_solo

Отправлено thambs 29-09-2019 в 17:41:

Ghoul [BB]
Например, вот эту станцию из одиссеи замутить:

Дядя Миша

Цитата:

Никому не было нужно.

Ты в timeline2 не играл? Глянь этот мод, уж очень он захватывает, даже несмотря на примитивное исполнение. Они там этот цилиндр имитировали очень короткими секциями с ченджлевелами, на зато в окошках вращающийся небосвод нарисовали.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 29-09-2019 в 18:00:

Цитата:

thambs писал:
Ты в timeline2 не играл?

неа.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ghoul [BB] 30-09-2019 в 01:41:

thambs ты бы лучше mq доделал...

Отправлено Crystallize 30-09-2019 в 05:13:

ну либо магические паззлы делать:
https://youtu.be/Thu0hZrgofk?t=203
thambs а я когда подростком играл этого не заметил как и невидимого монстра. Там видимо нужно умнее быть.
Кстати по всей видимости Timeline 2 вдохновлён вот этим:
https://www.youtube.com/watch?v=xPpXHX-Tu5U

Отправлено XaeroX 30-09-2019 в 05:45:

Цитата:

Дядя Миша писал:
это всегда можно было сделать. Никому не было нужно.

Подтверждаю. Единственное интересное применение я видел в Serious Sam: The Second Encounter, да и то - там это использовали буквально в паре мест, чтобы показать "смотрите, чё умеет наш движок!"

А так.. Не хочу уподобляться Мастеру, но в старой Волатиле (которая OIFD/Wolfram) уже был произвольный вектор гравитации, и у trigger_gravity было соответствующее поле. Кто ковырял SDK - тот заметил. Да только никому это нафиг не нужно было. И в новой я эту фичу делать уже не стал.

Добавлено 30-09-2019 в 12:45:

Цитата:

thambs писал:
Например, вот эту станцию из одиссеи замутить

Она орбитальная? Там же невесомость вроде должна быть? Или она крутится, создавая центростремительное ускорение?

__________________

Отправлено Crystallize 30-09-2019 в 05:49:

...и кстати игрок игроком, а для "космической станции" нужно будет и про энтити не забыть, чтобы та же дверь ездила в нужную сторону. Указать им всем источник откуда они будут брать корректный вектор.

Цитата:

XaeroX писал:
Да только никому это нафиг не нужно было.

Оно нужно либо в демках либо в мегапроектах. Если проект маленький то там обычно фантазия не доходит до космических станций.

Отправлено nemyax 30-09-2019 в 07:52:

Цитата:

XaeroX писал:
Единственное интересное применение я видел в Serious Sam: The Second Encounter

Кстати, отличная находка была. Ещё вспоминается The Nameless Mod для деуса, где такое замутили в метафизической лавке. Но там реализация топорнее.

Цитата:

XaeroX писал:
Или она крутится, создавая центростремительное ускорение?

Ага, по внешнему радиусу ходили-бегали.

Отправлено thambs 30-09-2019 в 10:59:

Ghoul [BB]
Увы, это уже только если команда будет — мне нужен ещё один мэппер и моделлер пропсов. В одиночку уже точно ниасилю — сам же видел сколько сил уходит на одну локацию (особенно если затупишь с чем-то).

XaeroX
Крутится да. Ну, конечно, это фича редкая и не то что бы востребованная, но отдельным работам придать изюминку может, ящитаю. В порядке "а что если", думаю, что будь у автора hazardous course 2 такая возможность — он бы станцию замутил, благо, даже с обычной гравитацией сделал локацию из "фонтанов рая", да и отсылок к "одиссее" там вагон и маленькая тележка (да и в приложенных сырцах есть эскиз станции). Кстати, если у вас в PW кроме беготни по колидорам и пустыне будет что ни будь орбитальное (предпоследний уровень, например, типа цель куда всю игру идёшь), то оно придаст игре дополнительных плюсов.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 30-09-2019 в 11:16:

Цитата:

thambs писал:
Кстати, если у вас в PW кроме беготни по колидорам и пустыне будет что ни будь орбитальное (предпоследний уровень, например, типа цель куда всю игру идёшь), то оно придаст игре дополнительных плюсов.

Ну это будет уже совсем наглое цитирование Quake 2

__________________

Отправлено thambs 30-09-2019 в 11:45:

XaeroX
Ну в ку2-то оно и на станцию мало похоже. Там, по моему, даже окон небыло, т.е. весьма абстрактная консткукция (ну и конечно, никакой кривизны). Да и потом, в ку2 небо рыжее с камнями, а у вас серое в тучах, как во втором фильме про чужих (активное терраформирование идёт?).

Добавлено 30-09-2019 в 14:45:

Цитата:

хождение по стенам

Вот кстати, ещё подумалось, что это весьма полезый вариант движений для тех же таракашек и хэдкрабов, например, ну и аналогичных монстров.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Ghoul [BB] 30-09-2019 в 11:57:

Цитата:

thambs писал:
Увы, это уже только если команда будет

Не будет. Уж если даже таким известным людям, как Ghoul [BB] и XWider в своё время никто не захотел помогать (а у них куча зарелиженых мощных проектов) то... сам понимаешь...

Отправлено nemyax 30-09-2019 в 12:16:

Цитата:

thambs писал:
весьма полезый вариант движений для тех же таракашек и хэдкрабов

В AvP и вовсе можно было за чужова самому по стенам ползать.

Цитата:

Ghoul [BB] писал:
Уж если даже таким известным людям, как Ghoul [BB] и XWider в своё время никто не захотел помогать

Может, известные люди слишком много обзывались анальными словами?

Отправлено thambs 30-09-2019 в 12:27:

nemyax
Вот, кстати, ещё вспомнил, в серии dead space вполне себе было много локаций, где на магнитных ботниках нужно было ходить по стенам и потолку. Т.е. не такая уж это прямо таки никому ненужная фича, но редкая, да.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено AntiPlayer 30-09-2019 в 12:44:

В mirrors edge можно было по стенам немношко бегать

__________________
I tell you to enjoy life

Отправлено FiEctro 30-09-2019 в 14:08:

Цитата:

Дядя Миша писал:
это всегда можно было сделать. Никому не было нужно.

А как тогда к неработающему барнаклу забраться

Отправлено Chyvachok 30-09-2019 в 16:07:

Беготня по стенам конечно очень специфичная фишка, реально годной темой были бы разрушаемые браши в стиле Ред Фекшон.

Вообще разрушаемости особенно детальной мало в играх удаляют внимания, а в современных ее почти и нет, вспоминается только онлайн шутер где ломать стены можно, а в остальных играх весь мир абсолютно статичный, даже у мебели и прочих пропсов просто физики нету, а зря разрушаемость это очень веселая часть игры, вспомнить те же автоматы с напитками из 1 халвы, вспомнить можно ещё и первый кризис с ломаемыми пальмами и халабудами, мне лично всегда было забавно орощить все в играх.

Отправлено Дядя Миша 30-09-2019 в 16:29:

Цитата:

Chyvachok писал:
мне лично всегда было забавно орощить все в играх.

есть такие товарищи, у них подсознательная тяга к разрушениям.

Добавлено 30-09-2019 в 19:29:

А вообще я вам скажу. Всё что я сейчас делаю - это даже не работа над новой архитектурой. Это всего лишь подготовка к работе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 02-10-2019 в 10:04:

Так, теперь самое интересное. Надо придумать метод при помощи которого рендерер будет получать новые энтити для отрисовки. Тут две проблемы, которые к тому же противоречат друг-другу. Сам рендер энтити брать не должен, т.к. ничего про них не знает, но если игровая дллка будет ему сама их давать, возникает вопрос, как тогда быть с мультипроходностью. Зеркала, вот это всё.

Добавлено 02-10-2019 в 13:04:

Там надо составлять какие-то листы видимости для каждого прохода, но в них нельзя ничего копировать, это будет слишком тормозно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-10-2019 в 10:10:

Вот очём я и говорил, "красивый код" не всегда самый эффективный

Отправлено Дядя Миша 02-10-2019 в 14:48:

Задачка имеет решение, надо лишь подумать как грамотно сделать.

Добавлено 02-10-2019 в 16:55:

Придумал. Перед началом основного кадра дллка добавляет список всех энтить для отрисовки в произвольном порядке, причём сами эти энтити могут быть вообще чем угодно, необязательно эдиктами. Могут и темп-энтити быть, например. Но при условии что эти объекты наследуются от абстрактного класса IRenderEntity. Примерно такого:

C++ Source Code:

1	class IRenderEntity

public:

4	~IRenderEntity() {}

5	virtual bool CheckVisibility( const ref_viewpass_t *view ) const = 0; // entity is present for this viewpass

6	virtual const vec3 &GetRenderOrigin( void ) const = 0; // actual entity origin

7	virtual const vec3 &GetRenderAngles( void ) const = 0; // actual entity angles

8	virtual const matrix3x4 &GetRenderTransform( void ) const = 0; // actual entity matrix

9	virtual const matrix3x4 *&GetRenderBones( int &num_bones ) const = 0; // get bones for studiomodels

10	virtual const float GetBlendFactor( void ) const = 0; // opacity value 0-1

11	virtual const IModelBase *GetRenderModel( void ) const = 0; // get model for rendering

};

А дальше рендерер уже сам их сортирует в плане прозрачности или для мультипроходности, вызывая вот эти каллбэки. Рендеру для успешной отрисовки в сущности нужно не так уж и много информации от энтить - вышеперечисленное и несколько локальных параметров, типа рендерколора, номера кадра (спрайты/брашы). Ну чот типа такого.
Это набросок. не окончательный вариант конечно.
Плюс в том, что все интеракции останутся в описании самих энтить, не придётся на клиенте городить огород, мучительно угадывая, кто это был на сервере и в какие поля у него какие номера эдиктов и флагов сохранены.

Добавлено 02-10-2019 в 17:43:

Вообщем с точки зрения пользователя клиентская часть (конструктивно объединённая с серверной в единой дллке) выглядит следующим образом:

CreateMove - тут обрабатываем нажатия клавиш
ClientReadSnapshot - получаем обновления с сервера
ClientRunFrame - предиктинг всех энтить (у которых это настроено)
AddRenderEntities - здесь считаем видимую позицию в мире (с учётом предиктинга, интерполяции, сетапим все кости и прочее).

дальше движок всё это сортирует и рендерит не обращаясь в пользовательскую юиблиотеку, но вызывая виртуальные методы в классах самих объектов. Методы все константные, т.е. в них не производится никаких рассчётов, это всё должно быть сделано в AddRenderEntities.
Таким образом пользователь получает возможность полноценно управлять процессом рендеринга и в то же время не вклинивается своими вызовами в отрисовку кадра, что потенциально небезопасно, т.к. может сломать мультипроходной рендеринг. Смысл еще и в том, что сам пользователь ничего не знает об организации рендеринга, что там вообще происходит, отложка, форвард, это для него полностью прозрачно. Единственное что пока под вопросом - это возможность кастомного рендеринга в определённых случаях. Ну например отрисовка лучей. Но и тут достаточно просто выйти из положения - завести еще один метод в классе IRenderEntity, типа bool CustomRenderEntity();
и в нём производить отрисовку, но из самой отрисовки оставить только генерацию вертексов. То есть никаких шейдеров-материалов в этом методе использовано не будет. Это позволит иметь и кастомный рендеринг и в то же время сохранить абстрагирование на прежнем уровне. По похожей схеме можно будет организовать и рендеринг пост-процессов, где пользовательская сторона, сообразуясь с миром сможет спокойно забивать всю необходимую инфу для доф-прицела, а в кастомной функции отрисовки рендерить FSQ

А очерёдность отрисовки задавать через очередной каллбэк явно или неявно.
То есть мы решаем сразу две задачки - во первых оставляем за пользователем возможность нарисовать всякую фигню, а во вторых не заставляем его заботится о бакэнде. В принципе можно и HUD рисовать таким образом, почему нет.

Добавлено 02-10-2019 в 17:48:

ЗЫ. Если из вышесказанного непонятно - сетап костей у моделей целиком и полностью на совести пользователя. То есть всякие там джигглы, рагноллы, кастомные веровки, мерж-бонесы, инверсная кинематика - ну словом абсолютно всё находится в пользовательской части. Рендер просто запрашивает массив уже посчитанных костей.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 02-10-2019 в 15:38:

Цитата:

Дядя Миша писал:
всякие там джигглы, рагноллы, кастомные веровки, мерж-бонесы, инверсная кинематика - ну словом абсолютно всё находится в пользовательской части

Какими средствами в пользовательской части можно будет палить игровое время и коллизию, чтобы трансформировать кости правильно?

Отправлено Дядя Миша 02-10-2019 в 17:10:

nemyax собсно все средства именно в пользовательской части и сосредоточены.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-10-2019 в 11:22:

Ладно, вам наверное текст читать не слишком интересно. Вот картинки.

Это AABB-Tree из первого квейка, в узлы линкуются энтити когда мы вызываем UTIL_SetOrigin.

А это такое же дерево, но из Doom3

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено AntiPlayer 04-10-2019 в 12:04:

Дядя Миша Больше лучше?

__________________
I tell you to enjoy life

Отправлено Дядя Миша 04-10-2019 в 12:18:

AntiPlayer под разные задачи просто.
Для Doom3 регулярная сетка по всем измерениям. Для квейков - только по XY.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 04-10-2019 в 12:49:

Зачем сетку за картой строить?

Отправлено XaeroX 04-10-2019 в 12:51:

Цитата:

Дядя Миша писал:
А это такое же дерево, но из Doom3

Почему такое плотное? В чём подвох?

__________________

Отправлено Дядя Миша 04-10-2019 в 15:34:

Цитата:

FiEctro писал:
Зачем сетку за картой строить?

регулярное AABB Tree.

Цитата:

XaeroX писал:
Почему такое плотное?

карта мелкая. Там же глубина константная.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 04-10-2019 в 16:14:

Для чего используются такие дерева?

Отправлено ncuxonaT 04-10-2019 в 16:34:

Почему для квейков регулярная по XY, а не по XZ? Y же вертикальная ось?

Отправлено Дядя Миша 04-10-2019 в 16:51:

ncuxonaT в квейках Z вертикальная ось, порабы уже запомнить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 04-10-2019 в 17:02:

Дядя Миша а на твоём скрине где вертикальная ось, если регулярная сетка по XY?

Отправлено Дядя Миша 05-10-2019 в 14:06:

Ну чтожы пришло время вплотную заняться модель-менеджером. В игровом коде кстати вот это тяжкое бредовое наследие из кваки, оно ведь не нужно совершенно. Я имею в виду эти магические пары PRECACHE_MODEL\SET_MODEL. Это имело смысл только для виртуальной машинки первокваки, поскольку она не могла обращаться со структурой model_t и там ввели модельиндексы для этого дела. Но на практике постоянно возникает необходимость считать какую-то информацию из модели. В халфовском сервере с этим очень грустно дела обстояли, на клиенте чуть полутьшы.
То есть там даже со всеми функциями, которые я ввёл, надо было сперва получить модельиндекс, потом по нему взять модель и только потом к ней обратиться. Всё это не нужно совершенно. Одной функции SetModel более чем достаточно. Прекэш можно оставить только для клиентских моделей, причём на клиент посылать не загадочный модельиндекс, а номер строки, который соответствует имени модели, чтобы потом на клиенте найти её по этому номеру. А модельиндексы соответственно вообще упразднить, они не нужны, как таковые. Точнее говоря в них был смысл, пока не было системы уникальных строк, идентификаторы которых куда как лучше справляются с заменой этих модельиндексов. Потому что эти таблицы репласемнтов по сути излишняя абстракция, которая была нужна только для сохранения совместимости.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-10-2019 в 09:04:

Так же мне хотелось бы заложить поддержку на уровне движка деформируемого и разрушаемого окружения. Ну тут достаточно просто, это лишь часть задачи. Очевидно, что берётся исходная модель, к которой применяются некоторые действия. Причём эти действия необязательно связаны деформацией, главное отличие - это изменение какой-либо информации в модели. Например модели с лайтмапами. В исходной модели информации о лайтмапах нет, всё необходимое записано в карту. Но вертексы там уже иные, либо как в случае последних экспериментов, он развернуты в фан-вертексы. либо если делать по уму, то остаются стрипами, но всё равно добавляется информация о развёртке лайтмапы. То есть вертексы уже не оригинальные. В случае с деформацией, они дополнительно еще и сдвинуты согласно физическим законам. Как это реализовать? В нужный момент, во время игры или на старте делается копия модели, но не полная, а только та часть, которая поменялась, ну в данном случае это вертексы. Т.е. создаётся некая мета-модель со ссылкой на референс. А чтобы не путаться и держать всё в юниформе - она просто помещается в тотже единый массив из всех моделей. Конечно её можно будет сохранить в сейв, если понадобится. Аналогичным образом происходит и разрушение - модель делится на свои обломки, которые гененрируют целую пачку новых мета-моделей, на каждую назначается своя энтить с физикой твёрдого тела. Конечно с BSP такую штуку не проделаешь, но вот со студиомоделями - вполне себе.
точнее говоря, с BSP тоже можно, но бессмысленно, там ведь основной смысл в PVS, видимость. Такое на лету не пересчитаешь.

Добавлено 07-10-2019 в 12:04:

Еще один важный шаг к генеричности надо сделать - убрать из движка любую информацию про worldmodel. Ему не надо знать, что какая-то модель это мир. Для движка все модели должны быть равноправны. Что в свою очередь позволяет потенциально иметь несколько миров, загруженных одновременно и быстро переключаться между ними. И всё это можно реализовать в рамках пользовательской библиотеки.
В сущности у движка привязка к миру сводится лишь к построению overview, но это я уберу, сделаю членом класса модели.
А ну и естественно при таких параметрах нам понадобится хороший такой лимит на эти модели. Тысяч на 16 я думаю. А энтить на 65к. Но лимит на энтити всё равно в игровой части, там их можно будет сколько угодно замутить. Вот только с кол-вом клиентов пока не определился. Их по прежнему остается 32 штуки. Ну да ладно, клиентами я займусь, когда буду сетевую модель переделывать, до этого еще долико.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-10-2019 в 13:27:

Так товарищи. Все необходимые подготовительные работы выполнены, я уже избавился от client.dll и подготовил базу для рендерера, частичную, но основные уточнения уже будут непосредственно по ходу разработки, т.к. у меня еще мысль не оформилась, такое только на практике делается, особенно если учесть что для меня это совершенно новый тип рендерера, и поскольку я сам его придумал, то подсмотреть реализацию негде. По остальным саб-системам решение принято, там ничего особо интересного нет, да и движок выбирают за картинку. Так что наступает самая ответственная часть проекта - собственно рендеринг. Посмотрим что у меня получится, ну и в процессе постараюсь вас радовать скриншотами.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 07-10-2019 в 13:40:

Цитата:

Дядя Миша писал:
в процессе постараюсь вас радовать скриншотами

Может ведосики начнёшь записывать?

Отправлено Дядя Миша 07-10-2019 в 13:41:

nemyax ну неисключено.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 07-10-2019 в 13:53:

Цитата:

nemyax писал:
Может ведосики начнёшь записывать?

А есть ли разница?
Я например в канале пробовал и так, и так - результат одинаковый.

А если нет разницы, но видосики при этом требуют больше времени для обработки - то может ну его?

__________________

Отправлено Crystallize 07-10-2019 в 14:03:

Цитата:

Дядя Миша писал:
Это AABB-Tree из первого квейка, в узлы линкуются энтити когда мы вызываем UTIL_SetOrigin.

Где у него АА и где BB? Если это противоположные углы кубика, тогда почему не АААBBB?

Отправлено nemyax 07-10-2019 в 14:07:

Crystallize
Axis-aligned bounding box.

Отправлено Дядя Миша 07-10-2019 в 15:27:

Crystallize что ты нисёжъ?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 10-10-2019 в 15:59:

Ну что же написал загрузчик вертексов в видеопамять. Там такая тема, что каждый вертекс должен точно соответствовать кол-ву своих переменных. Нельзя просто завести вертекс, в котором будут все атрибуты на все случаи жизни и использовать его для разных типов данных - будет ощутимо тормозить. Поэтому неплохо бы формировать эти вертексы исходя из данных, которые реально будут использоваться. Но проблема в том, что этих вариантов у меня уже накопилось достаточно немало и прописывать каждый вертекс отдельно во первых трудоёмко, во вторых очень легко запутаться, а в третьих мне еще и две версии надо иметь для старого железа и для нового.
Поэтому я разработал универсальный загрузчик. Здесь кстати, наглядно проявилось то, во что превращается крестовый код, если активно использовать все возможности. Понять что там происходит стороннему человеку уже практически невозможно, это взрыв мозга.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 11-10-2019 в 11:38:

Продолжаю имплементацию материалов. Сейчас именно тот самый момент, от которого зависит насколько будет удобно прописывать материалы по умолчанию. Надо подумать как лучшы сделать. Неявные хинты, дефолтный материал, или еще что-нибудь.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-10-2019 в 12:06:

Дядя Миша
Добавь в свой модельвьювер сразу возможность создавать и просматривать эти самые материалы в реальном времени, и дефолтные меши кроме самих моделей, кубик, сфера, цилиндр, конус, плоскость.

В блокноте врядли кто то будет ковыряться.

Отправлено thambs 11-10-2019 в 12:34:

Дядя Миша
А с отказом от ворлда, возможны ли будут "компилируемые префабы", ну или что-то вроде независимых кусков карты, которые можно вставить в другие карты и обращаться как к единому целому, так и к её составляющим?

Цитата:

Понять что там происходит стороннему человеку уже практически невозможно, это взрыв мозга.

А сам сможешь понять что писал, если, например, через год взглянешь на код?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 11-10-2019 в 13:00:

Цитата:

FiEctro писал:
Добавь в свой модельвьювер сразу возможность создавать и просматривать

да почему же именно в модельвьювер?

Тогда уж в материал-эдитор?

Цитата:

thambs писал:
А с отказом от ворлда, возможны ли будут "компилируемые префабы", ну или что-то вроде независимых кусков карты, которые можно вставить в другие карты и обращаться как к единому целому, так и к её составляющим?

Отказ от мира не означает, что его не будет. Это означает следующее:
1. явной мировой модели может и не быть и рендерер для этого не надо вводить явным образом в особое состояние, типа установки флажка RF_DRAW_WORLD. Как это реализовано сейчас: перед рендерингом вью-кэш ищет модельку с валидным PVS. Далее он проверяет что текущая позиция камеры попадает в ббокс этой модели и использует её для отсечения видимости.
2. мировых моделей может быть несколько штук, но их конечно надо будет разнести в пространстве. Ну или в игровом коде включать-отключать. Это уже на усмотрение мод-мейкера. Трасса по модели - это часть имплементации самой модели. Правда в классической трассе есть понятие мира, но трасса находится полностью в игровом коде, так что это легко поправить при необходимости.
То есть как это можно использовать: ну компилируемые префабы, да, бесшовная подгрузка уровней, обход каких-то лимитов или скажем просто лепить мир из повторяющихся кусочков. То есть тут масса вариантов может быть.

Цитата:

thambs писал:
А сам сможешь понять что писал, если, например, через год взглянешь на код?

Смогу, но мне для этого потребуется какое-то время.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-10-2019 в 13:34:

Цитата:

Дядя Миша писал:
да почему же именно в модельвьювер?
Тогда уж в материал-эдитор?

Это дополнительный софт писать, да и к тому же можно будет сразу на моделях посмотреть как выглядит тот или иной материал.

Отправлено Дядя Миша 11-10-2019 в 13:55:

Всё что было написано заранее, подготовлено, зачищено, так или иначе свелось к логическому упору, к самому главному моменту - настала пора заменить старый модельменеджер, который оперирует model_t на новый, который CModelBase. Это самая фундаментальная часть движка, на которой базируется абсолютно всё. Так что эта замена потребует порядочно времени, плюс у нового еще не все патчи дописаны, к примеру он умеет грузить только брашевые модели и ничего более. Так что в ближайшие недели новостей не будет. Но когда замена осуществиться - будет уже гораздо веселее, т.к. это самая масштабная часть операции по работе над ядром. Там уже глядишь и скриншоты пойдут, а может и демки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 12-10-2019 в 13:36:

Если кому-то интересно - проект готов примерно на треть.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 12-10-2019 в 15:19:

Дядя Миша
А как ты измеряешь готовность проекта?

__________________

Отправлено Дядя Миша 12-10-2019 в 20:35:

XaeroX по соотношению намеченного и реализованного.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 16-10-2019 в 14:59:

Дядя Миша
Помню, ты экспериментировал с фиксированным серверным пингом для более стабильной физики. Что получилось в итоге, войдёт ли оно в NT?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 16-10-2019 в 15:18:

Не пингом. Фиксированным серверным фпс. да, войдет, но не в том виде.
Теперь клиент-сервер тикают синхронно, а рендер уже сколько задашь.

Добавлено 16-10-2019 в 18:18:

И да, кстати, интерполяцию надо делать не между клиентскими кадрами, а между кадрами рендерера. Клиенту по большому счёту пофиг на интерполяцию. В халфе с этим как раз и была мешанина. Часть интерполяций делалась между рендер-кадрами, часть между серверными, в итоге возникало рассогласование. Ничего удивительного.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 16-10-2019 в 15:22:

>пингом
Опечатка.
Дядя Миша
А как оно с управлением игроком / поворотами камерой работает, сохранится ли отзывчивость, присущая высоким fps?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 16-10-2019 в 15:57:

Сохранится

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 17-10-2019 в 19:07:

Я вот размышляю над тем, что модифицированные модели полезно сохранять в сейв. Вспомним опыт первого дуума.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 17-10-2019 в 19:38:

Дядя Миша а как же мультиплеер? Это я про интерполяцию в рендерере.

Интерполировать движение объектов нужно и не только для рендерера. Халфа игроков интерполирует и получается, что на клиенте мы можем бросить трейс и быть уверенными что он попадёт в игрока как на клиенте, так и на сервере(на самом деле нет, ну оно просто само такое неидеальное). А когда сервер отмотает кадры в процессе анлага, то трейсы действительно придут куда надо.

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 17-10-2019 в 20:35:

a1batross так на клиенте фраги не считаются всё равно. А за визуальную часть попадания отвечает именно рендерер.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 18-10-2019 в 18:38:

Дядя Миша ну это да, а как же интерполированные энтити сделать солидными? Ну то, есть их рендерер будет солидными для себя?

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 18-10-2019 в 18:48:

a1batross не забивай преждевременно голову

Вообщем получился у меня такой типичный крестовый код. В максимальном приближении всё очень красиво, но только Аллах ведает как это всё взаимодействует и работает.

Навскидку, ну вот такая хрень

C++ Source Code:

1	CVBOCache CVBOManager :: CreateBuffer( const char pszName, const CMeshBuilder &src )

3	CVBOCache *pVBO = AllocBuffer();

4	Q_strncpy( pVBO->m_name, pszName, sizeof( pVBO->m_name ));

6	if( pVBO->Construct( src ))

7	return pVBO;

9	// for some reasons we failed

10	FreeBuffer( pVBO );

11	return NULL;

А за ней прячутся десятки килобайт шаблонов, которые строятся из других шаблонов, которые строятся из исходных структур.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 18-10-2019 в 19:06:

Дядя Миша а чего не new CVBOCache/delete pVBO?

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 18-10-2019 в 20:29:

a1batross такого тожы хватает.

По материалам я принял следующее решение: подсказки. Вот как это будет выглядеть:

C++ Source Code:

1	template <worldSolidMaterial>

3	image u_ColorMap = "textures/<wadname>/<mipname>.tga";

4	image u_DetailMap = "materials.def::detailmap";

5	vec2 u_DetailScale = "materials.def::detailScale";

6	float u_Smoothness = "0.35";

7	frag u_ShaderFrag = "glsl/bmodelSolid_vp.glsl";

8	vert u_ShaderVert = "glsl/bmodelSolid_fp.glsl";

9	#define APPLY_PBS

10	#usage mod_brush // hint for template to implicit apply them for all brush model materials

вот строчка #usage это подсказка использовать шаблон, когда грузим модель определённого типа. По крайней мере не придётся прописывать миллион однотипных строчек как в том же сталкере.

Добавлено 18-10-2019 в 23:29:

Но тут опять же встаёт вопрос - допустимы ли множественные шаблоны с такой подсказкой и как определить подходящий? Скорее всего придется запретить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 18-10-2019 в 20:32:

#usage

Дядя Миша
Это директива препроцессору, или? Первый раз вижу, где почитать можно что это такое?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 18-10-2019 в 21:14:

thambs это мои материалы такие. К С++ это отношения не имеет.

Добавлено 19-10-2019 в 00:14:

Скажем вот в том же ку3, если шейдер не был прописан явным образом, он генерировался в коде из каких-то дефолтных настроек. Но пользователь не мог на это повлиять, он и не знал точно какие там настройки применяется, к тому же это зависело от типа модели. Моя идея в том, чтобы эти шаблоны по умолчанию создавал сам пользователь, так как ему нужно. То есть допускается иметь шаблоны с подсказкой - эти будут применяться автоматически к материалам, для которых вообще нет описания и шаблоны без подсказок - эти пользователь сам сможет применять к материалам, указывая их явным образом и перегружая нужные ему настройки.
В принципе для отдельно взятого материала можно перегрузить все настройки или вообще не использовать шаблон для его построения.
Кол-во настроек материала тоже задаётся пользователем. То есть к примеру можно не указывать шейдер, если материалу он по смыслу не требуется, будет осуществлён рендеринг на фиксированном функционале.
Теоретически на подобной системе легко эмулировать функционал как кутришных шейдеров, так и дуумтришных материалов, причём пользователь сам это создаёт скриптами и шейдерами. Аналогично, если не хочется ничего прописывать, можно обустроить тепичные шаблоны для всех материалов, прописать их один раз и не париться. Вообщем под разные задачи.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 19-10-2019 в 07:06:

Цитата:

Дядя Миша писал:
Скажем вот в том же ку3, если шейдер не был прописан явным образом, он генерировался в коде из каких-то дефолтных настроек.

Кажется, настал Великий день, когда Дядя Миша наконец-то разобрался, что в ку3 (и в Волатиле) вовсе не обязательно "прописывать для каждой текстуры шейдер". И перестанет пугать этим выдуманным фактом потенциальных пользователей Волатилы до полусмерти.

Ура, товарищи! Свершилось!!!

__________________

Отправлено Дядя Миша 19-10-2019 в 08:46:

Цитата:

XaeroX писал:
наконец-то разобрался, что в ку3 (и в Волатиле) вовсе не обязательно "прописывать для каждой текстуры шейдер"

Всегда знал, но хорошего в этом мало. Дефолты не перегрузишь, не переопределишь никак.

Добавлено 19-10-2019 в 11:13:

К тому же сам язык кутришных шейдеров устарел, это язык для FFP-фунционала, он просто не нужен в таком виде. Ну хотя Волатила и так неявно использует FFP-модель.

Добавлено 19-10-2019 в 11:22:

Вот вам кстати наглядный пример как программы усложняются со временем на ровном месте. В квейке для парсинга текстовых файлов использовалась простейшая функция COM_ParseFile и этого хватало для всех случаев. А теперь в новомодных движках все скрипты пытаются сделать на базе XML.
Уже не говоря о том, что лично мне представляется небесспорной сама идя XML, так его пытаются использовать для простейших вещей, типа сохранения тех же конфигов. На мой взгляд смысла в подобных скриптах нет никакого, интерпретаторы тех же крестов спокойно разбирают вполне человеческий код, без всяких идиотских тэгов. То есть оно по сути не нужно никому, ни человеку, который в блокноте XML уже не отредактирует, ни парсеру, который справится с любым форматом текста. Очевидно что под эти скрипты надо еще и свой редактор писать. Из вики мне особенно понравилась вот эта строчка:

Цитата:

− Примитивная библиотека может делать неоптимальный XML (например, <tag></tag> вместо <tag /> ). Работающая оптимально намного сложнее в программировании.

То есть у XML появилось еще и понятие оптимальности, хотя скрипты вообще должны быть лишены такого качества. А ведь есть люди, которые на XML сейв-рестор делают, ну чёб не париться. И так - в любой области. Просто сейчас аппаратный прогресс остановился и народ начал замечать, что их процессоры по большей части заняты непонятно чем.

Добавлено 19-10-2019 в 11:46:

Кстати вот к вопросу парсинга. Я учёт приходов\расходов веду в обычных .txt файлах. Пробовал когда-то программы для учёта финансов, но эти прогаммы все устроены по идиотски, там какие-то поля надо заполнять, причём именно так, как того хочет сам автор программы, т.е. надо как минимум разбираться, что он там имел в виду. Я в своё время выработал свой формат записи, не предназначенный для парсинга вообще, просто обычные записи в блокноте, примерно такого плана:

C++ Source Code:

Месяц Год

Доходы:

дата

6	источник - сумма

дата

9	источник - сумма

...

дата

14	источник - сумма

Расходы:

дата

19	цель - сумма

дата

22	цель - сумма

...

дата

27	цель - сумма

Итого:

Должно быть понятно, что основную сложность представляло подведение баланса, считал вручную на калькуляторе, но это отнимало порядочно времени. В какой-то момент мне это надоело, я сел и написал маленькую консольную утилитку, которая не только парсит такой формат файлов, но еще и находит в них некоторые ошибки (например, если месяц с годом в шапке указан один, а в списке дата неверная), подбивает баланс и выводит итоговый отчёт, причём баланс за месяц она пишет в тот же самый файлик, сверяясь с текущей датой и убедившись, что месяц завершен, аналогично формируется промежуточный и годовой отчёт.
У нее нет никаких параметров, очередная кнопка сделать круто. Запустил и через полсекунды всё готово. Писал я её где-то часа четыре, весит 20 килобайт, отвечает всем поставленным задачам, прекрасно разбирает обычный человеческий текст, который вообще не предназначался для парсинга никогда. Так вот и какой смысл городить все огороды, спрашивается. Очевидный ответ - несолидно, надо больше всего, надо чтоб место занимало, надо чтоб интерфейс красивый, надо чтоб кнопок всяких и побольше. Главная цель за всем этим куда-то исчезла.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 19-10-2019 в 08:50:

Цитата:

Дядя Миша писал:
А теперь в новомодных движках все скрипты пытаются сделать на базе XML.

Я в старой волатиле тоже повёлся на это, и сделал XML-конфиги (для HUD). Даже tinyxml-парсер прикрутил. И всё время меня что-то беспокоило, но я не мог понять, что именно. Вроде и модно, и молодёжно, и современно - но кошки на душе скребут.
А потом я разобрался. Удалил в новой волатиле все эти xml-ы нафиг и сделал обычные парсеры на основе COM_Parse. И тут же стало легко и приятно на душе. И конфиги стали выглядеть прилично, а не как говно, пестрящее угловыми скобками.

Цитата:

Дядя Миша писал:
Ну хотя Волатила и так неявно использует FFP-модель.

Я больше скажу - абсолютно все движки неявно используют FFP-модель. Просто раньше они напрямую использовали функции OpenGL (типа glTexGen и TNT combiners), а теперь пытаются всё это эмулировать через шейдеры. А по сути это тот же набор fixed-функций, ну разве что чуть более расширенный - например, не одна, а три модели освещения на выбор.

Добавлено 19-10-2019 в 15:50:

Цитата:

Дядя Миша писал:
Пробовал когда-то программы для учёта финансов, но эти прогаммы все устроены по идиотски, там какие-то поля надо заполнять, причём именно так, как того хочет сам автор программы, т.е. надо как минимум разбираться, что он там имел в виду.

Открой для себя Microsoft Excel...

__________________

Отправлено Дядя Миша 19-10-2019 в 10:11:

Цитата:

XaeroX писал:
И конфиги стали выглядеть прилично, а не как говно, пестрящее угловыми скобками.

С этими тэгами вообще вопрос очень интересный. Если их надо закрывать ровно в той же последовательности, в которой открывал, то чем это лучше фигурных скобок? Очевидно здесь выполняется бессмысленная работа, к тому же еще и увеличивающая размер файлов. Кому это надо? Да никому.
Зачем это сделано? А хрен его знает. Мне больше всего нравится, что эти тэги пользователь еще и вручную определяет, то есть вместо именованного блока, типа:

C++ Source Code:

blockname

нас заставляют писать

C++ Source Code:

<blockname></blockname>

И сразу же появляется вопрос оптимальности, оказывается можно еще писать

C++ Source Code:

<blockname />

я так понимаю на тот случай, если у нас всё умещается в одну строку. С фигурными скобками этой проблемы не возникает вообще. Я понимаю, что оно от SVG кажется наследуется, а тот в свою очередь был сделан гораздо раньше, но зачем было вообще плодить эти сущности?

Цитата:

XaeroX писал:
Я больше скажу - абсолютно все движки неявно используют FFP-модель

Фиксированный функционал = мультипроходный рендеринг, он в первую очередь завязан на расположении текстурных юнитов. Потом добавили мультитекстурность и стало чуть попроще, но всё равно ты должен располагать эти юниты в определённом порядке, чтобы они правильно смешались между собой. В шейдерах это теряет всякий смысл, нам больше не надо городить блоки
{
map
}
в строго определённой последовательности в описании шейдера. Ну разве что мы будем эмулировать кутришный функционал.

Цитата:

XaeroX писал:
Открой для себя Microsoft Excel...

Ну Эксель как минимум надо поставить, а то еще и купить, мы же чесные программисты и против пиратства? А блокнот изкаропки есть.

Добавлено 19-10-2019 в 12:41:

Материалы-материалами, но походу возникла потребность сделать еще какое-то описание для шейдеров.

C++ Source Code:

frag u_ShaderFrag = "glsl/<rendertype>/bmodelSolid_vp.glsl";

vert u_ShaderVert = "glsl/<rendertype>/bmodelSolid_fp.glsl";

Вот так писать каждый раз в шаблоне еще нормально, а скажем в описании материала уже будет напрягать. К тому же этот объект скорее всего сможет переиспользовать одни и те же шейдеры множество раз, но с разными настройками #define, которые неплохо бы указать общими для такой сущности. То есть сделать для шейдерного объекта генеричное описание, с собственным именем. К тому же мне вероятно понадобится собрать в такой объект не один, а несколько шейдеров, понятно почему - для форварда основной проход, для форварда - освещение, для отложки построение G_BUffer, финальный рендеринг. Т.е. некая сущность над описанием шейдеров. И назвать её, ну скажем shaders.def, навряд ли их там будет слишком много, чтобы городить множество файликов.

Добавлено 19-10-2019 в 12:43:

Причём, я так полагаю формат описания логично унаследовать от описания материалов и шаблонов, чтобы получился настоящий полиморфизм. Это даст возможность конструировать любые типы объектов и перегружать любой параметр для отдельно взятого материала.

Добавлено 19-10-2019 в 13:09:

Посмотрел как в последнем крае это устроено. Ну там все техники, объявленные в шейдерах, жестко привязаны к вызовам этих имён из кода.
Это не то, что мне нужно.

Добавлено 19-10-2019 в 13:11:

То есть вот для примера technique SunShaftsDisplay - она жёстко объявлена в коде в движка, её нельзя переопределить или создать новую технику.
Можно только отредактировать сам шейдер.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 19-10-2019 в 10:15:

Дядя Миша а что если как раз дать переопределять дефолты? А то и разрешать наследование материалов:

default { /* default materials opts */ }

material1 { ... }

material2 : material1 { ... }

Это я так, про экономию строчек и удобство работы с материалами.

XaeroX нынче модно молодёжно это JSON.
Который кстати тем же COM_ParseFile в теории можно распарсить.

__________________
Xash3D FWGS форк

Отправлено nemyax 19-10-2019 в 10:30:

Цитата:

Дядя Миша писал:
Эксель как минимум надо поставить, а то еще и купить

LibreOffice Calc, да и всё.

Отправлено thambs 19-10-2019 в 10:35:

a1batross
Ну джонсон-то человекочитаем и человекоредактируем в отличие от.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено a1batross 19-10-2019 в 10:36:

thambs да, так и есть.

__________________
Xash3D FWGS форк

Отправлено thambs 19-10-2019 в 10:37:

Дядя Миша
А материал можно будет автоматически вывести из имени используемой текстуры? Например есть шаблон *wood*, и все текстуры содержащие *wood*, что отдельно не описаны, наследуют этот шаблон?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 19-10-2019 в 11:26:

Цитата:

a1batross писал:
а что если как раз дать переопределять дефолты?

ну я про это и говорю. Система наполовину существует в моём воображении, поэтому что-то будет скорее всего меняться, но пока концепция следующая:
1. мы можем создавать шаблоны для определённого типа моделей, типично это спрайты, студиомодели и брашы. Если придумаете по каким еще критериям можно отсортировать объекты на группы, то я могу включить и другие варианты в качестве хинтов, но пока что мне этот кажется наиболее логичным.

2. если у материала не прописан никакой тип и нет дефолтного шаблона, то скорее всего он будет рендериться как wireframe, чтобы наглядно это продемонстировать пользователю.

3. шаблон материалу можно указывать явным образом или не указывать совсем, если присутствуют шаблоны с подсказкой.

4. всё что указано в шаблоне можно переопределить в самом материале, но в большинстве случаев это просто не нужно.

5. наследование материала от материала сделать возможно, но я пожалуй воздержусь, т.к. это запутает юзера. К тому же, поскольку это всё же не язык программирования и здесь не требуется forward-declaration, то первое что сделает находчивый юзер, это унследует пару материалов друг от друга. чтобы посмотреть что из этого получится. Так что нет, это не слишком хорошая идея.

Цитата:

thambs писал:
А материал можно будет автоматически вывести из имени используемой текстуры?

нет, такого нет. Мне не нравится эта идея, эти фильтры принципиально неконтролируемы юзером, как поиск по маске почти никогда не находит точно то, что требуется. Он всегда находит либо больше либо меньше, а остальное человек уже должен сам вычленить из списка.

Для описания шейдеров навскидку сделал вот такой формат. Это ни в коем случае не окончательный вариант, это первое приближение.

Добавлено 19-10-2019 в 14:05:

Я не знаю как люди пишут скриптовые языки или вообще какие-то стандарты скриптов, но я сперва пишу сам скрипт, как бы мне хотелось чтобы это выглядело, а потом под него уже пишу парсер. Наоборот у меня не получается.

Добавлено 19-10-2019 в 14:26:

Вообще я планирую сперва воссоздать forward-патч на основе шейдеров из паранои, т.е. таким образом, чтобы мне не пришлось их подключать в коде.
А потом уже можно будет задуматься насчёт остальных патчей и их кол-ве.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 19-10-2019 в 11:49:

Цитата:

a1batross писал:
нынче модно молодёжно это JSON.
Который кстати тем же COM_ParseFile в теории можно распарсить.

Вот-вот. Поумнел народ с годами. Это радует.

Зато теперь появилось новое ругательство - "парсить джейсоны". Например, сделал человеку плохо, а он тебе - "шоб ты на работе парсил джейсоны!"

__________________

Отправлено Дядя Миша 19-10-2019 в 12:15:

Цитата:

За счёт своей лаконичности по сравнению с XML, формат JSON может быть более подходящим для сериализации сложных структур

МБУГОГА. Изобрели новый формат и тут же облили грязью старый, да мол XML этот ваш - гавно. Слышали?

Цитата:

Запись — это неупорядоченное множество пар ключ:значение, заключённое в фигурные скобки «{ }»

Ребята взяли описание энтити от кваки, но чтобы у них всё было "совершенно по другому", добавили еще двоеточие. Впрочем для "сериализации сложных структур" это всё равно не годится. Помните ad_sepulcher для ArcaneDimensions? Ну где 8 тысяч энтить? А в кваке сейвы устроены что твой JSON, ну только без двоеточия. Корочи на этой карте сейв грузится секунд 20. Надо ли говорить что в кувраппере на этой же карте сейв грузится пару секунд? Скрипты для сериализации не годятся абсолютно. Суть скрипта именно вот в том, чтобы их человек мог писать и редактировать. А сохранять в них что-то дурацкая затея. Скажем в той же кваке можно было открыть скрипт в блокноте и написать себе сколько угодно здоровья и пушек. Или там шаблера удолить из сейва, если вы его пройти не можете.

Добавлено 19-10-2019 в 15:15:

Вообще самая быстрая парсилка это fgets + sscanf, я када был молодой и неопытный, то переделал studiomdl со sscanf на COM_ParseFile, ну типо так красивше. И очень удивился, что у меня время на чтение .smd выросло, ну так раз в 10.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 19-10-2019 в 12:34:

XaeroX
А зачем их "на работе парсить", когда этим библиотека занимается?

Добавлено 19-10-2019 в 15:34:

Цитата:

Дядя Миша писал:
scripts.rar

А в shaders.def в одни строки заканчиваются на ";\r\n", другие — просто "\r\n". Как оно будет в финале?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 19-10-2019 в 13:02:

Мне стало интересно что вообще творится со скриптами в остальных движках, ибо, как известно, современный движок этими самыми скриптами и силён. В этом его главное отличие от кваки, где наоборот всё захардкодено и крутись как хочешь. Ну вот открыл UnrealScript:

Вот к примеру структурки:

C++ Source Code:

1	struct {DOUBLE} double

3	var native const int A;

4	var native const int B;

};

7	struct BitArray_Mirror

9	var native const pointer IndirectData;

10	var native const int InlineData[4];

11	var native const int NumBits;

12	var native const int MaxBits;

};

Ну это то ладно. Вот АТД Vector

C++ Source Code:

1	struct immutable Vector

3	var() float X, Y, Z;

};

Что такое var я не знаю. А вот насчёт immulatble тоже непонятно. Разве это не тоже самое что final?
А вот наследование:

C++ Source Code:

1	struct immutable Plane extends Vector

3	var() float W;

};

Константы

C++ Source Code:

const MaxInt = 0x7fffffff;

const Pi = 3.1415926535897932;

Здесь другая крайность - у констант почему-то не указан тип.
Но самая жэсть начинается далее:

C++ Source Code:

1	native(133) static final operator(34) byte *= ( out byte A, byte B );

2	native(198) static final operator(34) byte *= ( out byte A, float B );

3	native(134) static final operator(34) byte /= ( out byte A, byte B );

4	native(135) static final operator(34) byte += ( out byte A, byte B );

5	native(136) static final operator(34) byte -= ( out byte A, byte B );

6	native(137) static final preoperator byte ++ ( out byte A );

7	native(138) static final preoperator byte -- ( out byte A );

8	native(139) static final postoperator byte ++ ( out byte A );

9	native(140) static final postoperator byte -- ( out byte A );

10	native(129) static final preoperator bool ! ( bool A );

11	native(242) static final k2pure operator(24) bool == ( bool A, bool B );

12	native(243) static final operator(26) bool != ( bool A, bool B );

13	native(130) static final operator(30) bool && ( bool A, skip bool B );

14	native(131) static final operator(30) bool ^^ ( bool A, bool B );

15	native(132) static final operator(32) bool \|\| ( bool A, skip bool B );

Вот что это за хрень? Я плохо знаю С++, я даже не знаю, можно ли там перегружать постинскрмент, ну просто не возникало такой надобности, а проверять лениво. Ну здесь как мы видим можно. Но вот эти нативные номера смущают. Это типо как буллетины в первокваке штоли?
И что такое k2pure наконец?

Но вот мы добрались и до функций:

C++ Source Code:

1	static final function float FInterpEaseIn(float A, float B, float Alpha, float Exp)

3	return Lerp(A, B, Alpha**Exp);

6	static final simulated function k2pure float RandRange( float InMin, float InMax )

8	return InMin + (InMax - InMin) * FRand();

Опять загадочный k2pure. Обратите внимание, что интерпретатор даже не в состоянии догадаться что перед ним функция, ему надо прямо словами написать function. К тому же есть еще загадочный модификатор simulated. Ну вероятно есть и emulated. И вон там двойное умножение, не то взятие адреса, хотя из самой функции вообще непонятно зачем там брать адрес. Ну в принципе достаточно. А теперь ответьте мне на простой вопрос - неужели ВОТ ЭТО легче в освоении, чем кресты?
Мне кажется это тепичная подмена понятий по Конфуцию. Низкоуровневые языки сложны в освоении в первую очередь из-за необходимости "прямой" работы с памятью, в кавычках, потому что там минмум два слоя абстракции - защищеный режим процессора и ядро самой винды. Этож не 286-й, где можно было биосу тень херачить из паскаля. Ну не суть. Народ вообщем не любит когда исключения бросаются. Ну на то и песочница, чтобы разрулить проблемы с памятью. А вот зачем так усложнять синтаксис? Причём этих модификаторов там гораздо больше чем я показал, есть еще interface, event, cpptext, virtual кстати есть, transient, inherits. На кого это вообще рассчитано?

на дезигнеров? Не, ну серъезно.
Как бы на таком фоне неудивительно что они UC дропнули и замутили блупринты. Я их правда не видел, но они вероятно проще, раз с ними даже наш Жэка освоился.

Добавлено 19-10-2019 в 15:51:

Цитата:

thambs писал:
А в shaders.def в одни строки заканчиваются на ";\r\n", другие — просто "\r\n". Как оно будет в финале?

ну щас парсер напишу и посмотрим.

Добавлено 19-10-2019 в 16:02:

C++ Source Code:

1	/** @return the name of the package this object resides in */

2	final function name GetPackageName()

4	local Object O;

  O = self;

7	while (O.Outer != None)

9	O = O.Outer;

11	return O.Name;

А тут прямо квакой дыхнуло. local, self

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 19-10-2019 в 13:09:

Цитата:

И вон там двойное умножение, не то взятие адреса

Возведение в степень же, даже название у переменной соответствующее — во всех клиентских языках так. Это ведь только C, когда придумывали, то, видимо, на клавиатурах не было символов @, ни $, вот они и повесили по 4 действия на один литерал специально что бы текст как можно более нечитаемым сделать.

Цитата:

ВОТ ЭТО легче в освоении, чем кресты?

Ну так потому что если что-то основывается на "идеях С", то в результате становится монстрообразным кошмаром, кресты тут не исключение, и новые стандарты его не сильно спасают.

Цитата:

На кого это вообще рассчитано?

Потому что придумывают это погромисты, а не лингвисты.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 19-10-2019 в 13:30:

Цитата:

thambs писал:
Возведение в степень же, даже название у переменной соответствующее — во всех клиентских языках так.

А если три звёздочки?

Цитата:

thambs писал:
Ну так потому что если что-то основывается на "идеях С", то в результате становится монстрообразным кошмаром

GLSL стал кошмаром? Да и потом, что вообще считать "идеями Си". Придумать как можно больше всяких модификаторов, это кто такое предлагал? А перед каждой функцией писать function это вообще зачем?
парсеру очевидно это не нужно. Значит для тупых юзеров. Юзер настолько туп, что даже не в состоянии осознать что перед ним функция?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 19-10-2019 в 14:00:

Дядя Миша

Цитата:

А если три звёздочки?

Не встречал такого, может гиперстепень? Правда не видел кейсов где оно в реальных вычислениях используется.

Цитата:

GLSL стал кошмаром?

Так он его не расширяет а сужает же. А кошмар начинается, когда С-шными приёмами описывают высокие абстракции. Вот плюсы наиболее характерный такой пример, они ведь стали настолько запустанными и переусложнёнными, что никто уже не понимает что там происходит. Уже и метапрограммирование есть, а такие полезные вещи как строгая типизация и иерархия типов (которые в том числе могли бы на этапе компиляции отловить сотни ошибок) — их не будет никогда, т.к. невозможно в С-шную парадигму впихнуть её не изломав всё.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено FiEctro 19-10-2019 в 15:24:

Походу, один только я пишу код сплошными ифами и кейсами в не зависимости от языка.

Отправлено Дядя Миша 19-10-2019 в 15:35:

Цитата:

thambs писал:
Вот плюсы наиболее характерный такой пример

Там не в языке проблема, а в выборе объектной модели. Причём, как я понимаю, тот же STL навязывает свою объектную модель, а boost - свою.
Потому что у каждого свое виденье, как это должно выглядеть.

Ну да ладно, оставим лингвистические споры. В процессе реализации парсера техники пришло понимание, что её в некоторой степени надо сделать похожей на DX-технику, точнее говоря включить в нее те настройки, которые недоступны из шейдера. Это блендфунк, альфа-функ, куллинг, дептчмаск, ну понятно. Не в том конечно виде, в котором они представлены в кутришных шейдерах, в максимально приближенном к обычному гл-вызову. Рассчёт в этом (да и аналогичных случаях), такой:
те, кто будут это ковырять, уже наверняка знают GLAPI. А тем, кто не знает не придётся учиться новой абстракции. Ну потихоньку уже что-то вырисовывается. Я тут текстом попытался изобразить, но помоему не очень понятно получилось

code:
VBOMesh
	|->material0
		|->textures
				|->texture0
				|->texture1
				|->systemTexture0 (e.g. lightmap)
				|->systemTexture1 (e.g. screencopy)
		|->shaderObject
				|->techique0 (shader, glstate, defines)	// ambient pass
				|->techique1 (shader, glstate, defines)	// spotlight pass
				|->techique1 (shader, glstate, defines)	// omnilight pass
	|->material1
	|->material2

Добавлено 19-10-2019 в 18:35:

Млять! И всё съехало нахер! Ксераааааакс

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 19-10-2019 в 17:10:

Цитата:

Дядя Миша писал:
Млять! И всё съехало нахер! Ксераааааакс

Ну ты как будто вчера на нашем форуме зарегался.

__________________

Отправлено Дядя Миша 19-10-2019 в 21:14:

Пересмотрел концепцию (я научился этому у покойного бумки), текущий вариант выглядит вот так, он уже парсится. Вариант не окончательный, но уже близкий к тому. Декларация псевдокодом по моей задумке должна подчёркивать, что всё написанное это не просто переменные, которые либо будут использоваться, либо нет, а то, что гарантированно будет выполнено в коде. Техника таким образом это готовый шейдерный проход, позволяющий что-то нарисовать с заданными параметрами. Там список неполный, надо еще подключить технику для теней и отложки, но это позже.

Добавлено 20-10-2019 в 00:14:

Ну чтожы, потихоньку система собирается из тысячи кусочков в единый механизм

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 20-10-2019 в 01:55:

Дядя Миша эка у меня сразу текстовый редактор сказал -- это исходный код на C.
Наверное из-за .def расширения.

code:
depthMask( GL_FALSE );
blendFunc( GL_ONE, GL_ONE );

А в чём смысл от приставки GL_ тут?

__________________
Xash3D FWGS форк

Отправлено XaeroX 20-10-2019 в 06:49:

Цитата:

a1batross писал:
А в чём смысл от приставки GL_ тут?

Как в ку3.

__________________

Отправлено Дядя Миша 20-10-2019 в 11:41:

Цитата:

a1batross писал:
А в чём смысл от приставки GL_ тут?

есть алиасы без нее. Кому што нравится.

Добавлено 20-10-2019 в 12:45:

Да, с юниформами надо в корне пересмотреть концепцию, то что я нагородил мне сейчас решительно не нравится.

Добавлено 20-10-2019 в 14:41:

Моя ошибка была в том, что я использовал старую концепцию юниформов, когда один тип содержал в себе все варианты использования. Это просто избыточно и неудобно. Разделил на три типа: макросы для препроцессинга, собсно сами юниформы со значениями и текстурные юниты.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 20-10-2019 в 21:41:

Так, ну судя по всему от первоначального варианта вообще мало что останется. Не выдержал он столкновения с реальностью. А реальность нам дана в ощущениях в виде шейдеров из паранои.

Добавлено 21-10-2019 в 00:41:

Тимплейты под нож пойдут скорее всего, они не нужны.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено AntiPlayer 21-10-2019 в 07:16:

Цитата:

Дядя Миша писал:
XML

XML это формат разметки документов. Довольно странная идея хранить в них конфиги.
JSON тоже избыточен как по мне, это формат созданный для передачи данных по сети. Хотя, для хранения сейвов сам по себе подошел бы, наверное.

Чем плох обычный .ini для конфигов?

Цитата:

XaeroX писал:
Зато теперь появилось новое ругательство - "парсить джейсоны"

Мое любимое занятие

__________________
I tell you to enjoy life

Отправлено XaeroX 21-10-2019 в 07:23:

Цитата:

AntiPlayer писал:
Мое любимое занятие

В нашем возрасте пора заставлять делать это подрастающее поколение джуниоров!

__________________

Отправлено Дядя Миша 21-10-2019 в 13:58:

Ну чтоже. После всех поправок и корректировок моих фантазий сообразно с реальностью и внутренней организацией конвейера, получилось вот такое вот. Это уже не абстрактный пример, оно парсится и генерит шейдеры.

Поясню что здесь к чему.
Каждый материал содержит ссылку на т.н. ShaderObject, который содержит в себе Techinques - техники. Назначение техник жестко определено в движке, это фиксированный набор, который нельзя изменить. На данный момент в наборе есть следующие типы:
base (ambient) - проход для рендеринга в паре с лайтмапами, статичный свет. Что рендерить в этом проходе выбирает конечно сам юзер, ему никто не навязывает непременно рисовать лайтмапы.
spot - освещение объекта для спот-лайтов
omni, sun - аналогично для всенаправленных и солнца.
shadow (depth) - для прохода теней.
в дальнейшем так же планируется проход для г-буффера, возможно для пост-процессинга, ну вообщем понятно. Все техники указывать необязательно, если вы например хотите чтобы какой-то конкретный материал (ну например полупрозрачный) не давал тени - просто не прописываете её технику в описание шейдер объекта. Или наоборот хотите, чтобы объект было видно только в лучах фонаря - для base строите пустой шейдер, который записывает только в буффер глубины, и для спот-лайта еще один. Ну это просто как пример использования.

В самих техниках можно настроить gl-state, практически весь набор, используемый в паре с шейдерами (который невозможно эмулировать из шейдера) - куллинг, запись в буффер глубины, полигоноффсет, ваерфрейм, итд. gl-state нельзя переопределить ниоткуда, он всегда существует только в самой технике. Если вам нужно непременно его переопределить для какого-то материала, то заведите отдельный шейдеробъект. Разные шейдер-объекты могут ссылаться на одни и те же техники. В техниках, как вы видите прописаны юниформы, которые используются в шейдерах, путь до которых задаётся там же. Кроме самих юниформов им назначаются дефолтные значения, как явные, так и относительные, в виде ссылок на какую-то информацию из движка.
Всего доступно несколько больших групп с переменными:
globals - глобальные параметры
light - для текущего источника света
entity - параметры энтити
render - позиция камеры, вьюматрица, ну понятно
lightProbe - типа R_LightForPoint
cvar - взять переменную, имя текстуры или индекс текстуры из квара.
materials.def - взять из описания материалов.
либо задать константу. Константы можно задавать и для vec2-vec3-vec4.
смешанные данные для векторов не поддерживаются, это всё же не язык программирования, а просто скрипты.

аналогично прописываются и текстурные юниты с относительными путями, конечно никто не мешает влепить туда константный путь.ъ

юниформы и текстурные юниты можно перегружать из любого материала в любом кол-ве. Хоть вообще все, но есть одна тонкость - всё что вы пропишете в материале будет применено ко всем техникам из шейдерного объекта. Разумеется для конкретного прохода будут использоваться только те юниформы, которые реально существуют в конкретном шейдере, т.е. объявлять лайтмапу для спотлайта имеет смысл, если сам шейдер обращается к ней.

С макро-подстановками немного по-другому. Они доступны сразу из трёх мест - из шейдер объекта, из материала и из техники. В случае использования в материале и в шейдер объекте, макросы будут применены сразу ко всем техникам в группе.

Единственное что я еще планирую сделать на этом фоне - возможность постановки тех или иных макросов в шейдеробъекте в зависимости от условий. Т.е. ввести кондиции в шейдеробъект.

Задавайте вопросы, что непонятно, предлагайте что поменять. Вам же потом с этим работать.

Добавлено 21-10-2019 в 16:58:

Можете так же приводить примеры из других движков, если вам там что-то понравилось, какие-то идеи.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 21-10-2019 в 18:33:

Ладно, раз молчите, расскажу немного о концепции всего этого дела.
Эта система возникла не на пустом места, а явилась итогом многолетних рассуждений на тему организации материалов в рендерере. Я изучал как это реализовано в других движках, как к этому относятся непосредственные пользователи и выяснил несколько любопытных вещей:

1. Если движок базируется на идеях Кармака или просто частичный форк - там непременно будут либо кутришные шейдеры, либо дуумтришные материалы, либо их симбиоз в самых разнообразных вариациях. Причём не имеет особого значения, был ли это движок куплен у Кармака в далёкие времена или это народная модификация на GPL-сорсах. Тут еще что любопытно, те, кто эти системы модифицирует, как правило сам никаких материалов не пишет.

2. Если движок принципиально отвергает идеи Кармака, то материалы представляют собой две крайности: или это полная минималка, как в сталкерах-метро, где можно настроить несколько параметров и указать путь к детальной текстуре, либо чуть ли не свой собственный язык с визуальным конструктором, как во всяких Unity\Unreal.

3. Пользователи так же делятся на два типа. Одним просто нравится играться с настройками материалов, но ихние игры почти никогда не идёт в продакшен, это просто хобби такое, ну максимум ассет выпустят когда-никогда. Причём они в этом ассете все настройки пару лет подбирали. Второй тип, это которые делают реальную игру и у них голова болит сразу за миллион вещей и им эти материалы как серпом об асфальт.

4. То есть со стороны реального пользователя имеем на первый взгляд такие взаимоисключающие требования - с одной стороны чтобы система была мощной, с другой, чтобы по дефолту не надо было ничего крутить.

Вот на четвертом пункте, я и строил свою систему. Какое-то время у меня безусловно крутились мысли насчёт того, чтобы использовать все эти кутришные и дуумтришные материалы. Но в них есть одна очевидная проблема: эти материалы создавались в первую очередь для фиксированного конвейера и пытались собою подменить его функционал. Очевидно, если бы это имело практический смысл, то производители видеокарт не стали бы делать программируемый конвейер и все бы радостно юзали материалы из д3. Но в настоящее время, когда мы имеем возможность программировать конвейер видеокарты, все эти устаревшие концепции только мешают эффективному рендерингу. И кстати очень сильно ограничивают возможности редактирования визуальной части со стороны пользователя (через материалы), но по большей части это довольно сложно понять, т.к. обилие настроек в этих кутришны-дуумтришных материалах по большей части сбивает с толку, кажется что там есть абсолютно всё. На практике куда ни ткнись, кастомизировать не возможно ничего. Ну вот взять простейший пример - интеракция с динамическим светом. Что можно сделать из кутришного шейдера? А ничего. Максимум что можно - это запретить освещение совсем. Поменять модель освещения, сделать какие-то вариации на тему Subsurface Scattering или в случае, если у нас там волосы, глаза, зубы, всё приехали - это только лезть в код и не факт, что это получится сделать красиво, потому что придется эти настройки еще и выводить в эти шейдеры.

В этом плане моя система является полной противоположностью такому подходу. Это Data-Driven концепция, когда пользователь сам полностью формирует этапы рендеринга, а движок лишь выполняет то, что ему задали, не внося никакой отсебятины, не имея дефолтных параметров.
В идеале бы конечно построить такой механизм, когда вся кастомная часть рендера окажется в пользовательских скриптах и шейдерах. Ну и второй момент - это, как выразился thambs - вменяемые дефолты.
Здесь активно используются относительные пути, если мы имеем дело с текстурами и ссылки на другие источники. Большинство материалов уложится в стандартные параметры, описать придётся лишь всякие специальные вещи, типа зеркал, мониторов, но я полагаю это небольшая проблема

Добавлено 21-10-2019 в 21:33:

ЗЫ. Как я уже говорил, лучше всего на этих кутришных шейдерах получается сделать всякие мигалки и бегущие текстуры. Ну собсно, именно их все и делали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-10-2019 в 18:36:

просто в материале прописываешь шейдер, вот и всё

Отправлено XaeroX 21-10-2019 в 19:03:

Цитата:

Дядя Миша писал:
лучше всего на этих кутришных шейдерах получается сделать всякие мигалки и бегущие текстуры.

Можно подумать, от шойдеров ждут что-то ещё?

__________________

Отправлено Дядя Миша 21-10-2019 в 20:19:

вот в том-то и дело, что не ждут. Привыкли и смерились!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 21-10-2019 в 20:24:

Цитата:

Дядя Миша писал:
раз молчите

Всё равно пока не попробуешь поработать с живым движком, всё останется набором слов. А меня и вовсе устроил бы простейший шейдер только с диффузкой, но с демоническими тенями.

Отправлено Дядя Миша 21-10-2019 в 21:31:

С новой системой поидее можно будет иметь разные рендереры в разных модах, просто заменяя шейдеры.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 23-10-2019 в 07:28:

Вчера был осуществлён успешный пуск рендерера, который базируется на новых идеях. Data-Driven, как следует из названия потребляет очень много этой самой даты. Надо придумать как бы её ужать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 23-10-2019 в 07:32:

Типа дудосит жесткий диск?

Отправлено XaeroX 23-10-2019 в 13:51:

Цитата:

Дядя Миша писал:
Data-Driven, как следует из названия потребляет очень много этой самой даты.

А Test-Driven потребляет много тестов?

__________________

Отправлено Дядя Миша 23-10-2019 в 15:04:

Цитата:

FiEctro писал:
Типа дудосит жесткий диск?

Рендер где, всё жестко определено, может использовать условия, как и что ему рендерить. Data-Driven очевидно должен иметь уникальные описания на каждую поверхность. Ну пусть не прям на каждую, но вариантов там немало.

Цитата:

XaeroX писал:
А Test-Driven потребляет много тестов?

Хтоита?

Добавлено 23-10-2019 в 18:04:

Вообще у моего подхода есть один минус - не могу придумать как в материале задавать анимацию текстур. В архитектуру рендерера это не укладывается в любом случае, да еще и с описанием проблемы.
Разумный вариант, это сделать мультислойную текстуру с нужными кадрами, но КМК это не слишком удобно для пользователя.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 23-10-2019 в 15:06:

Цитата:

Дядя Миша писал:
Разумный вариант, это сделать мультислойную текстуру с нужными кадрами

Они будут в динамике генериться? Потому что иначе в слоумо будет треш.

Отправлено Дядя Миша 23-10-2019 в 16:21:

Юзер сам создаст, поидее.

Добавлено 23-10-2019 в 19:21:

Хотя можно и налиту, конечно. Разницы особо нет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 23-10-2019 в 17:15:

Цитата:

Дядя Миша писал:
Юзер сам создаст, поидее.

Рисовать отдельные кадры в фш, вручную скроля картинку?

Отправлено nemyax 23-10-2019 в 17:27:

Дядя Миша
Ты про трансформируемые картинки или про секвенции кадров?

Отправлено Дядя Миша 23-10-2019 в 17:52:

Про секвенции конечно жы. А вы что подумали?

Добавлено 23-10-2019 в 20:52:

А что такое трансформируемая картинка?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 23-10-2019 в 17:57:

Цитата:

Дядя Миша писал:
А что такое трансформируемая картинка?

Ну када крутишь-масштабируешь-скроллишь, как в кутрёх.

Отправлено Дядя Миша 23-10-2019 в 19:43:

А, тю. Ну в моей система это элементарно реализуется прямо в шейдерах.
Все эти крутилки. Единственное что - задавать их придётся конечно не так, как в кутрёх, иной синтаксис. Но тут как бы тоже не всё печально. В моей системе ведь есть макросы! так что можно очень даже близко переопределить всё. Я конечно потом проверю, аж самому интересно стало.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 23-10-2019 в 20:03:

Дядя Миша
Ну матричку наверняка можно скормить. Но ведь её ещё домножать надо до нужного спейса. Хотя смотря как там у тебя.

Отправлено Дядя Миша 23-10-2019 в 21:11:

nemyax ты имеешь в виду задать константную? Да можно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 24-10-2019 в 10:01:

Я тут принял решение отказаться от всех этих кастомных аллокаторов памяти, в настоящее время они практически неактуальны. Простенький лик-детектор еще можно оставить, но не более того. Я тут проанализировал код и понял, что мемпулы у меня используются только при загрузке моделей, а всё остальное прекрасно в деструкторах высвобождается. Ну то есть городить огород нет смысла. Для моделей я мемпулы завернул в класс, там это всегда полезно - посмотреть сколько памяти занимает та или иная модель, а остальное интереса не представляет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 24-10-2019 в 10:30:

Цитата:

Дядя Миша писал:
в настоящее время они практически неактуальны

Для каждой мелочи будешь VirtualAlloc звать из ядра?

__________________

Отправлено Дядя Миша 24-10-2019 в 10:52:

XaeroX маллок обычный. Вообще-то в CRT есть своя куча. Вот пусть и разбираются там. Я же говорю, после того как все рассчёты переместились на GPU, единственное что неплохо бы кастомизировать это модели.
Кармака понять можно, он для теневых объемов временные буфферы на кадре аллокал постоянно. Конечно ему кастомная куча была нужна.
Сейчас память аллокается только при загрузке, во время работы - нет.
Ну так и смысл городить аггарот?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 24-10-2019 в 11:26:

Цитата:

Дядя Миша писал:
Вот пусть и разбираются там.

Тебе приятно работать с чёрными ящиками? А если там завтра что-то сломают, то ты гордо пожмёшь плечами и скажешь "я ничо не знаю, пишите в суппорт майкрософт"?

Так оно и бывает. Сначала переходят на malloc, потом - на сторонние библиотеки, а там уже и до юнити рукой подать.

Цитата:

Дядя Миша писал:
маллок обычный. Вообще-то в CRT есть своя куча.

Это понятно, но в конечном итоге под виндой всё сводится к системному вызову в VirtualAlloc.

Добавлено 24-10-2019 в 18:26:

Цитата:

Дядя Миша писал:
во время работы - нет.

Во время работы можно кешировать разные промежуточные результаты. Когда куча кастомная - ты всегда знаешь, сколько у тебя свободной памяти, и можешь занимать её под кеш. А потом - если она кому-то понадобилась в обычном аллоке - этот кеш грохать по принципу FIFO.

__________________

Отправлено Дядя Миша 24-10-2019 в 13:22:

Цитата:

XaeroX писал:
А если там завтра что-то сломают,

Подскажи пожалуйста, ты может знаешь какой-то способ вообще обойтись без маллока? Ну там объявить гигантский статичный массив и черпать память из него, пока не кончится?

Цитата:

XaeroX писал:
Сначала переходят на malloc, потом - на сторонние библиотеки, а там уже и до юнити рукой подать.

ну не надо. Ты имплементацию ZIP сам писал или всё же zlib используешь? Совсем без сторонних библиотек не получится. Вот когда PVS в сторонней библиотеке, это конешно трогедия.

Цитата:

XaeroX писал:
ы всегда знаешь, сколько у тебя свободной памяти, и можешь занимать её под кеш

Твой хитрый план определённо имеет значение, если мы активно выделяем память во время рендеринга. Но если мы этого не делаем, то и смысла нет.

Цитата:

XaeroX писал:
всё сводится к системному вызову в VirtualAlloc

Я к слову почти не видел менеджеров, построенных на вызовах VirtualAlloc, видимо для портабельности. malloc то везде есть.
Ну даже если таковые и существуют, мне неизвестно чтобы они прям хорошо-хорошо работали, пуще прежнего. Конечно мне несложно эту кучу из Doom3 опробовать в деле и я вероятно это сделаю. Но навряд ли будет толк в 2019-м году.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 24-10-2019 в 13:35:

Цитата:

Дядя Миша писал:
Подскажи пожалуйста, ты может знаешь какой-то способ вообще обойтись без маллока?

Нет, вообще без маллока конечно же обойтись нельзя, но можно выделить сразу много страниц, а потом самим ими управлять, а не доверять это библиотеке, в исходниках которой чёрт ногу сломит.
Да не в исходниках дело. Эти маллоки сделаны универсальными, подходящими под любые задачи. Вот пример: multithreaded-CRT содержит примитивы синхронизации, в том числе - при выделении памяти. Зачем нужна синхронизация, если ты точно знаешь, что память у тебя выделяется только в главном потоке?

Цитата:

Дядя Миша писал:
Ты имплементацию ZIP сам писал или всё же zlib используешь?

Я использую её в виде исходного кода, а не либы.

Цитата:

Дядя Миша писал:
Совсем без сторонних библиотек не получится.

Я понимаю - zlib, ogg-vorbis, даже lua какая-нибудь, тут нет смысла изобретать велосипед.
Но есть вещи, над которыми лучше иметь максимальный контроль. Вот память это как раз одна из таких.

__________________

Отправлено Дядя Миша 24-10-2019 в 13:43:

Цитата:

XaeroX писал:
Вот пример: multithreaded-CRT содержит примитивы синхронизации, в том числе - при выделении памяти. Зачем нужна синхронизация, если ты точно знаешь, что память у тебя выделяется только в главном потоке?

Будет просто замечательно если ты, используя это знание, расскажешь, как ускорить, например rad.

Цитата:

XaeroX писал:
Зачем нужна синхронизация, если ты точно знаешь, что память у тебя выделяется только в главном потоке?

Так я ж и говорю, основная идея втом, чтобы вообще не выделять память во время работы. А если и выделять, то самый минимум, под списки там какие-нибудь.

Цитата:

XaeroX писал:
Но есть вещи, над которыми лучше иметь максимальный контроль. Вот память это как раз одна из таких.

Вы сегодня прямо все расшутились как не знаю кто. В процессоре контролерр памяти и защищенный режим, который тебя никогда не пустит в реальную ячейку физической памяти, а сверху слой абстракции от операционки, которая следит, что ты там навыделял и если что-то не так - кидается исключение, а не виснет весь комп нахрен. И вот в таких вот условиях ты что-то там за максимальный контроль агитируешь?
Ты мне вот скажи навскидку, что ты там такое выделять собрался, что тебе это надо непременно контролировать? Ну скажем, на примере Волатилы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 24-10-2019 в 13:47:

Цитата:

Дядя Миша писал:

Будет просто замечательно если ты, используя это знание, расскажешь, как ускорить, например rad.

Я, признаться, бесконечно был бы RAD
Лечь под этот электронный агрегат,
Чтобы капал самогон мне в VIS
Днём и ночью BSP!

Цитата:

Дядя Миша писал:
Так я ж и говорю, основная идея втом, чтобы вообще не выделять память во время работы.

Ну ты не будешь выделять, а потом придёт Мастер и прикрутит асинхронную загрузку моделей...

Цитата:

Дядя Миша писал:
Ты мне вот скажи навскидку, что ты там такое выделять собрался, что тебе это надо непременно контролировать?

Я уже привёл пример с кэшем. Приведу другой: в том же аллокаторе строк ку3 есть встроенная оптимизация, возвращать пустую строку и строки-цифры из статической памяти, не аллокая их. Т.к. у кваров значения обычно либо пустые, либо 0/1/2, то это позволяет избежать от 20% до 30% аллокаций на куче.

__________________

Отправлено Дядя Миша 24-10-2019 в 13:53:

Цитата:

XaeroX писал:
а потом придёт Мастер и прикрутит асинхронную загрузку моделей...

для моделей я оставил мемпулы, говорю жеж. Для остального считаю излишним.

Цитата:

XaeroX писал:
в том же аллокаторе строк ку3 есть встроенная оптимизация, возвращать пустую строку и строки-цифры из статической памяти, не аллокая их.

Эта оптимизация порождает очень серъезную проблему в тех же крестах, когда у нас АТД строки и вот представь, что на деструкторе там высвобождается память, а указатель ведёт на эту константную цифру.
И получим Unknown software exception или что-то в этом роде. Но для чистого Си с кучей, вполне норм вариант.

Цитата:

XaeroX писал:
Я уже привёл пример с кэшем

У меня стойкое подозрение, что твои знания по кэшу больше относятся к 90-м и нулевым годам. Но скажем, уже для коры дуба они неактуальны, а для айкора тем более.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 24-10-2019 в 13:59:

Цитата:

Дядя Миша писал:

Эта оптимизация порождает очень серъезную проблему в тех же крестах, когда у нас АТД строки и вот представь, что на деструкторе там высвобождается память, а указатель ведёт на эту константную цифру.

Нет тут неко кой проблемы, кастомный FreeString, который работает в паре с AllocString, эту ситуацию разруливает.

Цитата:

Дядя Миша писал:
Но скажем, уже для коры дуба они неактуальны, а для айкора тем более.

Ну понятно, когда есть гигантский L3, то это не то же самое, как фетчинг из оперативки. Но тем не менее.

__________________

Отправлено Дядя Миша 24-10-2019 в 14:01:

Я где-то на хабре видел статью вот как раз по архитектуре коры дуба и она полностью мои представления перевернула. Ну точнее привела в соответствие с современным железом.

Добавлено 24-10-2019 в 17:01:

Цитата:

XaeroX писал:
Нет тут неко кой проблемы, кастомный FreeString, который работает в паре с AllocString

ага, это если мы городим фабрику. Ну или как эта херь правильно называется. Но это именно Сишное мышление. Кресты навязывают маленькие локальные АТД.

Добавлено 24-10-2019 в 17:01:

Цитата:

XaeroX писал:
Ну понятно, когда есть гигантский L3

щас вообще существуют процы с L3 менее 16 метров? Мне кажется там уже за сотню перевалило.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 24-10-2019 в 14:02:

Цитата:

Дядя Миша писал:
Кресты навязывают маленькие локальные АТД.

Никто не мешает перегрузить для любого АТД new и delete.

__________________

Отправлено Дядя Миша 24-10-2019 в 15:23:

Цитата:

XaeroX писал:
Никто не мешает перегрузить для любого АТД new и delete.

Это да, но мне не даёт покоя мысль, почему Кармак это отключил для д3. Сделал и выключил.

Добавлено 24-10-2019 в 18:23:

Вот кстати, говоря возвращясь к той статье на Хабре про устройство современного процессора, там прямо в начале были такие занимательные строчки, что мол опытные программисты, до сих пор имеют о процессорах представление, застывшее на уровне суперскалярной архитектуры первого пня, а то что сейчас стоит у всех в компьютерах, даже С++ на дух не переносит, оно вообще точилось под виртуальные машинки.
Есть над чем задуматься.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 24-10-2019 в 15:30:

Цитата:

Дядя Миша писал:
что мол опытные программисты, до сих пор имеют о процессорах представление, застывшее на уровне суперскалярной архитектуры первого пня

Типичный хабр - "все вокруг дураки, один я умный в белом пальто стою красивый".

__________________

Отправлено Дядя Миша 24-10-2019 в 15:31:

XaeroX обижаешь. Это был перевод с английского, на Хабре только их и можно читать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 25-10-2019 в 03:43:

Дядя Миша

Цитата:

Для остального считаю излишним.

Звуки?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 25-10-2019 в 05:25:

А где асинхронные модели, там и асинхронные текстуры, так-то.

__________________

Отправлено Дядя Миша 27-10-2019 в 09:06:

С декалями я придумал вот какую концепцию - декаль будет тоже модель. Ну разумеется не для пользователя, а с точки зрения движка. Мой менеджер моделей в своей концепции позвоялет ссылаться на другую модель, как на родителя. Таким образом парент для модели декалей будет например мир или бмодель. Причём эта модель будет линковаться не к самой модели, а к энтити, чтобы не получилось ситуации, например, когда дубликат одной и той же встроенной модели заодно дублирует и свои декали на ней. Сохранение таких декалей будет происходить через методы, встроенные в саму модель (не только для модели декалей, а вообще для любой модели).
И пользователь сам сможет определить для какой модели надо сохранять декали, а для какой нет. Аналогично для такой модели будет строится и область видимости, как и для брашевой. Это позволит держать рендеринг в юниформе. И для травы будет точно такая же модель со ссылкой на родителя. а шейдеры будут линковаться через хинты mod_decal, mod_grass.
Сам рендеринг при этом принимает максимально однотипный вид - промаркировали видимость для списка и отрисовали всё.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 27-10-2019 в 20:28:

Текущий вариант организации скриптов. Здесь всё рабочее, все условия, параметры. всё рулит процессом. Работать становится всё удобнее, я к примеру добавил освещение на брашы, дописав несколько строчек в shaders.def

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 27-10-2019 в 20:57:

Дядя Миша
А как порядок наложения декаль-моделей будет рулиться?

code:"duct_flr02a"
{
	#material vent
}

А такие штуки можно будет в одну строчку писать?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 27-10-2019 в 21:36:

thambs не, нельзя.

Этож не просто key-value. Если бы ты дальше промотал. то увидел бы вот например такое:

C++ Source Code:

1	"{gratestep3"

3	#material grate

5	AlphaFunc( GL_GREATER, 0.25f );

Можно вообще всё полностью перегрузить, из того что объявлено в технике\шейдер объекте. Оно нечасто нужно, ну вот скажем зеркала или там видеотекстуры. Вот для таких случаев.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 27-10-2019 в 21:41:

Дядя Миша
Это да, понимаю. Я имел ввиду синтаксический сахар для тривиальных текстур.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 27-10-2019 в 22:51:

thambs когда я закончу препроцессор, ты сможешь использовать макроподстановки для этих целей.

вот типа такого:
#define MATERIAL( tex, mat ) \
tex
{ \
#material mat\
}

ЗЫ, дополнил немного технику бмоделей

C++ Source Code:

1	technique "bmodelSolidLightmapPass"

3	vertShader( "glsl/forward/scene_bmodel_vp.glsl" );

4	fragShader( "glsl/forward/scene_bmodel_fp.glsl" );

6	image u_LightMap = "entity->$LightmapTexture";

7	float u_LightStyleValues[64] = "globals->lightStyles";

9	#if r_fullbright \|\| !MODEL_HAS_LIGHTMAP

10	#define LIGHTING_FULLBRIGHT

#endif

13	#if r_lightmap == 1

14	#define LIGHTMAP_DEBUG

#endif

17	#if r_lightmap == 2 && MODEL_HAS_DELUXMAP

18	#define LIGHTVEC_DEBUG

#endif

21	depthMask( GL_TRUE );

то есть все квары теперь рулят дефайнами именно отсюда. Движок ничего не знает про эти шейдеры, он вообще про них ничего не знает. Всё здесь.

Добавлено 28-10-2019 в 01:42:

Вот примерчег чуть посложнее

C++ Source Code:

#if r_detailtextures && u_DetailMap

#define HAS_DETAIL

#endif

Что проверяется здесь? Во первых, чтобы квар r_detailtextures был установлен в состояние, отличное от нуля. Во вторых юнит u_DetailMap проверяется на заданный путь (причём неважно где вы его задали, в технике, в шейдеробъекте или в самом материале) и только если текстура действительно существует - применяется #define HAS_DETAIL. Т.е. система способна выполнять реальные проверки на валидность пользовательских данных. Ну и с бампом аналогично.

Добавлено 28-10-2019 в 01:46:

Может у кого-то вопрос возникнет, почему это именно препроцессинг. Отвечу, потому что эти условия выполняются только перед компиляцией шейдера. А квары, типа r_lightmap имеют теперь особый флажок FCVAR_RELOAD_SHADERS, который провоцирует ребилд шейдеров у всех моделей. Т.е. проверка идёт именно на этапе сборки. Условия, которые выполняются всё время, очевидно находятся в самих GLSL-шейдерах.
Ну впрочем, функции gl-state тоже часть реального кода, но условий там нету.

Добавлено 28-10-2019 в 01:51:

Кстати говоря, заведомо статичные условия выполняются еще на стадии парсинга всех этих скриптов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 28-10-2019 в 08:53:

Дядя Миша
Я правильно понимаю, что к моделькам уже можно вязать ключ-значения и что они могут передаваться как параметры в шейдер? И для каждой модельки эффект будет зависеть от значений параметров?

Отправлено Дядя Миша 28-10-2019 в 09:40:

nemyax через скрипты да. Вкомпиливать это внутрь модели смысла не вижу. Как тогда редактировать?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 28-10-2019 в 10:29:

А в какой момент изменения значений на модельке прорастают в шейдер?

Отправлено Crystallize 28-10-2019 в 10:38:

Цитата:

Дядя Миша писал:
Может у кого-то вопрос возникнет, почему это именно препроцессинг. Отвечу, потому что эти условия выполняются только перед компиляцией шейдера. А квары, типа r_lightmap имеют теперь особый флажок FCVAR_RELOAD_SHADERS, который провоцирует ребилд шейдеров у всех моделей. Т.е. проверка идёт именно на этапе сборки. Условия, которые выполняются всё время, очевидно находятся в самих GLSL-шейдерах.
Ну впрочем, функции gl-state тоже часть реального кода, но условий там нету.

По-моему ты с ума сойдёшь всё это документировать.
GL_GREATER это научное название альфатеста?

Отправлено Дядя Миша 28-10-2019 в 10:46:

Это операторы словами:
GL_EQUAL ==
GL_NOTEQUAL !=
GL_GREATER >
GL_LESS <
GL_GEQUAL >=
GL_LEQUAL <=

Добавлено 28-10-2019 в 13:46:

Цитата:

Crystallize писал:
По-моему ты с ума сойдёшь всё это документировать.

наоборот. Достаточно понять общие принципы, а дальше сработает экстраполяция.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 30-10-2019 в 15:51:

Ну што, работа идёт потихоньку. С новой скриптовой системой фичи добавлять одно удовольствие. Бамп подключил со спекуляром, за час.
Собсно, справился бы за пять минут, но ведь новые части системы написаны, а еще толком не отлажены. Плюс некоторые уточнения концепции.
Конечно нельзя сказать, что всё гладко. К примеру самая главная проблема отрисовки брашей - она никуда не делась. Надо придумать как оптимизировать это дело. А дело тут вот в чём:
Модель - понятно, загрузил меш, загрузил его индексы и рисуй себе.
С брашами не так. Там конечно можно весь мир засунуть в один вбо, но рисовать-то придётся по видимым фейсам, накапливая их в промежуточном буффере. Это первая проблема, то что нужен такой массив. Вторая проблема, что для того, чтобы сказать драйверу, какие именно сурфейсы рисовать, нам очевидно надо проталкивать индексы по шине каждый кадр.
Их не надо хранить, они всегда производное от surf->firstvertex (можете в ксаш-моде посмотреть), но положение это не спасает. Во первых их надо накопить в массиве. Во вторых их надо загрузить в видеопамять. Хреново вообщем. Пока карты стандартные халфовские это ни на что не влияет. Но взять ту же спонзу или карты рейда, и выходит что мы за кадр проталкиваем порядка 40 тысяч индексов. Конечно не вертексов, конечно это быстрее.
Но всё равно. Там где могло бы быть 2000 фпс, остаётся всего 300-400.
А с лайт-проходами и прочим, падение будет еще сильнее. Плюс это только рендерер. Вообщем имеет место быть мультипликационный эффект падения производительности. Надо придумать что с этим сделать.
Самое очевидное решение - вообще не использовать сложную брашевую архитектуру оставим на усмотрение дизайнерам. Если бы таких карт в природе не было, я бы может и не парился. Но они есть. И с этим надо что-то делать.

Добавлено 30-10-2019 в 18:51:

Из влобных решений - можно попробовать завести VBO для каждого фейса, но чёт мне кажется это плохая идея.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 30-10-2019 в 16:18:

Забить на отсечение брашевых фейсов и рисовать единый вбо? С з препассом, например. Медленно получится?

Отправлено XaeroX 30-10-2019 в 16:37:

ncuxonaT
У меня тут одна знакомая дочь офицера говорила по поводу з-препасса, что... ну ты понял.

__________________

Отправлено Crystallize 30-10-2019 в 16:49:

BSP геометрию при загрузке конвертить в модель

Отправлено Дядя Миша 30-10-2019 в 17:09:

Цитата:

ncuxonaT писал:
Забить на отсечение брашевых фейсов и рисовать единый вбо? С з препассом, например. Медленно получится?

Забивать не с руки, для колидоров весь смысл именно в отсечении, а для ландшафта проще поставить гигантскую модель. Если бы я хотел забить, я бы сделал движок вообще без брашей. Но так неинтересно.

Цитата:

Crystallize писал:
BSP геометрию при загрузке конвертить в модель

Модели фундаментально отличаются от брашей, если ты еще не понял.
Способом их редактирования. В модели ты берёшь один меш в котором миллионы вертексов и натягиваешь на это ЕДИНУЮ текстуру. Для брашей всё строго наоборот, там ты нарисовал кубек и каждую грань покрасил в свою текстуру. Текстура поменялась - стоп конвейер, перезапуск отрисовки.
Текстуры нельзя склеить в атлас, т.к. они с тайлингом. Текстуры нельзя склеить в 2Д массив, т.к. во первых они все разного размера, во вторых 2д массивы довольно таки тормозны, на удивление, на старом железе. А где то их нет вообще.

Добавлено 30-10-2019 в 20:07:

ЗЫ, биндлесс текстур на старом железе нет тем более.

Добавлено 30-10-2019 в 20:09:

Кстати говоря, насчёт отсечения. Возьмем пресловутый сипульчер. Там примерно триста тысяч фанов. С визом и куллингом, средняя видимость - ну тысяч 18, а то и меньшы. Конечно ежели бы этот сипульчер покрыть одной текстурой, будет очень быстро

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 30-10-2019 в 17:17:

Дядя Миша текстуры можно собрать в атлас с GL_NEAR, а фильтрацию делать в шейдере, но это, конечно извращение немножк

__________________
-Brain is dead-

Отправлено nemyax 30-10-2019 в 17:24:

Цитата:

Дядя Миша писал:
В модели ты берёшь один меш в котором миллионы вертексов и натягиваешь на это ЕДИНУЮ текстуру

Никто не заставляет в единую. Хочешь натягиваешь несколько по вкусу. Толку-то объединять, если моделек всё равно много и текстуры на них разные.

Отправлено Crystallize 30-10-2019 в 17:24:

Цитата:

Дядя Миша писал:
Текстуры нельзя склеить в атлас, т.к. они с тайлингом.

нифкурил

Отправлено nemyax 30-10-2019 в 17:29:

Crystallize
Если текстурные координаты за пределами единичного квадратика, то на атласе они бы брали чужие текстуры.

Отправлено Crystallize 30-10-2019 в 17:36:

nemyax А, ну это понятно. Ну при тайлинге отдельно хранимой текстуры рендер же доходит до конца массива пикселей и потом сбрасывает координаты на начало и начинает рисовать следующий тайл той же текстуры. Ну а в атласе значит надо для каждой текстуры хранить границы в которых она находится в атласе, и так же циклиться между ними. Это по идее, в атласах наверное есть заморочка почему это невозможно, или ещёченить.
Это в общем такая фундаментальная проблема что не ждёшь что она ещё где-то не решена.

Отправлено KiQ 30-10-2019 в 17:41:

Crystallize для каждого атласа заводить texture region по количеству изначальных текстур, которые будут клампить оффсет?

__________________
-Brain is dead-

Отправлено Дядя Миша 30-10-2019 в 17:53:

Crystallize это всё было бы хорошо в теории, если бы не существовало пирамидальной фильтрации, анизотропной фильтрации и других страшных слов.

Добавлено 30-10-2019 в 20:53:

Цитата:

KiQ писал:
а фильтрацию делать в шейдере

пирмаидалку вручную делать? нафиг-нафиг. Сам бы попробовал штоли.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 30-10-2019 в 18:14:

Ну так а это, сортировать видимые фейсы в текстурные списки?

__________________
-Brain is dead-

Отправлено Дядя Миша 30-10-2019 в 20:42:

Первые эксперименты по оптимизации.
Чёт какой-то COF получился.

Добавлено 30-10-2019 в 22:01:

Цитата:

KiQ писал:
видимые фейсы в текстурные списки?

что такое текстурные списки?

Добавлено 30-10-2019 в 23:34:

Вообще я подозреваю, мне просто нужно что-то из функционала GL посвежее. Я попробовал так же через glDrawArrays рисовать, ему индексов вообще не нужно. Но это deprecated по идее. Да и не всегда оно быстрее.

Добавлено 30-10-2019 в 23:42:

Гм. Похоже всё еще хуже. glDrawArrays просто экономит время, которое я трачу на генерацию индексов на CPU. И при сравнении оказалось, что это весьма незначительная часть процесса. Настолько незначительная, что разница даже в дебаге минимальна. Ну она есть конечно, скажем в релизе там 1100 фпс, а в дебаге 1030 фпс. Но и только.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 30-10-2019 в 20:54:

Вообще по сути с текущим пайплайном, как я его понял, проблема не только в текстурах, ведь одна текстура может шариться на несколько материалов, например, а значит конвейер будет тормозиться уже не на смене текстуры, а на переключении шейдера

__________________
-Brain is dead-

Отправлено Дядя Миша 30-10-2019 в 22:55:

ну текстура, материал, неважно. Понятно же что речь идёт об уникальном объекте. Пока не было шейдеров, в их роли выступали текстуры.
Список фейсов хитро отсортирован, чтобы минимизировать все переключения, так что этот фактор не влияет.
Вообщем я опробовал сравнительно свежий glMultiDrawElementsBaseVertex
и древний glMultiDrawArrays. И вот последний в моём случае дал наилучший результат. В принципе, когда у тебя вот такие вот три-фаны, их наверное и правда лучше рисовать совсем без индексов - быстрее будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 30-10-2019 в 23:52:

Дядя Миша вайрфрейм бы интересно глянуть, как оно разбивается

__________________
-Brain is dead-

Отправлено Дядя Миша 31-10-2019 в 14:18:

Поскольку текстура потенциально может грузиться из разных мест, добавил в скрипт функцию addImageLocation. Конечно при нормальной разработке игры, это ненужно, но для моей отладки, когда у меня тут зоопарк из разных карт, в том числе и кутришных, это может оказаться полезным.
Через этот же механизм реализуется и дефолтная текстура, которую можно задать, если ничего не нашлось. Для бампа, например можно сделать чёб он поискал текстуры с разными суффиксами, ну там _gloss, _spec понятно.
Для диффузки - в ваде, в папке textures и так далее. Эти пути конечно тожы можно перегружать раздельно для шейдер объекта, для материала и для техники и заключать в условия.

Добавлено 31-10-2019 в 17:18:

Вчера ради интереса поглядел как это устроено в старом Unigine - там очень похожая схема, ну просто очень. Точнее не схема, а концепция, там тоже есть обозначенные типы проходов - амбиент, разные типы лайтов, отложка, постпроцесс. Но там довольно много встроенных параметров, у меня нет вообще. Полностью настраиваемый конвейер.
Для полного щастья осталось добавить команду cvar, которая будет регистрировать квары, например из game.rc и можно создавать различные рендереры, вообще не затрагивая код.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 31-10-2019 в 15:15:

Цитата:

Дядя Миша писал:
например из game.rc и можно создавать различные рендереры, вообще не затрагивая код.

DX11-рендерер можно будет добавить через game.rc?

__________________

Отправлено Дядя Миша 31-10-2019 в 15:18:

XaeroX DX не нужен

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 31-10-2019 в 22:35:

С китайскими детайлами одна беда - они сделаны для сохранения совместимости, поэтому кол-во производимых лифов просто зашкаливает.
Сами понимаете, проверять десятки тысяч лифов на каком-нибудь сепульчере дорогостоящее удовольствие. Можно конечно пойти простым путём как Ксерокс, прикрутить кутришные карты. Но так неинтересно.
Тут всё дело в том, что у нас есть необходимая информация, чтобы из общей кучи лифов и нодов восстановить дерево без детайлов. Ну точнее говоря, смержить все детайл-лифы обратно в один, и ноды подсократить. Насколько их меньше? ну скажем на Edge Of Forever 145 тысяч лифов, а реальных, которые отвечают за видимость около двух тысяч (кстати даже меньше чем в ку3). Лифы, первый в списке это основной, остальные с таким же оффсетом виздаты - детальные. Ну и руководствуясь этой информацией, как вы понимаете, идя, обратно по родителю лифа, можно найти детальные ноды и построить новое дерево. Правда оно не годится для трассировки например, только для видимости. так что старое тоже останется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 31-10-2019 в 22:38:

Дядя Миша
А от разрезаний всего и вся и щелей это поможет?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 01-11-2019 в 09:10:

Ну кто о чём

Добавлено 01-11-2019 в 12:10:

Мне это напоминает, как какой-то чувак увидел в хидерах vgui какой-то класс SurfaceGL и тут же решил что это мониторы из третьего дуума. Ну ему просто очень хотелось, чтобы они там оказались.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 01-11-2019 в 14:47:

Дядя Миша Та не о чём, а о том что больше всего беспокоит в истории с дизайном карт.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 01-11-2019 в 16:54:

Цитата:

thambs писал:
а о том что больше всего беспокоит

В итоге все сошлись на том, что Черноморск в ближайшее время непременно будет объявлен вольным городом!

Када на карте 15 фпс, при 4 тысячах полигонах в кадре, щели отходят на второй план.

Добавлено 01-11-2019 в 19:54:

Первые результаты уже кстати есть. Но я помоему где-то налажал. Ну неудивительно, такого дерева еще никто не строил.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 01-11-2019 в 17:14:

Так всё-таки 4 тысячи полигонов а не 4 миллиона, правильно?

Отправлено Дядя Миша 01-11-2019 в 21:04:

Crystallize да. Построил новое дерево. Ну неплохо, на сипульчере 200 фпс, на Edge Of Forever 300. Теперь надо выкинуть лишние ноды из дерева.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 02-11-2019 в 03:33:

Цитата:

Дядя Миша писал:
Ну што, работа идёт потихоньку. С новой скриптовой системой фичи добавлять одно удовольствие. Бамп подключил со спекуляром, за час.
Собсно, справился бы за пять минут, но ведь новые части системы написаны, а еще толком не отлажены. Плюс некоторые уточнения концепции.
Конечно нельзя сказать, что всё гладко. К примеру самая главная проблема отрисовки брашей - она никуда не делась. Надо придумать как оптимизировать это дело. А дело тут вот в чём:
Модель - понятно, загрузил меш, загрузил его индексы и рисуй себе.
С брашами не так. Там конечно можно весь мир засунуть в один вбо, но рисовать-то придётся по видимым фейсам, накапливая их в промежуточном буффере. Это первая проблема, то что нужен такой массив. Вторая проблема, что для того, чтобы сказать драйверу, какие именно сурфейсы рисовать, нам очевидно надо проталкивать индексы по шине каждый кадр.
Их не надо хранить, они всегда производное от surf->firstvertex (можете в ксаш-моде посмотреть), но положение это не спасает. Во первых их надо накопить в массиве. Во вторых их надо загрузить в видеопамять. Хреново вообщем. Пока карты стандартные халфовские это ни на что не влияет. Но взять ту же спонзу или карты рейда, и выходит что мы за кадр проталкиваем порядка 40 тысяч индексов. Конечно не вертексов, конечно это быстрее.
Но всё равно. Там где могло бы быть 2000 фпс, остаётся всего 300-400.
А с лайт-проходами и прочим, падение будет еще сильнее. Плюс это только рендерер. Вообщем имеет место быть мультипликационный эффект падения производительности. Надо придумать что с этим сделать.
Самое очевидное решение - вообще не использовать сложную брашевую архитектуру оставим на усмотрение дизайнерам. Если бы таких карт в природе не было, я бы может и не парился. Но они есть. И с этим надо что-то делать.

Добавлено 30-10-2019 в 18:51:

Из влобных решений - можно попробовать завести VBO для каждого фейса, но чёт мне кажется это плохая идея.

О, круто. Это решение потом можно будет и в ксашмод перетянуть.
З.Ы: Не эту идею с кучкой VBO, конечно же.

Отправлено Дядя Миша 02-11-2019 в 07:57:

Там от оптимальности дерева куда больше зависит, чем от остального.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 02-11-2019 в 13:05:

Цитата:

Дядя Миша писал:
на сипульчере 200 фпс

сколько раньше было?

Отправлено Дядя Миша 02-11-2019 в 14:38:

Ну собсно, первые валидные результаты, для Edge Of Forever

Цитата:

LoadLeafs: time: 2.430553 secs
node tree optimized by 3 iterations
source 162224 nodes, optimized tree 3757 nodes
source 145323 leafs, optimized tree 2235 leafs
LoadNodes: time: 0.302457 secs

Оптимизед три - это вот как раз виз три. Карту с таким кол-вом нодов и лифов найти практически нереально, даже на сипульчере меньше.

Цитата:

Crystallize писал:
сколько раньше было?

15.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 02-11-2019 в 15:18:

Цитата:

Дядя Миша писал:
15.

Я имею в виду, если сепульчер запустить под Xash3D.

Отправлено Дядя Миша 02-11-2019 в 17:56:

Vis Tree, что это и для чего нужно

Ну чтожы, давайте немного расскажу о том, что это вообще такое, откуда взялось, почему не было раньшы. Бинарные деревья (хотя навряд ли только они), имеют следующую особенность - их построение привязывается к конкретной задаче. То есть нельзя построить идеальное дерево для всего сразу, но можно для одних и тех же данных построить несколько деревьев и каждое будет оптимально для своих задач. Собственно, поэтому и клипноды - оптимизированное дерево для коллизии. С видимостью всё не так однозначно. После первой кваки, Кармак решил не хранить более одного дерева на модель. В ку2 это привело к проблемам - на ноды пришлось класть брашы, дерево получилось неоптимальным, переусложнённым. Настолько неоптимальным, что для рассчёта видимости, компилятор создаёт новое дерево, игнорируя детальные и мелкие лифы. Но в ку2 нет явной привязки виздаты к лифам - там промежуточные индексы, которые называются кластерами. В ку3 дерево еще более общее. Если быть точным, оно ни для чего. Для коллизии оно слишком поверхностное, кмк регулярная сетка была бы куда более оптимальна. Для точечной трассы - аналогично, оно не включает в себя например плоскости патчей, трисурф-моделей, это надо трейсить отдельно. Еще и проверяя, что в этом лифе мы уже трейсили (это особенно интересно выполнять при мультипоточных рассчётах). Единственное для чего кутришное дерево оптимально - это для видимости. В моду уже входили графические ускорители, риваТНТ опять же. И вот с их учётом дерево и было построено. А для первой кваки остался самый неоптимальный вариант на текущий момент. Рассмотрим это подробнее.

В первой кваке\первой халфе, как известно нет функ_детайла, нет ареапорталов и прочего. Дерево там в первую очередь устроено для максимальной оптимизации коллизии. А небольшой размер дерева получался автоматически - квака не блистала детализаций в 95-м году, сами понимаете. Но время шло, карты становились всё навороченней и вот то самое дерево, которое идеально подходило для колоизации, выступило ключевым тормозом перестройки для проверки видимости.
По очень простой причине - чем больше детализация, тем больше лифов и нодов, чем больше лифов и нодов, там дольше обходить дерево. Возникала ситуация, когда проверка на видимость в десятки раз дольше, чем, собственно отрисовка. Вот кстати, что касается, сипульчера, спонзы и прочих подобных карт. Китаец и автор TyrUtils, понимали проблему, поэтому попытались ввести детайл-брашы для первого квейка\халфы. Но проблему это решило только наполовину и вот почему: оптимальное дерево существовало только для виза и здорово сокращало время его рассчётов, вплоть до того, что карта, которая могбы считаться часов 30, теперь считалась пару минут. Но для сохранения совместимости с форматом халфы\кваки, им в любом случае пришлось нагенерить дополнительных нодов-лифов для того чтобы описать все эти детальные брашы, чтобы движок смог их отрисовать. Причём нельзя даже сказать, что они вообще не нужны - ведь они же еще и для коллизии используются. Тот же рад, например тени по ним считает. Но считать видимость по такому дереву нельзя категорически. Вот у того же Edge Of Forever, скомпиленного в формат условной первохалфы, получается 136 тысяч лифов. Даже если просто пробежать их в цикле - ну можете подсчитать сколько времени это займет. Далее, видимые лифы копятся для энтить для быстрой проверки видимости. Ну кто движок ковырял тот знает. А если лифов через чур много, то вместо них делается проверка видимости по хеадноде. Вы никогда не задумывались сколько времени занимает такая вот проверка? Я не считал точно сколько там энтить каждый кадр её запрашивают, но всего на карте 386 энтить. Ну пусть половина. Этот запрос на проверку видимости, отнимает по времени 0.07 секунд!!!!! Рендер, к примеру управляется на два порядка быстрее. То есть получается идиотизм. Вроде бы и детайлы есть и виз оптимизированный. А фпс всё хуже и хуже. К слову говоря старый Кармаковский код с поиском лифов через родителя ноды в данной ситуации чувствует себя чуть получше. Но и только. Конечно это всё неюзабельно, как вы понимаете. Как же поступить в данной ситуации? Какие варианты у меня были?

Добавлено 02-11-2019 в 20:56:

самый "простой" метод, который у меня был, как вы понимаете - это взять формат карт из Quake3. После всего что я сделал для халфовского формата, научил его считать лайтмапы на моделях, повертексное и еще массу других интересных вещей, взять дропуть и прикрутить кутришный формат, как в Волатиле. Ну не скрою, текущая архитектура XashNT позволяет его прикрутитьЮ не затрагивая другие подсистемы. Но сами особенности формата могут доставить немало весёлых минут мапперам, если я им потенциально предложу на него перейти. Напомню, что я даже патчи и трисурфы имплементировал в халфовский формат. Как говорится - последний довод за кутришный, который мне всегда приводили в пример.
Ну вообщем с учётом вышесказанного я решил, что мне нужно не маяться дурью прикручивая к движку разные там форматы карт, этим хорошо заниматься, когда ты учишься, и попытаться решить проблему более элегантным способом. Например построить такое специальное дерево для видимости. Как это сделать? Компиляторы, учитывющие детайлы в картах делают одну оптимизацию - для детальных лифов пишется тот же самый оффсет виздаты, что и для главного лифа, из которого они наследуются. Второй момент - они обычно не раскиданы по карте вперемежку, а идут группой подряд. Собсно это второе больше влияет на возможности оптимизации по скорости построения нового дерева, а не на какую-то принципиальную невозможность. Главное же условие, я назвал - совпадающие оффсеты у виздаты. Итак, по этим оффсетам мы находим настоящие визлифы, их кол-во и создаём новый массив с визлифами, аккумулируя в один лиф всё из детальных. Аналогично из обычных нодов создаётся массив визнодов. Здесь над подстерегает одна нехорошая проблема - во первых эти ноды раньше ссылались на детальные лифы, а теперь на одни и те же номера обычных лифов, которыми мы их подменили. Это не фатально, но провоцирует дубликат в BoxLeafnums, что в свою очередь быстро приводит к их переполнению в массивах энтить и снова здравствуй поиск по хеадноде, а поскольку визнодов столько же, сколько было в исходном массиве, никакой оптимизации считайте и не было - только память зря израсходовали. То есть моя основная задача, которую я решал последние два дня - как эффективно выкинуть эти лишние ноды и при этом не поломать дерево и чтобы это было быстро (поскольку делается во время загрузки уровня). Ну собно, немного статистики я привёл выше. Edge Of Forever с виздеревом теперь выдаёт вместо 15 фпс, около 500. У спонзы тоже фпс очень вырос.
ну и разумеется в моде рейда произойдут аналогичные позитивные улучшения.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 02-11-2019 в 18:45:

Цитата:

Дядя Миша писал:
После всего что я сделал для халфовского формата, научил его считать лайтмапы на моделях, повертексное и еще массу других интересных вещей, взять дропуть и прикрутить кутришный формат, как в Волатиле.

А что тебя смущает, это самое логичное решение. Я эту иррунду с лифами и нодами, в которых непременно должны лежать все сурфасы, быстро просёк и даже не стал пытаться использовать. Оно полезно разве что для софтварного рендера.
Что касается "после всего что сделал" - ну я тоже когда-то сделал в волатиле кучу всяких интересных оптимизаций для шадов-волюмов, а ты говорил - не жалей, выбрасывай, ну неактуальны уже эти волюмы. И вот однажды я выбросил и не жалею.

__________________

Отправлено Дядя Миша 02-11-2019 в 20:13:

Цитата:

XaeroX писал:
Оно полезно разве что для софтварного рендера.

Оно полезно для точечной трассы в первую очередь.

Цитата:

XaeroX писал:
ну я тоже когда-то сделал в волатиле кучу всяких интересных оптимизаций для шадов-волюмов

Вот ежели бы ты научил волюмы кастовать тени от альфа-текстур - их реально было бы жалко выбрасывать.

Добавлено 02-11-2019 в 22:09:

Вообще я планирую кутришный формат прикрутить, в рамках теста. Ну интересно жеж. Ну то потом когда-нибудь.

Добавлено 02-11-2019 в 23:13:

Хым. Оказывается я случайно нашёл возможность оптимизировать любое дерево, не только содержащее детайл-ноды. Можно выкинуть из дерева ссылку на общий нулевой лиф и за счёт этого сократить его размер. Ссылка на этот лиф всё равно нахрен не нужна для визтри. А для наружки достаточно сделать PointInLeaf увидеть что кластер == -1 и включить полную видимость.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 02-11-2019 в 20:17:

Дядя Миша
Ничего не понял, но как всё таки с т.з. левел-дизайнера результирующие полигоны будут выглядеть на неаксиальной геометрии?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 02-11-2019 в 21:01:

Цитата:

thambs писал:
результирующие полигоны будут выглядеть на неаксиальной геометрии

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 03-11-2019 в 07:11:

Компилятор уровней в формат XashNT всё так же будет резать браши через определённые промежутки, пусть и не такие большие?

Отправлено Дядя Миша 03-11-2019 в 07:26:

Crystallize лайтмапы-то большие, можно практически не резать.
Во всяком случае это лучше, чем пытаться уменьшить лайтмапу, как ку3 делает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 03-11-2019 в 07:29:

Дядя Миша
В ку3 ты можешь сам порезать большие браши в Джеке, где надо.

__________________

Отправлено Дядя Миша 03-11-2019 в 07:36:

Очевидно в джеке можно порезать брашы для любой карты

Я кстати понял, откуда взялась внезапная оптимизация дерева даже для тех карт, где нет никаких детайлов.

C++ Source Code:

1	for( i = 0, data = g_uncompressed; i < leafnum; i++, data += g_bitbytes )

3	if( !memcmp( data, outbuffer2, g_bitbytes ))

5	g_dleafs[g_leafstarts[leafnum]+1].visofs = g_dleafs[i+1].visofs;

6	c_reused++;

    return;

От оно. У меня же виз по возможности идентичные векторы выбрасывает для экономии места. Хотя это и не совсем корректно по идее - использовать это как условие для идентичных лифов, придётся пересмотреть немного этот механизм.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 03-11-2019 в 07:40:

Цитата:

Дядя Миша писал:
Очевидно в джеке можно порезать брашы для любой карты

Угу, но халфовские компиляторы всё склеят обратно и порежут так, как им нравится. А ку3шные - уважают право маппера решать, как и что должно быть порезано.

Цитата:

Дядя Миша писал:
У меня же виз по возможности идентичные векторы выбрасывает для экономии места.

Это ещё одна умная оптимизация, от которой мало толку на ку3шном дереве с малым числом кластеров?

__________________

Отправлено Дядя Миша 03-11-2019 в 11:02:

Цитата:

XaeroX писал:
Угу, но халфовские компиляторы всё склеят обратно и порежут так, как им нравится

Халфовские порежут, а мои не порежут.

С этим виздеревом всё не так однозначно вообщем. Можно использовать один накопительный проход, это очень быстро, практически незаметно.
А можно использовать поиск по лифам NxN, но с прямым продвижением, я чёрт его знает как это правильно называется, не силён в терминологии.
Ну вообщем цикл вида

C++ Source Code:

1	for( int i = 0; i < numleafs; i++ )

3	for( int j = i + 1; j < numleafs; j++ )

Это дешевле чем настоящий NxN. Но и дерево для первого случая получается менее оптимальным, результаты для быстрого построения

Цитата:

LoadLeafs: time: 0.100575 secs
node tree optimized by 3 iterations
source 162224 nodes, optimized tree 3757 nodes
source 138415 leafs, optimized tree 2235 leafs
LoadNodes: time: 0.291052 secs

Результаты для глубокой аналитики от Ozzy

Цитата:

LoadLeafs: time: 2.419452 secs
node tree optimized by 3 iterations
source 162224 nodes, optimized tree 3757 nodes
source 138415 leafs, optimized tree 2235 leafs
LoadNodes: time: 0.291097 secs

На первый взгляд кажется, что один хрен. Но в игре, быстрое построение даёт 400 фпс, а медленное - 470 фпс. Так же на некоторых картах кол-во лифов для визтри может увеличиться при быстром построении, что тоже может сказаться на итоговом фпс. Здесь есть еще одна проблема - дублирующиеся лифы. Для поиска по дереву это не играет никакой роли, т.к. найденные сурфейсы всё равно помечаются единожды. Но это имеет значение для BoxLeafnums, куда попадают одинаковые лифы. Само по себе это не проблема тоже. Проблема в том, что этих лифов, как вы помните на энтитю не может быть более 48. А потом начинается тежолый поиск по головной ноде, хотя он теперь и происходит по визтри, это всё равно нежелательный кейс. Ну собсно, я пока что сделал проверку при сохранении лифов в энтить, чёб добавляло лишь уникальные. А потом надо подумать, возможно заменить фиксированный массив на деномический. Но гораздо важнее разобраться насколько вообще допустимы эти дублирующиеся лифы. На первый взгляд всё отлично, фпс сильно вырос, видимость корректно считается. Но тут необходимо провести серию юнит-тестов.

Цитата:

XaeroX писал:
Это ещё одна умная оптимизация, от которой мало толку на ку3шном дереве с малым числом кластеров?

Дерево само-по себе не самоцель. Оптимальнее иметь несколько деревьев для своих задач. Так вот кутришное толком не годится ни для чего. Оно только для видимости. Физика по нему настолько неоптимально считается, что я вот просто уверен, что если его заменить на AABB, станет быстрее. Кстати попробуй.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 03-11-2019 в 12:05:

Цитата:

Дядя Миша писал:
Физика по нему настолько неоптимально считается, что я вот просто уверен, что если его заменить на AABB, станет быстрее.

Быстрее на 0.00001 сек? Колоизация это последнее, что может тормозить на ку3шном дереве. Куда важнее дерево, которое использует физдвиг для динамической симуляции. Но там своё.

__________________

Отправлено Дядя Миша 03-11-2019 в 14:06:

Вот вам для понимания картинка виздерева, циферками обозначены номера лифов. Красной циферкой - аутсайд лиф, общий. Как видите тут очень много ссылок на второй номер лифа виздерева. В реальном дереве там конечно был какой-то свой уникальный лиф, но это неважно, потому что у всех этих уникальных лифов была ссылка на один и тот же указатель виздаты. Мой оптимизатор дерева исходит из очевидных предпосылок - если у ноды ссылки на детей оканчиваются одним и тем же лифом - такую ноду можно выкинуть. Если у ноды дальше по дереву всего два уникальных лифа, причём один из них общий, то такую ноду тоже можно безболезненно выкинуть, оставив только ссылку на ненулевой лиф. Почему - понятно, этож дерево видимости, за пределами уровня, оно всё равно значения не имеет, так что на его целостность это не влияет. Но вот иногда бывают такие мерзкие случаи как накартинке. С которыми я решительно не знаю чего делать. Да и нужно ли с ними что-то делать вообще. Время покажет.

Добавлено 03-11-2019 в 15:18:

Результаты для быстрого построения визтри и для медленного.

Конечно далеко не на каждой карте такая разница большая.

Добавлено 03-11-2019 в 17:06:

У меня тут еще появилось вот какое соображение. Дубликаты проявились только на картах, собранных промежуточной версией p2st. Возможно там что-то неоптимальное было. Надо будет пересобрать и проверить заново.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 03-11-2019 в 14:11:

А почему для всех задач деревья, то такие то сякие? Не может ли статься, что где-то больше подойдёт какая-нибудь хеш-табличка ну или там я не знаю?

Отправлено thambs 03-11-2019 в 14:15:

Дядя Миша

Цитата:

Ну плане, какие фэйсы получаются из брашей, сформированных из не-аксиально ориентированных плоскостей. Помнишь вот те гнутые тоннели у меня на карте и сколько с ними проблем было (а часть до сих пор осталась), как оно с новым подходом? Мне ведь чому кутришный формат симпатичен -- в силу его предсказуемости: как в джеке браши порежу, так и буду уверен что в игре оно будет идентично (а если уж алгоритм всё таки слажает, то детайл спасёт). А в случае с хлбсп -- половина времени уходит на поиск компромисного варианта, на котором не будет микрофэйсов и дырявых клипнод.

Цитата:

https://hlfx.ru/forum/attachment.php?action=preview&s=&postid=185759

А что циморки значат?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 03-11-2019 в 14:54:

Цитата:

nemyax писал:
А почему для всех задач деревья, то такие то сякие?

там где деревья не нужны, там обычно и апсуждать-то нечего. А дерево, его же можно повсякому построить.

Цитата:

nemyax писал:
где-то больше подойдёт какая-нибудь хеш-табличка

Полным-полно таких мест, но чо там аспуждать-то?

Цитата:

thambs писал:
Мне ведь чому кутришный формат симпатичен -- в силу его предсказуемости

Так ить режет-то CSG, а его можно выключить. Отправил проблемное место в func_group и выставил там zhlt_nocsg 1, всё.

Цитата:

thambs писал:
А что циморки значат?

Цитата:

Дядя Миша писал:
Вот вам для понимания картинка виздерева, циферками обозначены номера лифов. Красной циферкой - аутсайд лиф, общий

вы и с Гулем так же дискуссию ведете?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 03-11-2019 в 15:11:

Цитата:

Дядя Миша писал:
выставил там zhlt_nocsg 1, всё.

Та бсп-ж её корёжит. Вот тут nocsg=1, а тем не менее всё равно микрофэйсы есть, и чем геометрия сложнее, тем эта проблема острее вылезает*. В результате, в джеке всё выглядит ок, а в игре потом приходится эти места запоминать, переделывать, проверять, снова переделывать и пр. Ты-ж не представляешь даже насколько это отнимает время и силы при создании карты. Не говоря уже о времени компиляции**.

*гротто2 так вообще проще снуля будет сделать, видимо -- моделью.
**гротто2, если память не отшибло, минут 40 собирается (бсп+виз), на кутришном -- 2-4 минуты вместе с освещением.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 03-11-2019 в 16:20:

Цитата:

thambs писал:
Ты-ж не представляешь даже насколько это отнимает время и силы при создании карты

ну почему это не представляю? очень даже хорошо представляю.

Цитата:

thambs писал:
Та бсп-ж её корёжит

бсп может ну максимум некоторые микрофейсы выбросить поидее. Ну что еще?

Добавлено 03-11-2019 в 19:20:

Цитата:

thambs писал:
на кутришном -- 2-4 минуты вместе с освещением

да там такое асвищенее, лучшеб его не было.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 03-11-2019 в 18:50:

Цитата:

ну почему это не представляю? очень даже хорошо представляю.

Это ведь ещё на самом деле приводит к тому, что приходится очень заморачиваться над неаксиальными конструкциями, задумываться как бы так изловчиться, сколько граней делать, с хинтбрашами эксперементировать. Т.е. создаёт огромное количество совершенно бестолковой экспериментальной активности призванной как-то скомпенсировать принципиальные недостатки алгоритма с помощью ручного тюнинга, вместо, собственно художественного процесса.

Цитата:

бсп может ну максимум некоторые микрофейсы выбросить поидее. Ну что еще?

Ну разрезы же делает он? Выкидывание да, это ещё одна головная боль -- приходится осматривать карту, а потом долго и упорно пытаться найти такую конфигурацию, где их не будет. p2st выкидывает меньше конечно, но там тоже проблема бывает, когда все эти микробраши оказываются очень тонкими, то на них лайтмэпа плохо ложиться, ну и клипноды лажают -- то дыра, то застревание. Ну и опять же, чем сложнее конструкция -- тем всё это сильнее вылезать начинает.

Цитата:

да там такое асвищенее, лучшеб его не было.

Ну не настолько прямо что совсем плохое, хотя грязи немного есть, да. А с чем вот эта плохость, кстати, связана? Я помню, что там дело, вроде, в трассе, но это какое-то принципиальное ограничение, или возможно ли это качество улучшить пусть даже если время расчёта финального освещения возрастёт раз в 10?

Но вот то что подбор оптимальной геометрии и bsp+vis компиляция растягиваются -- это очень нехорошо, на самом деле, особенно, с увеличением размера карты. Если для черновой компиляции можно было-бы посчитать освещение уровня даже хуже чем ку3, а для финальной оставить компилироваться на пару-тройку часов -- это было бы удобней, по моему.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 03-11-2019 в 20:23:

Цитата:

thambs писал:
А с чем вот эта плохость, кстати, связана?

там вообще нет индиректа. Констант амбиент + директ.

Цитата:

thambs писал:
возможно ли это качество улучшить

ну надо новый компилятор написать. Я еще в прошлом году его начал делать. Лежит пока. Ждёт своего часа.

Цитата:

thambs писал:
Ну разрезы же делает он?

Ну дык понятно, это ж потом дерево для точечной трассы используется. Конечно рубит. В кутри, там просто в лиф натолкал и всё.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-11-2019 в 08:17:

Я вот что понять-то не могу. Вот взять сипульчер. Ну хорошо может там не прямо сложная геометрия. Но всё компилится, микродырок нет. Что родными компиляторами, что моими. Далее. Не скажу за p2st, но XashNT Tools прекрасно собирают родные кутришные карты - q3dm1, q3dm7. Со светом. Опять таки - некоких дырок, выпадающих полигонов там нет и близко. Достаточно простые карты? Ну хорошо Edge Of Forever достаточно сложная? А там снова идеальный результат. Но почему-то у Тхамбса проблемы на простейших скруглённых тоннелях вылезают, я этого решительно не могу понять. Гротто - там да, неисключено, такое вообще никто не рисковал компилировать в BSP. Но чтобы тоннели?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 04-11-2019 в 11:20:

Цитата:

Дядя Миша писал:
Гротто - там да, неисключено, такое вообще никто не рисковал компилировать в BSP. Но чтобы тоннели?

Ты говорил что и Сепульчер, и карты в Ку3 все держатся в рамках кубика +-8192 юнита, и что q3map2 за этими пределами начинает дивным образом плющить. Может в этом проблем и thambs где-то на границе сетки мапает?

Отправлено Дядя Миша 04-11-2019 в 12:34:

Ну точность флоата как бы никто не отменял, это правда. Но во первых в компиляторе даблы, а во вторых точность сохраняется до диапазона +\- 16384 примерно. Если гротто выходит за рамки, там возможны какие-то проблемы с генерацией порталов, да собсно всё упирается в эти долбаные порталы, там ОЧЕНЬ важна точность. Альтернатива вам хорошо известна - вручную расставлять окклюдеры у каждого дверного проёма.

Так, ну штож. С брашами подразобрались, настала очередь моделей. Может показаться, что я просто беру и копироваю код из паранои, но параноя писалась с учётом особенностей Xash3D, многие вещи нуждаются в переработке, можно сделать гораздо оптимальнее. Да и вообще в халфе эта дурь с сетапом костей в рендерере очень сильно вставляет палки в колёса. Вот зачем рендереру заниматься сетапом костей? Зачем ему вообще это нужно? Ему это никак не нужно. Ему просто надо получить кости из энтити и всё.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 04-11-2019 в 13:07:

Я правильно понял из вашей беседы, что в ку3 компилятор на нарезает геометрию на куски как, например, на скриншоте Тхамбса (обратите внимание на тоненькую полосочку, отрезанную от прямоугольного фейса на стене)? При этом там нормально строится и работает бсп-дерево и всё такое?

Отправлено Дядя Миша 04-11-2019 в 13:17:

Не нарезает, да. Но и использовать такое дерево для трассировки уже проблематично. Только для видимости.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 04-11-2019 в 13:28:

Выходит, вся эта канитель с кучей лишних треугольников, микрофейсами, корявой геометрией и швами нужна только чтобы трассу легко строить по дереву? При условии, что Кармак справился с этим 20 лет назад?

Отправлено Crystallize 04-11-2019 в 13:38:

Цитата:

Дядя Миша писал:
Но почему-то у Тхамбса проблемы на простейших скруглённых тоннелях вылезают, я этого решительно не могу понять.

Т.е. скруглённый тоннель из world-брашей как у thambs должен переезжать в игру 1-в-1 без всяких дополнительных разбиений типа тех что мы видим на картинке?

Отправлено Дядя Миша 04-11-2019 в 14:18:

Цитата:

ncuxonaT писал:
Выходит, вся эта канитель с кучей лишних треугольников, микрофейсами, корявой геометрией и швами нужна только чтобы трассу легко строить по дереву?

Ты на трассу не гони. Эта трасса быстрее любого специализированного рейтрейсера. Может даже вообще самая быстрая в мире.

Цитата:

ncuxonaT писал:
При условии, что Кармак справился с этим 20 лет назад?

Справился с чем именно? Построить такое дерево как в кутри напорядок легче чем такое как в ку1. А можно и вообще ничего не строить. А можно рисовать всю модельку разом. Прямо как в Юнити.

Добавлено 04-11-2019 в 17:18:

Цитата:

Crystallize писал:
Т.е. скруглённый тоннель из world-брашей как у thambs должен переезжать в игру 1-в-1 без всяких дополнительных разбиений типа тех что мы видим на картинке?

Я решительно не понимаю почему вас так волнуют эти разбиения. Надо наверное отключить ваерфрйем, чёб вы крепче спали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 04-11-2019 в 14:35:

Цитата:

Дядя Миша писал:
Я решительно не понимаю почему вас так волнуют эти разбиения. Надо наверное отключить ваерфрйем, чёб вы крепче спали.

А ну я не знаю, наверное фпс падает? И лайтмапы корёжит.

Добавлено 04-11-2019 в 21:35:

А можно ли шарить одну лайтмапу на несколько соседних патчей произвольной формы?

Отправлено ncuxonaT 04-11-2019 в 14:51:

Цитата:

Дядя Миша писал:
Ты на трассу не гони. Эта трасса быстрее любого специализированного рейтрейсера. Может даже вообще самая быстрая в мире.

Ну а смысл-то какой в этой самой быстрой трассе? В ку3 трасса была не такая быстрая, но он же не тормозил.

Цитата:

Дядя Миша писал:
Справился с чем именно?

С трассой по ку3шному дереву.

Отправлено Дядя Миша 04-11-2019 в 14:59:

Цитата:

Crystallize писал:
А ну я не знаю, наверное фпс падает? И лайтмапы корёжит.

ну вот да, единственно что, если микрофейс, там с лайтмапой будут проблемы. Ну так на то и детайлы.

Цитата:

Crystallize писал:
А можно ли шарить одну лайтмапу на несколько соседних патчей произвольной формы?

в халфе там рав-массив, не текстурки. Или что ты имеешь в виду? Если дата совпадает, она оптимизируется, да.

Цитата:

ncuxonaT писал:
Ну а смысл-то какой в этой самой быстрой трассе?

дык лайтмапы считать же.

Цитата:

ncuxonaT писал:
С трассой по ку3шному дереву.

яж говорю, у меня сильные подозрения, что если взаместо этого дерева взять AABB tree, для трассы даже быстрее будет. Я доберусь и до кутри, у меня и для него масса оптимизаций накопилась, надо жы многое проверить на практике. По планам сейчас что:
1. подключить рендер моделей
2. написать загрузчик и рендер спрайтов
а потом можно и с кутри поразбираться.

Добавлено 04-11-2019 в 17:59:

Я вам навскидку скажу одну очень нехорошую особенность кутришного дерева. Поскольку там фейсы лежат не на ноде, то они прилинкованы к лифам. А в разных лифах могут быть одинаковые фейсы, ну собсно это на любом BSP так. Но если трейсить по ноде, там всегда уникальные фейсы.
Так вот, если мы нашли какие-то лифы, то нам надо как-то пометить, что мы эти сурфейсы трейсили, чтобы не выполнять двойную работу. А лайтмаппер-то мультипоточный! Или делать синхронизацию тредов, что убьёт весь профит или на стеке выделять массив этих временных лифов, как Кармак сделал или строить для лайтмаппера вообще новую трассу, лишённую этого недостатка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 04-11-2019 в 15:00:

Дядя Миша
Ты приглядись внимательнее к eof -- там большинство брашей или аксиальыне, или под 45, остальные с рациональным соотношением сторон. У симонока вообще большей частью там замки, а террайны с преимущественно с близкими к регулярным сеткам. А чем больше флоатов, треугольников, чем больше брашей с близкими (но не совпадающими) плоскостями и чем меньше углы между ними, и чем дальше они от центра карты и больше по размеру -- тем больше проблем вылезает. p2st очень многое исправило, но всё равно раз-на раз не приходится. Т.е. даже если щелей нет, то будут места, где тонкие чёрные полоски -- из-за того что лайтмэпа плохо легла на микрофэйс, будут места со странными застреваниями или наоборот проваливаниями. И никак это не спрогнозировать. В результате вырабатывается конечно некоторое эмпирическое умение как минимизировать проблемы, но это получается перекладывания с больной головы на здоровую, в том смысле, что компьютер должен работать а человек думать, а не наоборот.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 04-11-2019 в 15:02:

C++ Source Code:

1	void TraceLine( const vec3_t start, const vec3_t stop, trace_t trace, qboolean testAll, traceWork_t tw ) {

  int				r;

  int				i, j;

4	dleaf_t *leaf;

5	float oldHitFrac;

6	surfaceTest_t *test;

7	int surfaceNum;

8	byte surfaceTested[MAX_MAP_DRAW_SURFS/8];

Вот такой порнографией Кармак в кутри занимался.

Добавлено 04-11-2019 в 18:02:

Цитата:

thambs писал:
и чем дальше они от центра карты -- тем больше проблем вылезает

Ну это понятно, ктож спорит. Вопрос в том, насколько дальше?
Может имеет смысл этот гротто сделать моделькой, да залайтмаппить её?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 04-11-2019 в 15:36:

Цитата:

Дядя Миша писал:
Может имеет смысл этот гротто сделать моделькой, да залайтмаппить её?

Вот да. Делай уже детали модельками, ну.

Отправлено XaeroX 04-11-2019 в 15:38:

Цитата:

Дядя Миша писал:
Или делать синхронизацию тредов, что убьёт весь профит или на стеке выделять массив этих временных лифов, как Кармак сделал или строить для лайтмаппера вообще новую трассу, лишённую этого недостатка.

Пфф, тоже мне проблема. Заалокать на куче битовые массивы по количеству тредов. По 4 кб на массив выйдет.

Добавлено 04-11-2019 в 22:38:

Цитата:

Дядя Миша писал:
Может имеет смысл этот гротто сделать моделькой, да залайтмаппить её?

Завертекслайтить, и делов.

__________________

Отправлено Дядя Миша 04-11-2019 в 15:45:

Цитата:

XaeroX писал:
Заалокать на куче битовые массивы по количеству тредов

У меня тут две версии битстрингов, CBitVec и CByteVec соответственно.
Так вот второй всё же быстрее. Надо будет кстати и на компиляторах проверить, глядишь тожы прерост будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 04-11-2019 в 15:52:

Цитата:

Дядя Миша писал:
дык лайтмапы считать же.

Ну считать их каким-то иным способом. Гадить геометрию, чтобы потом вроде как быстро посчитать лайтмапу - это очень странно.

Отправлено Дядя Миша 04-11-2019 в 15:58:

Не гадить, а подготавливать особенным образом. Тот же кутри лишён CSG, там вся внутренняя хрень, которая исчезает при препроцессинге, здесь радостно остаётся. И для нее тоже считается лайтмапа. На иных картах залетишь вот так в стенку, а внутри - еще одна стенка и на ней лайтмапа посчитана. Конечно это лучше. Щас во всех играх такое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 04-11-2019 в 16:06:

Цитата:

Дядя Миша писал:
Тот же кутри лишён CSG, там вся внутренняя хрень, которая исчезает при препроцессинге, здесь радостно остаётся.

Ну добавишь CSG, как я в волатиле, делов-та.
Ку3 - это всего лишь формат, конь-цепция. Никто ж не заставляет брать оттуда абсолютно всё? Если бы я так рассуждал, не было бы неко кой волатилы, взял бы я ку3 и сидел давольный.

__________________

Отправлено Дядя Миша 04-11-2019 в 16:26:

Цитата:

XaeroX писал:
Ну добавишь CSG, как я в волатиле, делов-та.

Добавлю конечно. Но это только полдела. Я сильно подозреваю, что тот же сталкер первоначально и базировался на кутришных картах. Но потом в процессе оттуда повыкинули дерево и всё остальное. И произошло это в первый же год разработки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-11-2019 в 12:35:

Подключил студиомодели.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 05-11-2019 в 13:15:

Дядя Миша
Совместимость с голдовскими будешь ломать?

Отправлено Дядя Миша 05-11-2019 в 13:44:

В дальнейшем буду. Я предусмотрю такой же конвертор из одного формата в другой, как и для уровней.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-11-2019 в 08:59:

Вот кстати говоря насчёт TBN на моделях. В параное сглаживание происходило только в рамках одного меша. Если кто-то не знает структуру студиомодели, поясню. Вся модель делится на Body Parts - это таблица индексов, к которой прилинкованы субмодели. Через параметр pev->body мы можем указывать рендереру какие именно части тела рендерить. Хитрость этой таблички в том, что мы уже при компиляции можем задать любые сочетания из имеющихся у нас субмоделей и привязать их к определённому номеру body. Допустим солдат-негр с дробовиков содержит в табличке 3 субмодели - тело солдата, голова негра и дробовик. Эти три меша будут отрисованы. Субмодели делятся на мешы, но при этом вертексы-нормали общие для всей субмодели. Один меш отличается от другого только текстурой. Так вот всё дело в том, что чаще всего нормали сглажены только для отдельно взятого меша, а не для всей субмодели. Проверить это утверждение очень легко - достаточно попробовать нарисовать Glow Shell, используя те нормали, которые уже есть в модели. Ну вы все знаете, как делается Glow Shell:

C++ Source Code:

vec3_t vertex = mesh->vertex + mesh->normal * shell_scale;

В квейках глоушеллы сделаны аналогично, но поскольку там всегда одна текстура на модель, то проблем не возникает. А тут приходится строить новую табличку. Надо сказать, что в Valve в целях ускорения, к этому отнеслись довольно наплевательски. Ну они просто пособирали все нормали с субмодели, которые попались первыми. Примерно в 70% случаев это конает. То что Glow Shell имеет разрывы - незаметно. Да я напомню, что это в основном использовалось на айтемах, ну и может на игроках. Ну как что сложнее - уже видны артефакты. Но в то же время есть еще один кейс где сглаженные нормали сквозь весь меш крайне критичны - это радионовская фича True Form, которая пыталась тесселировать модели в те далёкие времена, я помню её Ксерокс еще пытался заюзать в HLFX и у него бочки так смешно надувались

Тем не менее на ютубе есть ролики, где показано что это даже неплохо работало. А как строятся такие нормали? Там area weights для смежных треугольников субмодели. Я сделал аналогично и через dot сравнил нормали в модели с теми что у меня получились. И вот в 90% случаев dot выдал результат около 0.99, т.е. почти идентичные. Но кое-где было 0.1, а где-то даже -1. Это вот как раз те разрывные места между двумя мешами. У меня тут небольшой бардак с ресурсами, толком проверить пока не могу, но я оставлю эту фичу на будущее - пригодится.
По хорошему TBN надо сохранять в модель, но тогда придётся разработать новый формат, уже с нормальной индексацией треугольников, снять лимит на длину анимации в 64 килобайта, итд.

Добавлено 07-11-2019 в 11:59:

Модели худо-бедно рисуются, анимируются, теперь надо спрайтесы подключить. Старый вариант, где на каждый кадр грузилась отдельная текстурка никуда не годится. Я их сохраню в один большой атлас. А вертексы в VBO и спрайты теперь тоже будут рисоваться через шейдер.
Все равно их мягкими делать. Soft-Particles.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 07-11-2019 в 11:31:

Цитата:

Дядя Миша писал:
придётся разработать новый формат, уже с нормальной индексацией треугольников

В каком смысле с нормальной? Сейчас плохая? Или сейчас всё на стрипы завязано?

Отправлено Дядя Миша 07-11-2019 в 12:56:

Цитата:

nemyax писал:
В каком смысле с нормальной? Сейчас плохая?

Сейчас там raw-поток gl-комманд, к которому нет произвольного доступа, это дичайше неудобно, его приходится каждый раз весь проматывать.
Нормальная индексация, я имею в виду завести структурку triangle и там a,b,c индексы.

Подзагрузил спрайто-кадры в атласы, ну пока не очень плотно. Но для начала сойдет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 07-11-2019 в 13:07:

Дядя Миша будешь делать обрезалку квадов спрайтов, как хумус завещал?
http://www.humus.name/index.php?ID=266

Отправлено Дядя Миша 07-11-2019 в 15:28:

Не знаю пока насчёт обрезалки. Я тут в коде упаковщика картинок от Кармака баг нашёл. Сначала понять не мог, да что за дерьмо такое, ну вот ситуация. Допустим у нас в спрайте всего 1 кадр 16х16. Размер атласа аналогично 16х16. У меня там перед загрузкой еще код пытается определить потенциальные размеры атласа, чтобы потуже упаковать кадры.
Вполне естественно что для одного кадра он покажет именно его размеры.
А упаковщик - посылает. А всё почему?

C++ Source Code:

1	for( i = 0; i < blockWidth - w; i++ )

3	best2 = 0;

5	for( j = 0; j < w; j++ )

7	if( allocated[i+j] >= best )

      break;

9	if( allocated[i+j] > best2 )

10	best2 = allocated[i+j];

13	if( j == w )

15	// this is a valid spot

    x = i;

17	y = best = best2;

Видите условие для цикла?
Если blockWidth == w, цикл ни разу не прогонится. Отсюда идиотская ситуация, что мы не можем поместить в атлас картинку, которая точно совпадает по его размерам, но это ладно, это только полдела. Оно из-за этого еще и пакует хуже процентов на 15. То есть я подбирал оптимальные размеры атласа, куда по моим прикидкам должны были влезать все кадры. А упаковщик - хрена. 2-3 последних кадра не влезало. Как повизёт. Да что такое? Увеличил высоту еще на один шаг - влезло.
Странно. Начал разбираться. И вот такое.
Правильнное условие выглядит так

C++ Source Code:

for( i = 0; i <= blockWidth - w; i++ )

вот так всё прекрасно влезает на заданный размер.

Добавлено 07-11-2019 в 18:25:

Поглядел насчёт обрезалки. Это филлрейт понижать? Наши мапперы как наставят один за другим 100 спрайтов, туманчег делают, навряд ли оно спасёт.

Добавлено 07-11-2019 в 18:28:

Particle Trimmer, хех. В принципе такую штуку несложно и самому написать, этож 2д обрезалка. Если парт-системы сделать через инстансинг, то смысл безусловно есть. Впрочем там и лучи надо через него же рисовать, но с лучами попроще - их и так не надо обрезать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 07-11-2019 в 15:41:

Цитата:

Дядя Миша писал:
Поглядел насчёт обрезалки. Это филлрейт понижать? Наши мапперы как наставят один за другим 100 спрайтов, туманчег делают, навряд ли оно спасёт.

Странная логика, казалось бы как раз поэтому и нужно делать.

Отправлено Дядя Миша 07-11-2019 в 16:19:

Да не, от еденичных спрайтов подряд оно не спасёт. Это для облака партиклей в первую очередь полезно. Вот там да, овердрав, который можно сильно уменьшить.

Добавлено 07-11-2019 в 19:19:

Кстати насчёт того исправления о котором я написал выше. Залез в код ку3 - а там уже исправлено Причём тем же способом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 07-11-2019 в 17:08:

Цитата:

Дядя Миша писал:
код ку3

А в код Jedi Academy лазишь?

Отправлено Дядя Миша 07-11-2019 в 20:52:

Та я уже почти никуда не лажу. А если и лажу, то не за кодом, а посмотреть архитектурное решение.

Добавлено 07-11-2019 в 20:36:

Чтоб не мелочиться, загрузил вообще все спрайты, которые были. Прикольно выглядит.

Добавлено 07-11-2019 в 20:44:

Барон Ада из дуума занял текстуру 1024х768.

Добавлено 07-11-2019 в 20:46:

Вообще в NT я планирую сжать эти спрайты в DXT1\DXT5, это и будет "новый" формат.

Добавлено 07-11-2019 в 23:20:

Возвращаясь к теме убитых нормалей, то что я писал утром. Вспомнил, что у меня есть моделька, конверченная из ку3 с помощью этой японской программы, название которой я уже забыл. Ну вообщем нормали там вообще никакие. Я не знаю почему. Собсно слева - нормали в модели, а справа seamless normals by area weighting про которые я говорил.

Это конечно искуственный случай, ну просто чтобы было понятнее о чём речь.

Добавлено 07-11-2019 в 23:52:

Да, возвращаясь к вашей самой любимой теме, о том как можно текстуры с разных моделей совершенно не грузить, как дубликаты. В NT это вполне себе реализуемо. Правда с той оговоркой, что компиляторы пытаются подрезать текстуру на разных моделях ($cliptotexcoords), из-за чего одна и та же текстура может менять свой размер на разных моделях. Поэтому для таких текстур будет сделан дубликат. Но их не очень много.

Немного статистики для c1a0d.
Все текстуры уникальные - 653 штуки.
С дубликатами для одинаковых имён и разных размеров - 695 штук
Уникальные текстуры для каждой модели - 790 штук.
Для халфовских моделек вся экономия - 2 мегабайта памяти.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 07-11-2019 в 20:58:

Дядя Миша взвешенное сглаживание нормалей планируешь опциональным делать? Потому что если модель будет с запеченной нормалмапой, то из-за изменений нормалей нормалмапа пойдет по одному месту.

Crystallize ты как-то спрашивал на КСМе, почему в хлраде нет антиалиасинга у лайтмап, только блюр. А я ответил, что толку от антиалиасинга не будет, потому что при увеличении даже сглаженной текстуры всё равно полезут пиксели. Так вот, оказалось, что я был неправ, и можно заморочиться, чтоб лайтмапа была более-менее гладкая. Нужно пиксели интерполировать не билинейным фильтром, а, например, бикубическим. Но видеокарта в него не умеет, поэтому придётся городить огород в шейдере, и фпс немного упадёт, конечно.
Вот вроде бы самый быстрый способ:
http://www.java-gaming.org/index.php?topic=35123.0
Ожидаемый результат примерно такой:

Может, ДМа заинтересует.

Отправлено Дядя Миша 07-11-2019 в 21:57:

Цитата:

ncuxonaT писал:
взвешенное сглаживание нормалей планируешь опциональным делать?

пока вообще не знаю что с ним делать.

Цитата:

ncuxonaT писал:
Нужно пиксели интерполировать не билинейным фильтром, а, например, бикубическим.

бикубик зараза такая активно провоцирует швы. Нельзя просто взять и заменить фильтр. Надо что-то еще делать с лайтмапой.

Добавлено 08-11-2019 в 00:57:

Ну вот примерно так:

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 07-11-2019 в 22:06:

Дядя Миша добавлять бордюр в один пиксель вокруг каждого куска в атласе?

Отправлено thambs 08-11-2019 в 01:54:

>https://ndotl.files.wordpress.com/2...arvsbicubic.jpg
Красота какая.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Crystallize 08-11-2019 в 07:12:

Цитата:

ncuxonaT писал:
ты как-то спрашивал на КСМе, почему в хлраде нет антиалиасинга у лайтмап, только блюр.

Спасибо, красиво смотрится.

Цитата:

ncuxonaT писал:
Дядя Миша добавлять бордюр в один пиксель вокруг каждого куска в атласе?

Ну тогда уж смешать "до" и "после" по маске у которой крайние скажем 5 пикселей это градиент.

Добавлено 08-11-2019 в 14:12:

Я не понимаю почему билинейка такая, она же должна быть мутнее по идее.

Отправлено Дядя Миша 08-11-2019 в 07:48:

С бордюром\без бордюра. Если бы у меня что-то получилось с бикубиком, я бы его еще в параною добавил. Ему нужны сплошные непрерывные лайтмапы судя по всему, развертки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 08-11-2019 в 10:02:

Дядя Миша
А возможно в принципе поглядеть как оно выглядит на самом атласе и как туда полигоны отображаются?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 08-11-2019 в 10:08:

Цитата:

Дядя Миша писал:
С бордюром\без бордюра.

Вот эти косые фёгни на полу у стены — то, чего быть не должно?

Отправлено Дядя Миша 08-11-2019 в 10:54:

это швы

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-11-2019 в 10:56:

Откуда берутся эти тёмные швы? Там что в лайтмапе по краям тёмные пиксели которые не видны в обычной ситуации и с ними происходит блур?

Отправлено Дядя Миша 08-11-2019 в 11:00:

От бикубической фильтрации

Добавлено 08-11-2019 в 14:00:

Цитата:

thambs писал:
А возможно в принципе поглядеть как оно выглядит на самом атласе и как туда полигоны отображаются?

наверное можно, только смысл? Билинейка швов не делает, если сама лайтмапа впорядке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-11-2019 в 11:02:

Цитата:

Дядя Миша писал:
От бикубической фильтрации

с чем же нужно сфильтровать белую лайтмапу чтобы она так потемнела?

Отправлено Дядя Миша 08-11-2019 в 11:49:

Ну вот так работает бикубик. Он мне в своё время еще на звуке не понравился, ощущение было такое, что исполнителю вставили в рот валенок.
У него довольно ограниченное применение, потому его и не спешат реализовывать в железе.

Добавлено 08-11-2019 в 14:49:

вот ежели у меня руки когда-нибудь дойдут до LCSM, вот тогда и можно будет вернуться к этой теме.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 08-11-2019 в 12:44:

Подразумевалось, что бордюр будет заполнен цветом из соседнего пикселя, а не останется черным

Отправлено thambs 08-11-2019 в 13:22:

ncuxonaT
А если шов идёт по диагонали?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено ncuxonaT 08-11-2019 в 13:35:

thambs то что?

Отправлено nemyax 08-11-2019 в 14:12:

Цитата:

Дядя Миша писал:
ежели у меня руки когда-нибудь дойдут до LCSM

Делать для лайтмапы UV-развёртку брашевых фейсов? Нуниплоха наверное.

Отправлено Дядя Миша 08-11-2019 в 16:40:

Хым. Это я бордюр неправильно строил. Надо же по два пикселя брать, а я брал один. Вообще эти бордюры строить нетривиальная задачка, оч. легко запутаться. Но с бордюром, темнименее, мне уже прямо нравится. Я его окрасил в красный цвет для дебага, так вот даже уже с таким цветом - швы практически незаметны. Продолжаю эксперимент.

Добавлено 08-11-2019 в 19:32:

Всё равно швы лезут от бикубика. Правда в данном случае - на тех местах где они были изначально. Слева билинейка, справа бикубик

Тут еще надо отметить что эта версия c1a0d была скомпилена еще оригинальными вальвовскими компилерами, т.е. там полюбому швы были.
Может быть, если бы швов не было, они бы и не вылезли?

Добавлено 08-11-2019 в 19:40:

Ну вообщем серавно фигня. Вот заведомо бесшовная карта, а вот что происходит:

Спровидливозти ради стоит отметить, что это происходит далеко не везде. Может ему недостаточно бордюра в 1 пиксель? Попробую два.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 08-11-2019 в 17:03:

Дядя Миша а как ты бордюр строишь?

Отправлено Дядя Миша 08-11-2019 в 17:28:

ncuxonaT в основном - вокруг лайтмайпы. Или вквадрат, если быть точным.

Добавлено 08-11-2019 в 20:23:

Корочи даже по три пикселя бордюр даёт точно такой же эффект со швом. Спровидлизвоти ради стоит заметить что со включённой диффузкой этот шов незаметен, да и сами швы появляются далеко не везде, с бордюром-то.

Добавлено 08-11-2019 в 20:28:

Ну что тут скажешь. Есть места, где всё становится только лутьшы. Вот к примеру:

А здесь наоборот - сплошное расстройство

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 08-11-2019 в 18:15:

Дядя Миша
Эй, это же ку3дм1 из волатилы!

__________________

Отправлено Дядя Миша 08-11-2019 в 18:33:

Цитата:

XaeroX писал:
Эй, это же ку3дм1 из волатилы!

Yesлибы!

Добавлено 08-11-2019 в 21:33:

Вообщем ладно, бордюр я конечно оставлю, но эксперимент по прежнему считаю неудовлетворительным. К тому же этот фильтр жрёт фпс довольно сильно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 08-11-2019 в 19:41:

Бордюр наверное должен браться с прилегающих поверхностей

Отправлено nemyax 08-11-2019 в 19:45:

Дядя Миша
Ты ж писал, что будет одна динамика, и вдруг лайтмапы.

Отправлено Дядя Миша 08-11-2019 в 21:21:

nemyax ну выбросите лайтмапы, будет одна динамика

Добавлено 09-11-2019 в 00:21:

До сих пор разгребаю последствия полетевшего винта. Тут внезапно выяснилось, что все бэкапы паранои - тоже того, уже не являются архивами.
Ну есть конечно финальные актуальные сорцы. Но промежуточные все утеряны. Месяца за 4-5.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 08-11-2019 в 22:32:

Подтверждаю, у меня тоже швы вылазят. Теоретически я могу сделать, чтобы моя убиралка швов делала это с учетом бикубика, но тогда нужно будет хранить все куски с бордюром в 1 пиксель. Ну или сразу фикшенный атлас.

Отправлено Дядя Миша 09-11-2019 в 08:37:

Цитата:

ncuxonaT писал:
Теоретически я могу сделать, чтобы моя убиралка швов делала это с учетом бикубика

основная проблема в том, что лайтмапа это набор несвязанных кусочков. Вот и вылазит.

Добавлено 09-11-2019 в 11:34:

Заглянул в скрипты Wolf2009. По организации скриптов там смесь изд3-шных материалов и попыток сделать систему более гибкой.
Вот например так выглядит тепичный материал

Цитата:

textures/decals/pebbles_01
{
EditorImage textures/decals/pebbles_01_d
Image DiffuseMap textures/decals/pebbles_01_d
Image NormalMap textures/decals/pebbles_01_local
Image SpecularMap textures/decals/pebbles_01_s
Vector Specular 16 0 1 0
AlphaTest .1
noOverlays
VertexColor
PolygonOffset 1 1
NoTFix
Contents Nonsolid
NoShadows
nofragment
Vector DetailNormalControls 3 3 2 0
}

В ку3 было достаточно написать "map". Здесь еще требуется связать имя юнита в шейдере. Ну как бы уже не слишком наглядно.

А вот техника

Цитата:

Technique "AmbientDecalAdd"
{
Sort Depth
Pass
{
VertexShader "StandardDrawTexture"
{
Uniform vColorModulate Material::ColorModulate
Uniform vColorAdd Material::ColorAdd
Uniform vHPosBias BackEnd::HPosBias
}
FragmentShader "StandardDrawTexture"
{
Sampler ColorMap
{
Texture Material::ColorMap { _default }
MinFilter Linear
MipFilter Linear
MagFilter Linear
}
}
Blend Enable
BlendFunc One One
AlphaWrite Disable
DepthWrite Disable
}
}

Но как я понял, набор параметров везде свой. Тоже, как у меня доступ к общим переменным через ::

Вообщем я видимо самостоятельно нащупал какую-то вполне общепринятую концепцию.

Добавлено 09-11-2019 в 11:37:

Для сравнения вот моя техника

C++ Source Code:

1	technique "studioSolidLightmapPass"

3	vertShader( "glsl/forward/scene_studio_vp.glsl" );

4	fragShader( "glsl/forward/scene_studio_fp.glsl" );

6	image u_LightMap = "entity->$LightmapTexture";

7	image u_DeluxeMap = "entity->$DeluxemapTexture";

8	float u_LightStyleValues[64] = "globals->lightStyles";

9	float u_AmbientFactor = "globals->ambientFactor";

10	vec3 u_LightDiffuse = "lightProbe->color";

11	vec3 u_LightDir = "lightProbe->direction";

12	vec2 u_LightShade = "lightProbe->shadeAmbient";

13	vec3 u_AmbientCube[6] = "lightProbe->ambientCube";

15	#if MODEL_HAS_LIGHTMAP

16	#define SURFACE_LIGHTING

#endif

19	#if MODEL_HAS_VERTEXLIGHT

20	#define VERTEX_LIGHTING

#endif

23	// NOTE: TBN should be computed even bump texture is missed

24	#if MODEL_HAS_DELUXMAP

25	#define HAS_DELUXEMAP

#endif

28	#if r_fullbright

29	#define LIGHTING_FULLBRIGHT

#endif

32	#if r_lightmap == 1

33	#define LIGHTMAP_DEBUG

#endif

36	#if r_lightmap == 2 && MODEL_HAS_DELUXMAP

37	#define LIGHTVEC_DEBUG

#endif

39	#define NORMAL_RG_PARABOLOID

40	depthMask( GL_TRUE );

Правда она более широкого употребления - это шаблон для всех солидных студиомоделей. А вот шейдеробъект

C++ Source Code:

1	shaderObject "StudioModel"

3	setTechniquePass( "solid", studioSolidLightmapPass );

4	// setTechniquePass( "spot", studioSolidSpotLightPass );

5	// setTechniquePass( "omni", studioSolidOmniLightPass );

6	// setTechniquePass( "proj", studioSolidProjLightPass );

8	// declare common uniforms

9	image u_ColorMap = "globals->$WhiteTexture"; // fallback texture

10	image u_DetailMap = "materials.def->detailMap";

11	image u_NormalMap = "textures/<modelname>/<texname>_norm";

12	image u_GlossMap = "textures/<modelname>/<texname>_gloss";

13	// image u_GlowMap = "textures/<texname>_luma";

15	vec4 u_BonesArray[384] = "entity->bonesMatrix";

16	vec4 u_BoneQuaternion[128] = "entity->bonesQuaternion";

17	vec3 u_BonePosition[128] = "entity->bonesPosition";

18	vec2 u_DetailScale = "materials.def->detailScale";

19	vec2 u_TexOffset = "entity->conveyorMovement";

20	float u_Smoothness = "materials.def->smoothness";

21	vec4 u_RenderColor = "entity->renderColor";

22	mat4 u_ModelMatrix = "entity->transform";

23	vec3 u_ViewOrigin = "render->viewOrigin";

25	addImageLocation( u_ColorMap, "*<texname>" ); // embedded model texture

26	addImageLocation( u_ColorMap, "textures/<modelname>/<texname>" );

28	// add image extra info to help engine

29	setImageHint( u_ColorMap, "Albedo" );

30	setImageHint( u_NormalMap, "Normal" );

32	// add flags for image loader

33	addImageFlags( u_ColorMap, TF_SILENT_LOADING\|TF_KEEP_SRC_IF_ALPHA );

34	addImageFlags( u_NormalMap, TF_SILENT_LOADING\|TF_NORMALMAP );

  // FIXME

37	#if MODEL_NUM_BONES == 1

38	// #define MAXSTUDIOBONES 1

#endif

41	#if MODEL_HAS_BONEWEIGHTS

42	#define APPLY_BONE_WEIGHTING

#endif

45	#if r_physic_based_shading

46	#define APPLY_PBS

#endif

49	#if r_detailtextures && u_DetailMap

50	#define HAS_DETAIL

#endif

53	#if r_normal_mapping && u_NormalMap

54	#define HAS_NORMALMAP

55	#define COMPUTE_TBN

#endif

58	#if r_specular && u_GlossMap && u_Smoothness > 0

59	#define HAS_GLOSSMAP

#endif

62	#if u_GlowMap

63	#define HAS_LUMA

#endif

66	#if WORLD_HAS_GLOBALFOG

67	#define APPLY_FOG_EXP

#endif

70	#usage mod_studio

всё ли понятно по синтаксису?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 09-11-2019 в 10:18:

ncuxonaT перенести бикубическую фильтрацию в лайтмаппер, перед дядьмишиной затиралкой швов попяченой с хл2

Отправлено Дядя Миша 09-11-2019 в 11:43:

Цитата:

Crystallize писал:
перед дядьмишиной затиралкой швов попяченой с хл2

В хл2 нет никакой затиралки швов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 09-11-2019 в 12:10:

ну в сорсовском лайтмаппере тогда.

Отправлено Дядя Миша 09-11-2019 в 12:30:

ну нету в сорсе никакой затиралки швов нигде. Включи mat_showlightmaps или как оно там называется и убедись сам.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 09-11-2019 в 13:20:

Crystallize у меня есть затиралка швов, но она работает исходя из того, что потом текстура будет фильтроваться билинейно. Можно переделать для бикубика, но нужно будет как-то хранить бордюры

Отправлено SNMetamorph 09-11-2019 в 14:12:

А по поводу размерностей в UI есть какие-то идеи для движка?
Я ковырялся с этой проблемой, в итоге решил что со всем многообразием дисплеев с разными разрешениями, размерами и DPI, проще просто добавить в настройки параметр для скейла всего UI целиком. Не получилось у меня найти какого-то универсального решения.

Отправлено Дядя Миша 09-11-2019 в 14:42:

Цитата:

ncuxonaT писал:
Можно переделать для бикубика

и на билинейке швы полезут?

Добавлено 09-11-2019 в 17:42:

Цитата:

SNMetamorph писал:
Не получилось у меня найти какого-то универсального решения.

а для UI и не существует такого решения. Скейлить нельзя, всё должно попадать пиксель в пиксель для каждого разрешения.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 09-11-2019 в 15:01:

Цитата:

Дядя Миша писал:
всё должно попадать пиксель в пиксель для каждого разрешения

А ещё и это ко всему прочему. Вообще жуть какая то.

Отправлено Crystallize 09-11-2019 в 15:21:

Цитата:

Дядя Миша писал:
а для UI и не существует такого решения. Скейлить нельзя, всё должно попадать пиксель в пиксель для каждого разрешения.

Оно не попадает. Я помню как обнаружил что на GL_NEAREST и в софтваре спрайты пушек в инвентаре явно чёччче.

Отправлено ncuxonaT 09-11-2019 в 19:50:

Цитата:

Дядя Миша писал:
и на билинейке швы полезут?

полезут, конечно. Есть более дикий вариант - убирать швы непосредственно при загрузке карты, если включен бикубик. Но алгоритм нужен другой, этот слишком медленный.

Отправлено a1batross 10-11-2019 в 04:42:

SNMetamorph как вариант -- запихать спрайты в вектор и при загиузке их рендерить в нужное разрешение.

Это будет точно лучше, чем набор 320hud, 640hud из халфы и где последний рисуется "пиксель-в-пиксель" на FullHD и в итоге ничего вообще не видно, мелко.

__________________
Xash3D FWGS форк

Отправлено ncuxonaT 10-11-2019 в 12:30:

a1batross а как быстро и красиво рисовать вектор в рилтайме? Я читал про разные методы рендера шрифтов, и в заключении одной из недавних статей по этой теме было написано "Мы представили новый метод рисования векторных шрифтов, он быстрее всех предыдущих реализаций. Но в 40 раз медленнее, чем просто рисовать квад с текстурой".
На самом деле даже вектор не гарантирует, что всё четко будет. Не просто так в линуксах векторные иконки рисуют в разных разрешениях.

Отправлено XaeroX 10-11-2019 в 12:35:

ncuxonaT
Растр под макосью в режиме HDPI очень чёткий, не хуже вектора.

__________________

Отправлено ncuxonaT 10-11-2019 в 12:54:

XaeroX растр без мазни не отмасштабируешь, кернинг не сделаешь. Иными словами, шрифты - говно.

Отправлено thambs 10-11-2019 в 13:09:

ncuxonaT
Зачем в реалтайме?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено ncuxonaT 10-11-2019 в 13:25:

thambs ну а как иначе, если текст может меняться, или, например, прокручивать его нужно

Отправлено thambs 10-11-2019 в 13:50:

ncuxonaT
Так вроде-то задача не рендерить postscript-страничку, а заменить растровый шрифт фиксированного размера. Сменил разрешение -- закешировал рендеры шрифтов/иконок. Тот же растр остался, только генеришь его по необходимости из векторного исходника.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено ncuxonaT 10-11-2019 в 14:12:

thambs если потом рендерить растр пиксель в пиксель, то не получится сделать кернинг, плюс из-за округления расстояние между буквами будет не таким, каким должно быть. Если рендерить растр не пиксель в пиксель, то получится мазня.

Отправлено a1batross 10-11-2019 в 18:29:

ncuxonaT а зачем? Отрисовал в атлас и вперёд. Ну, хочется играть с масштабом -- есть SDF. Неидеально, но наврядли кто-то заметит разницу.

Вон у меня в mainui_cpp шрифторендер в атлас рисует и никогда больше не трогает шрифты. Пока конечно юзер не ресайзнул окно, лол.

Цитата:

Не просто так в линуксах векторные иконки рисуют в разных разрешениях.

O_o ЩИТО

Ты точно уверен что это вектор?

__________________
Xash3D FWGS форк

Отправлено ncuxonaT 10-11-2019 в 18:59:

a1batross как с атласом делать кернинг?

В атласе ширина глифов целочисленная или с плавающей точкой?

Цитата:

a1batross писал:
Ты точно уверен что это вектор?

Йеп, svg же. Открой любую тему, там будут папки 16х16, 32х32 и так далее с иконками соответствующих размеров.

Отправлено FreeSlave 10-11-2019 в 22:01:

Цитата:

ncuxonaT писал:
Йеп, svg же. Открой любую тему, там будут папки 16х16, 32х32 и так далее с иконками соответствующих размеров.

В этих папках лежат png. Ими пользуются приложения, которые не поддерживают svg. Это часть спецификации http://standards.freedesktop.org/ic...pec-latest.html и к теме не имеет отношения.

__________________
I'm on github
I'm on opendesktop.org

Отправлено ncuxonaT 10-11-2019 в 22:22:

FreeSlave только вот в большинстве тем там лежат именно svg.
стандартные КДЕшные иконки:
https://github.com/KDE/breeze-icons...er/icons/places
бывшие стандартные убунтушные иконки:
https://git.launchpad.net/ubuntu/+s.../Humanity/mimes

Отправлено a1batross 10-11-2019 в 22:57:

ncuxonaT

Цитата:

В атласе ширина глифов целочисленная или с плавающей точкой?

А атлас тут ни при чём. ВООБЩЕ.

1
2

Атлас в формате L8A8, поэтому я могу просто рисовать глифы поверх друг друга, сдвигая на определенное количество пикселей.
На второй пикче видно сам атлас. Красные линии -- bbox, зелёные -- отступы для керинга. Естественно на самой текстуре они не присуствуют, просто довольно удобно смотреть что же мне там выдал FreeType, stb_truetype или WinAPI.

(а ещё на первой картинке баг с порядком отрисовки, букву g сожрало

)

Цитата:

Открой любую тему, там будут папки 16х16, 32х32 и так далее с иконками соответствующих размеров.

Да, кстати, это вообще-то стандарт Freedesktop. Многое вообще симлинками, поэтому это фактически один и тот же файл.

Но я открыл случайный user-trash.svg и 16x16 и 64x64 -- это две разные картинки. Ну, они в разной детализации для разных задач. Одна в GUI на кнопке нарисуется, вторая в файл менеджере в качестве иконки папки.

__________________
Xash3D FWGS форк

Отправлено ncuxonaT 11-11-2019 в 00:15:

a1batross а неплохо. Но это атлас нужно рисовать в 2 раза больше, чем текст потом? То, что ты показываешь, - это не кернинг. Вот кернинг: https://ru.wikipedia.org/wiki/%D0%9...%B8%D0%BD%D0%B3

Цитата:

a1batross писал:
Но я открыл случайный user-trash.svg и 16x16 и 64x64

А ты открой 32х32 и 64х64 или 64х64 и 128х128. Картинки будут те же, но поправленные, чтобы всё попадало пиксель в пиксель. Да даже 16х16 и 22х22.

Отправлено a1batross 11-11-2019 в 01:55:

ncuxonaT
>Но это атлас нужно рисовать в 2 раза больше, чем текст потом?

Моя ошибка, на второй картинке -- атлас "большого" шрифта, он редко используется пока что. В основном используется "средний" или "мелкий". Их размеры высчитываются относительно высоты окна.

На самом деле конечно не нужно.

>То, что ты показываешь, - это не кернинг. Вот кернинг:

И в чём потенциальная разница? Ну, я не специалист в типографии, но по-моему мы говорим об одном и том же.
Видишь у меня буквы не разъезжаются, а вот ра-ааньше они разъезжались!

Конечно, всё это автоматически, ничего вручную я не расставлял, только по информации которая доступна в самом TTF файлике.

> А ты открой 32х32 и 64х64 или 64х64 и 128х128. Картинки будут те же, но поправленные, чтобы всё попадало пиксель в пиксель. Да даже 16х16 и 22х22.

Я открыл 128 и 512 иконку LibreOffice. Действительно, 512x512 выглядит лучше, чем 128x128 увеличенный до 512x512. Screenshot.
Но если приглядеться, видно, что в 128x128 убрана детализация, которую никто не увидит в таком разрешении.

В 256 уже, как ты и сказал, попадание пиксель-в-пиксель. Screenshot

Но как это соприксается с моим предложением вообще использовать вектора в HUD? Если у тебя векторная иконка пушки X в 4K будет выглядеть хуже, чем на HD, ты сделаешь отдельную версию для 4К, которая визуально будет приятнее. Но тем не менее, внутренний перфекционист игрока не будет ущемлён из-за того, что ты не подумал о, например, 1680x1050. А если в твою игру поиграет человек через 20 лет с монитором в 16K? Что ему делать, наслаждаться мылом или маленькими иконками?

У самого несколько месяцев назад был 1680x1050 и в некоторых случаях игры не догадывались брать 1080p HUD и брали 720p и была в основном просто мелкота. К счастью, никому мылить HUD в голову не приходит.

Особо богатые буратины на ютубах выкладывают записи игр в 8K, 16K разрешениях. Открыл случайное, GTA 4 в 8K выглядит хорошо. В Half-Life 2 он HUD не показал, но текст очень мелкий. Несмотря на то, что там TTF. Наверное правится в конфигах, не так критично если был бы битмапный.

__________________
Xash3D FWGS форк

Отправлено Crystallize 11-11-2019 в 02:21:

Цитата:

Дядя Миша писал:
ну нету в сорсе никакой затиралки швов нигде. Включи mat_showlightmaps или как оно там называется и убедись сам.

На КСМ ты говорил что затиралку китайца работающую в 3D ты не будешь брать как жрущую память и время но у тебя есть своя которая работает в 2D и она основана на аналогичных механизмах из Сорса. Это было или у меня Мандела?

Отправлено ncuxonaT 11-11-2019 в 21:47:

Можно наш трёп про шрифты и интерфейсы в отдельную тему перенести, чтобы тут на засорять? Спасибо.

a1batross ты шрифт из атласа рисуешь на экране 1:1 или масштабируешь тоже? Размер квадов и их координаты попадают в экранные пиксели? Отступы и размеры глифов в атласе в целых пикселях или как-то иначе?

Цитата:

a1batross писал:
И в чём потенциальная разница? Ну, я не специалист в типографии, но по-моему мы говорим об одном и том же.

Кернинг это вроде дополнения к твоим отступам. В силу внешнего вида некоторых символов, если ставить их подряд, будут образовываться дыры, слова будут разваливаться, нужна коррекция. Поэтому в шрифтах записаны кернинговые пары и значения, на сколько нужно сдвинуть второй символ в паре. Например, между Т и А будет большая дыра без кернинга, поэтому в шрифте записано что-то вроде ТА -120, соответственно, А сдвигается влево на 120 единиц.

Цитата:

a1batross писал:
Но как это соприксается с моим предложением вообще использовать вектора в HUD?

Просто хотел сказать, что это не серебряная пуля

Отправлено FiEctro 11-11-2019 в 22:14:

Вы не видите самого главного, всё это битмаповое гамно должен кто то рисовать. Для всех модов. А шрифтов хоть жопой жуй, качай нихачу. Зачем каждый раз возиться в фотошопе, если это можно реализовать программно вектором?

Отправлено a1batross 11-11-2019 в 23:12:

ncuxonaT > Просто хотел сказать, что это не серебряная пуля

Серебрянных пуль вообще не существует. Разве что не делать HUD вообще.

Если задача сократить себе работу на поддержке разных разрешений, можно вообще сделать его трёхмерным и тогда никакой речи о pixel perfect идти не будет. Это кстати популярно нынче.

Но я предлагаю решение для классического двухмерного HUD, который обязан выглядеть хорошо.

>ты шрифт из атласа рисуешь на экране 1:1 или масштабируешь тоже

1:1.

Масштабируется он только там, где отрисовать шрифт заново -- слишком дорого. Например, на мобильниках. Но там и ресайз окна -- задача нетипичная, на Android законным методом это можно делать только в последних версиях и этим никто не пользуется, особенно в активных играх.

>Кернинг это вроде дополнения к твоим отступам

Нет, такой вещи у меня нет. Но может когда-нибудь будет. Сейчас в шрифторенедере мне сильно нехватает дорисовки новых символов в атлас, просто MenuAPI Ксаша это не учитывает. А так будет -- и можно по запросу объединять символы и вообще хоть на арабском писать, просто атлас-текстура будет деномически расширяться.

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 12-11-2019 в 08:44:

Цитата:

Crystallize писал:
На КСМ ты говорил что затиралку китайца работающую в 3D ты не будешь брать как жрущую память и время но у тебя есть своя которая работает в 2D и она основана на аналогичных механизмах из Сорса.

Вообще всё напутал. У Китайца - не затиралка. У Китайца - наоборот, механизм не допускающий появления швов (по возможности), за счёт конвертирования текстурного пространства одного сурфейса в другое. Это делается при помощи расстановки маркеров-точек на границах полигона, что напоминает один из шагов алгоритма по затиранию швов, но таковым не является. То что в сорсе - это радиальный блур для индиректа, швы он не затирает, ну может немного замаскировать конечно, как и любой другой блур. Это можно посмотреть и в самом сорсе - там швы никуда не делись.
Я этот радиальный блур убрал впоследствии, т.к. толку от него немного. Но да, он быстрый.

Добавлено 12-11-2019 в 11:40:

Цитата:

FiEctro писал:
всё это битмаповое гамно должен кто то рисовать

Генератор фонтов из TTF.

Добавлено 12-11-2019 в 11:44:

Чтобы не было швов, надо использовать непрерывный атлас где смежные рёбра в 3д являются таковыми и в самом атласе, понятно, что это условие невозможно выполнить в 100% случае, но для углов свыше 50 градусов это и ненужно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-11-2019 в 08:48:

>> Генератор фонтов из TTF.

Ну найди для первокваки например такой.

Отправлено Дядя Миша 12-11-2019 в 20:31:

Ну вот, теперь и спрайты рисуются

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 12-11-2019 в 20:53:

Дядя Миша
Полноцветные?

Отправлено Crystallize 13-11-2019 в 03:08:

nemyax Ишь!

Отправлено Дядя Миша 13-11-2019 в 09:33:

nemyax обычные. Форматы менять - хаммер не поймет, как работать будете? Тут нужны предварительные договорённости.

Добавлено 13-11-2019 в 12:31:

Мне еще предстоить сделать mod_skybox, mod_grass и mod_particle.
Формировать какие-то списки отрисовки для каждого типа примитивов бессмысленно - их же рендерер в кадре сортирует. Поэтому абстракция должна выглядеть так. С лучами аналогично, но лучи станут частью mod_sprite.

Добавлено 13-11-2019 в 12:32:

А mod_skybox скорее всего будет отвечать за погоду, ну там дождь, снег, облака, время суток.

Добавлено 13-11-2019 в 12:33:

Самое сложное избавиться от долбаных рендермодов в движке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-11-2019 в 09:35:

Цитата:

Дядя Миша писал:
как работать будете?

Будем вешать модельку-плашку на резвый танк =)

Отправлено Дядя Миша 13-11-2019 в 09:59:

Вообще говоря реальных рендермодов, если продолжать и дальше такое деление, существует две штуки на каждый из режимов рендеринга геометрии. А режимы рендеринга геометрии понятно какие - непрозрачные и прозрачные. Так вот вариации на тему - это соответственно с освещением и без. В эти четыре кейса укладывается абсолютно любой запрос, ну кроме может быть этих старых фейковых гларесов, которые светили сквозь геометрию, но они это делали скорее неотхорошей жизни, а из-за того что шейдеров не было.

Добавлено 13-11-2019 в 12:42:

Теперь что касается смены одного рендермода на другой. Хотя в халфе и подразумевается возможность поменять любой на любой, но в реальности это никто не пользует, просто нет смысла. Вся замена это - прозрачный на непрозрачный и наоборот. Ну и опционально - включение фуллбрайта, но для солидных мешей в халфе это нереализуемо попросту. Там делали два меша, один фуллбрайт, другой нормально освщённый и меняли один на другой с помощью прозрачности.

Добавлено 13-11-2019 в 12:52:

Здесь thambs неявно опять поднял проблему скриптового языка, для описания энтить, но у меня признаться нет каких-то особых идей на этот счёт. Понимаете, все эти скрипты отлично работают на картах квейк-стайл, когда ты уровень прошёл и всё, больше туда не возвращаешься. Но на халфовских сейв-ресторах, когда ты можешь бесконечно нарезать круги по одним и тем же локациям, это вызывает массу вопросов. Во первых эти сами скрипты, они запускаются как в hlfx из какой-то энтити типо script_lua или из файлика с именем карты?
А если они дают эффект на энтить, которая может перемещаться на другой уровень вслед за игроком? Я напоминю, НИГДЕ я не видел, чтобы можно было брать с собой энтити с одного уровня на другой явным образом. Нигде.
Только неявным, через инвентарь. Или по скрипту, что фейк. Но вот так, чтобы игрок какого-то перса тыкнул, мол пойдем со мной и провёл его через всю игру - этого нет нигде. И это очень осложняет подключение внешних скриптов. Если скрипты пишутся для конкретной карты, как понять, что их исполнение нужно забрать на следующую карту? Если скрипт написан для какой-то энтити, как корректно перенести его состояние вместе с этой энтитью? Это практически неразрешимая задача. Я собсно, потому и не спешу внедрять какие-то скрипты, а пытаюсь всё описать внутри самиъ энтить. Но если у вас есть какие-то идеи концепции, то я вас слушаю.

Добавлено 13-11-2019 в 12:55:

Когда логическая энтить образует какую-то скриптовую конструкцию, мы можем её просто пометить, что она должна переходить на другой уровень.
Но в рамках скриптового языка мы не можем, написать, что вот эти функции должны, например работать где-то еще причём с переменными с этой же карты, потому что возникнет неизбежный вопрос, откуда брать эти сами переменные? С энтить? Тогда в чём вообще смысл скрипта? Из какого-то глобального пространства? Тогда как определить что они не пойдут на следующий уровень?

Добавлено 13-11-2019 в 12:59:

У меня еще был вариант, в скриптах описать сами энтити, например реализующие сложные логические условия, но и тут не всё гладко. У скриптов не будет полноценного доступа к настоящим энтитям. И наоборот тоже не очень понятно. Скорее всего они смогут выполнять только простейшие действия, типо активации цели, сеторигин и так далее. Выход из положения напрашивается сам собой - надо как в ку1 сделать виртуальную машинку подо все энтити. Но и тут проблема - как прикажете рассчёт костей делать? Тоже в куси? А поиск навигации для монстров, шедули эти все? Неподъемно для виртуалки, слишком тяжело.
Не знаю вообщем.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 13-11-2019 в 10:01:

Дядя Миша
Соображения есть, но пока не готов расписать, нужно ещё продумать всё. Сначала вопросы:
1. Есть ли в игре возможность явного доступа на чтение к полям энтити, например к таргетнэйму, ориджину и пр.?
2. Если ли возможность явного доступа к полям на запись, если есть, то как они защищены/не защищены?
3. В каком виде сервер сохраняет состояние энтить, как она сериализуется?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 13-11-2019 в 10:06:

Плюс если делать виртуалку, там придётся учитывать наследование классов, для того чтобы, оно отвечало текущей иерархии дллки, которая оптимизирует эти классы под новую структуру движка. Ну скажем, студиомодельки теперь работают только из класса CBaseAnimating, потому что это единственный класс, который занимается сетапом костей.

Добавлено 13-11-2019 в 13:06:

Цитата:

thambs писал:
Соображения есть, но пока не готов расписать, нужно ещё продумать всё. Сначала вопросы:
1. Есть ли в игре возможность явного доступа на чтение к полям энтити, например к таргетнэйму, ориджину и пр.?
2. Если ли возможность явного доступа к полям на запись, если есть, то как они защищены/не защищены?
3. В каком виде сервер сохраняет состояние энтить, как она сериализуется?

1. Что значит в игре? Ну очевидно у игрового движка в целом (ядро+геймкод), если полномочия модицифировать абсолютно всё по своему усмотрению, я ж говорю, что даже новое бсп-дерево налету строю при загрузке. Таргетнеймы никто не модифицирует, просто потому что в этом нет смысла, а не потому что нет доступа.

2. опять не понял. Что значит "поля" ? Куда их записать? В энтпатч?

3. Хм. https://www.hlfx.ru/forum/showthrea...=&threadid=3394

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-11-2019 в 11:29:

Дядя Миша
Насколько я понимаю, скриптинг обычно реализуют именно в виртуальной машинке и на основе отправки-приёма ивентов между скриптованными сущностями.

Цитата:

Дядя Миша писал:
эти сами скрипты, они запускаются как в hlfx из какой-то энтити типо script_lua или из файлика с именем карты?

Например, имя скрипта может быть указано для энтити в поле script, а сам скрипт с этим именем быть определён в игровых файлах.

Цитата:

Дядя Миша писал:
Если скрипты пишутся для конкретной карты, как понять, что их исполнение нужно забрать на следующую карту?

При инициализации на карте скрипт может гетать своих действующих лиц по имени и дальше работать с ними, если всех нашёл.

Отправлено Дядя Миша 13-11-2019 в 11:38:

Цитата:

nemyax писал:
на основе отправки-приёма ивентов между скриптованными сущностями.

ивенты - это вызов целей на карте, это и так есть безо всякой скрипт-машины.

Цитата:

nemyax писал:
имя скрипта может быть указано для энтити в поле script

и сам скрипт в скомпилированном виде тоже перемещать между уровнями? Со всеми стейтами?

Добавлено 13-11-2019 в 14:38:

В D3 кстати так и сделано, там скрипты даже положение стека запоминают.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-11-2019 в 12:00:

Вызов цели это всего лишь одна разновидность ивента. Бывают и другие. Взять те же префиксы, которые через задницу реализуют кокрастоке разные типы ивентов.
И да, без скрипта ты не запрограммируешь обработку принятого ивента.

Отправлено Дядя Миша 13-11-2019 в 12:18:

Скриптовой язык, это ведь не только операции, это еще и переменные.
Переменные через энтити конечно тоже доступны - env_local, env_global, но пока их немного, и они в сущности практически булевы. В скриптах же так не получится, надо как-то придётся указать, что вот эти переменные относятся к той или иной энтите, которая потом потенциально уедет на новый уровень. То есть либо эти скрипты так задавить ограничениями, что они не будут особо отличаться от скриптования энтитями, либо одно из двух.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-11-2019 в 12:25:

Цитата:

Дядя Миша писал:
Переменные через энтити конечно тоже доступны - env_local, env_global, но пока их немного

Что за переменные? Их можно натолкать свойствами в отдельную энтить, переходящую между уровнями и доступную скриптам для чтения-записи?

Отправлено Дядя Миша 13-11-2019 в 12:26:

Кстати говоря, в халфе када лепили свою скрипт-систему это отлично понимали, поэтому она у них умеет только групповой вызов целей, скрин-фейд, ну и прогрывание сентенций. Никаких переменных там и близко нету.

Добавлено 13-11-2019 в 15:26:

Цитата:

nemyax писал:
Что за переменные?

да я почём знаю. Но язык без переменных, это уже и не язык вовсе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-11-2019 в 12:41:

Цитата:

Дядя Миша писал:
Но язык без переменных, это уже и не язык вовсе.

Пусть в скрипте и определяются. Ну там я не знаю:

code:
class mcguffin
{
  entity target1;
  entity target2;
  void on_init(void);
  void on_kill(void);
};

void mcguffin::on_init()
{
  target1 = entities.get("entity14");
  target2 = entities.get("entity88");
}

void mcguffin::on_kill()
{
  events.kill(target1);
  events.kill(target2);
  die();
}

Отправлено XaeroX 13-11-2019 в 12:56:

Я думаю, что скриптовым языком в ксаше просто обязан стать Haskell.
Представьте себе, какое удовольствие будут получать мапперы, когда смогут реализовать сложнейшую функциональную взаимосвязь всего несколькими строчками и без переменных.

__________________

Отправлено Дядя Миша 13-11-2019 в 13:01:

nemyax то что ты привёл - это скрипт над объектами.

Добавлено 13-11-2019 в 16:01:

Цитата:

XaeroX писал:
обязан стать Haskell

Да нет не ко-кова Хаскеля

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 13-11-2019 в 13:02:

Дядя Миша
Есть, есть.

__________________

Отправлено nemyax 13-11-2019 в 13:04:

Цитата:

Дядя Миша писал:
то что ты привёл - это скрипт над объектами

А над чем надо?

Отправлено Дядя Миша 13-11-2019 в 13:08:

nemyax ну, как продолжение самих объектов, например.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-11-2019 в 13:30:

Дядя Миша
Я имел в виду, что этот скрипт можно связать с любой энтитью, и у неё появится этот конкретный обработчик ивента kill. При kill-е любой такой энтити она поведёт себя так, как определено в скрипте. А например on_use здесь не определено, поэтому на use она реагировать не будет.

Добавлено 13-11-2019 в 16:30:

Либо пусть запускает дефолтную реакцию энтити на ивент, если обработчик не определён. А чтобы отключить реакцию, явно прописывать в классе void on_hurt(float) {} или void on_hide(void) {return;}.

Отправлено Дядя Миша 13-11-2019 в 14:25:

Если просто ограничить скрипты вызовом эвентов, ну просто разгрузить карту от нагромождения логических энтить, то какой-то смысл в этом есть. Ну, послушаем, что Тхамбс предложит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 13-11-2019 в 15:36:

Я не вкуриваю почему нельзя пропарсить все карты мода и отслеживать все инкарнации одной и той же энтити на разных картах и отслеживать все её исчезания и появления на картах которые происходят когда игрок утащил энтитю с карты через одну дверь и потом притащил с другой карты через другую дверь.

Отправлено Дядя Миша 13-11-2019 в 16:55:

Crystallize какое отношение твои слова имеют к скриптам?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-11-2019 в 16:56:

Crystallize
При чём тут карты мода? Они лежат себе и не меняются.

Отправлено Дядя Миша 13-11-2019 в 20:25:

Это всё хорошо, но вот и настала пора для моих любимых экспериментоф.
Как вы помните я уже много всего опробовал, оттестировал, но кое-что еще у меня осталось в запасе. Специально для NT оставил, т.к. на старом ксаше такое было затруднительно тестировать. Я конечно апробую еще некоторые технологии в графике, но навряд ли это займет много времени, сейчас механизмы рендеринга максимально благоприятствуют экспериментам. А вот из отложенных про запас у нас остался извечный спор с Камрадом Ксероксом - так ли уж плох или хорош BSP46, в народе известный как ку3бсп. Ксерокс считает что формат годится для современных задач, надо только добавить в него лайтстили и еще пару мелочей. Я в свою очередь наоборот полагаю, что с учётом всего, что я сделал для развития халфовского формата карт, актуальность кутришного бсп под большим вопросом. Под кутришным бсп я разумею принцип построения дерева и хранения данных, бинарная совместимость особой роли не играет.
Впрочем моё исследование предполагается достаточно обширным, в качестве побочного эффекта, я наверное даже напишу новые компиляторы уровней для ку3. Собсно, я их еще в прошлом году писать начал, но пока остановил процесс. Наверное заведу под них отдельную тему.

Добавлено 13-11-2019 в 23:25:

Тема про компиляторы тут: https://hlfx.ru/forum/showthread.php?s=&threadid=5398

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 13-11-2019 в 20:58:

По каким критериям будет оцениваться плохость или хорошесть BSP46?

Отправлено Дядя Миша 14-11-2019 в 07:54:

Скорее пригодность для моих задач. Тут и так не очень простая ситуация - я уже могу в халфовский формат скомпилить любую кутришную карту.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 14-11-2019 в 21:41:

Загрузил лайтмапы. В ку3 там уже и так страницы атласа, но мелкие 128х128. Неудобно. Я придумал оригинальную абстракцию - представил страницы лайтмап как будто сурфейсы с лайтмапами 128х128 и загрузил их как эти сурфейсы. Ну чтобы не переделывать лайтмаппер под новый принцип. Надо только придумать как на вертексах сдвинуть оффсет st. ну то решаемая задача, в куфужене чот такое делают. Как же давно я в посл. раз загружал кутришные карты. в 2009-м году.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 15-11-2019 в 08:52:

Сколько же дури в этом кутри. Вот скажем взять эти патчи. Вот зачем их налиту строить во время загрузки? Почему нельзя было просто сохранить в карту? Опять же непонятно, как считается лайтмапа для такой текучей конструкции с переменной детализацией. Патчи, это абстракция, которая вообще не должна покидать компиляторы. Её взяли и засунули в рендерер. Ради автолодов, понятно. Вы помните эти автолоды? Трубу сделаешь, отошёл на пять шагов, она восьмиугольной стала. Зашибись оптимизация.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 15-11-2019 в 09:50:

Цитата:

Дядя Миша писал:
Сколько же дури в этом кутри. Вот скажем взять эти патчи. Вот зачем их налиту строить во время загрузки? Почему нельзя было просто сохранить в карту?

А как пидорасы по трубам лазить будут?

Отправлено XaeroX 15-11-2019 в 10:56:

Дядя Миша просто не умеет работать с патчами.
В PW, кстати, они активно используются, и не только для труб, но и для геометрии уровня. Вот и скажете потом, сильно ли смена лодов бросается в глаза на патчах. По-моему, на моделях - сильнее, если присматриваться.

__________________

Отправлено Дядя Миша 15-11-2019 в 11:22:

FiEctro ДА НЕ КАК

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 15-11-2019 в 15:26:

Цитата:

Дядя Миша писал:
Не гадить, а подготавливать особенным образом. Тот же кутри лишён CSG, там вся внутренняя хрень, которая исчезает при препроцессинге, здесь радостно остаётся. И для нее тоже считается лайтмапа. На иных картах залетишь вот так в стенку, а внутри - еще одна стенка и на ней лайтмапа посчитана. Конечно это лучше. Щас во всех играх такое.

А можно сохранить только ту часть механизма CSG которая про отрезание пересекающихся брашей, выкинув дальнейшее разбиение-склеивание?

Отправлено Дядя Миша 15-11-2019 в 16:00:

Цитата:

Crystallize писал:
только ту часть механизма CSG которая про отрезание пересекающихся брашей, выкинув дальнейшее разбиение-склеивание?

так это и есть одна операция. В q3map2 действительно попытались сделать, на полшышечки, ну вроде как ты себе нафантазировал, оно и не резало и не склеивало, так, только время отымало.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 18-11-2019 в 19:35:

Первые опыты. Чё, его так плющит, понять не могу. Наверное индексы где-то напутал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 18-11-2019 в 19:54:

Вторые опыты. Теперь надо патчи нагенерить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 18-11-2019 в 23:45:

Мысли по поводу скриптовой системы #1: возможная структура и юзкейсы

Цитата:

послушаем, что Тхамбс предложит.

Буду исходить из того, что скриптовая система не должна заменять или ломать существующий набор сущностей, а призвана скорее её дополнить и расширить, сделав более гибкой. Вообще-то говоря, сущности — довольно удобная штука и в 90% (условно) игровых механик какие-то дополнительные движения не требуются. Проблемы же начинаются тогда, когда из этих сущностей приходится городить сложные цепочки, вводить "логические энтити" и пр чертовщину. По моему опыту, использование более чем 5 сущностей в одном механизме создаёт путанницу, и чем дальше тем хуже. Особенно неудобно бывает, когда одна и та же цепочка сущностей используется в разных местах карты — приходится вручную переименовывать ключи, что тоже приводит ошибкам. Отчасти, это решается с помощью пре-процессинга .map-файла, но это не то что бы сильно универсальное решение, да и к тому же не избавляет от необходимости писать эти цепочки в .ent-файле, который остаётся сильно многословным в сравнении с той же функциональностью, выраженной на любом императивном яп.

О зле. На мой взгляд, основной источник зла — это т.н. "логические энтити", а точнее черезмерное их использование. Игровая логика в doom или quake была довольно проста: расставил монстров, связал кнопку с дверью, а дверь с ключ-картой, триггер — с ловушкой, и готово. Более комплексные игровые механики привели к разрастанию и непомерному усложнению всей системы. И самая пакость связана с тем, что, помимо сложности, система стала фактически "write only" — из-за того что при редактировании работаешь с одной энтитей за раз, то отладка/изменение сценария напоминает работу с древним БАСИКом — тем самым, в котором строки нумеровались цифрами, и редактор позволял работать только с одной строкой. А ведь, зачастую, эти самые сущности на карте расположены в разных местах и совершенно не обязательно как-то логически упорядочены.

О команде fire. Кстати, ещё в sauerbraten видел интересную штуку, оно конечно только proof of concept, для реальных применений не годится, но тем не менее. Ведь там совсем небыло энтить, а для манипуляции игровой логики был внутренний скриптовый язык. Причём скрипты на нём могли быть как во внешних файлах, подключаемых к карте, так и вызываться непосредственно из консоли, с такими же результатами. Мне это напомнило команду fire из спирита/ксаша в связке с trigger_command и те совершенно невозможные штуки, которые с помощью них делал доктортресни. Одного fire, конечно маловато.

О интерфейсе.Команда fire и поле target, фактически, позволяют передать некоторые параметры/сигналы сущности, но с большими ограничениями. Ещё есть changetarget, changeparent, env_render и всё, собственно. Что бы наблюдать за состоянием энтить — multi_watcher, но ему тоже доступен весьма ограниченный набор параметров. Наверное, имело бы смысл некоторое универсальное API, позволяющее передавать и получать от энтить любые допустимые параметры и проводить с ними операции. Не ломая существующую систему, можно было бы, например, ввести вызовы:

C++ Source Code:

$set(*entity, key, value) -> status

$get(*entity, key) -> value

$find(*world, mask) -> [*entity]

Из названий понятно: $set — установить пару ключ-значение для сущности
*entity; вернуть статус или неудачу, $get — получить значение, $find — сформировать список указателей на сущности с именем/класснеймом таким-то маске или значению, а world -- указатель на текущую карту. Сами функции, естественно, не содержат внутренних состояний.
Предположим, теперь, что у нас есть какой-то механизм сохранения состояний и обычные языковые конструкции. Добавим функцию асинхронной задержки:

C++ Source Code:

$sleep(time)

Тогда эти 4-вызова, тогда позволяют полностью заменить мульти_манаджеры/вотчеры, реле, энв_рендеры и пр. Возможные примеры использования дам дальше, пока о памяти.

При работе с памятью видится несколько кейсов. Предполагается, что скрипт может быть или глобальным (в масштабах карты), или связанным с какой-либо сущностью. При этом, у последней получается свой локальный нэймспейс. Так-как хочется работать с чистыми функциями и использовать обычную систему сохранений, то хранить какие-то состояния наверное лучше всего было-бы в каком ни будь специальном поле внутри самой сущности. Но я, к сожалению, так и не разбирался как у тебя сериализация устроена, возможно-ли туда затолкать полиморфный, изменяемый объект? И, если в функции есть вызовы $sleep, то, видимо нужно будет сохранять весь её стек...

Что же касается низкоуровнего выделения/освобождения, то наверное, самым разумным было-бы использовать RAII: выделяем память под переменную в том случае, если она синтаксически связалась с литералом, освобождаем (по мере необходимости) как литерал вышел из поля видимости. Например, пустой вызов:

C++ Source Code:

$find(*world, "func_door:storage*")

Не делает ничего,

C++ Source Code:

lst = $find(*world, "func_door:storage*")

связывает литерал lst с результатом вызова и храним его пока он в области видимости, или пока не вызвали какой ни будь $del(lst). При этом, соответственно, синтаксис не должен позволять существование несвязанного литерала, а если литералу присвоено новое значение, то старое удаляется.

Вызовы. Есть ещё момент, когда нужно вызвать скрипт автоматически, по наступлении определённых условий. Наверное, тут было-бы удобно тогда добавить внешний обработчкик. Например, указать в корне скрипта

C++ Source Code:

1	//следим за условиями

watch(){

3	if cond1 { ... }

4	if cond2 { ... }

Общая структура. Таким образом, вырисовывается какая-то такая структура скрипта:

C++ Source Code:

1	/* определяем сохраняемые поля */

2	@static var1 = ...

3	@static var2 = ...

4	/* определяем обработчики */

5	spawn(...)

6	watch(...)

call(...)

8	/* определяем всякие вспомогательные функции */

...

Юзкейс: поезд с колёсиками. Есть, например, префаб фанк_трейна, к нему приделаны колёсики, env_shake, фонарики, убивалки. Хочется, что бы колёсики синхронно вращались и частота тряски менялась в зависимости от скорости, фонарики красные зажигались на заднем ходу, дым там из трубы ну и всё такое. Пишем у поезда в строке скрипт имя скрипта а в самом нём что-то такое:

C++ Source Code:

1	@static wheels = $find(world, $get(this, "targetname")+"_wheels")

2	@const radius = 6

watch(){

4	v_old = $get(*this, "v_old");

5	v_new = $get(*this, "v_new")

6	if v_old neq v_new{

7	for( wheel : wheels){

8	$set(*wheel, "speed", v_new/radius)

Юзкейс: универсальная станция для поезда с дверкой. Поезд активирует скрипт станции, а станция узнаёт имя поезда, имя дверки, открывает её, закрывает e`, вносит поправки в расписание и пр.

Юзкейс: управление персоналом. Есть, например, некоторая зона, на которой расставлены scripted_sequence и бегают доктора. Хочется создать иллюзию жизни на этой локации. Каждая скриптед секвенция по завершению вызывает наш скрипт и передаёт локус доктора. Внутри выбираем что ему делать, куда идти и пр.

Юзкейс: диалоги. Цепочки из диалогов та ещё беда. По хорошему, всё это бы просто в команду $speak(*actor, *target, SENTENCE, time). Делаем какие угодно цепочки с каким угодно ветвлениями и рандомами, диалоговый скрипт можно привязать непосредственно к персонажу тем самым делая его уникальным.

Добавлено 19-11-2019 в 02:45:

Хм, да, сейчас понял, что семантика $find небезопасна, т.к. может возникнуть ситуация, когда в сохранении указатели на уже удалённые сущности. Значит этот момент надо по другому.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 19-11-2019 в 07:51:

Цитата:

thambs писал:
отладка/изменение сценария напоминает работу с древним БАСИКом

Да, это точное сравнение.

Цитата:

thambs писал:
когда в сохранении указатели на уже удалённые сущности.

ну это решено еще Вальвой. Нет такой проблемы.

Синтаксис конечно будет си-подобный, но основную мысль я понял - чтобы колёсики в такт тряслись поезду. Только вот поезд "перейдет" на другую карту, а как он там найдет этот скрипт?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 19-11-2019 в 09:29:

Дядя Миша
Ну основная идея что скрипт намертво привязывается к сущности. Т.е. у неё есть, например, поле script, в котором ссылка на текстовик, который читаем при загрузке карты, и есть какое-то скрытое поле, хранящее стек скрипта. Соответственно, паровозик переходит с карты на карту вместе со всей своей требухой что в скрипте насчиталась.

ps: я ещё обдумываю семантику и возможные варианты.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Crystallize 19-11-2019 в 10:17:

Цитата:

thambs писал:
Более комплексные игровые механики привели к разрастанию и непомерному усложнению всей системы.

И никто не смог её в полной мере заюзать кроме автора T.E.A. и нашего Доктора.

Цитата:

thambs писал:
то отладка/изменение сценария напоминает работу с древним БАСИКом

БАСИК должно быть даже удобнее чем энтити.

Цитата:

thambs писал:
$set(*entity, key, value) -> status
$get(*entity, key) -> value
$find(*world, mask) -> [*entity]

Тебе комфортно набивать все эти доллары и аст-ириски?

Отправлено thambs 19-11-2019 в 10:22:

Crystallize
Плевать на синтаксис, ДМ сделает как считает нужно. Давайте лучше семантику обсуждать.

Цитата:

кроме автора T.E.A. и нашего Доктора

Автор HC2 ещё, он правда совсем маньяк, но в основном использовал env_render -- следовал за авторами блю-шифта.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 19-11-2019 в 11:29:

Цитата:

Crystallize писал:
Тебе комфортно набивать все эти доллары и аст-ириски?

Всем похапешникам комфортно.

__________________

Отправлено FiEctro 19-11-2019 в 12:16:

>> $find(*world, "func_door:storage*")

Ну и дичь лютую вы удумали, писать скрипт под конкретную карту, для каждой сущности. Ещё и трахаться с ~~ДЕБАЖИТЬ~~ отладкой этих финдов.

Что мешает просто подгружать файл скрипта как отдельную сущность со своими полями? Написали какой нибудь trigger_butthurt.qc, если есть на карте он, то он подгрузился, если нет, то нет. Как во всех современных движках. А наследования в скриптах делать по классике, через объявление public/private и т.п.

Отправлено nemyax 19-11-2019 в 12:30:

Цитата:

FiEctro писал:
писать скрипт под конкретную карту, для каждой сущности

Где ты увидел "для каждой"?

Отправлено thambs 19-11-2019 в 13:05:

FiEctro
Ответь, почему ты так нагло ПЕРЕВИРАЕШЬ то что я писал?

Цитата:

Написали какой нибудь trigger_butthurt.qc

А ведь, я вообще не писал о том что бы создавать новые сущности, только о том как мог бы выглядеть механизм более тонкого и настраиваемого взаимодействия между существующими.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 19-11-2019 в 14:37:

Сгенерил патчи на кутришной карте, ну вроде норм - язык пропал (на q3dm1), как корова в реке утопила. Да что за бред, начал разбираться.
Оптимизатор отключаешь - язык на месте, остальное в порядке. Ну где я мог накосячить? Очевидно нигде. Расковырял функцию оптимизатора - там ошибка. Это походу уже становится традицией.

Добавлено 19-11-2019 в 17:37:

ЗЫ. Оптимизатор из OverDose если что. Не из ку3.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 19-11-2019 в 15:02:

Что оптимизирует оптимизатор?

Отправлено a1batross 19-11-2019 в 15:11:

Оптимизатор оптимизирует брашевые языки, вестимо.

__________________
Xash3D FWGS форк

Отправлено FiEctro 19-11-2019 в 15:39:

Цитата:

thambs писал:
FiEctro
Ответь, почему ты так нагло ПЕРЕВИРАЕШЬ то что я писал?

Да потому что это не интуитивно и запутанно. Что даже здесь я видимо не понял твоей полной задумки.

Цитата:

thambs писал:
FiEctro
А ведь, я вообще не писал о том что бы создавать новые сущности, только о том как мог бы выглядеть механизм более тонкого и настраиваемого взаимодействия между существующими.

Сущность это класс или скрипт, с одним единственным отличием - он прописан прямо в дллке. Ставя его на карту, мы лишь указываем ему значения переменных, абстрогируйся от этого. По мне очень здорово представлять сущность именно как отдельный скрипт, а не логические операции. Механизм каждый сможет подстроить под себя.

Отправлено Дядя Миша 19-11-2019 в 17:15:

Финальный результат.
Кутришные шейдеры прекрасно заменяются моей системой материалов, даже при отсутствии специализированных GLSL-шейдеров для кутришных заморочек. ну типа мигающих текстур, пидарасов, которые, как известно, ползут по трубам итак далее. Но всё это реализуется в пользовательской части, рендерер трогать не надо.
Для сравнения, тепичный кутришный шейдер, который ничего не делает, а просто заменяет путь к текстуре:

C++ Source Code:

1	textures/skin/surface8_trans

3	qer_editorimage textures/skin/surface8.tga

4	surfaceparm nonsolid

6	map $lightmap

7	rgbGen identity

11	map textures/skin/surface8.tga

12	rgbGen identity

13	blendFunc GL_DST_COLOR GL_ZERO

И его аналог в моей системе материалов

C++ Source Code:

1	textures/skin/surface8_trans

3	image u_ColorMap = "textures/skin/surface8.tga";

Если надо светящийся материал, то вот так

C++ Source Code:

1	textures/liquids/lavahellflat_400

3	image u_ColorMap = "textures/liquids/lavahell.tga";

4	#define LIGHTING_FULLBRIGHT

причём сам этот дефайн - он тоже пользовательский. Движок про него не знает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 19-11-2019 в 17:22:

Дядя Миша
По трубам, я так понимаю, ползать никто под ксашем не будет? Или можно самому написать шейдер? Если да, то как это будет выглядеть?

__________________

Отправлено Дядя Миша 19-11-2019 в 17:28:

Хм, картинку забыл.

Добавлено 19-11-2019 в 20:28:

Цитата:

XaeroX писал:
По трубам, я так понимаю, ползать никто под ксашем не будет? Или можно самому написать шейдер? Если да, то как это будет выглядеть?

Да, надо GLSL-шйдер написать и всё заползает. Выглядеть будет идентично ктури. Единственная проблема моей системы - я до сих пор не придумал как задавать анимацию. Не поддерживается она у меня пока что.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 19-11-2019 в 17:37:

Цитата:

Дядя Миша писал:
Да, надо GLSL-шйдер написать и всё заползает. Выглядеть будет идентично ктури.

Разве они не про монстров ползучих по стенам, как в думтри и свене? И ку2?

Добавлено 20-11-2019 в 00:37:

Цитата:

Дядя Миша писал:
u_ColorMap

Как получился такой термин? Юниформ? Если бы я не знал то подумал бы что это кастомная палитра текстуры, яркая как в Анриле (u).

Отправлено Дядя Миша 19-11-2019 в 17:40:

Цитата:

Crystallize писал:
Как получился такой термин? Юниформ?

да. Можно назвать как угодно. Я придерживаюсь такой терминологии.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 19-11-2019 в 18:05:

Дядя Миша
А покежь Renderer: Dynamic.

Отправлено Дядя Миша 19-11-2019 в 18:23:

Нету ищо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 20-11-2019 в 07:39:

Как история повторяется циклически, так и ДМ прикручивает ку3 формат циклически к ксашу.

Отправлено Дядя Миша 20-11-2019 в 09:44:

Вам возможно будет интересно, но в этот раз для кутришного формата я использовал все сабраутины от первой кваки. Кроме конечно разжатия PVS, поскольку в кутри PVS и так несжатый
Всё подходит.

Добавлено 20-11-2019 в 12:28:

Сделал вчера предварительный тест производительности. Там где эта же карта в халфовском формате выдаёт 400 фпс, кутришная выдаёт 700, но судить пока рано - я к примеру не подключил еще физику, она вполне может сбить итоговый фпс. Впрочем причины понятны - те же патчи рисуются как стрипы. Конечно это будет быстрее чем в халфовском формате, где всё отдельными трианглами. Плюс в кутри и сами секвенции гораздо длиннее. Продолжаю исследование.

Добавлено 20-11-2019 в 12:44:

Вообще у меня есть вот какая идейка. Если я ЧАЭС вкомпилю как встроенную модель со всеми стрипами, а дерево само её рассечёт на квадраты 1024х1024. Видимость это конечно посчитать не поможет, но как минимум куллиться будет эффективнее. Ну это позже.
Для меня есть одна загадка - я не понимаю как в движках организованы лайтстили без какой-либо привязки к лайтстилю. Вот вроде бы говорят, что в сталкере этих лайтмап можно насчитать сколько угодно, хоть для 12-и положений солнца. Судя по всему это не учитывает остальные источники, лайтмапы просто дублируются для них. И в унреале есть подобная замута.
Надо будет с этим разобраться.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 20-11-2019 в 21:20:

Ну что же. Пожалуй пришла пора реально реализовать функционал кутришных шейдеров, не затрагивая код рендерера - только через новую скриптовую систему. Посмотрим что у меня получится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 21-11-2019 в 08:01:

Цитата:

Дядя Миша писал:
надо GLSL-шйдер написать и всё заползает

Только фрагментник или вершинник тоже?

Отправлено XaeroX 21-11-2019 в 08:02:

И геометрический!

__________________

Отправлено Дядя Миша 21-11-2019 в 17:37:

Вот вам две занятные картинки: Там где фпс выше - это кутришная оригинальная карта. там где ниже - эта же карта, скомпиленная в халфовский бсп. Особо обращаю ваше внимание на кол-во DIP.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 21-11-2019 в 17:53:

Дядя Миша
Откуда такой дип? Ты не сортируешь что ли?

__________________

Отправлено Дядя Миша 21-11-2019 в 18:21:

XaeroX сортирую, но для кутри сортировку не оптимизировал. Но как видишь - всё равно быстрее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 21-11-2019 в 18:40:

О чем это говорит?

Отправлено Дядя Миша 22-11-2019 в 08:54:

Вот какую штуку я придумал. Тот формат записи, который есть сейчас, позволяет максимально подробно описать юниформы и текстурные юниты для шейдеров, но я подозреваю, что самим пользователям будет очень неудобно каждый раз такое прописывать. Это слишком общий формат записи, это для тех, кто будет создавать новые типы рендереров.
То есть каждый раз обозначать путь к текстуре таким образом:

C++ Source Code:

image u_ColorMap = "<textures/<modelname>/<texname>";

или явным образом

C++ Source Code:

image u_ColorMap = "textures/common/black.tga";

довольно таки неудобно. С юниформами аналогичная ситуация, но в то же время это оптимальный формат записи с точки зрения самого механизма и менять я его не намерен. Как же упростить эту задачу для пользователя?
И я придумал встроить поверх этой системы дополнительно простенький макро-язык, который сможет заменять key-value pair (ну в действительности сколько угодно аргументов) на необходимую нам строку.
То есть мы пишем что-то вроде

C++ Source Code:

#keydef map <value>\

image u_ColorMap = "<value>";

а при парсинге оно находит наши строки

C++ Source Code:

map textures\common\black.tga

и автоматически их заменяет на то что мы указали. А для лайтмапы, скажем

C++ Source Code:

#keydef map $lightmap\

image u_LightMap = "entity->$LightmapTexture";

Ну это просто как пример, в реальности будет несколько сложнее. Плюс в том, что мы таким образом сможем описать практически любую из существующих систем материалов или создать свою собственную.
Достаточно описать все ключевые конструкции кутришных шейдеров и всё это распарсится в исходную систему налиту. Или аналогично указать не кутришные ключевые слова, а параноевские. Ну единственно надо будет хорошо продумать правила автозамены.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 22-11-2019 в 11:21:

Цитата:

сможем описать практически любую из существующих систем материалов или создать свою собственную

Прям мета-система какая-то.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 22-11-2019 в 11:44:

Можно провести аналогии с тем же С++. Там ведь тоже есть макросы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 23-11-2019 в 16:01:

Дядя Миша
Скажи, а вот эту гадость с полупрозрачностью в новой системе удалось забороть?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 23-11-2019 в 16:57:

Эту "гадость" еще ни одному человеку на планете забороть не удалось и едва ли это вообще возможно. Впрочем, я еще не занимался стёклами.

Добавлено 23-11-2019 в 19:57:

В кутри это бороли повертексным освещением, но тогда прощай тени на стёклах. Дилемма.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 24-11-2019 в 13:55:

Трассировкой-то борют.

Отправлено Дядя Миша 24-11-2019 в 16:33:

Тут для солидных тел не могут толком трассировку наладить, а ты на полупрозрачные замахнулся, очуметь можно.

Добавлено 24-11-2019 в 19:23:

Довольно сложная штука этот макро-язык получается. Но по другому никак, ведь мы фактически задаём все юниформы и текстурные юниты из скрипта, тут не выйдет отделаться упрощённой формой записи - полезут разные нехорошие ограничения. А писать каждый раз полное выражение очень утомительно. Так что макро-замена тут идеальный выход. Это всё работает по принципу один раз настроил и больше не лазишь. Надо - еще добавил.

Добавлено 24-11-2019 в 19:26:

Сам макро-язык включает в себя три ключевых слова.
enum - это для макросчетчиков, которые можно инкременировать прямо во время макроподстановки, например для слоёв ландшафта или стадий в кутришном шейдере.
#keydef - заменяет одно регулярное выражение на другое. Пример:

C++ Source Code:

#keydef map <value>\

image u_ColorMap<unitNum> = "<value>";

второй аргумент - исходная переменная, путь к текстуре. А вот пример строгого соответствия

C++ Source Code:

#keydef map $lightmap\

image u_LightMap = "entity->$LightmapTexture";

Естественно, что у строгого соответствия приоритет выше.
ну и #define - заменяет одно слово на другое, без хитростей.
В принципе этого должно хватить, чтобы описать любую макроподстановку. Ну посмотрим.

Добавлено 24-11-2019 в 19:29:

А, да. <unitNum> в данном примере это как раз ссылка на счётчик, которая заменится на его текущее значение и получится строчка u_ColorMap0
Ну, разумеется к любой строке макро-подстановки это можно применять.
Сформированная финальная строка замены, просто подаётся на вход парсера, как будто бы она была в реальном файле и дальше парсинг происходит в обычном режиме.

Добавлено 24-11-2019 в 19:33:

И кстати это же правило действует на внутренние фигурные скобки, их тоже можно (и нужно) заменять.

У моей системы есть одно принципиальное ограничение - базовый формат, всегда должен иметь вид, типа

C++ Source Code:

materialName

Но для параноевских материалов и для кутришных шейдеров и для ку2-шных материалов из q2world и для дуумтришных материалов это требование соблюдается. Да и скорее всего еще много где, просто потому что это наиболее очевидный формат записи чего-либо. И вот эту конструкцию уже переопределить нельзя. Но не думаю, что это будет проблемой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 25-11-2019 в 10:32:

Ну вот потихоньку ввожу в строй свои макросы. Вот текущие команды для замены в кутришных шейдерах:

C++ Source Code:

1	enum unitNum;

2	enum stageNumber;

3	enum texModCount;

4	enum deformCount;

6	// q3map keywords (just eliminate)

7	#keydef qer_editorimage <value>

8	#define q3map_noFog

9	#define q3map_globalTexture

10	#define q3map_nonplanar

11	#keydef q3map_shadeangle <a>

12	#keydef q3map_sunExt <a> <b> <c> <d> <e> <f> <g> <h>

13	#keydef q3map_skyLight <a> <b>

15	// surfaceparms, etc

16	#keydef surfaceparm <value>

17	#define nopicmip

19	// blendfunc replacements

20	#define GL_ZERO 0.0

21	#define GL_ONE 1.0

22	#define GL_SRC_COLOR 2.0

23	#define GL_DST_COLOR 3.0

24	#define GL_ONE_MINUS_SRC_COLOR 4.0

25	#define GL_ONE_MINUS_DST_COLOR 5.0

26	#define GL_SRC_ALPHA 6.0

27	#define GL_DST_ALPHA 7.0

28	#define GL_ONE_MINUS_SRC_ALPHA 8.0

29	#define GL_ONE_MINUS_DST_ALPHA 9.0

30	#define GL_ALPHA_SATURATE 10.0 // rare case

32	#keydef map <value>\

33	image u_ColorMap<unitNum> = "<value>";\

34	unitNum++;

36	#keydef map $lightmap\

37	image u_ColorMap<unitNum> = "entity->$LightmapTexture";\

38	unitNum++;

40	#keydef blendFunc <src> <dst>\

41	vec2 u_BlendFunc<unitNum> = vec2( <src>, <dst> );

43	#keydef {\

44	addShaderDefine( SHADER_STAGE<stageNumber> );

46	#keydef }\

47	stageNumber++;

#define в моём языке всегда задаёт строгое соответствие замены A на B или A на пустоту. Сишная фишка с функциями типа #define func(a,b,c) не поддерживается, поскольку в подавляющем большинстве материалов никаких функций просто нет, там именно keyvalue pair. И наоборот, у меня работает то, что нереализуемо на сишных макросах (но там это и не нужно).

Простой пример, для кутришного блендфунка. Шаблон автозамены
blendFunc <src> <dst>
превращается сперва в
vec2 u_BlendFunc<unitNum> = vec2( <src>, <dst> );
потом подставляется текущее значение энума <unitNum>, а потом система ищет переопределение GL_SRC_XXX, GL_DST_XXX и тоже их заменяет на цифры. То есть финальный результат автозамены будет выглядеть примерно так:

C++ Source Code:

vec2 u_BlendFunc2 = vec2( 6.0, 8.0 );

и уже этот результат снова подаётся на вход парсера, где и читается в обычном режиме, т.к. нативный формат записи. А в шейдере для blendFunc будут условия на выходные значения, соответствующие режимам смещевания (собсно так и переводят кутришные шейдеры на GLSL). Для каждого юнита, соответственно юниформ со своим номером.
А чтобы понять, какие юниты задействованы в шейдере, у нас есть команда addShaderDefine( SHADER_STAGE<stageNumber> );
где stageNumber точно так же превратится в текущее значение счётчика.
Ну разумеется, в шейдере эти #ifdef SHADER_STAGE0, #ifdef SHADER_STAGE1 придётся прописывать ручками, но нам понадобится один-единственный шейдер для описания абсолютно всех комбинаций кутришных материалов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 25-11-2019 в 12:40:

Дядя Миша
А это всё куда-то потом коптилируется, или каждый запуск налиту читается?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 25-11-2019 в 13:08:

thambs
Заранее скомпиленные шейдеры вроде только в OpenGL 4.5 и новее поддерживаются. Обычно-то их компилят-линкуют-подключают при инициализации рендерера.

Отправлено XaeroX 25-11-2019 в 13:44:

nemyax
А вот в д3д всегда можно было бинарник с игрой распространять.

__________________

Отправлено Дядя Миша 25-11-2019 в 19:02:

Цитата:

thambs писал:
каждый запуск налиту читается?

каждый запуск читается налету, но это быстро. Это ж простая макро-подстановка и парсится она один раз при запуске движка.

Цитата:

nemyax писал:
Заранее скомпиленные шейдеры вроде только в OpenGL 4.5 и новее поддерживаются

так это вообще не шейдеры. Скомпиленные шейдеры у меня тоже поддерживаются.

Добавлено 25-11-2019 в 18:07:

Так, ну чтожы, я сделал макроподстановки для большинства случаев, ну покрайней мере чтобы материалы Edge Of Forever ни на что не ругались.
Теперь самое сложное - надо написать такой шейдер, который бы всё это корректно учитывал. То что я распарсил - это же просто параметры на вход шейдера, конвертация.

Добавлено 25-11-2019 в 18:09:

Для интерисующихся, пример тепичного шейдера. сконверченного в мою систему:

C++ Source Code:

1	textures/moteof/walltrim2

3	<ShaderState>

4	addShaderDefine( SHADER_STAGE0 )

5	addShaderDefine( SHADER_STAGE1 )

6	u_ColorMap0:-1 = unused;

7	u_ColorMap1:-1 = unused;

8	vec2 u_BlendFunc2;

диффузка + лайтмапа. Не пугайтесь странным значениям, это у меня дебаг-инфо недоделатый.

Добавлено 25-11-2019 в 18:10:

А вот шейдер с множеством стадий

C++ Source Code:

1	textures/moteof/water_healing

3	<ShaderState>

4	addShaderDefine( APPLY_DEFORM_VERTS0 )

5	addShaderDefine( SHADER_STAGE0 )

6	addShaderDefine( APPLY_VERTEXCOLOR0 )

7	addShaderDefine( APPLY_COLORWAVE0 )

8	addShaderDefine( APPLY_TEXMOD_TRANSFORM0_0 )

9	addShaderDefine( APPLY_TEXMOD_TURB0_1 )

10	addShaderDefine( SHADER_STAGE1 )

11	addShaderDefine( APPLY_VERTEXCOLOR1 )

12	addShaderDefine( APPLY_COLORWAVE1 )

13	addShaderDefine( APPLY_TEXMOD_STRETCH1_0 )

14	addShaderDefine( APPLY_TEXMOD_SCROLL1_1 )

15	addShaderDefine( SHADER_STAGE2 )

16	addShaderDefine( APPLY_VERTEXCOLOR2 )

17	addShaderDefine( APPLY_COLORWAVE2 )

18	addShaderDefine( APPLY_TEXMOD_TURB2_0 )

19	addShaderDefine( SHADER_STAGE3 )

20	addShaderDefine( APPLY_VERTEXCOLOR3 )

21	addShaderDefine( APPLY_TEXMOD_STRETCH3_0 )

22	addShaderDefine( APPLY_TEXMOD_TRANSFORM3_1 )

23	addShaderDefine( APPLY_TEXMOD_ROTATE3_2 )

24	u_ColorMap0:-1 = unused;

25	u_ColorMap1:-1 = unused;

26	u_ColorMap2:-1 = unused;

27	u_ColorMap3:-1 = unused;

28	vec2 u_WaveDeformFunc0;

29	vec4 u_WaveDeformBase0;

30	vec2 u_BlendFunc1;

31	float u_rgbGenWaveFunc0;

32	vec4 u_rgbGenWaveParams0;

33	vec4 u_texModBase0_0;

34	vec2 u_texModTrans0_0;

35	vec4 u_texModTurb0_1;

36	vec2 u_BlendFunc2;

37	float u_rgbGenWaveFunc1;

38	vec4 u_rgbGenWaveParams1;

39	float u_texModWaveFunc1_0;

40	vec4 u_texModWaveParams1_0;

41	vec2 u_texModScroll1_1;

42	vec2 u_BlendFunc3;

43	float u_rgbGenWaveFunc2;

44	vec4 u_rgbGenWaveParams2;

45	vec4 u_texModTurb2_0;

46	vec2 u_BlendFunc4;

47	float u_texModWaveFunc3_0;

48	vec4 u_texModWaveParams3_0;

49	vec4 u_texModBase3_1;

50	vec2 u_texModTrans3_1;

51	float u_texModRotate3_2;

Впрочем старая проблема по прежнему остается - я так и не придумал как делать анимацию текстур. Но на этой карте её и нету.

Добавлено 25-11-2019 в 22:02:

Кстати, что касается времени такого парсинга с заменой. Оптимизировал функцию, теперь это занимает 0.3 секунды для полного пака кутришных шейдеров + еще шейдеров 500 от Сока для его карт и шейдеры для rustgrad.
Можно их еще хэшировать, но я думаю и так уже норм.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 26-11-2019 в 07:34:

Немного причесал дебаг, ну вот примерно так выглядят входные параметры распарсенного кутришного шейдера.

C++ Source Code:

1	textures/base_light/proto_lightred2

3	#define SHADER_STAGE0

4	#define SHADER_STAGE1

5	#define SHADER_STAGE2

6	#define APPLY_COLORWAVE2

7	u_ColorMap0 = entity->$LightmapTexture;

8	u_ColorMap1 = textures/base_light/proto_lightred.tga;

9	u_ColorMap2 = textures/base_light/proto_lightred.tga;

10	vec2 u_BlendFunc1 = vec2( 3, 0 );

11	vec2 u_BlendFunc2 = vec2( 1, 1 );

12	float u_rgbGenWaveFunc2 = 1;

13	vec4 u_rgbGenWaveParams2 = vec4( 0.5, 0.5, 0, 1 );

Может я конечно буду менять организацию, но со скриптами это быстро.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 26-11-2019 в 07:47:

Выглядит очень переусложнённо в сравнении с самими ку3шными скриптами.
Да, возможностей больше - но они никому и не нужны. Сам же всем рассказывал, что мигающие лампочки нужны только Жэке в моде, а остальным достаточно статичных диффузки и нормалки.

__________________

Отправлено Дядя Миша 26-11-2019 в 07:53:

Цитата:

XaeroX писал:
Выглядит очень переусложнённо в сравнении с самими ку3шными скриптами.

то что я привёл - это скрытый промежуточный результат, который не виден пользователю. Это то, что подается на вход GLSL-шейдера. Ты правильно подметил, что это руками набивать - очуметь можно. А когда этим автозамена занимается - нормально.

Цитата:

XaeroX писал:
Да, возможностей больше - но они никому и не нужны

Смысл в том, что пользователь сможет создать свой мета-язык для описания материалов. Кутришные шейдеры в данном случае это стресс-тест для проверки возможностей системы. Так-то я планирую еще описать тепичные параноевские материалы, только теперь их значения будут не захардкодены, а тоже описаны в скрипте.

Добавлено 26-11-2019 в 10:53:

Кстати и волатиловские шейдеры я смогу описать точно так же

Т.е. это мета-язык для описания рендеринга, который вмещает в себя большинство форматов, когда-либо придуманных для этого дела.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 26-11-2019 в 07:58:

Цитата:

Дядя Миша писал:
Кстати и волатиловские шейдеры я смогу описать точно так же

Да вот хз. Есть у тебя аналог dynamicMap? Это когда на вход шейдера подаётся содержимое FBO от рендеринга экрана или зеркала?

__________________

Отправлено Дядя Миша 26-11-2019 в 09:33:

Цитата:

XaeroX писал:
Есть у тебя аналог dynamicMap?

image u_DynamicMap = "entity->$SubviewTexture";

Добавлено 26-11-2019 в 12:28:

Если интересно, вот полный список того, что можно подать на вход текстурного юнита:

C++ Source Code:

1	typedef enum

3	// types below are applied during model loading

4	LOC_MATDEF_DETAILMAP = 1, // path to detail texture from materials.def

5	LOC_GLOBAL_DEFAULT_IMAGE,

6	LOC_GLOBAL_PARTICLE_IMAGE,

7	LOC_GLOBAL_WHITE_IMAGE,

8	LOC_GLOBAL_GRAY_IMAGE,

9	LOC_GLOBAL_BLACK_IMAGE,

10	LOC_GLOBAL_FITNORM_IMAGE,

11	LOC_GLOBAL_WHITECUBE_IMAGE,

12	LOC_VARIABLE_PATH,

13	LOC_CONSTANT_PATH,

14	// types below are applied during rendering

15	LOC_GLOBAL_SKYBOX_IMAGE,

16	LOC_GLOBAL_SCREEN_COLOR,

17	LOC_GLOBAL_SCREEN_DEPTH,

18	LOC_ENTITY_LIGHTMAP,

19	LOC_ENTITY_DELUXMAP,

20	LOC_ENTITY_CUBEMAP0,

21	LOC_ENTITY_CUBEMAP1,

22	LOC_ENTITY_CINEMATIC, // cinematic texture

23	LOC_ENTITY_SUBVIEW, // reflection, portal, monitor etc

24	LOC_ENTITY_LAYERMAP, // terrain layers

25	LOC_LIGHT_SPOTLIGHT, // get spotlight texture from dlight

26	LOC_LIGHT_OMNILIGHT,

27	LOC_LIGHT_SHADOWMAP0,

28	LOC_LIGHT_SHADOWMAP1,

29	LOC_LIGHT_SHADOWMAP2,

30	LOC_LIGHT_SHADOWMAP3,

31	LOC_CONSOLE_TEXPATH // string or texturenum

32	} unitloc_t;

Добавлено 26-11-2019 в 12:29:

Последняя локация для дебага - берёт путь или индекс текстуры из консольной переменной

Добавлено 26-11-2019 в 12:33:

А вот входные данные для юниформов

C++ Source Code:

1	typedef enum

3	LOC_MATDEF_DETAILSCALE = 1,

4	LOC_MATDEF_SMOOTHNESS,

5	LOC_GLOBALS_GAMETIME,

6	LOC_GLOBALS_REALTIME,

7	LOC_GLOBALS_SCREENSIZE,

8	LOC_GLOBALS_SCREENSIZEINV,

9	LOC_GLOBALS_FARPLANE,

10	LOC_GLOBALS_LIGHTSTYLES,

11	LOC_GLOBALS_FOGPARAMS,

12	LOC_GLOBALS_AMBIENTFACTOR,

13	LOC_GLOBALS_DIFFUSEFACTOR,

14	LOC_GLOBALS_SUNREFRACTION,

15	LOC_GLOBALS_GAMMATABLE,

16	LOC_ENTITY_TRANSFORM,

17	LOC_ENTITY_BONEMATRIX,

18	LOC_ENTITY_BONEQUATERNION,

19	LOC_ENTITY_BONEPOSITION,

20	LOC_ENTITY_LIGHTSTYLES,

21	LOC_ENTITY_CONVEYOR,

22	LOC_ENTITY_RENDERCOLOR,

23	LOC_ENTITY_CUBELERPFACTOR,

24	LOC_ENTITY_BOUNDSCUBEMAP0,

25	LOC_ENTITY_BOUNDSCUBEMAP1,

26	LOC_ENTITY_ORIGINCUBEMAP0,

27	LOC_ENTITY_ORIGINCUBEMAP1,

28	LOC_ENTITY_CUBENUMMIPS0,

29	LOC_ENTITY_CUBENUMMIPS1,

30	LOC_ENTITY_SUBVIEWMATRIX,

31	LOC_ENTITY_VIEWFORWARD,

32	LOC_ENTITY_VIEWRIGHT,

33	LOC_ENTITY_VIEWUP,

34	LOC_ENTITY_VIEWORIGIN,

35	LOC_ENTITY_FRAMELERP,

36	LOC_ENTITY_SCALE,

37	LOC_LIGHT_SHADOWPARAMS,

38	LOC_LIGHT_SHADOWMATRIX,

39	LOC_LIGHT_DIRECTION,

40	LOC_LIGHT_COLOR,

41	LOC_LIGHT_ORIGIN,

42	LOC_LIGHT_MATRIX,

43	LOC_LPROBE_DIRECTION,

44	LOC_LPROBE_COLOR,

45	LOC_LPROBE_SHADEAMBIENT,

46	LOC_LPROBE_AMBIENTCUBE,

47	LOC_RENDER_VIEWORIGIN,

48	LOC_RENDER_VIEWRIGHT,

49	LOC_RENDER_CSMSPLITDIST,

50	LOC_RENDER_CSMTEXELSIZE,

51	LOC_CONSOLE_VARIABLE,

52	LOC_CONSTANT_VARIABLE,

53	} utype_t;

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 26-11-2019 в 10:23:

Цитата:

Дядя Миша писал:
image u_DynamicMap = "entity->$SubviewTexture";

Так может не быть неко кой энтити, для тех же зеркал.

__________________

Отправлено Дядя Миша 26-11-2019 в 10:27:

Ну это просто название такое. Так-то оно хранится персонально для каждого сурфейса.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 26-11-2019 в 10:28:

LOC_LIGHT_OMNILIGHT - это кастомный attenuation image?
А фильтрующая кувемапа где?

Добавлено 26-11-2019 в 17:28:

Ну в принципе да, по функционалу похоже на Волатилу. Поздравляю!

__________________

Отправлено Дядя Миша 26-11-2019 в 11:13:

Цитата:

XaeroX писал:
это кастомный attenuation image?

не, это диффузная кубемапа для омнилайта. Аттенюатион-имаджей у меня вообще нет, они прекрасно заменяются функциями в шейдере, это быстрее и проще. Я от них отказался еще в 2015-м году.

Цитата:

XaeroX писал:
по функционалу похоже на Волатилу

я вообще-то показал процентов 5 от функционала.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 26-11-2019 в 11:18:

Цитата:

Дядя Миша писал:
они прекрасно заменяются функциями в шейдере, это быстрее и проще

Ты исходишь из того, что аттенуация всегда простая - квадратичная там или линейная. Но за счёт кастомных текстур аттенуации в волатиле можно проворачивать разные штуки, например, имитировать ареа-лайты. Собсно, я это показывал в 2016 году в той теме, с уровнями из халфы.

Добавлено 26-11-2019 в 18:18:

Цитата:

Дядя Миша писал:
я вообще-то показал процентов 5 от функционала.

Ну я и имел в виду - твои 5% похожи на 5% функционала волатилы.

__________________

Отправлено Дядя Миша 26-11-2019 в 11:53:

Цитата:

XaeroX писал:
Но за счёт кастомных текстур аттенуации в волатиле можно проворачивать разные штуки

долго ли добавить? Я до света вообще еще недобрался, это просто такой задел на будующее.

Приступил к написанию убер-шейдера, который должен в себя включить все возможные комбинации кутришных шейдеров. Посмотрим как это у меня получится. Самое неудобное - вот эти грёбаные тексмоды, которые можно навешивать по нескольку штук на юнит.
Кстати говоря, я достаточно долгое время имел дело с кастомными поделками и вариациями на тему кутри, из чего у меня сложилось неверное представление об их возможностях. В оригинальной кутри лимиты гораздо скромнее, чем в этих форках. Там я помню какие-то бандлы наворачивали, чтобы значит сколлапсировать стадию в мульти-текстуринг, какие-то cg-программы можно было подключать (ессно никто этого не делал).
А в кутри всего восемь стадий-юнитов. По лимитам прекрасно укладываемся.
Впрочем я бы мультипроходность при всём желании замутить не смог, мой рендерер её не поддерживает. Да и не нужна она в наше время. Всё в шейдере прекрасно суммируется, без этих ваших depthFunc( GL_EQUAL );

Добавлено 26-11-2019 в 14:53:

Цитата:

XaeroX писал:
Ну я и имел в виду - твои 5% похожи на 5% функционала волатилы.

у меня есть все основания полагать, что новая Волатила мало чем отличается от прежней, на которой был сделан Wolfram. Ну вот навскидку - тот же Quake3 like формат уровней, те же Quake3 like описания материалов.
Тот же Нутон. Ну тени заменили со стенсильных на шадовмапы. А что еще?
Вот ты бы сам описал какие отличия старого движка от нового, такой список.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 26-11-2019 в 12:32:

Цитата:

Дядя Миша писал:
у меня есть все основания полагать, что новая Волатила мало чем отличается от прежней, на которой был сделан Wolfram.

Сильно отличается, на самом деле.

__________________

Отправлено Дядя Миша 26-11-2019 в 13:37:

Первые опыты
Это уже нарисовано через новую систему. Пока еще не мигает и не ерзает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 26-11-2019 в 14:34:

Дядя Миша
А какие идеи про анимацию шейдеров? Юниформ про аптайм движка или ещё как-нибудь?

Отправлено Дядя Миша 26-11-2019 в 14:53:

та пока никаких идей, этож общая проблема.
Она в основном упирается в синтаксис скрипта, как красиво написать, что мы на этот юнит хотим навесить несколько текстур, которые будут сменяться через время? Ну вот для стандартного описания юнита

C++ Source Code:

image = u_ColorMap = "textures/common/black.tga";

как здесь указать что будет много меняющихся текстур?

Добавлено 26-11-2019 в 17:53:

ЗЫ. с мультислоёными текстурами аналогичная проблема, кстати.
Ну ладно, fps или еще какое правило их смены можно задать через отдельную команду и это непроблема.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 26-11-2019 в 15:03:

Цитата:

Дядя Миша писал:
упирается в синтаксис скрипта, как красиво написать

Маску/список в квадратных скобочках ala bash?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 27-11-2019 в 06:32:

thambs приведи пример.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено AntiPlayer 27-11-2019 в 06:36:

Дядя Миша

C++ Source Code:

image = u_ColorMap = ["textures/common/black.tga", "textures/common/white.tga"];

Так не красиво?

__________________
I tell you to enjoy life

Отправлено Дядя Миша 27-11-2019 в 07:25:

Ладно, попозже к этой теме вернёмся. Может и норм.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 27-11-2019 в 07:56:

AntiPlayer Питон какой-то

Отправлено Дядя Миша 27-11-2019 в 09:21:

Я наверное пойду по старому, проверенному пути, сделаю что-то типа функции addUnitLayer или addUnitFrame. Не люблю когда строка далеко уходит вправо, за границу экрана.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 27-11-2019 в 09:40:

Дядя Миша
А переводы строк на что?

Отправлено Дядя Миша 27-11-2019 в 10:36:

nemyax не каждую строку можно перевести.

Добавлено 27-11-2019 в 13:36:

А я тем временем без дела не сидел - подключил блендфунки, смешал текстуры со всех слоёв, реализовал деформацию вертексов, чтобы пидарасы ползали по трубам и сделал все виды генерации текстурных координат. И тут мне конечно пришлось столкнуться с ограничением моей системы. Нет, оно работает корректно, но пользователь там один момент уже не контролирует в полной мере. Впрочем я никогда не видел, чтобы это в ку3 хоть кто-то использовал, т.к. заведомо бессмыссленая операция.
Продолжаю работу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 27-11-2019 в 11:00:

Дядя Миша
В петоне есть хорошее правило, что при открытой скобке переводы строк нещиток, пока не встретится закрытая.
То есть вот:

code:
image = u_ColorMap = [
  "textures/common/black.tga",
  "textures/common/white.tga"];

Отправлено AntiPlayer 27-11-2019 в 12:08:

Цитата:

Crystallize писал:
Питон какой-то

Так массивы в половине ЯП определяются.

Цитата:

Дядя Миша писал:
сделаю что-то типа функции addUnitLayer или addUnitFrame

Дублирование кода может получиться, все дела. Хотя выглядит неплохо.

__________________
I tell you to enjoy life

Отправлено Дядя Миша 27-11-2019 в 13:18:

nemyax не нравится мне такой способ записи. Мне вообще петон не нравится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 27-11-2019 в 13:20:

Дядя Миша
Так юзеры-ж писать будут?

>приведи пример
Обычные звёздочки, знаки вопроса, [a-z] и [0-9] и на выходе список отсортированный в лексикографическом порядке. Мб вообще рэгэксп туда напрашивается?

>addUnitLayer или addUnitFrame
Главное чтоб не было нужно руками такое писать.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 27-11-2019 в 13:55:

Цитата:

thambs писал:
рэгэксп

Я предлагал дяде мише добавить поддержку pcre, он предсказуемо отказался.

__________________

Отправлено Дядя Миша 27-11-2019 в 14:08:

Цитата:

thambs писал:
>addUnitLayer или addUnitFrame
Главное чтоб не было нужно руками такое писать.

ну в макрос обвернешь со счётчиком.

Так, у меня тут с кутришными шейдерами конечно образовалась трогедия. Я не могу отличить полупрозрачные от непроразрачных, тому шо сам кутри это делает неявным образом, по значению первого бленд-функа. То есть мне бы там влепить условие и посмотреть чему равны значения из юниформа блендфунка для нулевого юнита, но я поленился сделать им доступ к отдельным значениям для всяких там векторов. Похоже что всё же придется сделать.

Добавлено 27-11-2019 в 17:08:

у меня GL-стейты вообще не подвержены действию условий, нехорошо получается, рано или поздно это могло понадобиться. Придётся переделывать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 27-11-2019 в 14:13:

XaeroX
Я вот вижу ещё для них юзкейсы внутри скриптового языка вплане работы со строками: найти энтити по маске, загрузить какие-то ресурсы по маске (например, звуки и рандомно между ними переключаться вместо хардкода).

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 27-11-2019 в 14:55:

Цитата:

Дядя Миша писал:
Я не могу отличить полупрозрачные от непроразрачных

surfaceparm trans?

__________________

Отправлено Дядя Миша 27-11-2019 в 15:00:

Цитата:

XaeroX писал:
surfaceparm trans?

ога, я так и сделал. Но есть две проблемы. Во первых он не везде прописан, а с т.з. компилятрра, это типо детайла, т.е. и без него тоже можно.
А во вторых мне надо еще поймать блендфунк нулевого юнита.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 27-11-2019 в 16:26:

А вот если брашевую геометрию триангулировать и сгенерить ей какую-то дерьмовую развёртку и атлас, это будет рисоваться заметно быстрее?

Отправлено Дядя Миша 27-11-2019 в 18:29:

Я придумал, второе условие прозрачности можно повесить на cull disable.

Добавлено 27-11-2019 в 21:29:

В принципе тут какое дело - в ку3 любая полупрозрачная поверхность непременно будет иметь cull disable. Правда это же справедливо и для решёток, поэтому там выполняется дополнительное условие - чтобы блендинг нулевого юнита не был равен GL_ONE, GL_ZERO.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 27-11-2019 в 18:43:

Бывает так, что рендерер все полигоны трактует как полупрозрачные, включая те, у которых opacity 1.0?

Отправлено Дядя Миша 28-11-2019 в 06:24:

Рендерер не смотрит на блендфунки и opacity. У него главный критерий - отключённая запись в буффер глубины.

Добавлено 28-11-2019 в 09:24:

Подключил тем временем текс-моды, всё заерзало и закрутилось. Ну уже похоже на кутри. Остались rgbGen и alphaGen.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 28-11-2019 в 19:01:

На самом деле в кутришных шейдерах есть один нехороший случай, когда нулевым юнитом идёт нечто полупрозрачные, а следующим - текстура с альфа-каналом, ну например стеклянная колба, поверх которой обрамление.
Просто включением альфа-канала такое не разруливается.

Добавлено 28-11-2019 в 16:22:

Вот же грёбанная задачка, из шейдера стейты не поменяешь, а рисовать всё с blendFunc( GL_ONE, GL_ONE ) - значит решётки будут полупрозрачными.

Добавлено 28-11-2019 в 18:57:

Практически завершил работу над шейдерами. Проблема с прозрачностью, увы, никуда не делась. Комбинированный материал со стадиями trans->solid навряд ли возможно нарисовать через стандартный блендфунк. Рази что через копию экрана.

Добавлено 28-11-2019 в 18:59:

А остальное всё работает, не хуже чем в ку3
Мигает, двигается, елозит, ползает по трубам и так далее.

Добавлено 28-11-2019 в 21:58:

Добавил анимацию текстур довольно оригинальным образом - каждый текс-юнит содержит в себе деномический массив путей к текстуре, по которым его можно будет поискать. Ну так я просто добавил классу каждого пути еще одну переменную - номер фрейма и всё. Теперь каждый кадр может искаться по разным путям, но суммарно их кол-во равно восьми, как в ку3.
В будущем слегка модифицируя этот механизм можно загружать и мультислойные текстуры, ну или что-то в этом духе. Просто они сольются в одну, а не останутся массивом. Так что в ку3 уже факелы заработали как надо
И всё это - на простом скрипте, движок про кутришные шейдеры даже не подозревает, единственное мне пришлось вывести дурацкое условие-проверку, что какого-то материала нет лайтмапы, а только повертексное, причём оно нужно для тех случаев, когда для материала с повертексным освещением поленились написать шейдер.
Осталась только эта грёбанная прозрачность, ну-да мне всё равно копирование экрана тестировать.

Добавлено 28-11-2019 в 22:01:

А, да, формат аним-кадров забыл показать

C++ Source Code:

1	image u_ColorMap<stageNum> = "<frame0>";\

2	addUnitFrame( u_ColorMap<stageNum>, <frame1>, 1 );\

3	addUnitFrame( u_ColorMap<stageNum>, <frame2>, 2 );\

4	addUnitFrame( u_ColorMap<stageNum>, <frame3>, 3 );\

5	addUnitFrame( u_ColorMap<stageNum>, <frame4>, 4 );\

6	addUnitFrame( u_ColorMap<stageNum>, <frame5>, 5 );\

7	addUnitFrame( u_ColorMap<stageNum>, <frame6>, 6 );\

8	addUnitFrame( u_ColorMap<stageNum>, <frame7>, 7 );\

9	setUnitFramerate( u_ColorMap<stageNum>, <fps> );

это кусок риплейса, не пугайтесь странным значениям.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 28-11-2019 в 19:17:

Дядя Миша
Ухтыж, скажи, а вот таким способом можно будет аддитивно наложить рендер с монитора на диффузный материал?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 28-11-2019 в 19:38:

Цитата:

Дядя Миша писал:
Комбинированный материал со стадиями trans->solid навряд ли возможно нарисовать через стандартный блендфунк.

Пробовал через коммутативный, как тут?
http://www.openglsuperbible.com/201...ally-necessary/

Отправлено Дядя Миша 29-11-2019 в 06:42:

Цитата:

thambs писал:
а вот таким способом можно будет аддитивно наложить рендер с монитора на диффузный материал?

таким это каким?

Цитата:

nemyax писал:
Пробовал через коммутативный, как тут?

дело не в коммутации же. Нарушен порядок смешивания. Он там в статье верно говорит, если бы всё смешивалось через GL_ONE, GL_ONE то порядок был бы неважно.
Как есть сейчас:

C++ Source Code:

1	pass0 (GL_ONE, GL_ONE) +

2	pass1 (REPLACE) +

3	pass2 (GL_DST_COLOR, GL_ZERO) +

screen

как должно быть

C++ Source Code:

1	pass0 (GL_ONE, GL_ONE) +

screen +

3	pass1 (REPLACE) +

4	pass2 (GL_DST_COLOR, GL_ZERO)

Разница в том, что в первом случае для шейдера включён внешний бленд, т.е. мешается итоговый результат. Ессно получается вот такая ерунда.

Позже займусь, у меня еще автоспрайты не готовы. Надо будет сделать хинт для препроцессинга геометрии, иначе никак.

Добавлено 29-11-2019 в 09:41:

Вообще, посмотрел я на свои скрипты для рендеринга и окончательно утвердился в мысли, что для игровой части нужна полноценная скрипт-машина. Вот это вот стремление вынести в игровую дллку побольше связанного кода в конечном итоге только отпугивает потенциальных пользователей. Тем кто рисует текстурки, даже просто студию поставить - как серпом об асфальт. В тоже время когда существует масса лёгких IDE с подсветкой и возможностью запустить по горячей кнопке какую-либо командную строку для компиляции. Так что я полагаю надо сделать нечто вроде progs.dat и перенести все энтити туда. В таких скриптах даже наш Жэка разобрался - сундук вон сделал.

Добавлено 29-11-2019 в 09:42:

Главное чтобы скриптовой язык не было похож на UnrealScript где миллион новых кейвордов. Дичь какая-то.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 29-11-2019 в 13:24:

Цитата:

Дядя Миша писал:
Нарушен порядок смешивания. Он там в статье верно говорит, если бы всё смешивалось через GL_ONE, GL_ONE то порядок был бы неважно.

Он разбирает ещё и glBlendFunc(GL_ZERO, GL_SRC_COLOR);

Цитата:

Дядя Миша писал:
Главное чтобы скриптовой язык не было похож на UnrealScript где миллион новых кейвордов.

Лишь бы укладывалось в какую-нибудь популярную подсветку, сишную там, плюсовую или шарповую.

Отправлено a1batross 29-11-2019 в 13:37:

nemyax как оказывается, ничего читабельнее Си-подобного синтаксиса нет.

__________________
Xash3D FWGS форк

Отправлено thambs 29-11-2019 в 13:38:

nemyax
Ну сишный и плюсовый синтаксисы довольно всратые, хотя если убрать вездесущие точки с запятой перед переводом на следующую строку, лишние скобки и определения типов длиной в строку, то будет вполне читабельно.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 29-11-2019 в 13:44:

a1batross
Выше уже было упомянуто, что будет нечто сиподобное. Вопрос только в том, на что конкретно будет похоже.

Добавлено 29-11-2019 в 16:44:

Цитата:

thambs писал:
убрать вездесущие точки с запятой перед переводом на следующую строку

Нинада, вносит неоднозначность.

Цитата:

thambs писал:
определения типов длиной в строку

Ты про шаблоны штоле? Скрипты не решают задач, требующих подобных определений.

Отправлено thambs 29-11-2019 в 13:48:

Цитата:

Нинада, вносит неоднозначность.

Приведи пример.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 29-11-2019 в 14:07:

thambs
Пример не пример, а в общем случае непонятно, считать перевод строки концом стейтмента или нет. В сях вот всё просто: не считать.

Отправлено Дядя Миша 30-11-2019 в 11:37:

Ну чтожы. Как я и говорил кастомный бленд через копию экрана решил проблемы шейдеров, где на второй-третьей стадии снова идёт запись в буффер глубины. Осталось только разрулить проблемки с полупрозрачными сурфейсами в тумане.

Добавлено 30-11-2019 в 14:37:

Собсно, я не стал делать абсолютно все бленды через скринкопи, это достаточно дорого. Только вот эти сложные случаи, которые иначе не разрулить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 30-11-2019 в 13:02:

Туманчег

Добавлено 30-11-2019 в 16:02:

Ну вообщем да, я тут провёл некоторые опыты, во всех случаях, когда у нас шейдер со сложным смешиванием (например все стадии имеют свой бленд-функ), то копия экрана прекрасно разруливает эту ситуацию и всё корректно блендится в один проход. Но таких случаев весьма мало, навскидку вспомнил только кольцо вокруг портала.

Так. Судя по всему старый механизм условий уже не удовлетворяет возросшим требованиям. Пора его обновить и расширить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 30-11-2019 в 13:47:

Дядя Миша
Карты оригинальные кутрёвые или ты что-то с ними дополнительно делал?

Отправлено Дядя Миша 30-11-2019 в 15:09:

Цитата:

nemyax писал:
Карты оригинальные кутрёвые или ты что-то с ними дополнительно делал?

абсолютно оригинальные. Было сделано две вещи:
1. во все шейдерные скрипты добавлена строчка:

C++ Source Code:

#include "scripts\q3shaders.h"

в этой файлике у меня все макро-подстановки и авто-замены.
2. джипег текстуры сконверчены в tga, ксаш не умеет джипег.

Добавлено 30-11-2019 в 18:02:

Добавил скрытые ключевые слова
#beginsection и #endsection
ну это что-то вроде конструктора и деструктора для скриптов.
Вызываются, только если юзер добавил их в глобальный словар макроподстановок. Ну и там уже можно внутри проверять всякое, в конце скрипта, а в начале допустим писать отладочное сообщение.
Но надо еще что-то с кондициями сделать. Текущая система уже не удовлетворяет. Там фактически одно условие #if с кучей ограничений и непонятным для юзера поведением.

Добавлено 30-11-2019 в 18:08:

Нужен рефакторинг. Я еще задумывался насчё того, чтобы вообще отойти от жёсткой формы задания материала

C++ Source Code:

"name"

чтобы через автозамену можно было как угодно их описывать, но пока не знаю. Парсеру ведь тоже нужны какие-то реперные точки, в данном случае это скобки { и }. Но если я это сделаю - можно будет описывать вообще любую форму материала. В том числе и однострочные материалы, как в сталкерах каких-нибудь. Сейчас этому мешает то обстоятельство, что словарь автозамены действует только внутри секции скобок.

Добавлено 30-11-2019 в 18:09:

А накидайте мне, если вам нетрудно варианты описания разные материалов и шейдеров из разных игр. Посмотрим что бывает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 30-11-2019 в 16:20:

Цитата:

Дядя Миша писал:
Собсно, я не стал делать абсолютно все бленды через скринкопи, это достаточно дорого. Только вот эти сложные случаи, которые иначе не разрулить.

Сложные случаи-автодетект или вручную?

Отправлено Дядя Миша 30-11-2019 в 18:03:

Автодетект конечно. Ну он пока не все варианты отрабатывает, я решил пересмотреть немного концепцию материалов и условий. У меня тут уже накопилось достаточно информации для размышления.
Не в том смысле, что я в тупик куда-то зашёл и дальше не получается. Просто появились идеи, как сделать еще лучше. Пока размышляю.
В рамках будущей концепции я хочу представить материал, просто как набор параметров для шейдера и для движка (некоторые подсказки).
Сейчас оно так и есть, но жёстко ограничено формой записи материала

C++ Source Code:

"name"

плюс есть такие неявные вещи, как наследование, из шейдер-объекта, но оно появилось тогда, когда у меня еще не было некокой автозамены.
И вот в связи с этим я думаю, а зачем нужно неявное наследование, когда при помощи автозамены можно сделать явное и указать приоритеты.
Поглядим, вообщем.

Добавлено 30-11-2019 в 21:03:

Наконец-то доделал туман

Печально, но сами объемы правильно блендятся только через копию экрана, через стандартный бленд мне не удалось их заставить правильно рисоваться.
Впрочем фпс всё равно достаточный.

На небо внимания не обращайте, неба еще нет нигде. А это кутришные шейдеры сами размазали облака по скайбрашам.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 01-12-2019 в 06:55:

Минутка забавного. В ку3 клибрашам почему-то не дали параметр nodraw и ксаш их конечно жы нарисовал. Надо бы их спрятать, но как?
Я бы конечо мог ввести какой-нибудь хитрый параметр, типа #ignore, но я решил себя поставить на место пользователя, который не может ничего добавить в движок. Вот как бы я поступил на его месте? Решение нашлось

C++ Source Code:

#keydef surfaceparm clip\

alphaFunc( GL_NEVER, 0.0f );

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 01-12-2019 в 14:08:

Дядя Миша

Цитата:

туман

Он там линейный от камеры, не круговой как в ксашмоде, или мне кажется (смотрю на место где он с плоскостью неба "взаимодействует")?

Цитата:

таким это каким?

Ну этими шойдерными скриптами, слоями/смешиванием или как оно.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Crystallize 01-12-2019 в 15:07:

Цитата:

Дядя Миша писал:
surfaceparm

Почему кому-то захотелось сэкономить одну буквочку за счёт читаемости?

Отправлено Дядя Миша 01-12-2019 в 15:26:

Цитата:

thambs писал:
Ну этими шойдерными скриптами, слоями/смешиванием или как оно.

так оно в любом случае в GLSL смешивается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 02-12-2019 в 08:46:

Цитата:

Дядя Миша писал:
GL_DST_COLOR

А на эти штуки можно сделать реплейсов с наглядными названиями?

Отправлено Дядя Миша 02-12-2019 в 08:57:

можно конечно, но помоему они и так наглядные.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 02-12-2019 в 14:55:

Делаю рефакторинг системы материалов, в первую очередь надо нормальные условия сделать, предсказуемые для юзера. Ну и сам механизм немного поменяется. Я думаю теперь дефолтные материалы задавать с именем типа модели, ну вот так:

C++ Source Code:

mod_brush

3	// default params

думаю так нагляднее будет.
а потом пользовательский материал склеится с дефолтным, или же будет использован только дефолтный, если пользовательский не задан.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-12-2019 в 18:18:

Пиши параллельно документацию по системе шейдеров и материалов.

Отправлено Дядя Миша 04-12-2019 в 08:04:

Переписал систему материалов, теперь все бленды и прочее под полным контролем. Сказал бы мне кто раньше, что можно кутришные шейдеры описать простой автозаменой, я бы удивился и неповерил.
Вот вам файлик, для примера, который это делает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-12-2019 в 18:42:

Дописал скрипты для кутришных шейдеров. звучит конечно забавно, скрипты для скриптов. Ну я там даже некоторые оптимизации замутил, например удаление лишних стадий. Теперь надо небо сделать модное, со сменой времени суток, ну и не только. Какая же игра без скайбокса.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 05-12-2019 в 22:23:

Дядя Миша так ты не скажешь, почему на кутришной карте фпс был в 3 раза выше, чем на хлбсп?

Отправлено Дядя Миша 06-12-2019 в 07:21:

ncuxonaT позже скажу. У меня сейчас пока другие задачи, лоадер так толком и не доделат.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-12-2019 в 18:27:

С небом вот какая штука. Раз уж мы рисуем его из как кубическую карту из шейдера, то все вот эти древние ухищрения с проекцией текстурных координат просто идут лесом. Нам не нужно строить какие-то грёбаные виртуальные кубы в пространстве чтобы нарисовать скайбокс, мы в состоянии спроецировать кубемапу вообще на любой полигон.
Это сильно упрощает дело. Надо только придумать с облаками еще.
Можно ли им налету сгенерить координаты по полусфере.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 07-12-2019 в 19:36:

Дядя Миша
Скажи, а система материалов позволяет/ит прописать gl_nearest заданному набору текстур?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 07-12-2019 в 21:10:

thambs
Во фрагментном шейдере же ступенек намутишь.

Отправлено Дядя Миша 08-12-2019 в 11:02:

thambs на каждый юнит можно добавлять нужные текстурные флаги, в том числе и TF_NEAREST конечно. Можно эти флаги обвернуть в условие с кваром например. Т.е. в дополнение к gl_texture_nearest.

Добавлено 08-12-2019 в 14:00:

Прекрасно получилилось всё спроецировать на плоскость. Я вообще удивлён, что спустя столько лет, народ до сих пор копипастит эту херню с генерацией координат на кубе, сферы для облаков и прочее. Оно вообще не нужно, достаточно нарисовать просто полигон неба, как его поставил маппер и спроецировать туда скайбокс и облака. И помоему качество таких облаков даже выше, ведь полусфера имеет конечный шаг тесселяции, а тут у нас попиксельное совпадение. Второй несомненный плюс - небесная поверхность рисуется со включённой записью в буффер глубины, а значит сквозь нее не будет ничего просвечивать, значит плевать на порядок отрисовки.

Добавлено 08-12-2019 в 14:02:

Да и разумеется теперь задники грузятся в единую кубемапу, а не в отдельные шесть текстур. Фактически можно сказать, что я нарисовал небо, не модифицируя движок. Опять всё в скриптах и шейдере.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-12-2019 в 12:04:

Цитата:

Дядя Миша писал:
Фактически можно сказать, что я нарисовал небо, не модифицируя движок. Опять всё в скриптах и шейдере.

Ты ещё скажи что щас это обратно в Xash3D и XashXT подключишь)))

Отправлено Дядя Миша 08-12-2019 в 16:06:

Crystallize нет конечно.

Добавлено 08-12-2019 в 19:06:

Остался у меня только autoSprite2. Ух и вредная пакость, вроде ерунда, а на GPU хрен переложишь.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 09-12-2019 в 19:38:

Вот кстати еще хрень какая с автоспрайтами. В идеале предполагается, что автоспрайт будет иметь всегда четыре вертекса. Но есть вот карта XPac_Bt (Black Town), так вот там вертексов произвольное кол-во. Ну и чтобы вы думали? Ку3 надрывается, про odd vertex count, но тем не менее всё исправно рисует. Я долго не мог одуплить почему. А потом дошло. Я жы генерю ему секвенцию как набор трианглов. А надо как набор квадов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 11-12-2019 в 19:02:

В ку3-шных шейдерах была одна очень серъезная архитектурная проблема - шейдер на вход принимал не только имя, собсно, шейдера, но и номер лайтмапы. Причём, как вы догадываетесь, использование лайтмапы могло быть попросту отключено из самого шейдера. Дело тут вот в чём - повертексное освещение считалось компилятором для всех поверхностей. А вот лайтмапа кое-где скипалась, ну скажем миск-модели. То есть с лайтмапы на вертекс можно было переключиться всегда, а вот наоборот - нет. Но это полдела. Как вы понимаете, если уж шейдер объявлен пользователем, то там такие фокусы не проходят - прописал лайтмапу, значит будет лайтмапа. Или вертекс. Или всё вместе. А вот если шейдер был имплиситным - там начинались чудеса. Покроет дизайнер одной и той же текстурой стенку и модель какую-то, и генерируются для одного и того же материала два шейдера - с повертексным и с лайтмапным. Вторая проблема еще и в том, что шейдеры генерировались не для материала, а для сурфейса. Что в общем случае дольше. У себя я решил эту проблему достаточно просто - передал в юниформ номер страницы атласа. Тесселятор все чекает номер лайтмапы и останавливается, если он не совпал, а мы просто таким образом смотрим, раз -1 - значит повертексное. -2 - фуллбрайт ну или что-то в этом роде. Условие статичное, на производительность не влияет.

Добавлено 11-12-2019 в 22:02:

Вообще там много было весёлого. Например q3map2 зачем-то линкует сурфейсы бмоделей к лифам. Вот этого вот я вообще не понял. Может это конечно такие специальные лифы в общей куче, которые в дереве не участвуют. Ну знаете как построить фейковое дерево? Аллокнуть аутсайд ноду и к ней прилинковать лиф или вообще просто один лиф аллокнуть. Когда мы используем обход дерева это и не влияет, но я давно уже линейно обхожу лифы, поскольку это гораздо быстрее для отрисовки. Ну и видимо вот эти тоже задел.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 12-12-2019 в 09:02:

Похоже мне удалось-таки преодолеть главный затык в написании нового движка. Если я засматривался в какой-то степени на кутришный формат уровней, меня преследовала мысль, что это придется тащить кутришные материалы, а мне бы этого совсем нехотелось. Теперь же, когда материалы описаны в скрипте, соответственно проблемы никакой нет, рендерер остался генеричным. Значит можно и дальше двигаться в этом направлении.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 13-12-2019 в 09:07:

В халфе с точки зрения современной системы материалов, самая великая мерзость - вот эти рендермоды. Мало того, их еще и налиту переключать можно, что совсем уже за гранью. Для простейших материалов из одной диффузки это не имеет никакого значения. Но уже в ку3 эту тему дропнули.
С одной стороны - это просто такой способ задать прозрачность. С другой - одни и те же диффузки могут быть как прозрачными так и непрозрачными, вот в чём штука. И заранее это определить невозможно. Хранить по две копии материала для непрозрачных и прозрачных случаев - тоже глупость какая-то. Разве что в шейдер протащить эти рендермоды.
Но мне эта затея представляется небесспорной в том плане, что я возможно вообще дропну все эти старые материалы и рендермоды в плане их поддержки. Прозрачность регулировать из объекта - это пожалуйста, тут никаких проблем, но переключателя солид\транс точно быть не должно налиту. Впрочем можно провести любопытный эксперимент: прописать пресеты материалам исходя из их предназначения и поглядеть сколько будет мест, где это зафейлится. Стёкла, решётки там.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 13-12-2019 в 09:13:

>переключателя солид\транс
А это вообще хоть где-то используется?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 13-12-2019 в 09:18:

Цитата:

thambs писал:
А это вообще хоть где-то используется?

думаю нет. env_render юзали, чёб спрятать объект в основном. Ставили прозрачность на ноль.

Я вот еще думаю, оставить в движке формат текстур только DDS, а остальные форматы вынести в утилитку для конвертации. Как у вас workflow устроен, не будет ли это неудобно? Мне Элбер как-то доказывал, что ему TGA просто необходим.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 13-12-2019 в 09:40:

Цитата:

Дядя Миша писал:
Мне Элбер как-то доказывал, что ему TGA просто необходим.

Из ХЛ2 текстуры тащить?

Отправлено Дядя Миша 13-12-2019 в 09:42:

ксаш-тулзы кстати умеют конвертировать VTF->DDS без дополнительных операций.

Добавлено 13-12-2019 в 12:42:

Нет, ну вот скажем взять сталкер, там DDS-only и ничо, никто не жалуется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-12-2019 в 09:55:

Цитата:

Дядя Миша писал:
Я вот еще думаю, оставить в движке формат текстур только DDS, а остальные форматы вынести в утилитку для конвертации. Как у вас workflow устроен, не будет ли это неудобно? Мне Элбер как-то доказывал, что ему TGA просто необходим.

Если нормальный dds плагин для фотошопа найдешь

Отправлено thambs 13-12-2019 в 10:53:

Дядя Миша
tga оставь, удобней с ним работать и его все вьюеры видят, а в dds уже финалку перегонять.

Цитата:

Как у вас workflow устроен, не будет ли это неудобно?

Сейчас у меня вадники с превьюхами (что совсем неудобно) + tga/dds фулсайзы, с q3 форматом будет удобней держать в tga превьюхи для джека аля вад, а в игре грузить ddsки (при их наличии).

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено FiEctro 13-12-2019 в 10:58:

Кстати да, а джек то dds держит?

Отправлено Дядя Миша 13-12-2019 в 11:12:

Да должен поидее. Мне вот любопытно что никто BMP не любит, хотя он и в паинте открывается и превьюшки для него видны.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 13-12-2019 в 11:16:

Да, мне в любом случае из джека удобней работать с превьюхами, т.к. у них масштаб в основном 1тексель==1юнит.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено FiEctro 13-12-2019 в 12:31:

Цитата:

Дядя Миша писал:
Да должен поидее. Мне вот любопытно что никто BMP не любит, хотя он и в паинте открывается и превьюшки для него видны.

Да все его любят, вот только не весил бы он столько много. Твоя позиция то понятна, ты подгрузил и забыл. А разработчикам надо рисовать эти текстуры, параллельно просматривая как смотрятся они в игре, накладывать их в редакторе, а если ты получил пак текстур от другого человека или проекта, то имена тебе ничего не говорят. Приходится открывать вручную каждую, а в случае с dds ещё и конвертировать.

Отправлено Дядя Миша 13-12-2019 в 13:33:

Цитата:

FiEctro писал:
Да все его любят, вот только не весил бы он столько много

ровно столько же, сколько TGA, плюс\минус 100 байт. Но TGA все любят, а BMP отчего-то нет.

Добавлено 13-12-2019 в 16:33:

Цитата:

FiEctro писал:
Приходится открывать вручную каждую, а в случае с dds ещё и конвертировать.

ну я естественно дам пакетный умный конвертор, который будет не просто пережимать в DXT, но еще и смотреть даты, типа какой файлиг новее, надо ли обновлять, сам будет подбирать оптимальный режим сжатия, возиться и.т.д.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-12-2019 в 13:33:

Под аббревиатурой BMP же скрывается зоопарк форматов. Сложно такое надувательство любить.

Отправлено Дядя Миша 13-12-2019 в 13:35:

Цитата:

nemyax писал:
Под аббревиатурой BMP же скрывается зоопарк форматов

почему запарк-то? Три формата всего BM3, BM4 и BM5. Причём последние два юзает только линукс отчего-то. А Паинт хотя и умеет их открывать, но никогда в них не сохраняет, может в реестре где-то галка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Government-Man 13-12-2019 в 13:50:

Вообще странно видеть как в наше время, когда любая программа, умеющая открывать картинки, наверняка умеет еще и конвертировать целую тучу форматов, люди мучаются выбором формата для импорта.

Понятно, что когда люди сами рисуют текстуры, они это делают в программе типа фотошопа, и им не составит труда сохранить их в формате удобном для движка. Вся эта поддержка кучи форматов нужна только текстуроворам, которые воруют картинки из других игр, программ и интернета.

Движок конечно должен хранить текстуры в своем формате, это будет гораздо гибче, если ты вдруг решишь хранить в файлах текстур какие-либо еще данные, помимо собственно изображения. А импортировать/конвертировать надо из нескольких самых распространенных форматов типа PNG, BMP, TGA, JPG... Хотя я хочу посмотреть в глаза тому человеку который импортирует текстуры из JPG

ЗЫ. Дядя Миша
Кстати очень интересня тема, спасибо что решил завести блог, очень интересно следить за ходом социалистической мысли так сказать в прямом эфире!

Меня только мучает один вопрос... Я несколько лет не следил за твоей деятельностью и хорошо помню времена, когда ты писал исключительно на чистом Си. И я был шокирован, когда прочитал твои рассуждения о шаблонах и классах (да еще и абстрактных!) что стряслось?..

Кстати ты не думал выложить проект на гитхаб? Там мы могли бы напрямую наблюдать развитие движка, а также запиливать баг-репорты и пул-реквесты

Отправлено Дядя Миша 13-12-2019 в 14:01:

Ладно, используя возможности новой системы (я её условно-абстрактно назвал словарь замен), накидал вот такую вот штуку:

C++ Source Code:

1	#keydef renderMode kRenderTransTexture\

2	blendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA );\

3	depthMask( GL_FALSE );\

4	addShaderDefine( LIGHTING_FULLBRIGHT );\

5	addShaderDefine( ADDITIVE );

правда, как вы понимаете, я не смогу это переключать налиту, но смогу жёстко прописать в те материалы, которые по смыслу используют прозрачность. Примерно так:

C++ Source Code:

1	generic108

3	renderMode kRenderTransTexture

Это дверца микроволновки. Фиаско будет, если эта же текстура использует где-то еще как часть геометрии уровня

Ну да ладно, я не ставлю себе цели корректного рендеринга халфовских уровней, это так, баловство с целью отладки системы.

Цитата:

Government-Man писал:
и хорошо помню времена, когда ты писал исключительно на чистом Си. И я был шокирован, когда прочитал твои рассуждения о шаблонах и классах (да еще и абстрактных!) что стряслось?..

в каком смысле шокирован? Что ты там такое увидел?

Ничего не стряслось, очевидно мне надоело писать на чистом Си. Решил на крестах для разнообразия. На крестах же что в первую очередь получается хорошо? АТД? Вот я их и наделал как можно больше. Удобно.

Добавлено 13-12-2019 в 16:58:

Цитата:

Government-Man писал:
Кстати ты не думал выложить проект на гитхаб?

пока смысла в том не вижу. Может через год вернёмся к этой теме.

Добавлено 13-12-2019 в 17:01:

А насчёт жесткого прописывания материалов - моя попитка закончилась буквально в пределах одной карты c1a0d. Там жеж какие-то умники текстуру table2 заюзали как для стола, на котором стоит микроволновка, так и для защитных полос, закрывающих костюм Гордона.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 13-12-2019 в 14:20:

Дядя Миша TGA, тем более его реализация в Ксаше, умеет RLE(или мы это сами запилили, я уже чот не помню) , а компрессию в BMP почти никто не реализует, хотя там есть соответствующий biCompression.

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 13-12-2019 в 14:26:

Там точто такой же RLE, но мне не попадалось сжатых BMP, это редкость.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Government-Man 13-12-2019 в 14:47:

Цитата:

Дядя Миша писал:
Решил на крестах для разнообразия

Смотри, так еще на директикс перейдешь для разнообразия

По поводу текстур, мое мнение: игра которую юзверь запускает на своем компе (или другом устройстве) должна хранить текстуры в формате, который пригоден для того, чтобы напрямую скормить его графическому АПИ без всяких лишних телодвижений. Поскольку платформ и форматов в теории может быть великое множество, чаще всего удобнее именно свой формат, который все это поддерживает.

Отправлено Дядя Миша 13-12-2019 в 15:11:

Цитата:

Government-Man писал:
игра которую юзверь запускает на своем компе (или другом устройстве) должна хранить текстуры в формате, который пригоден для того, чтобы напрямую скормить его графическому АПИ без всяких лишних телодвижений

с этим никто и не спорит. Но юзвери вон жалуются, неудобно им.

Цитата:

Government-Man писал:
на директикс перейдешь для разнообразия

Ну для GL я могу на XP подключать любую версию, ну может не прям любую, но выше 3.30. А с DX - хрена. К тому же моё мнение насчёт DX было сильно подпорчено, когда я узнал, что там тоже есть расширения как в GL.
То есть, я когда-то рассуждал как Ксерокс, ну мол хорошо, в пределах версии он не гибкий, зато стабильный на любом железе. Да щас прямо.
Те же яйца абсолютно. Любую идею можно испохабить.

Добавлено 13-12-2019 в 18:11:

Так что там с шаблонами не так?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Government-Man 13-12-2019 в 15:13:

Цитата:

Дядя Миша писал:
Так что там с шаблонами не так?

Так я удивляюсь самому факту того, что ты начал их применять.

Отправлено nemyax 13-12-2019 в 15:14:

Плюсы на венде ещё и в более шустрые бинарники компилятся, чем сишечка.

Отправлено Crystallize 13-12-2019 в 16:14:

Цитата:

Дядя Миша писал:
Но TGA все любят, а BMP отчего-то нет.

Он многослойный. Многоканальный.

Отправлено Government-Man 13-12-2019 в 17:02:

Цитата:

Дядя Миша писал:
Но юзвери вон жалуются, неудобно им

Так сделай им конвертер или импортер.

Отправлено thambs 13-12-2019 в 17:02:

Цитата:

Но юзвери вон жалуются, неудобно им

Не, ну надо просто приоритет dds>tga. Tga удобно именно при разработке и lowres-превьюх в джеке что бы не прописывать шойдеры с масштабированием; тем более, не знаю как там сейчас, но когда я экспериментировал с ку3-форматом несколько лет назад, он текстуры с разрешениями 2048..4096 грузил как-то долго.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 13-12-2019 в 17:18:

Цитата:

Government-Man писал:
Так я удивляюсь самому факту того, что ты начал их применять.

Я их в одном месте по сути заюзал - в конструкторе вертекс-форматов для VBO. Ну и во всяких АТД, типа деномических массивов, но там итак понятно.

Добавлено 13-12-2019 в 20:16:

В шестёрке шаблоны это тихий ужос, к слову. Пока я писал на чистом Си, было вообще пофигу, а тут очень многие вещи повылазили.

Цитата:

Crystallize писал:
Он многослойный. Многоканальный.

Хто?

Цитата:

Government-Man писал:
Так сделай им конвертер или импортер.

Так об это же и речь, что они нехотят запускать конвентор каждый раз, когда отредактируют текстуру.

Добавлено 13-12-2019 в 20:18:

Government-Man между прочим очень правильную вещь сказал, насчёт нативного формата, я к примеру в DDS сохраняю reflectivity и еще кой-чего помелочи. Там всё равно дофига резервных полей. Причём DDS может быть и несжатый, если это нужно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-12-2019 в 17:26:

Цитата:

Дядя Миша писал:
В шестёрке шаблоны это тихий ужос, к слову.

Например?

Отправлено Дядя Миша 13-12-2019 в 17:58:

nemyax половина конструкций, валидных с точки зрения языка не работает. Я специально гуглил те или иные примеры, которые должны работать корректно, но в шестёрке оно либо не компилится, либо падает.
И typeof какие-то идиотские имена порой возвращает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Government-Man 13-12-2019 в 18:05:

Цитата:

Дядя Миша писал:
Так об это же и речь, что они нехотят запускать конвентор каждый раз, когда отредактируют текстуру.

Тогда надо сделать кнопку "сконвертить все" чтобы она шерстила папку с сорцами, сравнивала даты и конвертила только те текстуры что изменились. Тогда после любого редактирования нужно будет только щелкнуть по экзешнику.

Отправлено thambs 13-12-2019 в 18:10:

Дядя Миша
А чому ты clang не хочешь использовать?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 13-12-2019 в 18:15:

Дядя Миша
А я тебе говорил, возьми хотя бы дивятку =)
У меня в ей правда шаблонные методы не линковались, если определения были вынесены в .cpp. Если всё определяется при объявлении в заголовке, то ок. Не знаю, баг ли это или норма.

Отправлено Crystallize 13-12-2019 в 18:41:

Цитата:

Дядя Миша писал:
Хто?

формат TGA поддерживает альфу в отличие от BMP.

Отправлено Дядя Миша 13-12-2019 в 19:19:

Цитата:

Government-Man писал:
Тогда надо сделать кнопку "сконвертить все" чтобы она шерстила папку с сорцами, сравнивала даты и конвертила только те текстуры что изменились. Тогда после любого редактирования нужно будет только щелкнуть по экзешнику.

да я собсно, именно такую утилиту и сделал, и народ один хрен недоволен, что её надо лаунчить.

Цитата:

Crystallize писал:
формат TGA поддерживает альфу в отличие от BMP.

Цитата:

thambs писал:
А чому ты clang не хочешь использовать?

та я не знаю что это

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Government-Man 13-12-2019 в 19:35:

Цитата:

Дядя Миша писал:
народ один хрен недоволен, что её надо лаунчить

А как должно быть-то?

Отправлено Ku2zoff 13-12-2019 в 22:25:

Цитата:

Crystallize писал:
формат TGA поддерживает альфу в отличие от BMP.

32-битные BMP прекрасно поддерживают альфа-канал. Как, собсно, и 32-битные TGA.

Отправлено a1batross 14-12-2019 в 03:43:

Дядя Мишав том-то и дело, что сжатый BMP настолько редкость, что его никто не поддерживает. Чего не сказать о тарге.

А я думал ты с шестёрки всё же ушёл на современную студию. %)

Добавлено 14-12-2019 в 06:43:

nemyax это не баг. Так и должно быть, это плюсы такие.

__________________
Xash3D FWGS форк

Отправлено Ku2zoff 14-12-2019 в 07:20:

Цитата:

a1batross писал:
сжатый BMP настолько редкость, что его никто не поддерживает. Чего не сказать о тарге.

RLE сжатие, ИМХО, не очень хороший вариант для полноцветных текстур с плавными переходами. Лучше сжимать файлы непосредственно форматом игрового архива.

Отправлено Crystallize 14-12-2019 в 08:30:

Цитата:

Ku2zoff писал:
32-битные BMP прекрасно поддерживают альфа-канал. Как, собсно, и 32-битные TGA.

Так и знал что узнаю для себя что-то новое.

Отправлено Дядя Миша 14-12-2019 в 09:39:

Цитата:

Government-Man писал:
А как должно быть-то?

как мне говорил Элбер - запуск конвертора всё равно лишняя операция. Можно его добавить в батник на запуск движка, но он будет всё равно какое-то время провирять не изменились ли текстуры. Хоть полсекунды, а лаг.

Цитата:

a1batross писал:
А я думал ты с шестёрки всё же ушёл на современную студию.

пока не вижу смысла. Это опять всё перенастраивать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 14-12-2019 в 11:27:

Цитата:

Ku2zoff писал:
RLE сжатие, ИМХО, не очень хороший вариант для полноцветных текстур с плавными переходами. Лучше сжимать файлы непосредственно форматом игрового архива.

Не вижу смысла, всеравно оно потом разжимается и жрёт оперативку и видеопамять.

Отправлено Government-Man 14-12-2019 в 11:45:

Цитата:

Дядя Миша писал:
запуск конвертора всё равно лишняя операция. Можно его добавить в батник на запуск движка, но он будет всё равно какое-то время провирять не изменились ли текстуры. Хоть полсекунды, а лаг.

А ничего, что железо не понимает ни пнг ни жпг, и при загрузке их по любому придется разжимать, читай: выполнять ту же конверсию на лету каждый раз при запуске.

Видимо юзеров бесит что между запуском экзешника и появлением окна проходит время. Запили тогда конверсию в движок и отложи до времени загрузки - когда текстура грузится, она проверяет есть ли в сорцах более свежая версия, если есть конвертит ее и грузит.

Отправлено Дядя Миша 14-12-2019 в 12:17:

Цитата:

Government-Man писал:
А ничего, что железо не понимает ни пнг ни жпг, и при загрузке их по любому придется разжимать

Всё равно вопрос времени, что быстрее - разжать только те текстуры, которые использует конкретный уровень, либо сравнить даты абсолютно всех текстур в игровой папке + загрузить DXT.

Цитата:

Government-Man писал:
когда текстура грузится, она проверяет есть ли в сорцах более свежая версия, если есть конвертит ее и грузит.

так тоже можно, но идея же была в том, чтобы выбросить из движка лишние форматы и вынести их в отдельную утилитку

Добавлено 14-12-2019 в 15:15:

Впрочем полностью избавиться всё равно не получится. Движок, он же не только грузит, он и создаёт картинки: кубемапы, скайбоксы, скриншоты наконец. И если кубические можно сразу сжимать в DXT, то скриншоты наоборот лутьшы в jpg сохранять. Хотя, в тех же сталкерах-метро никто не парится - так и пишут в DXT. Левелшоты так точно, а вот про скриншоты я не помню.

Добавлено 14-12-2019 в 15:17:

Заглянул в xray16-xd там вот такое

C++ Source Code:

1	pcstr extension = "jpg";

2	FREE_IMAGE_FORMAT format = FIF_JPEG;

3	if (strstr(Core.Params, "-ss_png"))

5	extension = "png";

6	format = FIF_PNG;

ну наверное это юзвери сами сделали. Я в упор не помню во что их сохранял оригинальный сталкер.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Government-Man 14-12-2019 в 13:02:

Дядя Миша
По мне так в любом случае удобнее, когда есть отдельная либа, которая умеет работать с картинками, и все кому нужно загрузить или сохранить картинку к ней обращаются.

Отправлено Дядя Миша 14-12-2019 в 13:25:

Ладно. Щас форматы уровней\моделей в приоритете, точнее их разработка. К картинкам всегда можно вернуться. Кстати говоря, я удивлён, что ты мою тему обнаружил только сейчас.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 14-12-2019 в 20:21:

Подключил колоизацию к кутришным картам и моментально столкнулся с залипанием возле чётных сторон брашей. Как в 2008-й год вернулся.
Только тогда я вообще не понимал что происходит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 14-12-2019 в 21:06:

Дядя Миша
А что происходит?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 15-12-2019 в 10:37:

Починил кутришную колоизацию, добавил там эти оффсеты. А проверить очень просто - если коллизия лажает, то расстревалка пишет в консоль Unstick by <offset number>. Для игрока так-то почти незаметно.
Это без овербаунса.

Добавлено 15-12-2019 в 13:37:

Я же TraceWork из паранои заюзал, так что у меня изкаропки будет нормальная коллизия с ротатаблями
А вот с капсулой, к слову, так и не получилось. Уж не знаю, то ли у меня капсула слишком жирная, но игрок имеет тенденцию застревать в некоторых уголках, там где не застревает ббокс.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 15-12-2019 в 12:22:

Дядя Миша
Хулл игрока стало можно менять?

Отправлено Дядя Миша 15-12-2019 в 18:51:

nemyax можно-можно.

Приступил к разработке компилятора уровней. Ну я там естественно тоже хочу все режимы описать функциями, а к привычному виду привести через словарик автозамен. Вообще я так прикинул, если выкинуть оттуда лишние флаги и контентсы, то может получиться вполне неплохой генеричный формат уровней. То есть скажем таких вещей как CONTENTS_WATER|CONTENTS_LAVA быть вообще не должно, подобные вещи пользователь должен в материале описывать. А в компиляторе просто подсказка, что этот браш ликвидный. Ну и всё в таком же духе.
Основная задача на текущий момент - научить его собирать халфовские карты, вы будете смеяться, но кутришные компиляторы дико фейлят от того, что прекрасно собиралось даже ZHLT, порою. Там планесы куда-то корёжит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 15-12-2019 в 20:08:

Дядя Миша
А лайтмэпы по-хэлфовскому или по-кутришному будешь организовывать? Расскажи, плз, про овербаунсы и вообще как вся эта система работает.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Crystallize 16-12-2019 в 07:20:

Дядя Миша Расскажи про чётные стороны брашей.

Отправлено Дядя Миша 16-12-2019 в 08:16:

Цитата:

thambs писал:
А лайтмэпы по-хэлфовскому или по-кутришному будешь организовывать?

не понял. Лайтмапа, она и есть лайтмапа. Вот ежели бы ты спросил, буду ли я делать обычные лайтмапы или сферические гауссовы.

Цитата:

thambs писал:
Расскажи, плз, про овербаунсы

Да нечего особо расказывать, есть в коде игрока вот такая функция.

C++ Source Code:

1	int CBasePlayer :: ClipVelocity( const vec3 &in, const vec3 &normal, vec3 &out, float overbounce )

3	float angle = normal.z;

5	int blocked = 0x00; // Assume unblocked.

7	if( angle > 0 ) SetBits( blocked, 0x01 ); // If the plane that is blocking us has a positive z component, then assume it's a floor.

8	if( angle == 0.0f ) SetBits( blocked, 0x02 ); // If the plane has no Z, it is vertical (wall/step)

10	// Determine how far along plane to slide based on incoming direction.

11	// Scale by overbounce factor.

12	float backoff = DotProduct( in, normal ) * overbounce;

14	for( int i = 0; i < 3; i++ )

16	float change = normal[i] * backoff;

17	out[i] = in[i] - change;

19	// If out velocity is too small, zero it out.

20	if( out[i] > -STOP_EPSILON && out[i] < STOP_EPSILON )

21	out[i] = 0.0f;

24	// Return blocking flags.

25	return blocked;

ну она вообщем-то не только для игрока используется. Во всех кваках она есть. Она хотя и называется ClipVelocity, но мне кажется её уместнее было бы назвать ReflectVelocity. Вообщем она отвечает за скольжение вдоль плоскости стены. Параметр овербаунс равен еденичке, если поставить его немного больше, скажем 1.1, то игрока будет слегка отталкивать от плоскости. Поэтому в ку3 прыжки на стенку такие "деномичные". Ну и плюс он после каждого прыжка немного приседает, это тоже вносит свой вклад, хотя к физике отношения не имеет.

Цитата:

Crystallize писал:
Расскажи про чётные стороны брашей.

В ку3 планесы хранятся в определённом порядке, цитата из qfiles.h

Цитата:

// planes x^1 is allways the opposite of plane x

а первые шесть плоскостей любого браша - всегда аксиальные и из них можно вывести bbox этого браша.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 16-12-2019 в 18:56:

Приступил к написанию компилятора уровней. Название придумал хорошее - makebsp. Надо его сперва перевести на нормальные вектора, матрицы и виндинги, устал уже везде писать VectorCopy; Я сперва планировал для него создать отдельную тему, но потом подумал, а что я собственно вам такого смогу про них рассказать? Это у халфы была на компиляторы достаточно богатая история. Для кутри всего две штуки их - q3map и q3map2. Не о чем писать особо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 17-12-2019 в 06:58:

Цитата:

Дядя Миша писал:
а первые шесть плоскостей любого браша - всегда аксиальные и из них можно вывести bbox этого браша.

А как это приводит к застреванию у чётных сторон?

Отправлено Дядя Миша 17-12-2019 в 20:05:

Вообще q3map2 занимается удивительной глупостью. Вместо того чтобы в своё время имплементировать нормальный инклуд .map файлов в основную карту, юзерам предложили такое корявое решение: делаем карту-префаб, "компилируем" её в ase (по сути просто выкидываем структурные фейсы), затем этот ase вставляем в новый префаб, затем в новый и так у нас в итоге получается конечный префаб, сложно-составной. Минус подхода очевиден - если понадобится внести изменения в самую базовую частичку такого префаба - придётся перекомпиливать вообще всё заново, значит создавать какие-то кучи батников и что немаловажно - всё время следить за порядком их компиляции, иначе ерунда получится. Я еще в 18-м году рассудил, что это полная ерунда и в параноевские компиляторы замутил полноценный инклуд map-файлов. А теперь значит настала пора это и в сам ку3 внедрить

Добавлено 17-12-2019 в 22:32:

Хотя я кажется догадываюсь, почему этого не было сделано. У автора q3map2 были какие-то сложности с матрицами, он сам там писал в каментах благодарности, типа спасибо, что матрицы помогли настроить.
Ну а о том, чтобы корректно трансформировать брашы, видимо даже и речи не шло.

Добавлено 17-12-2019 в 23:05:

В q3map2 так и не порезали триангл-модели плоскостью тумана, ох жэсть какая. 19 лет прошло, а конь так и не валялся.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 18-12-2019 в 09:58:

Засела мне тут одна мысль в башку. Ведь турбулентность-завихрения, по идее можно реализовать в пиксельном шейдере безо всякого там субдивайда. Ну в софтварной кваке же его не было.

Добавлено 18-12-2019 в 12:58:

вообще конечно так посмотришь эти фантазии на тему форков - какой жы лютый мрак, они все тащут эту копипасту из первого-второго-третьего квейка, и конечно жы кутришные шейдеры. И всё это практически в неизменном виде, никаких попыток переосмыслить. В лучшем случае это будет копипаста из третьего дуум как в овердозе. Я ведь собственно, почему так долго раскочегаривался с XashNT - не хотел идти их путём. Зачем это нужно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 18-12-2019 в 10:11:

Цитата:

Дядя Миша писал:
вообще конечно так посмотришь эти фантазии на тему форков - какой жы лютый мрак, они все тащут эту копипасту из первого-второго-третьего квейка, и конечно жы кутришные шейдеры. И всё это практически в неизменном виде, никаких попыток переосмыслить.

Наверное для совместимости

Отправлено Дядя Миша 18-12-2019 в 18:48:

Предсказания плюшевого пророка

Тогда еще, когда я только начинал строить свой движок, году примерно в 2007-м, как вы помните, я тогда задался целью всё построить на Dll Hell.
Ну чтобы значит эти дллки с унифицированными интерфейсами, чтобы всё грузилось так и эдак, в зависимости от того, какая часть движка их использует. И на геймдеве советовался с тогдашними опытными участниками, как мне лучше поступить. И вот один из них мне сказал, рано или поздно ты придёшь к тому, чтобы поместить всё в единый экзешник и не маяться этой дурью с библиотеками. Но я ему тогда конечно не очень поверил.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 18-12-2019 в 19:01:

Ага, особенно моды и VGUI

Отправлено Ku2zoff 18-12-2019 в 21:08:

Цитата:

Дядя Миша писал:
дллки с унифицированными интерфейсами, чтобы всё грузилось так и эдак, в зависимости от того, какая часть движка их использует

Всё зависит от того, что конкретно должно быть доступно стороннему разработчику. При желании, можно не только игровую логику и худ, как изначально было в халфе, но и рендерер с частью физики (как в сделано в новых версиях хлсдк) вынести. Ну то есть, что на данный момент имеется? Логика, худ, рендерер частично и физика частично (pm_shared). По-хорошему, это всё должно быть вынесено в пользовательские длл, чтобы без хаков делать разные плюшки. А всякая низкоуровневая бяка, типа файловой системы, сети, всякой жудкой математики, да даже звуковой движок, пусть будут в дллке движка, или даже в экзешнике.

Отправлено nemyax 18-12-2019 в 21:11:

Если с другой стороны поглядеть, один разработчик — одна исполняшка. Идеальный баланс.

Отправлено FiEctro 19-12-2019 в 09:54:

Цитата:

nemyax писал:
Если с другой стороны поглядеть, один разработчик — одна исполняшка. Идеальный баланс.

И многочасовая компиляция.

Отправлено nemyax 19-12-2019 в 11:11:

FiEctro
Не в случае ксаша. Ты собирал ксаш и ксашмод?

Отправлено Дядя Миша 19-12-2019 в 11:27:

Я почему-то считаю, что юзеры вообще не хотят ничего кодить, абсолютно. Максимум скриптов понаписать. То есть вот взять даже монстров. Никто не хочет писать нового монстра. Нет, вы мне дайте такой скрипт, чтобы там можно было кастомизировать поведение базового и этого обычно достаточно. В этом конечно плане самые разнообразные монстры были пожалуй в первой кваке, одни кусают, другие мечом лупят, третие через пропасти прыгают, зомбей вообще убить невозможно. В халфе из всех монстров только барнакль так выделялся. Ну и может быть еще тентакли, но они скриптовые.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-12-2019 в 11:32:

Дядя Миша

Цитата:

Дядя Миша писал:
Я почему-то считаю, что юзеры вообще не хотят ничего кодить, абсолютно.

На юнити хотят, на геймейкере хотят, а вот на ксаше не хотят. Вот гады, да?

Отправлено Дядя Миша 19-12-2019 в 11:44:

Цитата:

FiEctro писал:
На юнити хотят, на геймейкере хотят

Не лжы. На юнити все покупают ассеты. В том числе и скриптовые.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-12-2019 в 12:24:

Цитата:

Дядя Миша писал:
Не лжы. На юнити все покупают ассеты. В том числе и скриптовые.

А ассеты по твоему кто пишет? Корова которая в рике утонула?

Отправлено Дядя Миша 19-12-2019 в 12:36:

Ассеты пишут в рассчёте на множественные продажы, хех.
Не для себя в основном. Этоже гораздо проще чем сделать целую игру и гадать выстрелит она или нет. А так сделал ассет и продавай себе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-12-2019 в 16:33:

Цитата:

Дядя Миша писал:
Ассеты пишут в рассчёте на множественные продажы, хех.
Не для себя в основном. Этоже гораздо проще чем сделать целую игру и гадать выстрелит она или нет. А так сделал ассет и продавай себе.

Есть не меньше бесплатных ассетов

Отправлено Дядя Миша 19-12-2019 в 17:20:

Цитата:

FiEctro писал:
Есть не меньше бесплатных ассетов

помогли они тебе сделать игру на Юнити?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-12-2019 в 17:51:

Дядя Миша
Отчасти

Отправлено KiQ 22-12-2019 в 18:06:

Ну я бы с удовольствием вернулся к кодингу на ксаше, особенно с учётом последних изменений, когда будет стабильный билд. Я вообще всегда больше любил поковыряться в коде, чем рисовать текстурки и прочие ресурсы, поэтому много моих проектов так и загнулись - какая-никакая кодовая база была, а ресурсов нет. Вспомнить хотя бы сколько я тем запостил с различными фишками, типа аптечки с собой, фикс модельки в GUI, куфантомасу вот кваковскую физику приделали с распрыгом и дабл-джампом, тулово от первого лица, да и много чего

__________________
-Brain is dead-

Отправлено Дядя Миша 22-12-2019 в 18:38:

KiQ в этом-то и проблема, что твое творчество не найдет выхода без ресурсов. Надо наоборот, пусть лучше не кодят, но чтобы игра получилась.
Хоть какая-нибудь. Я согласен даже на самую лучшую игру всех времён и народов. Даже на игру, которую мы заслужили вместе с тобой.

Добавлено 22-12-2019 в 21:38:

Вспомнил про X-Real, дай думаю скачаю, посмотрю, как оно. Я еще смутно припоминаю, что они там слегка модифицировали кутришный формат карт, но щас глянул - ничего подобного, всё родное. Но материалы - из Doom3.
Так что будет мне еще дополнительный стресс-тест для словарика - подключить дуумтришные материалы простой автозаменой терминов и регулярных выражений

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 24-12-2019 в 11:27:

Как выяснилось, в XreaL уже присутствуют guide, такие однострочные выражения, которые потом распахиваются во вполне полноценные описания.
Ну особой проблемы они не составили - я просто слегка доработал парсер, чтобы он мог учитывать не только автозамену внутри секции, но и снаружи её. Правда это получается как бы две стадии - на первой стадии материалы парсятся в память и происходит частичная автозамена, на случай вот таких вот гайдов. А уже полноценная делается когда материал реально запрошен из загрузчика моделей.
Впрочем у меня еще тут таблицы и регулярные выражения, надо подумать как бы это красиво оформить. Есть небольшая проблемка - в таблицах может быть сколько угодно элементов, а мой парсер регулярных выражений базируется на строгом соответствии кол-ва аргументов. Возможно надо ввести что-то типа VA, три точки или типа тово.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 26-12-2019 в 15:16:

Разбираюсь с этой мешаниной, которую в XreaL натворили, скрестив кутришные шейдеры и дуумтришные материалы, обратил внимание вот на какой любопытный аспект. В ку3 шейдеры были генеричные - ты сам управлял какую стадию с какой смешать - парсер в это дело не вмешивался.
А здесь, ну начнём с того, что можно писать diffusemap, bumpmap и specularmap в любом порядке - пофиг, всё равно смешается правильно, лайтмапа вообще не указывается явно, она всегда подразумевается в режиме статичного освещения. Т.е. таким образом, несмотря на кажущуюся сложность этой системы, она даже более проста в переложении, поскольку оставляет куда меньше пространства для манёвра с точки зрения пользователя. Основная свобода там в задании этих условий динамических и регулярных выражений. Всё остальное нацелено на то, чтобы писать как можно короче.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 27-12-2019 в 08:47:

Дядя Миша

Цитата:

Возможно надо ввести что-то типа VA, три точки или типа тово.

В Си есть есть #define foo(...) bar(__VA_ARGS__). Вполне подойдёт думаю для твоей макросовой автоподмены, да.

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 27-12-2019 в 12:46:

Я уже отказался от этой идеи поправде говоря. Мой парсер в состоянии заменять только целые строки, а таблицы зачастую идут с переносом, фактически мне надо будет детектировать блок текста с очень нечёткими условиями, плюнул и распарсил эти таблички как есть, в дуумтришном формате, к тому же, насколько я в курсе больше никто и никогда ничем подобным не занимался, так что их не бывает разных видов.
Но. Эти же va могут пригодится например для переноса регулярных выражений в юниформы, там-то всё на одной строчке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 27-12-2019 в 20:22:

Добавил дуумтришные регулярные выражения для записи в юниформы.
Ну там если честно, отличие от обычных регулярных выражений - это доступ к таблицам этим. Тут вот какое дело - несмотря на все успехи и достижения GPU-ускорителей, подобные таблицы хранить в них действительно накладно, потому, что как я понимаю, они куда-то там пытаются на стек поместится, и всё начинает дико тормозить на определённом железе. А иногда эти таблички очень даже нужны, да вот хотя бы лайтстили прописать.
Так что я их добавил. Теперь можно их значения в качестве константы пропускать в юниформ, причём писать практически как в GLSL.
Ну например:

C++ Source Code:

vec2 u_MyScrollTexture = vec2( time * 0.03, sinTable[time * 0.6] + 0.5 );

то есть вот даже такое теперь потдерживается, эти значения обновляются каждый кадр и посылаются в шейдер. Но разумеется никто не мешает и в самом шейдере всё это объявлять.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 27-12-2019 в 20:26:

Цитата:

sinTable[time * 0.6]

А это что, там оператор интерполяции внутри какой-та, или?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 27-12-2019 в 20:51:

Похоже на доступ по индексу с неявным приведением. Тогда time это счётчик этих ваших тчинков штоле?

Отправлено Дядя Миша 28-12-2019 в 08:10:

Кармак, когда эти таблички для doom3 делал, явно или неявно руководствовался поведением OpenGL. Интерполятор - часть настроек таблицы, а не модификатор доступа.

Добавлено 28-12-2019 в 11:10:

Цитата:

nemyax писал:
Тогда time это счётчик этих ваших тчинков штоле?

просто игровое время.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 28-12-2019 в 08:46:

Цитата:

Дядя Миша писал:
просто игровое время

Оно у тебя целочисленное? И что тогда означает [time * 0.6]?

Отправлено Дядя Миша 28-12-2019 в 09:16:

nemyax ну что означает? Тоже самое что и в дуум3.

C++ Source Code:

int tableIndex = (int)(cl.time * 0.6);

в подобных скриптах никогда нет явного приведения типов, чтобы не путать пользователей.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 28-12-2019 в 10:03:

Дядя Миша
Так путает же, наоборот. Я вот как взглянул, так о-жид-ал, что квадратные скобки от флоата между двумя точками линейно интерполируют.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 28-12-2019 в 10:30:

Ну по умолчанию оно действительно интерполирует, но вовсе не потому что там float. Это в свойствах самой таблицы задается - интерполировать или нет. Если таблица интерполируемая, там достаточно задать просто 0 и 1 и этого достаточно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 28-12-2019 в 16:18:

Идея с тремя точками отпадает и вот почему. Мой риплейсер позволяет один и тот же входной аргумент размножать на выход сколько угодно раз, если это потребуется. А когда мы задаем входные аргументы вот так

C++ Source Code:

#keydef scroll ... , ...\

vec3 u_texMod<stageNum>_<texModCount> = vec3( <scroll>, <...>, <...> );\

texModCount++;

мы уже сами не можем отличить где первый набор, а где второй. Эта конструкция работает, но я не могу размножить первый набор вар-аргов, например. Нужен другой подход. Например аргумент VA должен начинаться с какого-то особого символа, ну скажем с собаки. Типа такого <@va1>, <@va2>

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 28-12-2019 в 18:22:

Помню в Fenyx Engine у меня тчинки лежали в long, а когда нужно было что-то типа time + 0.6 я флоат переводил в миллисекунды

__________________
-Brain is dead-

Отправлено Дядя Миша 29-12-2019 в 16:41:

Ну чтожы закончил работу над поддержкой особенностей дуумтришных материалов. Теперь каждому юниформу можно задавать регулярное выражение вместо константы. Ну и однострочные материалы, по типу как в сталкере и метро теперь автоматически разворачиваются в нужный вид. А так же внедрена поддержка этих таблиц из дуум3. Ну кстати с табличками можно много чего интересного придумать, в том же XreaL например грозовое небо сделали, которое озаряют отсветы молний. Прикольно смотрится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 29-12-2019 в 16:43:

Цитата:

Дядя Миша писал:
Ну кстати с табличками можно много чего интересного придумать, в том же XreaL например грозовое небо сделали, которое озаряют отсветы молний. Прикольно смотрится.

Кто-то мне годами рассказывал, что все эти эффекты нужны только для мерцающих лампочек и только в моде Жэки. Кто бы это мог быть, не помнишь?

__________________

Отправлено Дядя Миша 05-01-2020 в 10:48:

Собрал bsp, компилю карты, геометрия в порядке, а туман превращает полигоны в кашу. Ну что такое! Опять эта хрень с разной точностью флоата у msvcrt\libc. Как жы мне всё это надоело...

Добавлено 05-01-2020 в 13:48:

Самая пакость начинается, когда приходится подключать сторонние либы, которые уже скомпилены в какой-то таргет и вот он не совпадает с основным приложением.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 05-01-2020 в 12:16:

дай скрин с туманом))
свой компилятор никогда не думал писать?

Отправлено Дядя Миша 05-01-2020 в 14:44:

Цитата:

Crystallize писал:
свой компилятор никогда не думал писать?

я по твоему чем сейчас занимаюсь?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 05-01-2020 в 21:26:

Туман не такой, при котором бочком лучше видно?

Отправлено Дядя Миша 05-01-2020 в 21:42:

nemyax это линейный

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 06-01-2020 в 10:23:

Дядя Миша я имею в виду, компилятор для С\++

Отправлено Дядя Миша 06-01-2020 в 13:22:

Новая напасть. Вот эта карта.
Все стены почему-то з-файтят, даже если к ним применить дефолтный материал лайтмапа+диффузка. Взрыв мозга. Самое смешное, что если я своим текущим компилятором (который в разработке), собираю эту же карту из исходников - ничего не зфайтит. Но и под ванильной кутри ничего не зфайтит. Ну что за бред, вперые в жизни с таким сталкиваюсь.
Как будто там двойная геометрия. Но это еще не самое смешное.

Я сравнил статистику для свежеизготовленной и для оригинальной карты.
И вот по статистике выходит, что на моей, только что собранной в 2 раза больше сурфейсов чем на оригинале. Но з-файтит именно оригинал.
Ничего не понимаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 06-01-2020 в 13:57:

Дядя Миша там на самом деле двойная геометрия, поверх обычной геометрии еще такие же патчи

Отправлено Дядя Миша 06-01-2020 в 14:22:

ncuxonaT а чем ты это смотришь? Я в упор не вижу этого ни в исходнике, ни в ваерфрейме.

Добавлено 06-01-2020 в 17:22:

Думал-думал, как же это дерьмо проверить и придумал.
Всё очень просто. Все эти стены на самом деле сделаны кривыми безье.
То есть, если собирать оригинал-исходник с ключом -nocurves, то стенки просто исчезнут. Я так и поступил - действительно исчезли. Но патчи я не могу посмотреть проволокой, почему, потому что блин код удаляет коллинеарные строки, превращая патч в точто такой же полигон, как и в оригинале, у них же края совпадают. То есть я не увижу вот эту сетку у себя, и в ку3 не увижу - лишние вертексы удалены. Тогда я просто проигнорил патчи при загрузке - не стал их добавлять в VBO. Ну и что? Действительно стены остались на месте, а з-файтинг исчез. Теперь к вопросу откуда взялось это дерьмо. Это очень просто:

C++ Source Code:

q3map_forceMeta

превращает любые поверхности в трианглы. Осталось только понять, а почему собственно, в ку3 не зфайтит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 06-01-2020 в 14:33:

Дядя Миша я сделал конвертер q3bsp в obj, он патчи бьёт с заданным шагом.

Цитата:

Дядя Миша писал:
Осталось только понять, а почему собственно, в ку3 не зфайтит.

Может, там какой материал невидимый на патчах? Или в ку3 для патчей всегда есть оффсет глубины?

Добавлено 06-01-2020 в 17:33:

Ты вот говорил, что в ку3 компиляторы пакуют лайтмапу, просто укладывая прямоугольники. В то же время на этой карте лайтмапа выглядит вот так.

Отправлено Дядя Миша 06-01-2020 в 15:04:

Цитата:

ncuxonaT писал:
Ты вот говорил, что в ку3 компиляторы пакуют лайтмапу, просто укладывая прямоугольники.

прямоугольники укладывает q3map оригинальный. То что ты привёл - это уже q3map2 колдует. Мне нравится. Там походу вплоть до того, что может быть две пересекающиеся лайтмапы, если в месте пересечения цвет идентичный. Хитрая штука.

Цитата:

ncuxonaT писал:
Может, там какой материал невидимый на патчах?

да нет же, патчи это исходные, маппер стенки ими делал. А q3map2 превратил патчи в треугольники, но при этом оригинальные патчи почему-то не удалил

Цитата:

ncuxonaT писал:
Или в ку3 для патчей всегда есть оффсет глубины?

единственное что я знаю - для них там лоддирование есть, они как-то деномически достраиваются.

Добавлено 06-01-2020 в 17:58:

Жованный крот!

C++ Source Code:

1	// we may have a nodraw surface, because they might still need to

2	// be around for movement clipping

3	if(s_worldData.shaders[LittleLong(ds->shaderNum)].surfaceFlags & SURF_NODRAW)

5	surf->data = &skipData;

  return;

это условие именно для патчей. Больше нигде этот флаг не используется.
Ну теперь понятно всё.

Добавлено 06-01-2020 в 18:04:

Это типа хака. Ку3 же не умеет в коллизию по треугольникам, вот и оставили невидимые патчи на всякий случай. Не ожидал такой засады, поправде говоря.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-01-2020 в 10:35:

Приступил к разработке собственного формата BSP.
Здесь у нас некоторые взаимоисключающие требования, но я полагаю, что мне удасться их успешно разрешить. Халфовский формат я дропну, т.к. из-за большого кол-ва лифов и отсутствия стрипификации он на данный момент выступает ключевым тормозом в отрисовке мира. Даже не смотря на мою оптимизацию, о которой я упоминал - построить из видимого хулла визтри, сколлапсировав ноды. Да, непосредственно для BSP29\BSP30 это ОЧЕНЬ хорошая оптимизация, до которой не догадался абсолютно никто, кроме меня, она даёт бууст производительности от 10% до 500%. Но в сравнении с нативным q3bsp скорость отрисовки всё равно в пару раз меньше чем могла бы быть. Далее, если я планирую вставлять модельками куски уровня, ну тот же ЧАЭС из сталкера, очевидно было бы неплохо, если бы BSP посёк эту модельку ну хотя бы на аксиальные сектора 1024\1024, тогда появится возможность отсекать большие площади по фрустуму лифа, даже при условии, что никакой виздаты у нас нет. И разумеется тристрипы для подобных поверхностей. Теперь, собственно, что позитивного у нас осталось в халфовском формате, с чем не хотелось бы расставаться. Ну во первых, конечно жы, как я неоднократно говорил - это сверхбыстрая трасса. К счастью её можно построить прямо в компиляторе света, так что можно не хранить её в карте. Второй момент - вот эти вашы лайтстили. В ку3, как вы помните их не было, но Raven или кто там делал солдат у дачи их добавил в формат максимально неоптимальным образом. Не говоря уже о том, что значительно вырос размер файла, лайтстилей так и осталось ровно четыре штуки. Я хочу сделать систему без лимита на лайтстили. Если уж их реально добавлять.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 07-01-2020 в 10:45:

Дядя Миша
Стрипификация не особенно актуальна на современном железе с жирным TnL кэшем. Если важно гонять индексы по шине - тогда лучше сделать их 16-битными, как в старые-добрые времена.

__________________

Отправлено SNMetamorph 07-01-2020 в 10:48:

А в чем вообще фишка лайтстилей, зачем они нужны?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено XaeroX 07-01-2020 в 10:57:

SNMetamorph
Чтобы лампочки мигали и выключались.

__________________

Отправлено Дядя Миша 07-01-2020 в 10:58:

А, пока не забыл. В качестве контейнера для карт я возьму WAD-файл, поэтому все лумпы будут поименованные, отпадает проблема с нумерацией версий, расположением лумпов и их кол-вом. Ну и бонусом можно будет из любого редактора вадов экспортить куски карты для дальнейшего изучения, а лайтмапы прям сразу в картинки сохранять, например.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 07-01-2020 в 11:04:

Дядя Миша
Но тогда у тебя все будут спрашивать - where is all the data?

__________________

Отправлено SNMetamorph 07-01-2020 в 11:08:

Цитата:

XaeroX писал:
Чтобы лампочки мигали и выключались.

А т.е. эта такая альтернатива динамическим лампочкам, только для статического освещения?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено nemyax 07-01-2020 в 11:08:

XaeroX
Можно будет отвечать: I'll tell you for a WAD of cash.

Отправлено Дядя Миша 07-01-2020 в 11:10:

Цитата:

XaeroX писал:
Стрипификация не особенно актуальна на современном железе с жирным TnL кэшем

та-да-да-да. То-то когда я ЧАЭС дестипифицировал, фпс упал почти что вдвое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 07-01-2020 в 12:45:

Цитата:

SNMetamorph писал:
А т.е. эта такая альтернатива динамическим лампочкам, только для статического освещения?

Это как тот мем "Lol they made X into a real thing"

Добавлено 07-01-2020 в 19:45:

Цитата:

Дядя Миша писал:
Raven или кто там делал солдат у дачи их добавил в формат максимально неоптимальным образом. Не говоря уже о том, что значительно вырос размер файла

Разработчики порта SoF под Дримкаст жаловались что после всех оптимизаций уровни не влазили в память приставки целиком и их пришлось резать на 2-3 части.

Отправлено Дядя Миша 07-01-2020 в 16:06:

Цитата:

Crystallize писал:
Разработчики порта SoF под Дримкаст

то первая часть, она кажется на ку2 была.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-01-2020 в 22:50:

Подключил CSG к компилятору. Первый случай, когда у кутришного компилятора появился CSG
Ну правда на кутришных картах толку от него практически нет. На q3dm1 он смержил мне два каких-то браша, а на q3dm7 - три.
Его истинное предназначение - это конечно карты от халфы и кваки.
Между прочим мне здорово пригодились старые наработки. Я жы когда-то планировал заюзать кудвашный формат уровней для нового ксаша. Ну так дело было за малым - научить его жрать карты от халфы. Да не абы какие, а от Монорейл Квеста, чтобы быть точно уверенным, что оно соберётся.
И соответственно я там уделил большое внимание функции SplitBrush.
А она, что в ку2 что ку3 одинаковая. Ну вот и пригодилось
Теперь надо научить его парсить халфовский и кушный формат карт.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 10-01-2020 в 16:11:

Ну что жы, реализовал рекурсивное вложение карт-префабов для моего нового кутришного компилятора, по аналогии с параноевскими тулзами.
Плюс в том, что можно выбирать поведение - вставлять либо оригинальные модельки, в формате .ase, либо исходники .map если они конечно есть.
С префабами в формате .map есть еще и тот плюс, что для них можно наладить пространство имён и вставлять не просто куски геометрии, а целые отлаженные системы скриптов, например. Эх, научить бы Джек показывать эти префабы
Ксероксу такое nepozubam, а у меня сорцев нету.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 10-01-2020 в 16:12:

Дядя Миша
Круть, а bsp-шки так можно будет?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 10-01-2020 в 16:51:

если определиться с пространством имён, то разницы никакой, что .map при компиляции, что .bsp при загрузке.
Но это очень важный вопрос, представить префаб как набор инпутов-аутпутов. Чтобы если их было много, нигде не пересекались имена, чтобы если часть префаба поехала на другой уровень это не вызвало там проблем, и так далее. Тут нужна целая концепция.

Добавлено 10-01-2020 в 19:51:

ЗЫ, сорс тоже может вкладывать эти префабы нерекурсивно ( 1 уровень вложения), вот надо посмотреть как там пространство имён разрулили.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 10-01-2020 в 17:12:

Дядя Миша
Джек в основном на волатилу нацелен, там нет map-префабов, вот и nepozubam.
По-хорошему надо в Джеке сделать собственную систему префабов, но это пожжы.

Добавлено 11-01-2020 в 00:12:

Цитата:

Дядя Миша писал:
вот надо посмотреть как там пространство имён разрулили.

Вероятно, так же, как в хаммере? Хаммер умеет вкладывать префабы со скриптами, сохраняя связи (см. префаб взрывающегося ящика).

__________________

Отправлено Дядя Миша 10-01-2020 в 18:41:

Неисключено. Надо будет посмотреть как там сделано.

Добавлено 10-01-2020 в 21:38:

Надо еще вот какую штуку сделать. В разных компиляторах существуют разные виртуальные энтити, которые удаляются на этапе компиляции.
Ну самый известный пример это func_group наверное. Ну так вот надо вынести описание этих виртуальных энтить в текстовый файлик и там же простые операции, которые к ним следует применить.
Например - мувнуть брашы в мировую энтить, поставить всем контент-флаг DETAIL, и так далее. Там не так уж и много вариантов. В компиляторе это держать неудобно.

Добавлено 10-01-2020 в 21:41:

В идеале бы вообще сделать, чтобы компилятор читал FGD и там из него брал энтити. Но проблема в том, что во первых у меня нет своего редактора, а во вторых мне активно не нравится сам FGD-формат и я не хочу внедрять его поддержку.
Здесь конечно должна быть реплика с мест "пиши свой редактор". А у меня основная сложность в написании собственного редактора, в том, что я не могу освоить ни хаммер ни радиант. Вот и спрашивается, на что он будет похож?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 10-01-2020 в 18:59:

Цитата:

Дядя Миша писал:
на что он будет похож?

На кварк, разумеется.

__________________

Отправлено nemyax 10-01-2020 в 21:11:

А должен быть на что-то похож? Так и получится очередная кубалка.

Отправлено Crystallize 11-01-2020 в 05:00:

Не думал форкнуть кварк и переделать?

Отправлено Дядя Миша 11-01-2020 в 09:52:

Crystallize я думал о многом, я думал о разном, смоля папироской во мгле!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-01-2020 в 12:59:

Цитата:

Дядя Миша писал:
А у меня основная сложность в написании собственного редактора, в том, что я не могу освоить ни хаммер ни радиант. Вот и спрашивается, на что он будет похож?

Избавься вообще от брашей, оставь разве что BSP модели. Тупо чтобы подгрузить модели расставить их на карте с энтитиями, посчитать VIS и запечь лайтмапу.

Отправлено Дядя Миша 11-01-2020 в 13:12:

Цитата:

FiEctro писал:
Тупо чтобы подгрузить модели расставить их на карте с энтитиями, посчитать VIS и запечь лайтмапу.

да нельзя посчитать виз без брашей, когда же до вас уже это дойдет?

Аксиальная геометрия генерит порталы на своих плоскостях и то возникают сложности с конечной точностью вещественных. Да и потом брашы, всё равно дело хорошее, например для обозначения зон или воды. Вот как ты сделаешь воду без брашей? Подумай хорошенько, это не такой уж и простой вопрос.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 11-01-2020 в 13:28:

Цитата:

Дядя Миша писал:
Вот как ты сделаешь воду без брашей? Подумай хорошенько, это не такой уж и простой вопрос.

В первом Унреале вода делалась без брашей. Не веришь - спроси Скааржа.

__________________

Отправлено SNMetamorph 11-01-2020 в 14:37:

А почему при компиляции получается так много разбиений на открытых пространствах?
Это слабое место BSP подхода, или дело в компиляторах?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 11-01-2020 в 14:47:

Цитата:

XaeroX писал:
В первом Унреале вода делалась без брашей.

В первом унреале был применён подход выгрызания пространства в солидной структуре. Как при таком подходе сделать воду брашами, я не очень понимаю. Вычитательная геометрия не создаёт, а удаляет.

Цитата:

SNMetamorph писал:
А почему при компиляции получается так много разбиений на открытых пространствах?

Разбиений на самом деле немного, то что считаешь разбиением, это субдивайд для лайтмапы. Если сделать геганцкий куб и растянуть текстуру по его размерам, то останутся только аксиальные разбиения с шагом 1024 по дефолту, ну или сколько сам задашь в -maxnodesize.
Т.е. хоть кубик 128х128, хотя 32768х32768, там будет одинаково 6 нодов.

Добавлено 11-01-2020 в 17:47:

SNMetamorph

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 11-01-2020 в 15:45:

Дядя Миша
Аддитивная геометрия там тоже, разумеется, была.
А вода создавалась через zone properties (это точечный актор) между zone portals.

__________________

Отправлено Дядя Миша 11-01-2020 в 16:10:

XaeroX я уже очень смутно помню, была ли вода в UT99.
В первом унреале точно была, там у меня еще один Скарж утонул

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 11-01-2020 в 17:34:

Цитата:

Дядя Миша писал:
я уже очень смутно помню, была ли вода в UT99

Зелёная жыжа на деке 16 точно была.

Отправлено FiEctro 11-01-2020 в 22:40:

Цитата:

Дядя Миша писал:
Да и потом брашы, всё равно дело хорошее, например для обозначения зон или воды. Вот как ты сделаешь воду без брашей? Подумай хорошенько, это не такой уж и простой вопрос.

bbox?

Цитата:

Дядя Миша писал:
да нельзя посчитать виз без брашей, когда же до вас уже это дойдет?
Аксиальная геометрия генерит порталы на своих плоскостях и то возникают сложности с конечной точностью вещественных.

Можно на пальцах? Не очень понятен корень проблемы.

Отправлено Ku2zoff 12-01-2020 в 10:18:

Цитата:

nemyax писал:
Зелёная жыжа на деке 16 точно была.

Если за воду считать лаву, то была, и много. А вообще, есть карта с подводной базой, где штурмующим надо плыть с кислородными баллонами наперевес. Так что вода там была. Ах да, ещё карта со штурмом линкора, который простреливает из пушек ворота в финале. Там тоже вода есть.

Зато я точно знаю одну игру, где воды (в которой можно плавать) нет. СВАЛКЕР. Там только болота по щиколотку, по которым ГГ едва может ходить.

Добавлено 12-01-2020 в 17:18:

Цитата:

Дядя Миша писал:
В первом унреале точно была, там у меня еще один Скарж утонул

Вот чем унреал хорош, так это тем, что НПС в нём хорошо взаимодействуют с миром, а исчо умеют стрейфить и стрелять на ходу. Из всех халфомодов, где такое реализовали, я могу назвать только свенкооп. Кстати, такую фичу хорошо бы в новый движок. Ну чтоб НПС не были на уровне первохалфы: или стоят и стреляют, или бегут и получают по щщам, а дать отбоя не могут.

Отправлено Дядя Миша 12-01-2020 в 10:49:

Цитата:

FiEctro писал:
bbox?

вода не всегда простой формы. Иногда её приходится делать из составных брашей. Например изгибающееся русло реки.

Цитата:

FiEctro писал:
Можно на пальцах? Не очень понятен корень проблемы.

ты порталы собрался генерить из треугольников моделей? Ну так у тебя виз будет год считать. И процентов 95 будет бессмысленной работы.
Альтернатива - расставлять визблокеры вручную. Как в халфе ноды для монстров расставляли. Некоторым нравится.

Цитата:

Ku2zoff писал:
Зато я точно знаю одну игру, где воды (в которой можно плавать) нет. СВАЛКЕР

в митро тоже плавать нельзя. Но там интересно сделано. В третьей части есть лодка, на лодке можно форсировать водные преграды. А как без лодки - сразу тонет, хоть и не Игорь.

Добавлено 12-01-2020 в 13:49:

На данный момент исправляю утечки в компиляторе. Там вообще интересно, когда компилятор писался изначально, там высвобождали всё лишнее, а как начали прикручивать новые фичи, типа того же тумана, то сразу и забили.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 12-01-2020 в 11:50:

Цитата:

Дядя Миша писал:
Но там интересно сделано.

Ага. Особенно в Last Light Redux. Стоит наступить одной ногой в болото, запускается сценка с погружением по ушы в дерьмо и последующим выныриванием оттуда игрока. В третью часть не играл, т.к. у меня видеокарта тово, помёрла.

Цитата:

Дядя Миша писал:
А как без лодки - сразу тонет, хоть и не Игорь.

Мне вспомнился ролик Ильи Мэддисона про игру "Патриот". Там если в первой миссии прыгнуть за борт, будет написано "Такой-то Такой-то плавает как топор". В рамках "Патриота" выглядит странно, т.к. ГГ там служит на корабле, а во флот, я думаю, неплавающих не берут. Вот в рамках метра вполне норм такое смотрится, т.к. ГГ рос в метре, ~~в говне~~ в подземке, и воды там нету, учиться плавать негде.

Добавлено 12-01-2020 в 18:50:

Цитата:

Дядя Миша писал:
В третьей части есть лодка

А педобир, которого можно убить только следуя скриптам, там тоже есть, как во второй части?

Отправлено thambs 12-01-2020 в 11:57:

Цитата:

А педобир, которого можно убить только следуя скриптам

Ох уж этот педобир! Мне из-за него всю главу переигрывать пришлось, сэйвы -- не, не слышал.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 12-01-2020 в 12:06:

Цитата:

Ku2zoff писал:
во флот, я думаю, неплавающих не берут

вроде как им без разницы, для того чтобы драить палубу не обязательно уметь плавать.

Цитата:

Ku2zoff писал:
А педобир, которого можно убить только следуя скриптам

ведмедик? Да, есть. Его поджыгать надо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 12-01-2020 в 12:08:

Цитата:

Дядя Миша писал:
ты порталы собрался генерить из треугольников моделей?

Декомпозиция жеж.

Отправлено Ku2zoff 12-01-2020 в 12:24:

Цитата:

Дядя Миша писал:
ведмедик? Да, есть. Его поджыгать надо.

А другими способами он никак не убивается? Просто интересно. Вот представьте, если б в халфе гарги только скриптами убивались. Жэсть же. Хотя, халфа тоже не очень хороший пример. Взять хотя бы тентаклей и гонарча. Они убиваются по скриптам. Ох, как я не люблю такое. Особенно бесконечных врагов, которые лезут из какой-то дырки, пока не замочишь босса или не свалишь с локации.

Дядь Миш, как у тебя в целом продвинулась работа над новым движком? И ещё, что будешь на нём демонстрировать? Вторую Порнонойю портируешь?

Отправлено nemyax 12-01-2020 в 12:29:

Цитата:

Ku2zoff писал:
Вот представьте, если б в халфе гарги только скриптами убивались.

Я первые три раза думал, что так оно и есть. И, как говорится, ничего!

Отправлено Ku2zoff 12-01-2020 в 12:40:

Цитата:

thambs писал:
сэйвы -- не, не слышал.

А вот это вообще печально, на самом деле. Я про отсутствие сохранений в произвольный момент. Кажется, такие игры разрабатывают люди, любящие унижения. В особенности анальные. Видимо, в жизни практикуют, и им это нравится. Вот, буквально вчера играл в СВАЛКЕРА с АМК модом. Какой мазохист придумал электрохимеру? Это ведь жуткая имба: от неё надо валить на 100-150 метров, чтобы при попадании в неё пульки, игрока не ударило током.

Добавлено 12-01-2020 в 19:35:

Цитата:

nemyax писал:
Я первые три раза думал, что так оно и есть. И, как говорится, ничего!

Я тоже так думал, пока не попробовал их взрывать, лет эдак 15 назад на N-ное прохождение. Здорово же, правда? Никогда нельзя запирать игрока в какие-то рамки. Нужно давать максимальную свободу, какая возможна. Ох, как мне всегда хочется замочить Гюнтера при выходе из метра при прохождении Deus Ex.

Добавлено 12-01-2020 в 19:40:

Админы, будьте добры, вынесьте наш флуд в отдельную тему. Чувствую, скоро будет выброс эмоций про отсутсвующие квиксейвы и неубиваемых чушек.

Отправлено XaeroX 12-01-2020 в 12:41:

Цитата:

Ku2zoff писал:
Я про отсутствие сохранений в произвольный момент. Кажется, такие игры разрабатывают люди, любящие унижения.

Да тут всё просто: с квиксейвом игра проходится намного быстрее, чем без, т.к. а) поощряет игрока рисковать, б) ошибка обходится дёшево (не надо перепроходить много локаций). В итоге - общее время игры стремится ко времени базовой пробежки по локациям. И вместо 10 часов геймплея имеем 4, а как следствие - меньше вовлечённость аудитории, больше критики "игра слишком короткая" и т.п.
С другой стороны, нудная игра без квиксейвов быстро отправляется в треш. Если ты продолжаешь играть в такую - значит, всё же цепляет. Это показатель, имхо.

__________________

Отправлено Ku2zoff 12-01-2020 в 12:48:

Цитата:

XaeroX писал:
С другой стороны, нудная игра без квиксейвов быстро отправляется в треш. Если ты продолжаешь играть в такую - значит, всё же цепляет. Это показатель, имхо.

Думаю, мне стоит завести новую категорию в стимовской библиотеке. И назвать её "Нудятина". Первой туда отправится Метро 2033.

Отправлено XaeroX 12-01-2020 в 12:50:

Цитата:

Ku2zoff писал:
Ох, как мне всегда хочется замочить Гюнтера при выходе из метра при прохождении Deus Ex.

Слушай, ну надо иметь совесть.

Есть же такое понятие, как гейм-дизайн. Тебе и так дали возможность отбиться от солдат на станции спутниковой связи, потом спасти брата, потом замочить Анну - а ведь, кмк, немногие и до этого момента дойдут. В деусе как раз на удивление гибкая квестовая система - ключевых персонажей можно убить на разных этапах, и игра это старается учитывать.

__________________

Отправлено Ku2zoff 12-01-2020 в 12:55:

Цитата:

XaeroX писал:
ключевых персонажей можно убить на разных этапах, и игра это старается учитывать.

О, да. Я, к своему позору, не так давно узнал, что Анну Наварре можно убить кодовой фразой на выходе из штаба Юнатко. А до этого я всегда мочил её, чтобы спасти Лебедева...

Отправлено nemyax 12-01-2020 в 13:04:

Запрет на ручные сейвы, по-моему, уместен в игорях типа Borderlands (для тех, кому скучно). Миссии мелкие, терять нечего, при желании можно пофармиться и апнуться.
Либо надо как-то компенсировать игроку страдания от ампутации сейвов. Хотя бы как в риддиках и свежих вольфенштайнах, где накидывают здоровья с энной попытки пройти какую-нибудь комнатуху.

Добавлено 12-01-2020 в 16:04:

XaeroX
Кстати, как контрабандиста спасти?

Отправлено Ku2zoff 12-01-2020 в 13:06:

Цитата:

nemyax писал:
Хотя бы как в риддиках

ЕМНИП, первая игра про Риддика вполне себе умеет в квиксейвы. А вот переиздание с "Assault on Dark Athena" уже нет. И то, это вполне легко лечится правкой конфига.

Отправлено Crystallize 12-01-2020 в 13:10:

Цитата:

XaeroX писал:
В первом Унреале вода делалась без брашей. Не веришь - спроси Скааржа.

Ставить точечную энтитю, от неё создавать горизонтальную поверхность и рекурсивно смотреть какой объём эта вода зальёт?

Отправлено XaeroX 12-01-2020 в 13:14:

nemyax
В самом конце последней миссии в Нью-Йорке сходить к нему и предупредить.
Правда, придётся напрячься, т.к. на улицах много солдат и ботов.

Добавлено 12-01-2020 в 20:14:

Цитата:

Ku2zoff писал:
не так давно узнал, что Анну Наварре можно убить кодовой фразой на выходе из штаба Юнатко. А до этого я всегда мочил её, чтобы спасти Лебедева...

Анну в игре можно убить несколько раз: у Лебедева, затем в метро, затем в офисе Унатко из оружия или килфразой.
А ещё можно убить килфразой Гюнтера.

__________________

Отправлено Ku2zoff 12-01-2020 в 13:14:

Цитата:

nemyax писал:
Миссии мелкие, терять нечего

В Borderlands в принципе играть не сложно. Когда игрок дохнет - воскрешается. В зависимости от того, сколько у него денег, цена воскрешения либо растёт, либо падает. Интересно, если на счету будет один бакс, сколько раз можно воскреснуть в этой задротской песочнице?

Отправлено nemyax 12-01-2020 в 13:16:

Crystallize
Ограничивающий объём по-любому как-то надо определить.

Добавлено 12-01-2020 в 16:16:

Цитата:

Ku2zoff писал:
если на счету будет один бакс, сколько раз можно воскреснуть в этой задротской песочнице?

Бесплатно воскресят, напишут: fee waived.

Отправлено Ku2zoff 12-01-2020 в 13:21:

Цитата:

XaeroX писал:
А ещё можно убить килфразой Гюнтера.

Это если сходить в Парыжэ в кафешку, чтоб Юнатковский дохтор тебе эту фразу сказал. Эх, а в первое прохождение я вообще случайно с ним поговорил. И опять же, не так давно, выяснил, к чему этот разговор приводит.

Добавлено 12-01-2020 в 20:21:

Цитата:

nemyax писал:
Бесплатно воскресят, напишут: fee waived.

Реально? Я никогда баланс бабла не доводил до таких низких значений. Ну, если так, то игра - говно

Какой вообще стимул в такое играть? Это как бессмертный Марио на Денди. Я б прошёл всю игру за пару дней с бесконечными жизнями.

Отправлено XaeroX 12-01-2020 в 13:31:

Цитата:

Ku2zoff писал:
Это если сходить в Парыжэ в кафешку, чтоб Юнатковский дохтор тебе эту фразу сказал.

Да, но чтобы доктор там появился, ему надо сказать определённую фразу ещё в Унатко. После чего ты потеряешь возможность получить одну из канистр апгрейда. Всё в деусе имеет свою цену.

__________________

Отправлено Chyvachok 12-01-2020 в 13:40:

Цитата:

Ku2zoff писал:
Вот представьте, если б в халфе гарги только скриптами убивались. Жэсть же.

Ага как в Блек Мессе, там и Апач такой же сделали.

Кстати насчёт Риддика, я когда проходил его как то и не запомнилось отсутствие квиксейвов, может я и включил эти сейвы через конфиг, но вообще имхо отсутствие квиксейвов минус в любой игре, уж сильно я привык к тому что они почти везде есть.

Насчёт ИИ, в халве он топорный в плане навигации, те же ученные часто застряют, в том же анриле классно сделали что монстры и стрейфятся, и плавают и при стрельбе делают поправку на упреждение вроде тоже насколько я помню, да и в первом квейке монстры постоянно бегали туда-сюда.

Добавлено 12-01-2020 в 15:40:

Кстати когда я прогодил первый раз халву я и не знал что гарга надо под трансформатор заманить, я не знал что с ним делать и закидал гранатами и прочей взрывчаткой просто по приколу и убил его.

Отправлено nemyax 12-01-2020 в 13:54:

Цитата:

Ku2zoff писал:
Какой вообще стимул в такое играть?

Лут и качка. Не сюжетные же повороты.

Добавлено 12-01-2020 в 16:50:

Цитата:

XaeroX писал:
После чего ты потеряешь возможность получить одну из канистр апгрейда

Зато он тебе подарит аугментацию в качестве parting gift-а, не?

Добавлено 12-01-2020 в 16:54:

Цитата:

XaeroX писал:
Анну в игре можно убить несколько раз: у Лебедева, затем в метро, затем в офисе Унатко из оружия или килфразой.
А ещё можно убить килфразой Гюнтера.

Прикольно, что Саймонза можно вообще не трогать. Так и будет как лох за тобой бегать.

Отправлено XaeroX 12-01-2020 в 14:02:

Цитата:

nemyax писал:
Зато он тебе подарит аугментацию в качестве parting gift-а, не?

Да вот по-моему у меня такая уже была (или её можно получить позже).
В общем, мне думается, что канистры ценнее, т.к. они всегда используются, в отличие от аугов.

Добавлено 12-01-2020 в 21:02:

Цитата:

nemyax писал:
Прикольно, что Саймонза можно вообще не трогать. Так и будет как лох за тобой бегать.

Так и от Гюнтера, емнип, можно тоже убежать в Париже.

__________________

Отправлено nemyax 12-01-2020 в 14:15:

Цитата:

XaeroX писал:
Так и от Гюнтера, емнип, можно тоже убежать в Париже.

Можно, но с ложно-вата. Надо сначала до кампупера добраться незамеченным.

Отправлено Ku2zoff 12-01-2020 в 14:16:

Цитата:

XaeroX писал:

Так и от Гюнтера, емнип, можно тоже убежать в Париже.

Я так никогда не пробовал делать. Если уж баталия наметилась, то я устраивал мочилово. Было бы здорово, если б неубитый перс продолжал преследовать игрока.

Отправлено Дядя Миша 12-01-2020 в 17:07:

Цитата:

nemyax писал:
Декомпозиция жеж.

Да причём тут декомпозиция

Чтобы создать портал, достаточно и треугольника. Сколько миллионов их нагенерится и толку от них?
Для эффективного рассчёта видимости нужна лоуполи аксиальная геометрия, которую никаким прогрессив-мешем нормально не сделаешь.
Потому что даже с ручной геометрией, с порталами иногда случаются забавные вещи. ну вы в курсе.

Цитата:

Ku2zoff писал:
Дядь Миш, как у тебя в целом продвинулась работа над новым движком?

Работаю. Читай тему сначала.

Добавлено 12-01-2020 в 18:45:

Цитата:

Crystallize писал:
Ставить точечную энтитю, от неё создавать горизонтальную поверхность и рекурсивно смотреть какой объём эта вода зальёт?

хорошые у вас сегодня шышки

Добавлено 12-01-2020 в 20:07:

Халфовский CSG, кроме того что вычитает брашы друг из друга, пытается их объеденить. И вот здесь, судя по всему и начинаются проблемы на сложной геометрии. Собственно, каждый маппер знаком с этим явлением. Пол, на полу кубик. Кубик разобъет пол на несколько частей, даже при условии что он его не пересекает. Такое уж требование к халфовскому BSP, чтобы правильно уложить сурфейсы на ноду. Но вообще CSG эту ситуацию обрабатывать никак не должен. Вот ежели бы кубик немножко залез внутрь браша, тогда да, он бы спровоцировал появление новых.
В моём новом компиляторе CSG только вычитает брашы. Можно добавить и объединение конечно, но сперва надо подумать как часто возникают подобные ситуации. Навскидку, это актуально только для воды.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 12-01-2020 в 18:23:

Чо-т я не понимаю. Для эффективного виза нужна лоуполи аксиальная геометрия, поэтому браши. Но тут приходит CSG и нарезает браши на каломассу с кучей лишних треугольников и корявостей от недостатка точности.

Цитата:

Дядя Миша писал:
вода не всегда простой формы. Иногда её приходится делать из составных брашей. Например изгибающееся русло реки.

возможно, проще хранить эти составные браши и считать пересечения с ними индивидуально, нежели нарезать и собирать деревья?

Отправлено nemyax 12-01-2020 в 18:45:

Цитата:

Дядя Миша писал:
Да причём тут декомпозиция

Чтобы создать портал, достаточно и треугольника. Сколько миллионов их нагенерится и толку от них?

Значит апроксимация кубиками. Из кубообразного меша получатся близкие по форме брашы.

Отправлено XaeroX 12-01-2020 в 18:49:

nemyax
Как аппроксимировать кубиками тетраэдр или пирамиду?

__________________

Отправлено nemyax 12-01-2020 в 18:54:

XaeroX
Если аксиально, то как-то так: https://i.imgur.com/xmwzByb.png

Отправлено XaeroX 12-01-2020 в 19:00:

nemyax
Какое жуткое нагромождение вместо простейшего браша.

__________________

Отправлено Дядя Миша 12-01-2020 в 19:06:

Цитата:

ncuxonaT писал:
Для эффективного виза нужна лоуполи аксиальная геометрия, поэтому браши. Но тут приходит CSG и нарезает браши на каломассу с кучей лишних треугольников и корявостей от недостатка точности.

ну вот на таких взаимоисключащих требованиях и построен халфовский формат уровней, да.

Цитата:

ncuxonaT писал:
возможно, проще хранить эти составные браши и считать пересечения с ними индивидуально, нежели нарезать и собирать деревья?

с водой коллизия не считается. Там бинарное состояние - в воде\не в воде.

nemyax я напоминаю, что геометрия должна быть замкнутая, иначе портал флоу вытечет наружу, за пределы уровня. Аппроксимация не даст замкнутой геометрии. Хотя конечно, если её надуть как клипноды, может из этого что-нибудь и получится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 12-01-2020 в 19:06:

XaeroX
Ну декомпоз даст красотульку в этом случае. Но дядя Миша вон говорит, что это шышки и что надо аксиально.

Отправлено Дядя Миша 12-01-2020 в 19:06:

Там смысл в чём: при надувании мелкие детали сами-собой растворяются.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 12-01-2020 в 19:10:

Цитата:

Дядя Миша писал:
я напоминаю, что геометрия должна быть замкнутая

Если у тебя изначально winged-edge меш, например, то она будет по определению замкнутая. Это к слову о том, на что мог бы быть похож редактор.

Отправлено Дядя Миша 12-01-2020 в 20:02:

Ну чтожы, настала пора самого интересного - собирать халфовские карты моим компилятором. Тут ведь идея в чём? Карта она так и остаётся прежней, со своими путями к текстурам. Но компилятор, вооружонный мощной системой материалов спокойно находит всё что ему нужно, причём пути указывает юзер.

Добавлено 12-01-2020 в 23:02:

ЧТобы было понятнее о чём речь, пусть вам Thambs расскажет, как он однажды попытался скомпилить свои карты под ку3 и писал всякие шейдеры.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 12-01-2020 в 20:02:

Цитата:

Дядя Миша писал:
с водой коллизия не считается. Там бинарное состояние - в воде\не в воде.

ну вот, с набором примитивных брашей это должно супербыстро считаться без csg-bsp.

Цитата:

Дядя Миша писал:
Ну чтожы, настала пора самого интересного - собирать халфовские карты моим компилятором.

это уже в ку3шный формат?

Отправлено Crystallize 12-01-2020 в 20:04:

nemyax я думаю идеальный дядемишин редактор это как Майнкрафт, только кубики не фиксированы а заданы размерами текстуры.

Отправлено Дядя Миша 12-01-2020 в 20:45:

Цитата:

ncuxonaT писал:
это уже в ку3шный формат?

Да.

Добавлено 12-01-2020 в 23:45:

Вообще говоря с кутришным форматом работать на порядок приятнее, точнее говоря не с самим форматом конечно, а подобной организацией дерева. Халфовский компилятор из-за озвученного выше противоречия работаешь на пределе точности двойного вещественного. А кутришному и флоата за глаза хватает. Нет ощущения, что вот сейчас один эпсилон подкрутишьи всё полетит к чертям, взорвется дырками, ликами и битыми полигонами.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 13-01-2020 в 03:07:

Цитата:

пусть вам Thambs расскажет, как он однажды попытался скомпилить свои карты под ку3 и писал всякие шейдеры.

Ну там, собственно, три проблемы было. Первая -- это собственно, эти замороченные шойдеры, которые писать замаялся, там сотни ненужных опций, причём на каждый чих и всё равно их прописывать приходилось, типа тут лайтмэпу такую, тут секую, никакой автоматизации или адекватных дефолтов. И от неба небыло _spread для солнца. Вторая -- это брашевые горы, так и не удалось найти оптимальные параметры, что бы он целиком их в единое полигоновое месево превратил, а без этого швы получались. Впрочем, я по всей видимости буду от брашевых гор отказываться и переводить их в модели, тк иначе не получится сделать несколько уровней песка, да и вообще ландшафты в блендере удобнее делать. Третья -- это там какие-то проблемы с путями были, я их решил, но с ..дцатого раза. А так, геометрия там, конечно лучше получалась, тоннели полигон-в-полигон, а гротто2 -- в фанк_статик (но его тожа в модель надо будет, брашами его делал скорее от безисходности).
На самом деле, у меня основная проблема это текстуринг в блендере, очень уж неудобно для мировой геометрии сочинять все эти развёртки, там бы режим наложения как в джеке -- цены б ему не было.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено thambs 13-01-2020 в 11:18:

Дядя Миша
У меня следующая бНОПНЯ, каким образом в компиляторе/игре определяется число субдивайдов в q3-патчах, возможно ли его вынести в необязательные параметры статика для удобства стыковки всяких труб и пр.?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 13-01-2020 в 11:32:

Цитата:

thambs писал:
У меня следующая бНОПНЯ, каким образом в компиляторе/игре определяется число субдивайдов в q3-патчах

а никаким

Они делятся пока уровень ошибки станет меньше заданного значения.
Т.е. вот этот параметр r_patch_subdivision это на самом деле r_patch_maxerror. А эксплиситного субдивайда в ку3 нет, его только в дуум3 сделали.

Кстати вот да, подтверждаю насчёт путей, в ку3 это полная жопа, он постоянно не может что-то найти, что лежит у него под носом. Вот не вижу и всё тут. Идиотизм.

Добавлено 13-01-2020 в 14:32:

А я тем временем собрал сипульчер своими компиляторами. Заняло около двух минут

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 13-01-2020 в 19:46:

Нашёл жырный баг в SplitBrush, функцию скопировали из ку2 в ку3. В q3map2 она непофикшена, подозреваю и в волатиле тоже. В лёгких случаях приводит просто к утечке памяти. Ну а если над компилятором ведутся фундаментальные работы, ну вот как в моём случае, добавляются CSG и прочие михонизмы, тут-то всё гавно наружу и полезло.

Добавлено 13-01-2020 в 22:01:

Попробую китайскую формулу для выбора секущей в ку3. Интересно будет ли толк.

Добавлено 13-01-2020 в 22:46:

Только приступил - уже ляп нашёл, валидные размеры считаются только для корневной и впоследствии только для аксиальных нод. Для неаксиальных они равны родительской. Просто не стали заморачиваться.
Эффективное дерево так не построишь. Ну просто для ку3 на многие моменты забили.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 14-01-2020 в 07:48:

Цитата:

Дядя Миша писал:
Ну а если над компилятором ведутся фундаментальные работы, ну вот как в моём случае, добавляются CSG и прочие михонизмы, тут-то всё гавно наружу и полезло.

А в халфлайфовских компиляторах есть какие-то подобные серьёзные упущения?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено XaeroX 14-01-2020 в 09:15:

Цитата:

Дядя Миша писал:
как в моём случае, добавляются CSG и прочие михонизмы, тут-то всё гавно наружу и полезло.

Почему-то в VMap тоже есть "CSG и прочие михонизмы", и гавно ни в движок не утекло, ни наружу не полезло. Может, у вас с Мастером карма такая?

Добавлено 14-01-2020 в 16:15:

SNMetamorph
В оригинальных - дофига, я даже лет 10 назад про это писал, когда свои компиляторы делать пытался. А потом китаец многое поисправлял.

__________________

Отправлено FiEctro 14-01-2020 в 09:26:

Цитата:

XaeroX писал:
Почему-то в VMap тоже есть "CSG и прочие михонизмы", и гавно ни в движок не утекло, ни наружу не полезло.

Всё ещё впереди

Отправлено Crystallize 14-01-2020 в 09:48:

Цитата:

XaeroX писал:
В оригинальных - дофига, я даже лет 10 назад про это писал, когда свои компиляторы делать пытался. А потом китаец многое поисправлял.

а где ты писал?

Отправлено Ku2zoff 14-01-2020 в 09:59:

Crystallize поищи по форуму тему о компиляторах с кастомным subdivide. Думаю, там.
XaeroX а ты только hlcsg и hlbsp тогда исправил?

Отправлено XaeroX 14-01-2020 в 10:17:

Цитата:

FiEctro писал:
Всё ещё впереди

Впереди у нас исключительно юный Октябрь.

Цитата:

Ku2zoff писал:
а ты только hlcsg и hlbsp тогда исправил?

Угу.

__________________

Отправлено Дядя Миша 14-01-2020 в 16:34:

Цитата:

SNMetamorph писал:
А в халфлайфовских компиляторах есть какие-то подобные серьёзные упущения?

Ну вот я и сделал p2st чтобы исправить ихние недостатки.

Цитата:

XaeroX писал:
и гавно ни в движок не утекло, ни наружу не полезло

когда гавно утикает в движок, это типа означает - я ничего не могу с этим поделать. А когда гавно лезет на ружу, тут-то сразу и понятно кто вредитель.

Добавил в функцию выбора секущей волшебную китайскую формулу из VHLT. Стало лучшы, но буквально на пару процентов. Ну то есть было в дереве 2009 нодов, а стало 1936. Вот это максимальный профит по идее. Ну на сепульчере чуть получше конечно, было 11300 нодов, стало 10495. Вообщем для такого дерева мало что можно оптимизировать, не вижу смысла дальше копать в этом направлении. Другой важнейший вопрос меня занимает - как удалить невидимые фейсы воды, соприкасающиеся друг с другом.
Я за эти несколько дней подробно проштудировал этот вопрос и вот что выяснилось. В халфе этим занимается CSG, который брашы не только вычитает, но и склеивает. Но склеивает-то он не сами брашы, а их сурфейсы, в противном случае его возможности были бы куда скромнее.
Добавить в CSG объединялку брашей несложно, брашы вообще легко склеивать, но разумеется это при условии, что на выходе получится аксиальная фигура с ббоксом, точно равным сумме ббоксов двух брашей.
А если у воды один браш шире, а другой уже, подобной фигуры уже не получится. В ку2 я долгие годы ошибочно полагал, что склеиванием воды тоже занимается CSG. Так вот нет, оказывается там фейсы генерятся из порталов на ноде, при условии что нода не солидная. Изящное решение, но мне опять таки не подходит - в ку3, как мы помним на ноде не лежат фейсы, дерево другого типа. Их можно попытаться найти по плоскости, но чёт мне кажется это стрёмная затея. К тому же вода детайлом так точно не найдется. Значит остаётся всего один вариант - мержить финальные дравсурфсы.

Добавлено 14-01-2020 в 15:58:

Вообще, если вам интересно, я ведь именно по той причине и отказался от кутришного формата карт в 2008-м году, потому что он воду не склеивал. То есть все халфовские карты просто шли лесом, не говоря уже о битых полигонах. Ну вот, спустя годы, я снова возвращаюсь к этой задачке.

Добавлено 14-01-2020 в 19:34:

Вариант с отсечением порталами отпал сразу - порталы не лежат на сурфейсах, да они вообщем-то и не должны, это просто в ку2 так совпадало, из-за организации дерева. Значит буду делать полноценный CSG по сурфейсам, как в халфе. Вариант с брашами я тоже пожалуй оставлю, он для коллизии полезен. Впрочем всё это будет легко отключить параметрами.
Я планирую сделать такой файлик настроек, makebsp.def и сохранять его рядом с gameinfo.txt и пусть там лежат настройки компилятора и описание компиляторных энтить, ну всяких там func_group, func_detail и прочих.
Описание и порядок операций - мувнуть брашы в мировую энтить, перед этим поставить им контентс детайл. Типа такого.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 14-01-2020 в 17:29:

расширение def смущает пользователя, лучше ini.

Отправлено XaeroX 14-01-2020 в 17:37:

Цитата:

Crystallize писал:
расширение def смущает пользователя

Глупости какие. Нормальное расширение, это волатильный аналог *.qc.

__________________

Отправлено nemyax 14-01-2020 в 17:44:

Crystallize
Чего тебя всё смущает какая-то иррунда?

Отправлено Дядя Миша 14-01-2020 в 20:37:

Подключил CSG, пропали межводяные стенки
Правда надо еще подумать как его полутьшы встроить, чтобы ничего не паламать. Типа того жы тумана. Поидее из фейсов CSG можно строить улутьшенное дерево, т.е. более оптимальное.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 15-01-2020 в 01:16:

nemyax какая была предыдущая?

Отправлено nemyax 15-01-2020 в 05:44:

Crystallize
Ну скобки тебе не те были =)

Отправлено Дядя Миша 15-01-2020 в 07:57:

В качестве временного решения, замена вадам будет следующая:
имя вада в поле "wad" у "worldspawn" это textures\wadname\
Это на время миграции.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 15-01-2020 в 14:33:

Халфовский CSG, как мы помним разбивал не просто проникающие, но соприкасающиеся брашы. Это было нужно для того дерева. Для кутришного, понятное дело, ни к чему. CSG для соприкасающихся брашей я оставил только для водички, естественно. Вообще там какой-то баг похоже, или невнимательность моя, в плане фильтрации контентсов. Ведь после работы брашевого CSG этот не должен продуцировать ничего лишнего.
Ну я еще поставлю тесты на специальных картах.
Кстати говоря, может у Тхамбса есть такие примеры фейла CSG, я жы знаю как он его любит.

Добавлено 15-01-2020 в 17:33:

Так, ну Сипульчер и Грендель с этим CSG собираются правильно, но там непонятно. В халфе из-за ограничений формата китаец ввёл иные правила, Eric W. в своих TyrUtils не смог с одной стороны добиться такой же эффективности, как китаец, но и правила у него слегка отличались. К примеру в VHLT запрещена вода детайлами. В TyrUtils - можно.
У китайца было понятие детайллевелов - т.е. более низкий левел жрёт те что левелом повыше. В TyrUtils вместо левелов было просто несколько энтить, func_detail, func_detail_wall и func_detail_illusionary, которые условно соответствуют левелам 1, 2, 3. То есть получается что detail_wall кромсает таких же и illusionary, но не трогает просто func_detail. В ку2, если не путаю, там наоборот было - структуральные брашы вообще не затрагивали детальные, а детальные соответственно структуральные, т.е. было как две непересекающихся группы. Поправьте меня, если я неправ.
Я могу просто завести приоритет детального уровня, если это востребовано.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 15-01-2020 в 15:42:

Цитата:

Я могу просто завести приоритет детального уровня, если это востребовано.

Для совместимости (вплане все эти zhlt_detaillevel дабы не переделывать)

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 15-01-2020 в 21:17:

Я тут еще подумал, что можно вывести глобальную настройку для регулировки степени агрессивности CSG.
Нулевой уровень - bypass
Первый уровень - взаимодействие только воды с водой и воды с солидами
Второй уровень - солиды с солидами, солиды с водой, вода с водой, но если брашы просто касаются друг друга (не пересекаются), то вычитания не происходит.
Третий уровень - поведение как в халфе, максимально агрессивное.
Ну и CSGBrush можно будет по желанию включать и выключать отдельно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 16-01-2020 в 16:32:

Надо еще приделать мержинг фейсов. Слава богу эти фейсы не влияют на построение дерева, а значит их можно объединять и разъединять как угодно - дырок не будет.

Добавлено 16-01-2020 в 19:32:

Ну товарищи, теперь наступила полная красота!
Есть два регулятора - агрессивность CSG и агрессивность объединителя сурфейсов. Так что теперь можно настроить любой уровень разбиения-склеивания, и что особенно приятно - это не будет влиять на качество дерева. Хотя я посмотрю, может и такую опцыю тоже введу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 17-01-2020 в 13:51:

Ну кстати говоря CSG очень сильно помогает увеличить фпс. Практически вдвое ему это удаётся. Но только в паре с мержилкой сурфейсов, разумеется.

Добавлено 17-01-2020 в 15:23:

На неотвиженном сипульчере на дохлой GT640 средний фпс в раёне 50.
Очуметь можно! На халфовском формате о такой оптимизации можно было только мечтать.

Добавлено 17-01-2020 в 15:25:

Для понимания пикантности ситуации - сипульчер, собранный ericw-тулзами, на QSpasm на этой же GT640 примерно и выдавал аналогичные 40-50 фпс.
С визом, разумеется И естественно там геометрия была в статичном VBO.

Добавлено 17-01-2020 в 16:51:

Становится всё интереснее. Пользуясь особенностями формата, я просто пропускал результаты работы CSG и merge на генерацию видимых фейсов, а дерево строил из оригинальных брашей. Но конечно жы мне, как и вам наверняка пришёл в голову простой вопрос, а что если построить оптимизированное дерево из того, что нам нарезал CSG? Построил. Размер дерева сократился на четверть! И это для кутри где дерево и так не великое. Я предполагаю, что карта скомпиленная с такими оптимизациями, даже в ванильной кутри будет рисоваться гораздо быстрее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 18-01-2020 в 16:24:

Наконец-то дошли руки и до встраиваемых в карту моделей.
Здесь я хочу уделить особое внимание их колоизации. В параное, как вы помните, я просто генерил микробраш из каждого треугольника в целом это работало. Примерно той же чертовщиной занимается и q3map2. Но это дополнительная нагрузка на код коллизии. Я планирую после генерации этих брашей объединять их вместе, до тех пор, пока они остаются конвексными. Так же вероятно пропущу через симплифкатор геометрии, но это попозже.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 18-01-2020 в 19:49:

Дядя Миша
Если сделать уровень замкнутым мешом, как будешь поступать с вогнутыми участками, у которых с той стороны космос? Пол и потолок например.

Отправлено Дядя Миша 18-01-2020 в 21:27:

Цитата:

nemyax писал:
Если сделать уровень замкнутым мешом, как будешь поступать с вогнутыми участками

ну значит тонкими брашами. Чтож тут непонятнова?

Просьба от меня небольшая. Скачайте вот эту карту, пооткрывайте её в разных редакторах, на предмет битых полигонов:
www.hlfx.ru/xash/collision.7z

тому шо у меня есть только древнй кварк.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 18-01-2020 в 22:11:

Цитата:

Дядя Миша писал:
ну значит тонкими брашами. Чтож тут непонятнова?

Можно ведь вместо тонких брашей конвексный AABB описать вокруг всего этого дела, не?

Отправлено Дядя Миша 18-01-2020 в 23:05:

Цитата:

nemyax писал:
конвексный AABB

Чего-чего

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 18-01-2020 в 23:09:

Нормалями плейнов наружу.

Отправлено XaeroX 19-01-2020 в 05:29:

nemyax
Конвексный AABB это звучит так же впечатляюще, как "плоский треугольник".

Добавлено 19-01-2020 в 12:29:

Цитата:

Дядя Миша писал:
тому шо у меня есть только древнй кварк.

Кому-то пора давно поставить Джек.

Причём не просто поставить, а в коллекцию любимого и самого используемого софта.

__________________

Отправлено nemyax 19-01-2020 в 05:45:

XaeroX
Ну я имел в виду конвексный пааллелепипедский меш по ААББ, вы же пони.

Отправлено Ku2zoff 19-01-2020 в 08:32:

Цитата:

Дядя Миша писал:
Просьба от меня небольшая. Скачайте вот эту карту, пооткрывайте её в разных редакторах, на предмет битых полигонов:

Открыл в Джеке. Последняя стимовская бета. Визуально дырок нет. Тонна ошибок Invalid solid structure (face is not planar), (tiny edge). Ну и, соответственно, нестыковки по сетке, см. аттач.

Добавлено 19-01-2020 в 15:32:

Хаммер 3.5 сразу же при загрузке карты говорит "For your information, 2854 solids were not loaded due to errors in the file". И после загрузки на виде сверху сплошные дырки.

Отправлено Дядя Миша 19-01-2020 в 11:56:

Цитата:

nemyax писал:
Нормалями плейнов наружу.

Косинусом вперёд?

Добавлено 19-01-2020 в 14:48:

Цитата:

Ku2zoff писал:
Открыл в Джеке. Последняя стимовская бета. Визуально дырок нет. Тонна ошибок Invalid solid structure (face is not planar), (tiny edge). Ну и, соответственно, нестыковки по сетке, см. аттач.

Ну вот наконец-то открылась страшная правда. В древнем кварке на этой карте ровно один неисправный браш, в котором достаточно удалить одну overconstrained плоскость. При использовании этих брашей для колоизации, тем более нет никаких проблем. А ваши хвалёные хаммеры, да джеки - фейлят. Ну вот и понятно откуда дырки, вот и понятно откуда говно в движок утикает. Надо всё же писать свой редактор, это ужас какой-то.

Добавлено 19-01-2020 в 14:56:

Ну вот, построил колоизацию для моделей. Теперь самое время заняться мета-сурфейсами, стрипификацией и прочим. Хотя у меня даже на чистых фан-секвенциях, даже без виза очень впечатляющие результаты.

Вот к примеру тестовая кутришная карта с ландшафтами.
Кстати говоря я планирую реализовать генерацию этих ландшафтов по картинкам. Т.е. из хейтмапы сперва генерятся треугольники, потом из треугольников создаются коллизионные брашы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 19-01-2020 в 12:57:

Цитата:

Дядя Миша писал:
В древнем кварке на этой карте ровно один неисправный браш, в котором достаточно удалить одну overconstrained плоскость. При использовании этих брашей для колоизации, тем более нет никаких проблем. А ваши хвалёные хаммеры, да джеки - фейлят.

А какой минимальный шаг сетки в этом древнем кварке? Небось, меньше 1 юнита? А то и вообще 0.125? Помнится, у кого-то были проблемы с инвалидными брашами, когда он пытался скомпилить из исходника твою тестовую карту для спирита с зеркалом. Дело оказалось в том, что толщина табличек на дверях 0.5 юнита. Ну хаммер и тово, корёжил браши при экспорте. Джек стопудово норм работает с 0.5 юнита, я проверял. 0.25 уже китайские компиляторы сами бракуют на этапе сборки.
Попробуй научить свой колоизатор выдавать результат с точностью хотя бы не ниже 0.5 юнита. Думаю, в таком случае, в джек импортнётся без проблем, а в хаммере кол-во инвалидных структур уменьшится в разы.

Отправлено Crystallize 19-01-2020 в 13:14:

Цитата:

Ku2zoff писал:
А какой минимальный шаг сетки в этом древнем кварке?

ДМ говорил что 1/10000 юнита но спустя пару версий поменяли на 1/100.

Добавлено 19-01-2020 в 20:14:

Дядя Миша ты вот делаешь много оптимизаций для CSG, ту которая ускоряет от 10 до 500% и ту где у тебя стало на четверть меньше плейнов. Но нейжели Кармак не догадывался о таком? Или догадывался но счёл неуместным, может у него были другие цели?

Отправлено Дядя Миша 19-01-2020 в 15:04:

Цитата:

Crystallize писал:
Но нейжели Кармак не догадывался о таком?

Творчество закончилось вместе с первой квакой. Дальше начался чистый продакшен.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 19-01-2020 в 15:11:

Цитата:

Crystallize писал:
1/10000 юнита но спустя пару версий поменяли на 1/100

Имхо, даже одна сотая - перебор. При прямых руках маппера вершины не будут съезжать с сетки. Есть же куча статей, как делать то да это. Либо вообще отказываться от привязки к сетке. Тогда другая проблема - в редакторе всё может быть норм, а на выходе у компилятора всё поедет после оптимизаций. Ну не зря же эту сетку вообще завели? Как раз таки, чтобы маппер придерживался того, что в теории может компилятор.

Отправлено Дядя Миша 19-01-2020 в 16:41:

Цитата:

Ku2zoff писал:
При прямых руках маппера вершины не будут съезжать с сетки

Причём тут вообще нахрен сетка? Сетка изначально базировалась на неверном предположении, что если всё делать по ней, то можно избежать потери точности. Это условие справедливо, когда у тебя все стороны аксиальные. Как только ты начинаешь делать какие-то скосы, ты не контролируешь уже ничего и сетка из друга превращается в смертельного врага, который всё портит. Весь этот снаппинг противоречит устойству вещественных с плавающей точкой. Вы просто не помните, что сетку вводили изначально в те далёкие времена, когда компиляторы считывали карты в формате целых чисел. И мнимальный шаг был 1 юнит. В тот момент, когда это решили переделать, от сетки надо было отказываться ВООБЩЕ или же хотя бы выполнить шаг в комфортных для флоата значениях.
(1/8), (1/16)?, (1/32), но эти больные ублюдки начали снапать к десятичным значениям 0.1, 0.01, 0.001 и огребли кучу проблем, причём большинство даже не поняло откуда.

Добавлено 19-01-2020 в 19:21:

Нет, я всё-таки чую придется свой редактор писать. Не обойтись без этого.

Добавлено 19-01-2020 в 19:35:

Вот хорошая статья про вещественные: https://habr.com/ru/post/112953/

Добавлено 19-01-2020 в 19:41:

Вот вам маленький примерчег, для понимания что такое флоат

C++ Source Code:

1	float f = 0.0f, f2 = 0.02f;

3	for( i = 0; i < 1000000; i++ )

  f += f2;

5	Msg( "float: %f\n", f );

Калькулятор это маскирует, надо именно в коде.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 19-01-2020 в 17:14:

Цитата:

Дядя Миша писал:
Вот вам маленький примерчег, для понимания что такое флоат

Это нужно запустить и пронаблюдать?

Отправлено Дядя Миша 19-01-2020 в 19:43:

Crystallize посмотреть что он напишет.

Добавлено 19-01-2020 в 22:43:

Цитата:

Дядя Миша писал:
Калькулятор это маскирует, надо именно в коде.

хотя я наверное погорячился. Ну не хватило у меня терпения миллион раз нажать на кнопку +.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 19-01-2020 в 20:13:

Дядя Миша
В калькуляторх fixedpoint юзается же.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Government-Man 19-01-2020 в 21:52:

Цитата:

Дядя Миша писал:
Нет, я всё-таки чую придется свой редактор писать. Не обойтись без этого.

Зачем множить сущности? Лицензируй у Ксерокса сорцы Джека

Отправлено Дядя Миша 20-01-2020 в 09:37:

Government-Man я не совместим с хаммероподобным редактором.
Да и в любом случае объем переделок сопоставим с написанием с нуля.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 20-01-2020 в 11:55:

Дядя Миша
Надоел кварк?

Отправлено Дядя Миша 20-01-2020 в 12:09:

Кварк не поймёт новую систему материалов, да и модельки по типу халфовских он рисовать никада не умел

Добавлено 20-01-2020 в 15:09:

Но в целом да, вот интерфейс у кварка идеальный, покрайней мере для меня. Компас опять жы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 20-01-2020 в 12:13:

Цитата:

Дядя Миша писал:
Как только ты начинаешь делать какие-то скосы, ты не контролируешь уже ничего и сетка из друга превращается в смертельного врага, который всё портит. Весь этот снаппинг противоречит устойству вещественных с плавающей точкой.

Мне вот интересно, почему в 3д моделировании принято делать именно 4вершинные полигоны, и всякие компиляторы и конвертёры моделей их прекрасно триангулируют. А вот у халфовских компиляторов случается майндфак, и в панике они начинают пытаться натянуть сову на глобус, тоесть вершины на плоскость, в итоге на выходе жидко обсираясь сами же вставляют себе палки в колёса.

Отправлено nemyax 20-01-2020 в 12:22:

Цитата:

FiEctro писал:
почему в 3д моделировании принято делать именно 4вершинные полигоны

Для контроля над лупами и полюсами при подразделении.

Цитата:

FiEctro писал:
у халфовских компиляторов случается майндфак, и в панике они начинают пытаться натянуть сову на глобус, тоесть вершины на плоскость, в итоге на выходе жидко обсираясь

В общем случае четырёхугольник не плоский и одной текстурной матрицей 2х3 быть затекстурирован не может.

Отправлено Ku2zoff 20-01-2020 в 14:57:

Цитата:

Дядя Миша писал:
Кварк не поймёт новую систему материалов, да и модельки по типу халфовских он рисовать никада не умел

А для него плагины разве не на петоне пишутся? Неужели нельзя дописать нужный функционал?

Отправлено Дядя Миша 20-01-2020 в 16:44:

Цитата:

nemyax писал:
В общем случае четырёхугольник не плоский и одной текстурной матрицей 2х3 быть затекстурирован не может.

Может. Но не только лишь всегда.

Цитата:

Ku2zoff писал:
А для него плагины разве не на петоне пишутся?

Там очень коварное дело с этими плагинами. Я поначалу тоже губищщи раскатал, щас думаю добавлю потдержку патчей в халфовский формат карт. Строчка там, строчка здесь - вылет, падение. Я уже и так и этак, а потом понял, что плагины там для отвода глаз, многие вещи намертво захардкодены. В том числе и типы поддерживаемых игр. И вот ежели там прописано, что патчи могут быть только в Quake3, то нипочем ты это из плагинов не переделаешь - оно просто в консоль кучу ошибок вываливает и всё. Да и сочетание делфи+питон ничего более омерзительного нельзя себе представить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 20-01-2020 в 16:52:

Цитата:

Дядя Миша писал:
Может. Но не только лишь всегда.

Я и говорю не в общем случае. Расставишь ювишки трапецией и превед. Тока параллелограммы.

Отправлено Crystallize 21-01-2020 в 01:54:

Цитата:

Дядя Миша писал:
Ну вот наконец-то открылась страшная правда. В древнем кварке на этой карте ровно один неисправный браш, в котором достаточно удалить одну overconstrained плоскость. При использовании этих брашей для колоизации, тем более нет никаких проблем. А ваши хвалёные хаммеры, да джеки - фейлят. Ну вот и понятно откуда дырки, вот и понятно откуда говно в движок утикает. Надо всё же писать свой редактор, это ужас какой-то.

Хаммер портит нормальную геометрию чтоли? Может просто Кварк не слишком строго ищет ошибки?

Цитата:

А где там снаппинг при скосах?

Добавлено 21-01-2020 в 08:54:

Цитата:

Дядя Миша писал:
Government-Man я не совместим с хаммероподобным редактором.

Цитата:

Дядя Миша писал:
Но в целом да, вот интерфейс у кварка идеальный, покрайней мере для меня. Компас опять жы.

Ты не перевариваешь переключение режимов маппинга? А компас когда пригождается?

Отправлено FiEctro 21-01-2020 в 06:35:

Мне интересно, кто из здешних сможет кварк юзать. Те кто юзал, всегда обычно плевались после этого, и забывали этого франкинштейна как страшный сон. По мне, решение крайне мягко говоря неудачное.

Отправлено Crystallize 21-01-2020 в 06:49:

FiEctro в нём здорово скриптовать и скетчить энтити, ну и ещё - по идее - какие-нибудь туннели делать по рисунку.

Отправлено Дядя Миша 21-01-2020 в 12:14:

В сорцах радианта на джитхабе есть папка regression_tests, я давно на нее обратил внимание. А в той папке - разные неудобные штуки. Ну типа копланарных планесов и прочего. И вот значит я все эти карты прогнал под своим компилятором чтобы проверить на наличие ошибок. Ошибки действительно нашлись, но совершенно не те, о которых я думал.
Первая бага приводила к бесконечному циклу с выбором аксиальной секущей на границе блока 1024х1024, ну помните я вам еще показывал, что построялка дерева делит bbox ноды, только если он аксисальный, так еще и напрямую сравнивает флоат с 1.0. Добавил там эпсилон маленький, ушла проблема. Вторая проблема как ни странно была связана с тем, что тестовая карта была расположена за пределами максимально допустимых границ карты, у меня там было +\-32768, а в ку3 +\-65536, из-за чего ни один браш не создался и кое-где начались вылеты - просто не было проверок на NULL.
Во всём остальном - идеально. Никаких битых полигонов, мерцающих точек и прочей гадости. Да потому что изначально надо было делать bsp на даблах, а не выделываться. Я вам больше скажу, там есть какая-то адская конструкция с плоскостями тоньше 1\8 юнита, так вот после компиляции эти стороны даже в экранный пиксель толком не помещаются - настолько они тонкие. Но никуда не пропадают.

Добавлено 21-01-2020 в 15:14:

Тестирую эти мета-сурфейсы из q3map2. Помоему хрень полнейшая.
Я-то думал она там будет стрипифицировать и триангулировать, хрен бы там. Там как-то так интересно получается, что на каждом этапе по чуть-чуть. Тут PicoModel убрал дубликаты, тут мета-сурфейсы что-то склеили, наконец оригинальный стрипификатор нагенерил индексы.
И что характерно - основная задача этих мета-сурфейсов, вовсе не то что я думал. В ку3 же размер буффера - тысяча вертексов. И вот оно режет сложные сурфейсы на более простые, размером в тысячу вертексов.
Ну капец. У меня-то нет никаких-таких ограничений. Это чисто для совместимости с кутри.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 21-01-2020 в 13:43:

Цитата:

Дядя Миша писал:
там есть какая-то адская конструкция с плоскостями тоньше 1\8 юнита

Ну, это извращение какое-то. 1/2 юнита просто предел. Ну максимум 1/4. Куда тоньше-то? Уже ж давно все такие мелкие детали делают моделями. Вообще, ты сам ответил на вопрос по поводу нужности таких значений:

Цитата:

Дядя Миша писал:
после компиляции эти стороны даже в экранный пиксель толком не помещаются - настолько они тонкие

Цитата:

Crystallize писал:
А где там снаппинг при скосах?

Вот именно для этого и есть всякие уроки, как делать скалы, тоннели и прочее, чтобы после Clip Tool или Vertex Tool ничего с сетки не соскакивало. Стоит освоить принципы, и ты уже машинально работаешь с брашами так, чтобы ничего никуда не съезжало. А в игре, на готовом уровне, глазу на самом деле ничего не видно, по сетке там у тебя, или не по сетке. Здесь всё упирается в удобство и быстроту построения таких конструкций.
Возьмём в пример Clip Tool. Он позволяет отрезать от браша куски линиями под определённым углом. На проекции "сверху" мы отрезали чётко по сетке, на проекции "сбоку" - тоже по сетке. А на проекции "спереди" получилось не по сетке в месте стыковки двух срезов. Тут или сам редактор должен исправлять браш таким образом, чтобы все вертексы снаппились на сетку автоматом, либо вообще стоит отказаться от сетки, как говорит ДМ. Я, конечно, за первый вариант, т.к. отказ от сетки = неточности и несоответствия между элементами геометрии.

Цитата:

Дядя Миша писал:
Там очень коварное дело с этими плагинами.
*****
плагины там для отвода глаз, многие вещи намертво захардкодены.

А ты форумчан агитировал юзать этот редактор, ну. А там автор такой вот вредный, даже расширять функционал не даёт.
Я пробовал мапперить в кварке. Касаемо создания геометрии и навигации в 2Д и 3Д он не так уж плох. Это всё сила привычки: в хаммере/джеке одни горячие клавиши, а в кварке другие. Но текстуринг и выделение в кварке с непрывычки - ад адский. Может быть есть какой-то способ научить его текстурить вменяемо, а не через несколько кликов?

Добавлено 21-01-2020 в 20:43:

За иерархическую структуру всего и вся кварку плюс. На сложных картах это удобно, особенно, когда нет визгрупп.

Отправлено Дядя Миша 21-01-2020 в 15:07:

Цитата:

Ku2zoff писал:
Уже ж давно все такие мелкие детали делают моделями. Вообще, ты сам ответил на вопрос по поводу нужности таких значений:

компилятор в принципе должен такое обрабатывать корректно. А то что никто не будет делать, не имеет никакого значения. Самая большая пакость всегда начинается с допущения "нуу, так всё равно никто делать не будет".

Цитата:

Ku2zoff писал:
За иерархическую структуру всего и вся кварку плюс

да, мне тоже оч. нравится

Добавлено 21-01-2020 в 18:07:

Цитата:

Дядя Миша писал:
"нуу, так всё равно никто делать не будет".

я вам даже пример приведу. Когда я в ксаш-моде впервые сделал колоизацию по моделькам, я полагал, что будут ею колоизировать разные небольшие модельки, ну как в халфе. Угадайте что народ сделал в первую же очередь? Правильно, ландшафт 32х32 килоюнита моделькой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 21-01-2020 в 15:43:

Цитата:

Дядя Миша писал:
Правильно, ландшафт 32х32 килоюнита моделькой.

Ну это в СВАЛКЕРА переиграли, чего уж таить. Там ландшафты моделькой. Вообще, ИМХО, это неправильный подход в рамках Quake-архитектуры.

Добавлено 21-01-2020 в 22:43:

Но, может быть, это ещё и влияние Хаммера. Там-то вообще никак без манипуляций с вертексами, ландшафт не создать. Вот народ и решил пойти лёгким путём.

Отправлено thambs 21-01-2020 в 15:50:

Ku2zoff
А как правильно, так что бы всё это плавно с горами состыковать и несколько уровней земли сделать?

Цитата:

Там-то вообще никак без манипуляций с вертексами, ландшафт не создать

Ну это неверно, кстати. Я вполне себе делал из больших призм и набора детализирующих усечённых конусов. Другое дело, что сложную поверхность так не сделаешь.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 21-01-2020 в 16:23:

Цитата:

Ku2zoff писал:
Ну это в СВАЛКЕРА переиграли, чего уж таить. Там ландшафты моделькой

в сталкере брашей-то нету.

Цитата:

Ku2zoff писал:
Вообще, ИМХО, это неправильный подход в рамках Quake-архитектуры

брашы нужны только для колоизации. Их можно нагенерить автоматически (я вам как раз карту-пример недавно выкладывал). А визуальная структура - ну например из модельки или хейтмапы.

Вся беда в том, что Джек такое не нарисует.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 21-01-2020 в 16:24:

Да, за дерево проекта редактору сразу плюс много в карму.

Отправлено FiEctro 21-01-2020 в 17:14:

32х32 килоюнита это только прудик сделать

Отправлено Дядя Миша 21-01-2020 в 20:25:

FiEctro ты сделал? Покажы

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 21-01-2020 в 20:33:

FiEctro напрудил?

Отправлено nemyax 21-01-2020 в 20:36:

Ничоси прудик. Там серьёзный подпрудный уровень поместится.
А какова между тем площадь Мытищ?

Отправлено Дядя Миша 21-01-2020 в 21:21:

Цитата:

nemyax писал:
А какова между тем площадь Мытищ?

34 кв.км. Не влезет

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 22-01-2020 в 12:22:

Думаю выложить вам тестовый билд, ну в первую очередь, чтобы вы смогли прицениться к новой системе материалов и сказать, насколько это удобно.
Интересно кому-нибудь?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 22-01-2020 в 12:34:

Дядя Миша
Да, нужно, я бы потихоньку попробовал портировать свою карту и заодно наживую бы твои коптеляторы потестил.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 22-01-2020 в 12:42:

Дядя Миша
С моделек уже компилируешь полноценные уровни?

Отправлено Дядя Миша 22-01-2020 в 16:00:

nemyax как несложно эти уровни компилировать с моделек, столь же сложно отобразить их в джеке, от коего нет сорцев. Хотя, он жы .ase понимает. Есть некоторая надежда.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 22-01-2020 в 16:03:

nemyax
А есть способ эти .ace из блендера по человечески экспортить?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 22-01-2020 в 16:04:

Мне, товарищи, самое главное, чтобы новая система материалов была интуитивно понятной. В конце-концов она предполагает, что язык материалов каждый формирует сам для себя, как ему удобно.

Добавлено 22-01-2020 в 19:04:

Цитата:

thambs писал:
А есть способ эти .ace из блендера по человечески экспортить?

а как жы. Ксерокс их оттуда именно и экспортит. Но тебе наверное его метод не подойдет - у вас же базовые ценности отличаются.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 22-01-2020 в 16:48:

Цитата:

Дядя Миша писал:
как несложно эти уровни компилировать с моделек, столь же сложно отобразить их в джеке

Главна чтобы компиляция работала, а с джеками я разберуся.

Отправлено Crystallize 23-01-2020 в 05:20:

Цитата:

Дядя Миша писал:
Во всём остальном - идеально. Никаких битых полигонов, мерцающих точек и прочей гадости. Да потому что изначально надо было делать bsp на даблах, а не выделываться

Но эксешники же разделили как раз ради экономии памяти?

Добавлено 23-01-2020 в 11:54:

Цитата:

Ku2zoff писал:
Дело оказалось в том, что толщина табличек на дверях 0.5 юнита. Ну хаммер и тово, корёжил браши при экспорте.

Да не может такого быть. Пол-юнита это дофига.

Цитата:

Т.е. Хаммеры напрасно считают какие-то браши слишком изящными и намеренно загрубляют их и в результате ломают?

Добавлено 23-01-2020 в 12:20:

Path duplicator

Отправлено Дядя Миша 23-01-2020 в 10:17:

Цитата:

Crystallize писал:
Но эксешники же разделили как раз ради экономии памяти?

ну и что что разделили? и csg и bsp оба на даблах работают.

Цитата:

Crystallize писал:
Т.е. Хаммеры напрасно считают какие-то браши слишком изящными и намеренно загрубляют их и в результате ломают?

Я по собственному опыту убедился, что любые округления и снаппинги идут только во вред. Есть пара-тройка приёмов, которые ничего не ломают, но на этом и всё. Если бы мы округляли финальные положения вертексов, то проблем бы не было, но с плоскостями так поступать нельзя. Особенно с неаксиальными.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 24-01-2020 в 12:05:

Пишу потихоньку мануал по новой системе материалов. Как закончу - выложу вам тестовый билд.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 01-02-2020 в 10:53:

Я таки дописал предварительную документацию по системе материалов, получилось 67 килобайт чистого текста. Надеюсь Thambs её сконвертит в pdf для удобочитаемости. И можно выкладывать тестовый билд.
Но есть обоснованные сомнения, что у народа будет свободное время и желание тестировать всё это дело.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 01-02-2020 в 12:09:

Дядя Миша По объёму сравнимо с документацией на Кварк?

Отправлено Дядя Миша 01-02-2020 в 12:52:

Я никогда не читал документацию на Кварк

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 01-02-2020 в 15:26:

Из всех свойств документации её объём имеет наименьшее значение.

Отправлено FiEctro 01-02-2020 в 16:21:

Цитата:

Дядя Миша писал:
Я никогда не читал документацию на Кварк

Я до этого момента, не знал что она вообще существует. Впрочем знание о существовании кварка это уже что-то из разряда сакрального. Типа как до изобретения будильника, например в Англии, ходил дед и тыкал палкой в окна.

Отправлено Crystallize 03-02-2020 в 14:23:

FiEctro чекай

Отправлено Дядя Миша 12-02-2020 в 19:44:

Ну што, встал перед очередным выбором. Отказаться от лайтмап совсем или оставить их опционально. Ваши мысли по поводу?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 12-02-2020 в 19:53:

Дядя Миша зависит от того, не пострадают ли производительность и качество освещения. Какие будут в таком случае системные требования, чтобы бодро бегало в 100+ фпс в FullHD, с уровнем детализации как в П2, например? Про качество освещения: к сожалению, полную динамику в п2 (а я думаю, что именно к этому ты клонишь, собираясь отказаться от лайтмап) я видел только на скринах, т.к. к моменту её релиза моя производительная видюха приказала долго жить. На офисной затычке GT 220 это дело вообще работает неправильно с чёрными пятнами на полэкрана и выдаёт 3-5 фпс. Так вот, если минимальные требования будут на уровне GF 400-500, ИМХО, это норм.

Отправлено Дядя Миша 12-02-2020 в 20:05:

Ну у меня GTX650. Подо что-то такое и буду ориентироваться, как под середину.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 12-02-2020 в 20:13:

Дядя Миша напомни, плиз, какой квар в п2 включает полную динамику? И на какой версии игры она уже есть? Я забыл уже. Наверное, придётся качать версию 1.5. Ну или какая там доступна последняя.

Отправлено nemyax 12-02-2020 в 20:15:

Цитата:

Дядя Миша писал:
Отказаться от лайтмап совсем или оставить их опционально.

Отказаться например. Наверно, станет попроще.

Отправлено Дядя Миша 12-02-2020 в 20:23:

Ku2zoff gl_deffered. А вообще не оффтопь. Создай тему в ветке паранои и там спрашивай.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Lev 12-02-2020 в 20:24:

Дядя Миша Всё же с лайтмапами ИМХО индор интересней выглядит(непрямой свет и т.д.). Фулл динамик конечно тоже норм, но тогда для полумрака в помещениях хотя бы SSAO понадобится.

Отправлено Дядя Миша 12-02-2020 в 20:29:

Цитата:

Lev писал:
Всё же с лайтмапами ИМХО индор интересней выглядит

это касатся только лоуполи индора. На высокополигональные объекты лайтмапу накладывать чистое мучение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-02-2020 в 20:33:

>> Ну што, встал перед очередным выбором. Отказаться от лайтмап совсем или оставить их опционально. Ваши мысли по поводу?

Чет гибридное придётся мутить. Для радиосити хотябы.

Отправлено Lev 12-02-2020 в 20:34:

Дядя Миша Поэтому да, с технической точки зрения динамика наверное удобней. Но тогда нужны шейдеры постобработки. Я не знаю как сделано в третьем ведьмаке - но освещение там очень приятное и почти везде динамика.

Отправлено Дядя Миша 12-02-2020 в 21:19:

да я думаю в наше время уже вполне реально намутить фуллдинамик с подобием радиосити, чтобы пользователь уже не разобрал, где его обманули.
А смешанный режим всегда будет хуже, потому что в какой-то момент станет даже тормознее реалтайма, я уже говорил об этом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 13-02-2020 в 10:35:

Здесь есть еще вот какое соображение. При полностью динамическом освещении, картинка будет заведомо освещена единым образом, независимо от типов объектов, что положительно скажется на её восприятии, даже если где-то индирект будет неслишком убедительный или вообще фейковый. Строго говоря, его ведь даже рад считает упрощённо.
Вот эти патчи, на которые разбивается поверхность, ну они в оригинале 64х64, в параное 128х128, это значит что индирект люксели имеют имено такой размер. При таком сверхнизком разрешении можно смело забыть про вторичные тени, например. И очень много вопросов как это увязать с моделями, где множество мелких треугольников. Я лично так и не понял, как этот вопрос грамотно разрешить. Так что уж оставим лайтмапы за бортом истории, есть параноя, я там довольно многое сделал в этом направлении.
Теперь займемся полностью динамическим освещением, посмотрим что тут можно оптимизировать.

Добавлено 13-02-2020 в 13:33:

В качестве индиректа, я в первую очередь попробую LPV, он должен неплохо сочетаться с BSP-уровнями. Его ведь делали фактически для самых обычных моделей с избыточными поверхностями, а тут у меня есть возможность определить, если какие-то ячейки сетки попали в солидную геометрию, например. Это поможет бороться с лайтликами.

Добавлено 13-02-2020 в 13:35:

Но еще до того как заняться индиректом мне предстоит финализировать новые компиляторы, теперь работа над ними значительно упрощается, т.к. их не придется готовить к лайтмапам. А потом надо сделать динамическое прямое освещение с хорошей производительностью. И тогда уже можно будет заняться индиректом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-02-2020 в 11:31:

Дядя Миша
А как быть с той рейтрейсовой ку2 (которая не RTX), возможно что то оттуда использовать для динамического освещения?

Отправлено Дядя Миша 13-02-2020 в 12:40:

Цитата:

FiEctro писал:
А как быть с той рейтрейсовой ку2 (которая не RTX), возможно что то оттуда использовать для динамического освещения?

я жеж вам сделал рейтрейсер в параное на аналогичном принципе.
Правда я его там использовал только для рассчёта теней, ну так зато и фпс кратно выше.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 13-02-2020 в 12:48:

Цитата:

Дядя Миша писал:
В качестве индиректа, я в первую очередь попробую LPV, он должен неплохо сочетаться с BSP-уровнями. Его ведь делали фактически для самых обычных моделей с избыточными поверхностями, а тут у меня есть возможность определить, если какие-то ячейки сетки попали в солидную геометрию, например. Это поможет бороться с лайтликами.

Вот лично мне очень интересно было бы увидеть работы с realtime-GI, сам даже таким заняться хочу, только вот мне еще до такого учиться и учиться

А вообще, лайтмапы на самом деле фигово масштабируются: увеличиваешь разрешение люкселей - больше время компиляции и больше размер карты. Причем больше намного.

Добавлено 13-02-2020 в 21:48:

Цитата:

Дядя Миша писал:
а што такое mem2pix? текстуры варавать из волатилы?

Можно сказать и так. Я её использовал для реверсинга одного визуального эффекта из Silent Hill 3.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 13-02-2020 в 13:37:

У LPV, собственно главная проблема, характерная для любого индиректа - лайтблидинг. Ну так это и для лайтмап справедливо. Я думаю CSG разрешит эту проблему. Вообще любые техники непрямого освещения ориентируются на произвольные модели, у которых множество невидимых полигонов. Т.е. фактически на сырьё. И многие проблемы, которые присущи этим техникам, в первую очередь из-за отсутствия постобработки геометрии. Ну посмотрим, насколько это справедливо.

В целом моя идея, сделать такой фуллдинамик, чтобы пользователь не смог его визуально отличить от лайтмапы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-02-2020 в 13:44:

Дядя Миша
Какие планируешь делать светильники? Directional, point, spot, area?

Отправлено FiEctro 13-02-2020 в 13:49:

Цитата:

Дядя Миша писал:
я жеж вам сделал рейтрейсер в параное на аналогичном принципе.
Правда я его там использовал только для рассчёта теней, ну так зато и фпс кратно выше.

Ну такое вышло, мне кажется можно было как то разбить это по буферу глубины, чтобы размытия убрать. Типа в несколько проходов, отрисовать передний план, потом средний, потом дальний (примерно как с mip текстурами принцип), причём мб даже дальнему плану делать меньше разрешение, чтобы ускорить рендеринг, а потом всё это композить в обычном разрешении.

Отправлено Дядя Миша 13-02-2020 в 14:38:

Цитата:

nemyax писал:
Какие планируешь делать светильники? Directional, point, spot, area?

ты помоему их все перечислил. Area этож фейк по сути, его не сделаешь по нормальному. Точнее тени.

Цитата:

FiEctro писал:
Ну такое вышло, мне кажется можно было как то разбить это по буферу глубины, чтобы размытия убрать

А как по твоему билатералка работает? У тебя синдром попаданца.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 13-02-2020 в 15:02:

LPV говно

Отправлено Дядя Миша 13-02-2020 в 15:07:

ncuxonaT твои варианты?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Lev 13-02-2020 в 15:40:

Дядя Миша в фуллдинамике игру света и тени можно реализовать - те же лучи солнца, но не как в кризисе(скринспейсовые), а из чистого неба - честные.

Отправлено ncuxonaT 13-02-2020 в 16:19:

Дядя Миша если не лайтмапы, то лайтпробы. Статические или полудинамические как в дивижне.

Отправлено Дядя Миша 13-02-2020 в 19:22:

Цитата:

Lev писал:
но не как в кризисе(скринспейсовые), а из чистого неба - честные.

это волуметрик лайт называется.

Цитата:

ncuxonaT писал:
если не лайтмапы, то лайтпробы. Статические или полудинамические как в дивижне.

Для индиректа? Так LPV этим и занимается, по большому счёту. И PRT примерно тем же самым.
Я вообще склонен считать, что дело не столько в технологии, сколько в исходной геометрии. Те же лайтмапы прекрасно текут, если геометрия не прошла CSG. Вторичка у рада очень низкочастотная + она переотражение цвета вообще не учитывает, в отличие от того же LPV. Так в чём принципиальная разница?

Вот здесь тов. Suslik подробно расписал преимущества и недостатки большинства известных алгоритмов и в итоге выработал свой, скринспейсовый. Он неплохо работает, но обладает существенным недостатком - только камера от третьего лица, иначе просто недостаток информации в пределах экрана.

Так же ему очень нравится ISM, но мне если честно сама идея достраивать тени из точек представляется небесспорной.

Добавлено 13-02-2020 в 22:22:

ЗЫ. Помнишь ты мне как-то демку Геометрикса давал на Юнити? Так вот там тоже свет утикал. Ессно CSG её никто не обрабатывал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-02-2020 в 19:31:

Цитата:

Дядя Миша писал:
ЗЫ. Помнишь ты мне как-то демку Геометрикса давал на Юнити? Так вот там тоже свет утикал. Ессно CSG её никто не обрабатывал.

Эти лики и с обычной шадоумапой происходят, я так понимаю, нужно просто бекплейны ставить. Метод конечно так себе, но я проверял, вроде работает.

Отправлено Дядя Миша 13-02-2020 в 19:40:

Цитата:

FiEctro писал:
Эти лики и с обычной шадоумапой происходят

ну если от солнца, то да.

Добавлено 13-02-2020 в 22:40:

Надо будет освежить основные материалы по непрямому освещению, последний раз я это штудировал в 16-м году.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 13-02-2020 в 20:24:

Цитата:

Дядя Миша писал:
Те же лайтмапы прекрасно текут, если геометрия не прошла CSG.

Просто не надо делать такую геометрию, которой нужно CSG проходить.

Цитата:

Дядя Миша писал:
Вторичка у рада очень низкочастотная + она переотражение цвета вообще не учитывает, в отличие от того же LPV.

О каком раде речь? У хлрада вторичка низкочастотная из-за больших патчей по умолчанию. Если патчи поставить меньше, то и тени от вторички станут четче.

https://csm.dev/attachments/kreozot_test_0001-jpg.119431/

https://csm.dev/attachments/kreozot_test_0002-jpg.119432/

Не знаю, в чем принципиальная отличие LPV от всего остального, пейпер не осилил, но кроме второго крузиса он почему-то нигде не используется. А во всех видео демок на ютубе выглядит как говно. Впрочем, как и второй крузис.

В обзоре суслика нет способа из дивижона)
Да и не во всём он прав. Например, "Photon mapping... В принципе не ложится на GPU". Вполне себе ложится.

Отправлено Дядя Миша 13-02-2020 в 22:59:

Цитата:

ncuxonaT писал:
Если патчи поставить меньше, то и тени от вторички станут четче.

Ничего себе! А теперь представь, нам ЧАЭС надо скомпилить. Ну или что-то вроде этого.

Цитата:

ncuxonaT писал:
но кроме второго крузиса он почему-то нигде не используется.

строго говоря LPV даже из пятого края никуда не исчез. А если он используется в играх, то это видимо никак не подчеркивается.

Цитата:

ncuxonaT писал:
А во всех видео демок на ютубе выглядит как говно

Зачем мне ютуб, у меня примерчег, где эта штука на спонзе под 300 фпс выдает и если накрутить настройки, то достаточно неплохо выглядит даже на исходной модельке, с множеством лишних поверхностей. ISM будет напорядок тормознее.

Цитата:

ncuxonaT писал:
В обзоре суслика нет способа из дивижона)

Они пейпер писали про освещение? Я что-то такое смутно припоминаю про миллионы статичных лайтпроб с переменной плотностью. И кажется там гармоники были запечены. Ну вообщем-то ничо новава. Только LPV эти лайтпробы спавнит прямо перед носом у изумлъоннава игрока.

Добавлено 14-02-2020 в 00:18:

Цитата:

ncuxonaT писал:
Да и не во всём он прав. Например, "Photon mapping... В принципе не ложится на GPU". Вполне себе ложится.

Не ложится. Трассировка это почти всегда рекурсия, которая недружелюбна к GPU. Ты наверное воспринял слова "не ложится" в контексте невозможно сделать?

Добавлено 14-02-2020 в 01:21:

Вот доклад по дивижену

Самый обычный предрассчитаный PRT. И в Сорсе2 такой же точно.
И кстати Запрягаев его юзал в первых версиях Unigine, а потом отчего-то дропнул.

Добавлено 14-02-2020 в 01:40:

На 23.34 приводится статистика. Уровень ~6 кв км, но я думаю брешет, потому что на флоатах без особой потери точности не более пяти кв.км. Ну да не принципиально. Всего-навсего один миллион лайтпроб, каждая из лайтпроб получается рендерингом G-Buffer в кубическую карту. Страшно даже подумать сколько времени всё это занимает. У них-то ферма для лайтмап, наверняка. Ну и гигбайт места на предрасчёты.

Добавлено 14-02-2020 в 01:52:

Дослушал до момента, как они под автомобили лепили "AO-декали", которые рендерились только в SSAO буффер и выключил. Эту игру не программисты делали, а художники. Поэтому там в целом картинка приятная. Но применяемые подходы это тихий ужос.

Добавлено 14-02-2020 в 01:59:

В самом конце зачотный вопрос, а вы как-то проводили валидацию с эталоном, ну там с патч-трейсером? Как говорил Задорнов - какой раскошный ответ я получил. Ну мы просто крутили параметры, пока нас не похвалил директор

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 13-02-2020 в 23:56:

Цитата:

Дядя Миша писал:
Ничего себе! А теперь представь, нам ЧАЭС надо скомпилить. Ну или что-то вроде этого.

И с этим успешно справится лайтбейкер или что-то подобное.

Цитата:

Дядя Миша писал:
А если он используется в играх, то это видимо никак не подчеркивается.

Если посмотреть презентации с сигграфа, которые выкладывала Татарчук за последние 10 лет, можно увидеть, что lpv упоминается только у Капланяна в Сруэнджин 3. Если это такая замечательная технология, чо ж все довольствуются лайтмапами и лайтпробами?

Цитата:

Дядя Миша писал:
Зачем мне ютуб, у меня примерчег, где эта штука на спонзе под 300 фпс выдает и если накрутить настройки, то достаточно неплохо выглядит даже на исходной модельке, с множеством лишних поверхностей.

Яви народу, как оно выглядит

Цитата:

Дядя Миша писал:
Всего-навсего один миллион лайтпроб, каждая из лайтпроб получается рендерингом G-Buffer в кубическую карту. Страшно даже подумать сколько времени всё это занимает. У них-то ферма для лайтмап, наверняка. Ну и гигбайт места на предрасчёты.

Не думаю, что они весь миллион за один раз рендерили. Да и вообще, если одна кубемапа рендерится за 0.01с, то миллион кубемап рендерится 3 часа. Не так уж и много для 6кв км города. Хотя скорее всего еще быстрее, кубемапы же 64х64 или типа того. Гигабайт для лайтпроб - это много, а вот гигабайт для лайтмап в Паранойе - это хорошо.

Цитата:

Дядя Миша писал:
И в Сорсе2 такой же точно.

откуда инфа? его же не видел никто

Цитата:

Дядя Миша писал:
Дослушал до момента, как они под автомобили лепили "AO-декали", которые рендерились только в SSAO буффер и выключил.

Как бы ты решал эту задачу?

Отправлено Crystallize 14-02-2020 в 01:42:

ncuxonaT
Картинки с КСМ не видны ни у кого. По крайней мере у меня с мобилы не видны.

Ты лайтбейкер-то доделал? Последний раз когда мы его видели он страдал от детских болезней типа каши из лайтмап.

Отправлено ncuxonaT 14-02-2020 в 01:45:

К слову, у спонзы размер 10х20 метров. Ты не пробовал демке большие сцены подсовывать, ту же свою ЧАЭС? Насколько хорошо алгоритм масштабируется?

Добавлено 14-02-2020 в 04:45:

Crystallize каша была на формате карт ксаша с настраиваемой плотностью лайтмапы. Лайтбейкер в процессе перехода на рейтрейсинг

Отправлено Дядя Миша 14-02-2020 в 10:07:

Цитата:

ncuxonaT писал:
И с этим успешно справится лайтбейкер или что-то подобное.

и выдаст статичное освещение в итоге.

Цитата:

ncuxonaT писал:
Если это такая замечательная технология, чо ж все довольствуются лайтмапами и лайтпробами?

Я не говорил что она замечательная. Я говорю, что эта технология, с которой стоит поэкспериментировать. Вполне вероятно, из нее сейчас можно выжать больше чем в 2010-м году, особенно если подготовить геометрию.

Цитата:

ncuxonaT писал:
Да и вообще, если одна кубемапа рендерится за 0.01с, то миллион кубемап рендерится 3 часа

5-6 секунд на кубемапу, 8 часов на всю сцену, он же там приводил данные. Или ты не смотрел?

Цитата:

ncuxonaT писал:
Гигабайт для лайтпроб - это много, а вот гигабайт для лайтмап в Паранойе - это хорошо.

Где я говорил, что гигабайт лайтмап в параное это хорошо?

Цитата:

ncuxonaT писал:
откуда инфа? его же не видел никто

ну есть же демка для очков. Да и писали они где-то об этом.

Цитата:

ncuxonaT писал:
Ты не пробовал демке большие сцены подсовывать, ту же свою ЧАЭС? Насколько хорошо алгоритм масштабируется?

ну вот если бы ты статью осилил, то знал, что он очень хорошо масштабируется, за счёт вложенных сеток. Да, светоперенос там аналитический, страноватый. С другой стороны radiance hints это вообще фейк.
Суслик вот правильно подметил, основная проблема рассчётов в том, что мы делаем 90% бессмысленной работы. Если меня LPV не устроит, я буду копать в сторону скринспейса, как и он.

Цитата:

ncuxonaT писал:
Лайтбейкер в процессе перехода на рейтрейсинг

а лайтмапы на моделях он будет потдерживать?

Добавлено 14-02-2020 в 11:42:

Про лайтпробы скажу отдельно. Самый большой недостаток лайтпроб - это места их расположения. Натыкаешь регулярно - будет весить дохрена. Натыкаешь случайно - освещение будет странным. Натыкаешь аналитически - окажется что твой случай годится только для строго определённого типа сцен. Вручную их расставлять, это с дуба можно рухнуть. И опять надо думать в шейдере фетчинг в какую-то здоровую структуру, который сам по себе небесплатный и плохо вяжется с батчингом. Если это гармоники третьего порядка, там уже одной float-текстуры не хватит.

Добавлено 14-02-2020 в 11:49:

Вот, собсно статья от Суслика: https://gamedev.ru/code/articles/realtime_gi_pt1
где он подметил самое важное свойство - до сих пор все технологии прекрасно ложились на растеризацию треугольников. И только индирект на нее не ложится в принципе и приходится городить какие-то вспомогательные структуры.

Добавлено 14-02-2020 в 13:07:

Собсно, почему я хочу начать свои изыскания именно с LPV, потому что я вижу там только три решаемых недостатка.
Лайтблидинг - это устраняется подготовкой геометрии, её бы в любом случае пришлось готовить и для лайтмап в том числе.
Аналитическое распространение непрямого света - можно подкрепить реальным окклюженом, например через pointcontents.
Низкое разрешение сетки - ну тут совсем просто. Если лайтмапам поставить разрешение 64 юнита на люксель, они тоже будут выглядеть как говно.

В плюсах - хорошая масштабируемость для открытых сцен за счёт иерархических сеток, очень приличная производительность, тот факт, что технология применялась в коммерческом движке (к слову чуть ли не единственная подобного рода) ну и скромное потребление памяти.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 14-02-2020 в 13:54:

Цитата:

Дядя Миша писал:
5-6 секунд на кубемапу, 8 часов на всю сцену, он же там приводил данные. Или ты не смотрел?

Видео не смотрел, только слайды читал. В слайдах написано 5-6 секунд на сектор, в каждом секторе в среднем 300 кубемап.

Цитата:

Дядя Миша писал:
ну вот если бы ты статью осилил, то знал, что он очень хорошо масштабируется, за счёт вложенных сеток.

На словах-то он лев толстой, а на деле?

Цитата:

Дядя Миша писал:
а лайтмапы на моделях он будет потдерживать?

А он и щас поддерживает. Ему всё равно, какая геометрия.

Цитата:

Дядя Миша писал:
Лайтблидинг - это устраняется подготовкой геометрии, её бы в любом случае пришлось готовить и для лайтмап в том числе.

Как можно подготавливать геометрию для этого? LPV семплится по типу как 3д текстура?

Цитата:

Дядя Миша писал:
Если лайтмапам поставить разрешение 64 юнита на люксель, они тоже будут выглядеть как говно.

Но лайтмапам при желании можно поставить разрешение 4 юниты на люксель, и они будут выглядеть отлично, а с LPV так можно сделать?

Цитата:

Дядя Миша писал:
тот факт, что технология применялась в коммерческом движке

Тот факт, что технология применялась и больше не применяется в этом коммерческом движке.

Отправлено SNMetamorph 14-02-2020 в 14:20:

Цитата:

ncuxonaT писал:
Тот факт, что технология применялась и больше не применяется в этом коммерческом движке.

Это ещё ни о чём не говорит. Мне кажется однозначно стоит поэкспериментировать, а там уже будет видно что к чему.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 14-02-2020 в 15:23:

Цитата:

ncuxonaT писал:
В слайдах написано 5-6 секунд на сектор, в каждом секторе в среднем 300 кубемап.

а секторов 4000.

Цитата:

ncuxonaT писал:
А он и щас поддерживает. Ему всё равно, какая геометрия.

я про бинарную совместимость.

Цитата:

ncuxonaT писал:
LPV семплится по типу как 3д текстура?

ну кстати необязательно. Можно и 2д сетку.

Цитата:

ncuxonaT писал:
Но лайтмапам при желании можно поставить разрешение 4 юниты на люксель, и они будут выглядеть отлично

Ну и считаться соответственно сколько?

Цитата:

ncuxonaT писал:
технология применялась и больше не применяется

она никуда не делась, можешь в сорцах посмотреть

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 14-02-2020 в 16:38:

Цитата:

Дядя Миша писал:
а секторов 4000.

И это целая большая игра, между прочим

Цитата:

Дядя Миша писал:
ну кстати необязательно. Можно и 2д сетку.

Не понимаю, как тогда можно изменением геометрии победить лики

Цитата:

Дядя Миша писал:
Ну и считаться соответственно сколько?

Лайтбейкером быстро.

Ты покажешь демку всё-таки? Может, я не прав, и LPV на самом деле замечательный и можно его настроить до годного результата. Просто всё, что я раньше видел с ним, выглядело калово

Отправлено Дядя Миша 14-02-2020 в 16:44:

Цитата:

ncuxonaT писал:
Ты покажешь демку всё-таки?

не, демку я уже не найду, да и то что она выдает мне не нравится. Но потенциал я вижу, а это самое главное.

Цитата:

ncuxonaT писал:
И это целая большая игра, между прочим

если бы ты внимательно послушал о чём он там вещает, то понял бы что эта игра - мечта ФиЭктры, костыль на костыле.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 14-02-2020 в 16:59:

Цитата:

Дядя Миша писал:
не, демку я уже не найду, да и то что она выдает мне не нравится.

ну понятно

Цитата:

Дядя Миша писал:
если бы ты внимательно послушал о чём он там вещает, то понял бы что эта игра - мечта ФиЭктры, костыль на костыле.

Потому что там под машинами декали? И это плохо потому что..?

Отправлено Дядя Миша 14-02-2020 в 17:34:

ncuxonaT обманул я тебя
Есть еще демка в инете: http://sauerbraten.org/lee/lpv.zip
спонзу брать тут https://github.com/jimmiebergmann/Sponza

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Lev 14-02-2020 в 20:12:

Дядя Миша к слову, вот еще о чем спросить хотел - будет ли поддержка многопоточности?

Отправлено Дядя Миша 14-02-2020 в 20:57:

Lev поддержка ради поддержки?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 14-02-2020 в 21:03:

Дядя Миша
Все современные процы завязаны на многопоточность, и софт без её поддержки будет тормозить из-за низкой частоты на ядро. Карочи твой софт просто будет крайне не эффективно использовать ресурсы процессора. Тоже самое и с x86 архитектурой, с её дебильным ограничением в 4гб оперативки.

Отправлено Дядя Миша 14-02-2020 в 21:10:

FiEctro где ты такие шышки берёшь?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 15-02-2020 в 01:29:

Нашел еще кое-что интересное по теме
https://www.youtube.com/watch?v=dE6r0-MfyRI

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено nemyax 15-02-2020 в 05:46:

Какую проблему в данном случае должна решать поддержка многопоточности?

Отправлено Ku2zoff 15-02-2020 в 06:29:

Цитата:

nemyax писал:
Какую проблему в данном случае должна решать поддержка многопоточности?

Вот я тоже думаю. Чего распараллеливать-то? Движок нетребовательный, идёт на старых картах семилетней давности на максималках. Ежели было б как в Лост Альфе, тогда другое дело. Они уже после релиза 1.4007 прикрутили многопоточность к рендереру и получили + 20-30 фпс, во. А нагрузка на проц от игровой логики и монстров небольшая, это не 30 ботов на сервере считать. Даже если бы и так, тот же сорс 2013 по-сути однопоточный. У ксго высокие требования к производительности на ядро, особенно при игре с ботами. И ничё, даже на кукурузенах бегает 100+ фпс при бодрой видеокарточке.

Добавлено 15-02-2020 в 13:29:

При низких общих системных требованиях многопоточность нужна ровно для одного: загрузки ресурсов. Чтобы вместо минуты, все сотни текстур грузились 15 секунд. В той же ЛА, в отличие от ТЧ, загрузка локации происходит быстрее, потому что пашет как минимум в 4 потока. Это сама игра в 4 потока, а загрузка, возможно, использует все ядра.

Отправлено nemyax 15-02-2020 в 06:35:

Ku2zoff
Не, ну можно рассовать в разные потоки I/O и рендеринг. Ну а ещё-то что?

Отправлено XaeroX 15-02-2020 в 06:59:

Цитата:

nemyax писал:
Ну а ещё-то что?

В волатиле:
- Рендеринг
- Нанесение декалей
- Физика
- Микширование звуков
Ещё можно было бы вынести в поток ИИ (всякие CheckLocalMove нехило жрут цпу), но мне было лень.

Добавлено 15-02-2020 в 13:59:

Цитата:

Ku2zoff писал:
многопоточность нужна ровно для одного: загрузки ресурсов

Разве обращение к диску может быть параллельным? И разве всякие glTexImage2D не синхронизируются?

__________________

Отправлено Lev 15-02-2020 в 07:06:

Дядя Миша нет, при увеличении сложности сцены и вычислении на одном ядре в нынешние времена для сносной работы надо эток 3,6-4 Ггц на ядро. Это касается относительно новых процов. При многопоточности, с учётом того что твой двиг действительно не особо требовательный, можно получить высокий фреймрейт даже на старых низкочастотных четырёхядерниках с нормальной видяхой. Типо E5450 и 750Ti.

Отправлено Дядя Миша 15-02-2020 в 09:11:

Цитата:

Ku2zoff писал:
Даже если бы и так, тот же сорс 2013 по-сути однопоточный.

У сорса сервер на отдельном ядре бегает.

Цитата:

Ku2zoff писал:
В той же ЛА, в отличие от ТЧ, загрузка локации происходит быстрее, потому что пашет как минимум в 4 потока

Ты будешь смеяться, но у меня ЛА грузится раз в пять дольше чем ТЧ.
Товариши, которые полагают, что многоядерная загрузка что-то там оптимизирует, почему-то упорно забывают, что грузят они с одного и того же винчестера, у которого одна голова и грузят в видеокарту, которая тоже не умеет это делать в мультипотоке. Единственное, где это оправдано - фоновая загрузка ресурсов.
На ютубе где-то есть обзор эксодуса со включённым профайлером и там есть расклад поядрам - одно ядро 70%, другое ядро 30%. Отлично распараллелили. Причём я думаю, что 70% это физикс.

Чтобы от параллельных процессов был прирост надо:
1. найти то, что можно считать параллельно
2. не потерять время на синхронизации

Вот в том же Сорсе, как я говорил, сервер тикает отдельно, если энтить довольно много, это вполне себе разумное решение. Но и то - под вопросом. Возьмём мой любимый AD, сипульчер. Там 5000 энтить и 100 фпс. Причём низкий фпс обусловлен неоптимальностью дерева, в первую очередь. Но в любом случае он выше современного стандарта в 30-60 фпс.

Добавлено 15-02-2020 в 11:54:

Цитата:

Lev писал:
Это касается относительно новых процов. При многопоточности, с учётом того что твой двиг действительно не особо требовательный, можно получить высокий фреймрейт даже на старых низкочастотных четырёхядерниках с нормальной видяхой. Типо E5450 и 750Ti.

Я смотрю ФиЭктра с тобой шышками поделился? Откуда эта песня про "новые процы" взялась?

Добавлено 15-02-2020 в 11:56:

Есть условно две школы подхода к оптимизации. Старое поколение привыкло это делать алгоритмически, новое свято уверено, что всё можно распараллелить, а сами алогоритмы могут быть сколь угодно неоптимальные, главное - раскидать по ядрам.

Добавлено 15-02-2020 в 12:06:

Цитата:

SNMetamorph писал:
Нашел еще кое-что интересное по теме
https://www.youtube.com/watch?v=dE6r0-MfyRI

кажется они там сломали интерполяцию, индирект мельтешит при движении источника.

Добавлено 15-02-2020 в 12:11:

В Унреале-то для динамики тоже LPV используется, просто эпики предпочитают не заострять на этом внимание.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 15-02-2020 в 11:36:

>> Есть условно две школы подхода к оптимизации. Старое поколение привыкло это делать алгоритмически, новое свято уверено, что всё можно распараллелить

Что мешает сочетать и то и другое?

Отправлено XaeroX 15-02-2020 в 11:54:

Цитата:

Дядя Миша писал:
новое свято уверено, что всё можно распараллелить, а сами алогоритмы могут быть сколь угодно неоптимальные, главное - раскидать по ядрам.

Впервые слышу такое мнение. Ни в одной нормальной фирме на код-ревью не пропустят квадратичный алгоритм там, где можно уложиться в линию или нлогн.
Параллелят обычно чтобы меньше нагружать UI-поток. Юзер любит, когда программа отзывчива, а все эти крутящиеся песочные часы желает видеть как можно реже.

__________________

Отправлено ncuxonaT 15-02-2020 в 13:25:

Цитата:

Дядя Миша писал:
В Унреале-то для динамики тоже LPV используется, просто эпики предпочитают не заострять на этом внимание.

Не используется. "Light Propagation Volumes are a feature in development and not ready for production. " Он даже выключен по умолчанию, нужно конфиг править, чтобы включить.
В твоём же видосе на 27 минуте написано, что нет каскадов, то есть эта хрень не масштабируемая.

Посмотрел демку. Можно подобрать параметры, при которых отдельные места будут выглядеть приемлемо, но при этом все остальные превращаются в тыкву. Есть подозрение, что автор где-то накосячил. Почему, например, отсвет от синего шара разбегается, если увеличивать количество проходов? Оно суммироваться должно по идее. Или это из-за сферических гармоник?

Отправлено Дядя Миша 15-02-2020 в 14:01:

Цитата:

FiEctro писал:
Что мешает сочетать и то и другое?

Так вопрос был не о сочетании, а о том, что параллельные потоки я непременно должен использовать.

Цитата:

XaeroX писал:
Ни в одной нормальной фирме на код-ревью не пропустят квадратичный алгоритм там, где можно уложиться в линию или нлогн.

Ну начинается.

Цитата:

ncuxonaT писал:
Не используется. "Light Propagation Volumes are a feature in development and not ready for production. " Он даже выключен по умолчанию, нужно конфиг править, чтобы включить.
В твоём же видосе на 27 минуте написано, что нет каскадов, то есть эта хрень не масштабируемая.

Вообще-то видос 16-го года, а на дворе 20-й. Если ты имеешь дело с UE, то можешь нам рассказать как обстоит ситуация сегодня. И как там вообще реализновано деномическое освещение. Из самого видоса я понял, что SDF используется в качестве ускоряющих структур для трассировки. Ну то есть объект пишут в 3д текстуру и потом по ней выполняется трасса. Это взаместо классических шадов-лодов такая апчхимизация.

Цитата:

ncuxonaT писал:
Есть подозрение, что автор где-то накосячил

Да запросто. Я и не говорю, что она идеальная. Я сказал, что вижу потенциал для того, чтобы разобраться с этим. Остальные алгоритмы я не вижу смысла даже рассматривать, они еле-еле ворочаются на своих же тестовых картах.

Цитата:

ncuxonaT писал:
Или это из-за сферических гармоник?

гармоники нелинейные же. Ты почитай статью на геймдеве, там даны графики как реальная функция накладывается на производную гармоники и они порой очень сильно не совпадают. Ну да гармоники можно кубемапами заменить, к примеру. И окклюзию подкрепить тестом реальной геометрии. Благо у нас там будут брашы и будет PointContents.
Для моделей, понятное дело, такие вещи нереализуемы.

Добавлено 15-02-2020 в 16:50:

Цитата:

ncuxonaT писал:
Можно подобрать параметры, при которых отдельные места будут выглядеть приемлемо

Совсем забыл. Включи propgrid3d 1 - это поможет предотвратить часть утечек.

Добавлено 15-02-2020 в 17:01:

Ну а пока вы тут обсуждаете сложность алгоритмов в нормальных фирмах, я продолжаю работать над компиляторами. После того как было принято решение оставить только динамический свет, сами понимаете, у меня оказались развязаны руки в плане подготовки геометрии к лайтмапам. Поскольку всего этого больше делать не нужно, то и нет смысла хранить параметрические поверхности в карте, их можно сразу превратить в треугольники-стрипы. Што я, собственно и проделал, же.
Теперь этим нашим патчам надо построить клипбрашы. В отличие от моделей с их непредсказуемой топологией, здесь мы можем получить куда больше подсказок. Ну например очень легко задатектировать замкнутый патч, хотя бы одному измерению - это будет труба. Патч, замкнутый по двум измерениям будет уже шар, но Ксерокс сказал, что в Джеке нет такого префаба. Правда сам факт замкнутости еще никоим образом не говорит нам о том, что получившийся патч будет конвексным. Например язык на q3dm1 вполне себе замкнутый, но не конвексный ни разу. Так что надо дополнительно еще проверить на конвексность и соответственно выбрать метод генерации брашей. Идеальный кейс это один колоизационный конвексный браш для одного патча. Чуть более худший - аппроксимация квадами, ну и дефолтный вариант - налепить тонких брашей из треугольников, понятно, что объема в патче так уже не будет, но если патч незамкнутый, то этого и не надо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 15-02-2020 в 14:19:

Цитата:

ncuxonaT писал:
каша была на формате карт ксаша с настраиваемой плотностью лайтмапы. Лайтбейкер в процессе перехода на рейтрейсинг

А между тем формат с настраиваемой плостностью лайтмапы-это не какое-то экспериментальное недоразумение, и его тоже хорошо бы поддерживать.
Получается на обычной ХЛ та версия не глючила? Ты выкладывал её для скачивания?

Я надеюсь по завершению перехода на рейтрейсинг ты потестишь её вот как раз на громадной карте типа ЧАЭС.

Отправлено ncuxonaT 15-02-2020 в 14:48:

Цитата:

Дядя Миша писал:
Вообще-то видос 16-го года, а на дворе 20-й.

я ж цитату привёл из актуальной документации

Цитата:

Дядя Миша писал:
Совсем забыл. Включи propgrid3d 1 - это поможет предотвратить часть утечек.

Только хуже стало

Цитата:

Crystallize писал:
А между тем формат с настраиваемой плостностью лайтмапы-это не какое-то экспериментальное недоразумение, и его тоже хорошо бы поддерживать.
Получается на обычной ХЛ та версия не глючила? Ты выкладывал её для скачивания?
Я надеюсь по завершению перехода на рейтрейсинг ты потестишь её вот как раз на громадной карте типа ЧАЭС.

По большому счету, это проблема не запекания света, а загрузки БСП. На обычной ХЛ не глючила, выкладывал на КСМе.
ЧАЭС вроде из моделей был собран, нет? И соответственно, развертки под лайтмапу там не было?

Отправлено Дядя Миша 15-02-2020 в 15:48:

Цитата:

ncuxonaT писал:
я ж цитату привёл из актуальной документации

да я ж почём знаю, откуда цитата.

Цитата:

ncuxonaT писал:
ЧАЭС вроде из моделей был собран, нет?

да, из моделей. Развертка генерится на лету и нигде не хранится.

Вот так выглядит описание одного сурфейса (треугольника) для моделей лайтмапы

C++ Source Code:

1	typedef struct

3	byte styles[MAXLIGHTMAPS];

4	int lightofs; // -1 no lightdata

5	} dfacelight_t;

Добавлено 15-02-2020 в 18:48:

Ну да ладно, к освещению мы позже вернёмся. Сейчас на повестке дня доделать бсп и сделать виз.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 15-02-2020 в 16:00:

Цитата:

Дядя Миша писал:
Патч, замкнутый по двум измерениям будет уже шар

Бублик.

Отправлено Дядя Миша 15-02-2020 в 19:04:

nemyax как вариант.

Добавлено 15-02-2020 в 22:04:

Первые опыты. Это коллизия для планарных патчей.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 16-02-2020 в 09:18:

Кстати в Tesseract по моим воспоминаниям реалтаймовый GI весьма шустро работал, но правда вот косяк с утечками света был. Сделал коробку без окон абсолютно, свет снаружи падал на крышу, и она изнутри светилась.

P.S. Нашел еще кое-что https://www.youtube.com/watch?v=fAsg_xNzhcQ
С руки на спонзе что-то проржался.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 16-02-2020 в 10:32:

Цитата:

SNMetamorph писал:
Кстати в Tesseract по моим воспоминаниям реалтаймовый GI весьма шустро работал

Radiance Hints это еще больший фейк, чем LPV.

Добавлено 16-02-2020 в 12:37:

Цитата:

SNMetamorph писал:
Нашел еще кое-что

любая имплементация, кроме ISM предполагает какую-то дополнительную структуру для трассировки геометрии, либо вообще забивает на это.
В Унреале к примеру додумались аппроксимровать дистанс филдами. Спорное решение ИМХО. Я в параное сделал честную трассу по BSP в шейдере, но это не слишком быстро, конечно. Хотя Barnes запускал на своём титане, говорит 250 фпс выдавало даже на фуллресе.
В новом движке я хочу переложить на KD-tree это всё. Но опять же - это касается только статичной геометрии.

Добавлено 16-02-2020 в 13:32:

А я пока разбираюсь с колоизацией для патчей. Мне бы хотелось охватить все случаи, в которых коллизию можно свести к одному брашу, вместо того чтобы городить тонкие брашики на каждый треугольник.
Ну вот пример того, что у меня получилось.
Планарные конвексные патчи и враппед-патчи зачастую можно представить таким образом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 16-02-2020 в 15:10:

Частные случаи я успешно превратил в еденичные брашы, а вот с общими конечно ерунда полная. Максимум что тут еще можно сделать без дополнительной аналитики - это найти полностью конвексные модели, но вероятность невелика, разве что на тестовых уровнях.
Надо завозить ConvexDecomposition.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 16-02-2020 в 20:42:

Цитата:

Дядя Миша писал:
Надо завозить ConvexDecomposition.

Ну отож.
Для виза и колоизации ты строишь отдельные деревья?

Отправлено Дядя Миша 16-02-2020 в 21:00:

одного вполне достаточно. Для точечной трассы можно KD-tree потом построить. Ну это для GPU.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 17-02-2020 в 16:21:

Начал разбираться с конвексной декомпозицией. Удивительно, но нашлось примерно ничего. Всё что есть - это реализация в составе буллита. Олдовый алгоритм, который, по чьему-то меткому выражению "надувает брашы" и два модерновых - HACD и VHACD. Второй создаёт облако точек, в силу чего для генерации хуллов из простейшей модельки может потреблять в пике до 300 мегабайт. Пока оставил его. А HACD должен работать. Подключил его к себе. Там запредельно идиотская имплементация векторов, ну да ладно.
Вроде бы скормил всё правильно, он работает и выдаёт мне серию хуллов, в каждом их которых по два треугольника
Ну я всю жизнь полагал, что для конвексного хулла надо ну хотя бы 4 треугольника. Но нет, вот упёрся и всегда выдаёт 2. Я тогда подумал, может эти треугольники надо смержить в единый браш - опять ничего подобного.
Чёрт его знает что за алгоритм такой. Главное в самом буллите его и не юзают.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 17-02-2020 в 17:28:

Цитата:

Дядя Миша писал:
Там запредельно идиотская имплементация векторов

Чем идиотская?

Отправлено Дядя Миша 17-02-2020 в 18:28:

Через тимплейты. Вообщем как я не маялся, она мне стабильно выдаёт хуллы по 2 треугольника. Но! Стоит чуть-чуть подкрутит Concavity, как всё волшебным образом меняется, оно даже начинает что-то там генерировать.
И из этой кашы даже получаются валидные хуллы временами.
Там кажется в основе алгоритма лежит забавное допущение, что можно генерировать слегка вогнутые мешы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 17-02-2020 в 18:52:

По идее тебе даже простительны пересекающиеся хуллы. Может, это облегчает задачу. Не знаю, допускаются ли такие в физдвижках.

Отправлено Crystallize 17-02-2020 в 19:45:

Дядя Миша ну на хлру же делали самотыкообразный столбик одним брашем.

Отправлено Дядя Миша 17-02-2020 в 21:15:

Цитата:

nemyax писал:
По идее тебе даже простительны пересекающиеся хуллы

ну это если я плюну и сам начну решать эту задачку. Частные случаи, такие как планарный конвексный патч и замкнутый конвексный патч я решил (и выложил карту-пример). А эти вот пытаюсь решить с помощью науки и техники. HACD я дропнул в итоге, он начинает относительно корректно работать только когда ему наращиваешь concavity. Теперь проверяю VHACD. Воксельный декомпозитор, кстати он для блендера есть.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 17-02-2020 в 21:23:

Цитата:

Дядя Миша писал:
кстати он для блендера есть

Пожалуй, лучше в гудини пойти, где встроенный оператор Convex Decomposition порубает налиту =)

Отправлено Дядя Миша 17-02-2020 в 21:49:

VHACD работает, но во первых долго, а во вторых очень приблизительно.
Причём приблизительность, судя по всему напрямую зависит от кол-ва вокселей. Тепичный представитель нового подхода к программированию - долго-долго маслает, жрёт несколько ядер и выдаёт крайне приблизительный результат. Не нравится мне всё это.

Неаккуратные брашы - это продукт VHACD.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 17-02-2020 в 21:56:

Вообще говоря, дефолтный патч это работа через OpenCL. Но даже при максимальных настройках оно ведёт себя странновато.
Я бы не стал заострять на этом внимание, но по сути это вообще единственное, что я смог найти. Прикладываю демку, сами попробуйте.
Столик, кстати из буллита.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 17-02-2020 в 22:05:

А вот коллизия 12 минут считалась. Ну это несеръезно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 18-02-2020 в 06:12:

Обычную бсп-шинковку меша по фейсам можно приспособить для декомпозиции? Или это и есть олдовый алгоритм?

Отправлено Дядя Миша 18-02-2020 в 07:26:

nemyax да я уже думал об этом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 19-02-2020 в 19:47:

Прогнал конкавные мешы через BSP-дерево. Это далеко не такое простое занятие, как может показаться. Дерево, оно же не различает где пустота, а где солид, поэтому мы на выходе очевидно имеем нарубленное конвексное пространство. И из этой кашы нам надо вычленить наш исходный меш.
Простая фильтрация точек в дерево не спасёт - точности не хватает.
Моё решение - задвинуть исходные точки полигонов внутрь, примерно на ON_EPSILON * 2, тогда в большинстве случаев референсные лифы определяется правильно. Фейл обычно наступает в случае заострённых поверхностей, ну например на приложенной карте к грешному языку прилипло два лишних браша. Для наконечников тоже есть эта проблема, но поскольку наконечники являются wrapped convex меш, то для них вызывается другой алгоритм, без декомпозиции.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 19-02-2020 в 20:38:

Цитата:

Дядя Миша писал:
Дерево, оно же не различает где пустота, а где солид

Ты ведь можешь метить оригинальные фейсы, мол у меня со стороны бакфейса солидно/пусто. При разрезании это свойство унаследуется.

Отправлено Дядя Миша 19-02-2020 в 21:12:

nemyax кутришное дерево не сохраняет фейсы, да и толку мне с тех фейсов? Мне же конвексные брашы нужны, а не фейсы.

Цитата:

nemyax писал:
мол у меня со стороны бакфейса солидно/пусто

это не работает так. Это если я бы изначально фильтровал брашы в дерево.
А я сую ему вот эту кашу из полигонов и потом, получившимся деревом кромсаю браш на конвексные части. Ну как в унреале, для понимания.
Там не остаётся места для пустоты, там всё заполнено брашами. Я тоже думал, да ерунда ща определим. Весь день промудохался, пока не придумал фильтровать в дерево оригинальные плоскости, но с небольшим смещением, чтобы компенсировать потерю точности.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 19-02-2020 в 21:38:

Есть понимание, как надо моделить, чтобы получалась хорошая разбрашовка?

Отправлено Дядя Миша 19-02-2020 в 22:19:

nemyax это только для коллизии и по желанию дизайнера.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 24-02-2020 в 18:56:

Утомил меня этот .ase в край. Более идиотского текстового формата я просто не видел. Там получается занятная тенденция, поскольку текстовый формат не является строгим, то каждый извращается как может.
На этом фоне .smd выглядит просто образцом стандартизации, хотя он тоже текстовый. Вот как раз потому что никакие вольности там недопустимы, даже пробелы и отступы должны совпадать. Так что финальная версия компилятора будет грузить именно .smd. А для асешек я конвертор напишу, ну оно не особо сильно нужно, скорее для обратной совместимости и тестирования.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 25-02-2020 в 08:54:

Цитата:

Дядя Миша писал:
На этом фоне .smd выглядит просто образцом стандартизации

Ага, только новые версии 3д пакетов его уже не поддерживают, никто не писал никаких плагинов. Разве что в блендере был экспорт в сорсовский smd.

Цитата:

Дядя Миша писал:
Прогнал конкавные мешы через BSP-дерево. Это далеко не такое простое занятие, как может показаться. Дерево, оно же не различает где пустота, а где солид, поэтому мы на выходе очевидно имеем нарубленное конвексное пространство. И из этой кашы нам надо вычленить наш исходный меш.

А по нормалям меша нельзя определить?

Отправлено Дядя Миша 25-02-2020 в 09:19:

Цитата:

FiEctro писал:
никто не писал никаких плагинов

Там плагин элементарно пишется за полчиса, вон Немякса спроси.

Цитата:

FiEctro писал:
А по нормалям меша нельзя определить?

В дереве используются только чётные плоскости.

Мне тут в голову пришла любопытная мысль. Я же собирался сделать поддержку компилируемых декалей, ну т.е. таких, которые будут превращаться в полигоны уже на этапе компиляции карты, значит можно организовать некоторую поддержку для хейтмапы прямо в компилере.
Можно вообще по хейтмапе сразу сгенерить выпуклую декаль, как будто это параллакс какой-нибудь

Но конечно опционально. Скажем еденичную дырку от взрыва или там лужу так еще сделать можно, а вот всю стену выпуклыми кирпичами замостить - нет, слишком тормозно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 25-02-2020 в 10:56:

Smd объединяет вершины с одинаковыми координатами в одну вершину, это не круто.

Отправлено nemyax 25-02-2020 в 11:25:

ncuxonaT
Сам по себе smd ничего токова не делает. Хочешь раздельные вершины — записывай туда раздельные индексы.

Отправлено Дядя Миша 25-02-2020 в 12:11:

Цитата:

ncuxonaT писал:
Smd объединяет вершины с одинаковыми координатами в одну вершину, это не круто.

Это кто тебя так обманул?

studiomdl этим действительно занимается, но это его дело. В хл2, к примеру ничего подобного не происходит, хотя модель создается из точно таких же smd-шек.

Накидал тут примерные структуры будущего формата BSP. Основной упор сделан на максимальную прозрачность. Т.е. не хранить ничего такого, что в дальнейшем устареет и не будет востребовано.

Добавлено 25-02-2020 в 14:54:

Цитата:

nemyax писал:
Хочешь раздельные вершины — записывай туда раздельные индексы.

smd вообще не поддерживает индексы и слава богу. В текстовом формате они только место зря занимают.

Добавлено 25-02-2020 в 15:11:

Вообще, что для текстового формата в приоритете должно быть?
1. неизменность формата. Для текстового подобное правило соблюсти невероятно тяжело, потому что некоторым товарищам очень хочется предусмотреть вообще всё на какие-то мифические будущие случаи. Для smd это правило слава богу соблюдается, за 23 года единственное расширение формата - это развесовка.

2. упор на максимально быстрый парсинг. Аналогично, здесь smd вне конкуренции, поскольку он парсится не словами, а строками. А строка читается при помощи sscanf, который на порядок быстрее чем COM_ParseFile. Я знаю о чём говорю, когда-то давно, году в 2007-м я переделывал .smd парсер вот как раз на COM_ParseFile и на гигантских моделях получил чудовищное падение скорости чтения, раз в 8 примерно.

3. не пытаться сохранить в модель избыточную информацию, типа тех же индексов или цветов вертекса либо еще какой-то чертовщины. Всё это как правило уникально по месту вставки статичной модели, например для освещения или смешивания слоёв ландшафта. Т.е. в исходник эту информацию запекать всё равно бессмысленно, а индексация подобных моделей лишь увеличивает время парсинга, потом их придётся всё равно разиндексировать и построить нормальные стрипы, потому что никто не будет проверять как построены индексы в исходнике, это бессмысленная операция. Да как угодно! К тому же, когда модель вставляется в карту - вертекс тяжелеет, начинает содержать какую-то дополнительную информацию, из-за чего старая индексация моментально теряет свою актуальность.

4. возможность ручного редактирования. И здесь smd без равных, потому что данные идут предсказуемыми блоками безо всякой индексации. Я помню, как в том же .ase пытался заменить материал, а он не менялся и в итоге выяснилось, что там записано несколько одинаковых материалов - формат-то позволяет. В .smd просто включаешь автозамену и никаких сюрпризов. Ну и тот факт, что любой меш всегда привязан к кости в данном случае благо - мы всегда можем его быстренько покрутить или подвинуть целиком на какое-то расстояние. А вы попробуйте этот же фокус проделать в .ase или .obj. Obj кстати имеет милую привычку ссылаться на внешний материал описания файлов (тоже разумеется текстовый), но цымес в том, что имена ссылок вполне могут совпадать с реальными текстурами, поэтому одни парсеры считают эти ссылки путями к текстурам, а другие падают с ошибкой о том, что mtllib.c не найден.

Я с этими текстовыми форматами уже второй месяц вожусь плотно, я ведь сперва тоже думал, что они все примерно одинаковые и удобные. Хрен-то там. Дичь лютая творится. Я уже в .ase парсере сделал кучу магических условий, чтобы он мог адекватно парсить разные выхлопы экспортёров.
То что было закомпилено при помощи q3map2 надо свапать вертексами и потом еще дополнительно вращать на 90 градусов, то чтобы сделано при помощи самописного экспортёра от авторов X-Real, надо свапать индексами, при том, что сбор имён текстур материалов - само по себе увлекательнейший квест, оно может быть прописано как в MAP_NAME так и в BUTMAP так и в MATERIAL_NAME, либо в сабсекции DIFFUSE_NAME, где есть очередные BITMAP и MAP_NAME. И каждый экспортёр это оформляет как ему больше нравится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 25-02-2020 в 13:19:

Цитата:

Дядя Миша писал:
Это кто тебя так обманул?

studiomdl этим действительно занимается, но это его дело. В хл2, к примеру ничего подобного не происходит, хотя модель создается из точно таких же smd-шек.

Как оно определяет, это одна вершина или несколько разных?

Отправлено thambs 25-02-2020 в 13:33:

Цитата:

Дядя Миша писал:
типа тех же индексов или цветов вертекса либо еще какой-то чертовщины

VertexBlend же для ландшавтных-моделей очень удобен безо всяких хейтмэп, или ты не об этом?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено ncuxonaT 25-02-2020 в 15:09:

Цитата:

Дядя Миша писал:
3. не пытаться сохранить в модель избыточную информацию,

Хранить на каждый треугольник полностью 3 вершины - это и есть избыточная информация. 99% вершин принадлежат больше, чем одному треугольнику, поэтому отделение одного от другого с индексированием уменьшит объем занимаемой памяти в несколько раз.

Отправлено Дядя Миша 25-02-2020 в 16:00:

Цитата:

ncuxonaT писал:
Как оно определяет, это одна вершина или несколько разных?

то, чем занимается studiomdl вообще делалось для immediate отрисовки.

Цитата:

thambs писал:
VertexBlend же для ландшавтных-моделей очень удобен безо всяких хейтмэп, или ты не об этом?

Да, но цвета задаст компилятор, в .smd им просто нечего делать.

Цитата:

ncuxonaT писал:
Хранить на каждый треугольник полностью 3 вершины - это и есть избыточная информация

под избыточной я имел виду всякие дополнительные атрибуты.
А то, что текстовый формат неиндексирован - так это очень большой прирост в скорости парсинга, я выше объяснял почему.

Добавлено 25-02-2020 в 18:58:

Приступил к разработке виза. Поскольку лайтмапы отменяются, набор для компиляции будет состоять из двух утилит, ну понятно.
Думаю за пару дней справлюсь.

Добавлено 25-02-2020 в 19:00:

Вообще говоря, я потом этот виз протестирую на работу с двойной точностью и если это не скажется на скорости и не внесёт негативного эффекта, то можно будет объеденить их с makebsp, как фкутри.
Там просто жы эти пассажы, они память жрут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 25-02-2020 в 16:26:

Цитата:

Дядя Миша писал:
то, чем занимается studiomdl вообще делалось для immediate отрисовки.

Как это меняет тот факт, что информация теряется во время экспорта в smd? После него либо сливай все вершины в одну, либо не сливай ни одной.

Отправлено Дядя Миша 25-02-2020 в 16:34:

Цитата:

ncuxonaT писал:
Как это меняет тот факт, что информация теряется во время экспорта в smd?

какая именно информация теряется во время какого экспорта и причём тут вообще smd?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 25-02-2020 в 16:41:

ncuxonaT
На развесовку смотри. Совпадает — клеишь.

Отправлено ncuxonaT 25-02-2020 в 16:53:

Дядя Миша информация об индивидуальных вершинах теряется при записи в smd. Бывает такое, что вершин одинаковые координаты, но они при этом принадлежат разным треугольникам. После экспорта в smd этого уже не восстановить, вершины сольются в одну, у треугольников появится общее ребро. TBN будет строиться криво, привет швы из дума 3.

Добавлено 25-02-2020 в 19:53:

nemyax из того, что развесовка совпадает, не следует, что это вершина одна. На неё можно смотреть, если типа целый объект предполагается разделять, и фрагменты привязаны к разным костям. Но в случае моделей с симметричной разверткой типа дум3 это не сработает.

Отправлено nemyax 25-02-2020 в 16:59:

Цитата:

ncuxonaT писал:
у треугольников появится общее ребро

Значения нормалей по углам от этого не изменятся.

Добавлено 25-02-2020 в 19:59:

В конечном итоге ты всё равно не знаешь, какие вершины в какой момент на видимокарте окажутся склеены и какая там будет индексация. Дядя Миша пострипает, как ему нравится, или уложит всё под вызов какого-нибудь glDrawElements на своё усмотрение.

Отправлено ncuxonaT 25-02-2020 в 17:05:

Цитата:

nemyax писал:
Значения нормалей по углам от этого не изменятся.

Зато изменится тангент вектор, который станет нулевым.

Цитата:

nemyax писал:
В конечном итоге ты всё равно не знаешь, какие вершины в какой момент на видимокарте окажутся склеены и какая там будет индексация. Дядя Миша пострипает, как ему нравится, или уложит всё под вызов какого-нибудь glDrawElements на своё усмотрение.

От стрипов и индексации ничего не случится. А вот переклеивать вершины не надо.

Отправлено Дядя Миша 25-02-2020 в 19:29:

Цитата:

ncuxonaT писал:
информация об индивидуальных вершинах теряется при записи в smd

Что такое "индивидуальные вершины" ?

Цитата:

ncuxonaT писал:
После экспорта в smd этого уже не восстановить, вершины сольются в одну

Да каким же это образом вершины сольются в одну?

C++ Source Code:

triangles

2	textures/moteof/walltrim2

3	0 -88.000000 112.000000 0.000000 0.000000 0.000000 -1.000000 6.745331 9.926242

4	0 -60.000000 84.000000 0.000000 0.000000 0.000000 -1.000000 6.745331 9.484300

5	0 -92.000000 104.000000 0.000000 0.000000 0.000000 -1.000000 6.997871 9.894674

6	textures/moteof/walltrim2

7	0 -60.000000 84.000000 0.000000 0.000000 0.000000 -1.000000 6.745331 9.484300

8	0 -68.000000 80.000000 0.000000 0.000000 0.000000 -1.000000 6.997871 9.515867

9	0 -92.000000 104.000000 0.000000 0.000000 0.000000 -1.000000 6.997871 9.894674

Описание треугольника:

C++ Source Code:

1	<путь к текстуре>

2	<номер кости> <x> <y> <z> <nx> <ny> <nz> <s> <t>

3	<номер кости> <x> <y> <z> <nx> <ny> <nz> <s> <t>

4	<номер кости> <x> <y> <z> <nx> <ny> <nz> <s> <t>

Объясни уже наконец, что тут такое должно потеряться?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 25-02-2020 в 20:22:

Дядя Миша строки 4 и 7 - это одна вершина? Строки 5 и 9 - это одна вершина?

Отправлено nemyax 25-02-2020 в 21:32:

Цитата:

ncuxonaT писал:
изменится тангент вектор, который станет нулевым

А как его вычисляют?

Отправлено Дядя Миша 25-02-2020 в 22:47:

ncuxonaT ты как-то странно используешь слово "одна". Если все атрибуты совпадают, её можно расшарить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 26-02-2020 в 00:38:

nemyax тангент-вектор (красный на иллюстрации) должен лежать в касательной плоскости, то есть быть перпендикулярным нормали. Векторов в плоскости много, поэтому для стандартизации люди договорились считать тангент-вектор направленным в одну сторону с осью U на развертке. По одной вершине непонятно, куда направлена U, нужны соседние, поэтому тангент-вектора сначала считаются для треугольников, а потом уже для вершин берётся среднее значение от соприкасающихся треугольников.
Представь, что на третьей картинке используется развертка из двух зеркальных частей. То есть на левой половине вместо D7 D8 D1 будут отзеркаленные D4 D3 D2. Для правой половины тангент-вектор будет направлен вправо, для левой - влево. А в сумме выйдет ноль.

Дядя Миша а можно не расшарить. В SMD нет информации, какие вершины нужно шарить, а какие нет.

Отправлено nemyax 26-02-2020 в 06:56:

ncuxonaT
Ну так данные нормалей предоставляют тебе всю потребную информацию, чтобы находить общие рёбра и чтобы векторы не гасились. А ты как будто топишь за то, чтобы их наоборот можно было гасить в произвольных местах.

Отправлено Дядя Миша 26-02-2020 в 07:45:

Цитата:

ncuxonaT писал:
а можно не расшарить

они в любом случае пошарятся, для стрипификации.

Цитата:

ncuxonaT писал:
Представь, что на третьей картинке используется развертка из двух зеркальных частей

ну так это проблема моделлёра, а не касательного пространства. Впрочем, можно сначала построить тангенты, а потом уже расшарить вертексы.
Проблема надуманная абсолютно.

Доделал виз, работает. Я почти всё взял от оригинала, там особо нечего модифицировать. Впервые за всё время существования квейков появилась возможность оценить вклад CSG в работу виза. Так вот вклад есть и он существенный. На q3dm1 без виза получается в среднем 42 портала на лиф, а с CSG - всего 30 порталов. Отдельно скажу за механизм портально-пассажного виза. Ничего особенного он не делает, обычный баланс междуь памятью и процессорным временем. Классический портальный виз вычисляет сепараторы по ходу работы, портально-пассажный строит их до начала вычислений, сепараторы конечно требуют какой-то объем памяти.

Есть еще интересная штука - мержилка лифов и фейсов. По дефолту она выключена. Может помочь сократить кол-во порталов и лифов, которые по смыслу можно объеденить, главное что бы у них плоскости совпадали.
Впрочем на размер виздаты это никак не влияет. Наверное было бы логичнее эту мержилку перенести в BSP.
Так же хочу отметить, что итоговый фпс с визом нельзя назвать прямо сильно отличным от старых халфовских карт, для которых я построил оптимальное визтри на лету. Ну я рассказывал об этом.
На сипульчере в оригинале 290 фпс, на кутришной карте 350 фпс. На гренделе оригинальная карта показывает даже более высокие значения.

Добавлено 26-02-2020 в 10:45:

И чтобы окончательно закрыть эту тему с касательным - абсолютно все лоадеры, которые я видел избавляются от индексов на этапе загрузки, строят уникальные вертексы, т.е. эта информация теряется в любом случае.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 26-02-2020 в 14:27:

nemyax я не понимаю, что ты говоришь. Нормали кроме касательной плоскости ничего не дают.

Цитата:

Дядя Миша писал:
ну так это проблема моделлёра, а не касательного пространства.

Так же думали погромисты дум3. А моделлеры дум3 думали, что это проблема погромистов, ведь в 3дмаксе у них всё нормально было, вертексы разделены. Если сначала строить тангенты, то это нужно делать еще до экспорта из 3д редактора.

Цитата:

Дядя Миша писал:
они в любом случае пошарятся, для стрипификации.

Моделлер решает, где вертексы шаренные, а где нет. И в нормальном формате это записывается. Только что проверил, FBX, DAE, неоптимизированный OBJ из 3дмакса и просто OBJ из блендера сохраняют всё нормально.
К слову, в SMD не добавишь ни второго канала развертки, ни vertex color.

Добавлено 26-02-2020 в 17:27:

Цитата:

Дядя Миша писал:
абсолютно все лоадеры, которые я видел избавляются от индексов на этапе загрузки, строят уникальные вертексы,

зачем это делать, если индексы уже подразумевают под собой уникальные вертексы

Отправлено Дядя Миша 26-02-2020 в 16:52:

Цитата:

ncuxonaT писал:
Так же думали погромисты дум3. А моделлеры дум3 думали, что это проблема погромистов, ведь в 3дмаксе у них всё нормально было, вертексы разделены.

Тогда объясни как это в хл2 нету проблем с бампом, они-то модельки тоже из smd компилят.

Цитата:

ncuxonaT писал:
К слову, в SMD не добавишь ни второго канала развертки, ни vertex color.

А зачем добавлять то, что игнорируется в любом случае?

Цитата:

ncuxonaT писал:
зачем это делать, если индексы уже подразумевают под собой уникальные вертексы

Индексы не подразумевают ничего. Я в любом случае это по своему индексирую.

Добавлено 26-02-2020 в 19:50:

У smd на самом деле есть одно важное преимущество - он по дефолту уже ориентирован "По Кармаку", значит его не надо никуда лишний раз поворачивать при импорте-экспорте. По крайней мере в рамках рабочей среды, если это экспортёр из блендера, то там наверное надо.

И вообще мне честно говоря это уже вкрай надоело. Чтобы я ни сделал - начинает спорить, что-то доказывать. Да нахер мне это надо? Иди свой движок пиши и там делай как тебе нравится.

Добавлено 26-02-2020 в 19:52:

Главное столько лет этот бамп в параное делали - ни слова от тебя не было на тему того, что он из-за smd кривой. А тут вдруг выяснилось. Тебе просто скучно и надо поспорить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 26-02-2020 в 17:10:

Цитата:

Дядя Миша писал:
Тогда объясни как это в хл2 нету проблем с бампом, они-то модельки тоже из smd компилят.

В хл2 нет моделей с симметричной разверткой как в дум3

Цитата:

Дядя Миша писал:
Главное столько лет этот бамп в параное делали - ни слова от тебя не было на тему того, что он из-за smd кривой. А тут вдруг выяснилось. Тебе просто скучно и надо поспорить.

Было. Я еще на ксме говорил, что на модели толстяка из дума шов на нормали

Цитата:

Дядя Миша писал:
А зачем добавлять то, что игнорируется в любом случае?

Сейчас игнорируется, а потом понадобится. А уже не добавить.

Цитата:

Дядя Миша писал:
Чтобы я ни сделал - начинает спорить, что-то доказывать.

Когда я не спорил и не доказывал, у вас нормали были в разные стороны, а на моделях со скелеткой вообще черти чего. Ты этого хочешь?

Отправлено nemyax 26-02-2020 в 17:15:

Цитата:

Дядя Миша писал:
если это экспортёр из блендера, то там наверное надо

В блендере Z-up, X-right. Всё по-кармаковски.

Отправлено Дядя Миша 26-02-2020 в 18:12:

Цитата:

ncuxonaT писал:
В хл2 нет моделей с симметричной разверткой как в дум3

ну вот видишь как просто это решить

Цитата:

ncuxonaT писал:
модели толстяка из дума шов на нормали

да это Элбер его криво экспортнул. Мы же понятия не имеем чем он пользовался.

Цитата:

ncuxonaT писал:
Сейчас игнорируется, а потом понадобится

не понадобится.

Цитата:

ncuxonaT писал:
не доказывал, у вас нормали были в разные стороны

А как же они по твоему должны быть в одну сторону штоле?

Добавлено 26-02-2020 в 21:12:

В любом случае тангента строится на основе нормали и текстурных координат для дублирующихся вертексов. Если она будет отличаться, вертекс шареным и не станет, очевидно же. Т.е. это элементарно восстанавливается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 27-02-2020 в 01:48:

Цитата:

Дядя Миша писал:
В любом случае тангента строится на основе нормали и текстурных координат для дублирующихся вертексов. Если она будет отличаться, вертекс шареным и не станет, очевидно же.

Вероятно, это сработает. Конечно, если на развертке не будет диких искажений. И нужно будет поставить какой-то значительный порог сравнения тангентов. Ну чтобы не получилось, что никакие вертексы не шарятся.

Отправлено Дядя Миша 27-02-2020 в 07:46:

ncuxonaT я вот еще думаю, если получившийся TBN прогнать через BFN-карту и сохранить их как char[3]. И по хорошему, когда снимаешь нормали с меша, их тоже перед записью в tga надо прогонять через BFN.

Добавлено 27-02-2020 в 10:46:

Цитата:

ncuxonaT писал:
И нужно будет поставить какой-то значительный порог сравнения тангентов.

Гм. Векторы сравнивают через дот, а в качестве порога берут угол в радианах. Я обычно использую шаг в 2 градуса. Впрочем в оригинальных студиомоделях нормали индексируются с точно таким же шагом. Это нам даёт 32400 уникальных нормали по идее. Но конечно в BFN разрешение даже выше получается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 27-02-2020 в 13:43:

Цитата:

Дядя Миша писал:
я вот еще думаю, если получившийся TBN прогнать через BFN-карту и сохранить их как char[3].

Это только для экономии памяти? Может, и ничего, только несколько побьются axis aligned вектора.

Цитата:

Дядя Миша писал:
И по хорошему, когда снимаешь нормали с меша, их тоже перед записью в tga надо прогонять через BFN.

Я про это думал. По уму надо все мипы прогонять BFN. И со сжатием текстур оно дружить не будет.

Цитата:

Дядя Миша писал:
Я обычно использую шаг в 2 градуса.

Есть подозрение, что для тангентов шаг маловат, из-за искажений развертки тангенты могут сильнее отличаться. Но оно чисто умозрительное.

Отправлено Дядя Миша 27-02-2020 в 15:17:

Цитата:

ncuxonaT писал:
Это только для экономии памяти?

Не только. Для того чтобы погрешность везде была идентичная.

Цитата:

ncuxonaT писал:
И со сжатием текстур оно дружить не будет.

в ATI2N? Хороший вопрос, конечно. А Крайтек по этому поводу ничего не писал?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 27-02-2020 в 16:08:

Цитата:

Дядя Миша писал:
А Крайтек по этому поводу ничего не писал?

Неа. Они делали свой энкодер для ATI2N, который считал ошибку не по отдельным каналам, а по восстанавливаемой нормали. Но он одну текстуру сжимал 3 часа, поэтому использовался только в крайних случаях.

Отправлено Дядя Миша 27-02-2020 в 17:08:

Цитата:

ncuxonaT писал:
Но он одну текстуру сжимал 3 часа

Им по идее надо было еще одну табличку намайнить для стереографической проекции.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-02-2020 в 11:20:

Ну чтожы, работа над компиляторами потихоньку движется к завершению.
Я правда не исключаю варианта, что мне придется всё же опять вернуться к лайтмапам (зависит от того, насколько хорошим будет деномическое освещение), поэтому сам формат пока оставлю кутришным, не буду его переделывать.
Осталось добавить статические декали и разобраться с генерацией клип-брашей для некоторых случаев.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-02-2020 в 15:48:

Так же начерно реализовал обещанную концепцию скриптовых компилерных энтить, вот пример для общеизвестного func_group

C++ Source Code:

1	"func_group"

3	movePrimitives( "classname", "worldspawn" );

4	removeEntity();

Внутри описания находятся команды, что сделать с данной энтитью. Ну в данном случае - отправить примитивы в энтить, которую мы ищем по класснему и этот класснейм - ворлдспавн. Но конечно возможна и классическая связка "targetname" "target". Это в первую очередь полезно потому что, вот этих компиляторных энтить существует великое множество и делать поддержку этого зоопарка внутри кода просто неразумно.
В идеале я хочу вообще избавиться от константных имён внутри кода XashNT. Ну кроме игровой дллки конечно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 29-02-2020 в 22:58:

Дядя Миша что ты планируешь показать народу в качестве демки на новом движке? Идеи есть? Мб Monorail Quest, если Thambs согласится его портировать? Или p2? Всё это звучит и выглядит здорово, кабы не было похоже на очередной Generic Engine с кучей фич, продемонстрированных на нескольких перекомпиленных картах из других игр. С Xash3D такой ситуации не возникло, потому что ты завёл там совместимость с голдсорсом, и база того, во что можно погамать, получилась просто огромной.

Отправлено Дядя Миша 01-03-2020 в 06:52:

Цитата:

Ku2zoff писал:
что ты планируешь показать народу в качестве демки на новом движке?

Строго говоря, движка скорее всего в свободном доступе и не будет.
Так что играйтесь с демкой, те кто успели скачать, сегодня удолю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 01-03-2020 в 11:12:

Добавил важную штуку - детальные сепараторы, которые не ликуют.
В ку2 такие были. Это детайлы которые остаются полноценной частью уровня, но при этом не участвуют в создании порталов для виза.
Естественно классические детайлы тоже никуда не делись, но теперь благодаря новой системе описания компиляторных энтить можно завести и такие и такие.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 02-03-2020 в 13:25:

Я еще вот что планирую сделать - подгрузку smd моделей для энтить.
Вот например у нас func_door который делают брашами, ну в крайнем случае патчами. А можно просто указать .smd модель ему и будет сразу дверь моделькой и с коллизией. И вагончик халфовский можно будет точно так же делать, да что угодно. Чтобы не заниматься дурной работой, когда дверь делается из клипбрашей и к ней аттачится визуальная часть.
А тут просто загрузил модельку, клипбрашы сами сгенерились.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 02-03-2020 в 14:16:

А смд будет налиту компилиться в мдл или сразу как смд использоваться?

Отправлено Дядя Миша 02-03-2020 в 14:46:

smd будет вставляться в карту

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 03-03-2020 в 09:19:

Решил проверить оригинальный код текстурирования террайна (на его базе когда-то выросли параноевские ландшафты, но в параное попиксельные слои, а тут повертексные). Ну вообщем грасс_тест раскрасил, сижу жду.
Уже минут пять наверное. В стоке какой-то дико неоптимальный код.
В q3map2 алгоритм получше, но загрузчик текстуры альфа-мапы остался какой-то кастомный, в результате он почти никогда не может найти эту грёбаную текстуру. Поэтому и кутримапные ландшафты тоже никто и никогда не юзал. Юзеры они ведь как - если не сработало с первого раза забывают навсегда.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 03-03-2020 в 09:26:

Дядя Миша
В эдж оф форевер и мирапиде магикан же оно было, там ещё в исходнике он вертексты специальными брашами помечал?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 03-03-2020 в 09:30:

Досчитало. Семь минут бесполезной работы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 03-03-2020 в 09:35:

Вид сверху

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 03-03-2020 в 10:59:

Дэнди какое-то
Я помню вы всё собирались написать специальный редактор для этих ландшафтов, дошли руки у кого-нибудь?

Отправлено FiEctro 03-03-2020 в 11:03:

Хех, по скрину можно все пиксели сосчитать. Я так понимаю там текстурка 64х64? Выглядит уродливо, надо какую нить сглаживалку сделать, чтобы убрать пиксельность.

Отправлено thambs 03-03-2020 в 11:13:

FiEctro

Цитата:

но в параное попиксельные слои, а тут повертексные)

Ну если сетка нерегулярная будет, со сгущениями в областях больших градиентов, то и попиксельности никакой не будет, я так понимаю.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 03-03-2020 в 12:14:

Переделал текстурирование, вроде стало повеселее

Добавлено 03-03-2020 в 15:14:

Ну и да, вместо семи минут теперь компилится 25 секунд.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 03-03-2020 в 12:19:

Заменил один слой для наглядности. Впрочем что у этих ландшафтов, что у параноевских одна и та же проблема - юзеры не хотят редактировать ч\б карту вслепую.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-03-2020 в 12:27:

Дело не в карте, а то что такой вид тераинов обычное баловство, не более. Ничего адекватного на них не сделать, вот хотябы даже ограничить горами карту как нибудь, чтобы она не обрывалась в небо, или каньон с обрывами. И при этом смотрелось вполне достойно. В лучшем случае можно сделать пару островков и натыкать туда моделей. Первый скрин мне понравился, видимо тут ещё конечная картина зависит от того какие текстуры подберешь.

Отправлено Дядя Миша 03-03-2020 в 14:42:

Цитата:

FiEctro писал:
Ничего адекватного на них не сделать, вот хотябы даже ограничить горами карту как нибудь, чтобы она не обрывалась в небо, или каньон с обрывами

Это же обычные брашы, как хочешь так и делай. Террайн затрагивает только текстурирование. Да и в параное точто так же было.
Я кончно могу налиту сгенерить брашы из хейтмапы, но мне надо чтобы джек это потдерживал.

Добавлено 03-03-2020 в 15:34:

Вообще я эту задачу решил еще тогда в 16-м году, когда замутил попиксельное текстурирование террайнов. Всё упирается только в визуализацию редактирования. Насколько я понимаю, радиант тоже не показывает как это выглядит. Поэтому все и юзали максимум двухслойные террайны, где сразу видать что к чему.

Добавлено 03-03-2020 в 17:42:

Кутришный код подсчёта т-джунков это нечто. Запустил сразу сипульчер - считало 21-минуту. При том, что без т-джунков компиляция карты занимает менее двух минут. Никуда не годится. Впрочем у меня подозрение что эти т-джунки они вообще не особенно актуальны. Неужели за столько лет производители видеокарт не решили этой проблемы в драйвере, почему надо этот мусор добавлять в геометрию непременно?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 03-03-2020 в 14:50:

Цитата:

Дядя Миша писал:
почему надо этот мусор добавлять в геометрию непременно?

потому что без них между фейсами будут щели из-за конечной точности флоатов

Отправлено Дядя Миша 03-03-2020 в 15:18:

ncuxonaT в ку3 все точки брашей снапятся к сетке. Если бы дело было в конечной точности, то этот простой трюк бы полностью исправил положение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 03-03-2020 в 15:21:

Дядя Миша в ку3 браши не нарезаются? Откуда там вообще тогда тжунки?

Отправлено Дядя Миша 03-03-2020 в 16:42:

ncuxonaT ты точно правильно понимаешь их природу?
Дело не в том, нарезаются браши или нет и не в конечной точности флоата.
В первой кваке, к примеру все вертексы были снапнутые, да и сам софт-рендер работал на целочисленой математике, однако же от т-джунков это не спасало.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 03-03-2020 в 16:51:

Дядя Миша не точно. Я считал, что они добавляются на стыках, где вершина одного фейса попадает на ребро другого, чтобы не было щелей. Это неверно?

Отправлено Дядя Миша 03-03-2020 в 16:53:

ncuxonaT добавляются они именно туда, но совсем не потому что нехватает точности флоата.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 03-03-2020 в 17:08:

Дядя Миша почему же?

Отправлено Дядя Миша 03-03-2020 в 18:04:

Хороший вопрос. Это как-то связано с принципами растеризации.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 03-03-2020 в 18:15:

Дядя Миша ну так я про то и говорил. Из-за конечной точности флоатов при растеризации получается так, что вершина не попадает на ребро, вылазит микрощель

Отправлено Дядя Миша 03-03-2020 в 18:17:

ncuxonaT а если попадает, а щель всё равно есть?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 03-03-2020 в 18:21:

Дядя Миша не должно быть такого. Да и как она может попасть. Были у тебя координаты вершин целые по сетке, на матрицу проекции умножил, вот уже и конечная точность флоатов, вершина с ребра убежала

Отправлено Дядя Миша 03-03-2020 в 18:37:

ncuxonaT смелое допущение. В таком случае любая карта бы пестрела щелями. Но нет - они строго на определённых местах.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 03-03-2020 в 18:52:

Дядя Миша ты сейчас о каких именно картах говоришь?

Отправлено Дядя Миша 03-03-2020 в 19:19:

Я напомню, на первом плейстейшене вот как раз из-за недостаточной точнсти фиксированной точки полигоны реально дышали. Но щелей - не было. Догадаешься почему?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 03-03-2020 в 19:20:

Дядя Миша потому что не было там тжинков, вершины у треугольников совпадали

Отправлено Дядя Миша 03-03-2020 в 20:00:

Не, потому что оно плаваало всё вместе, синхронно. Точность-то нарушается сразу у всех вертексов. А тут иное.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 03-03-2020 в 20:11:

Дядя Миша вместе плавают вершины. Вершина с ребром вместе не плавают. Было у тебя как слева. Вершины немного поплыли, и ребро убежало. Когда есть тжинк, он эту дырку прикрывает (потому что его вершины плавают вместе с остальными).

Отправлено Дядя Миша 03-03-2020 в 21:13:

ncuxonaT ну ты же видел эти щели. Они не похожи на второй скрин. Они выглядят именно как тонкая линия.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 03-03-2020 в 21:25:

Дядя Миша ну так не настолько же низкая точность. А на первой плойке так бы и было

Отправлено FiEctro 04-03-2020 в 13:44:

Зачем компилятор вообще Т-джинки делает? Рёбра экономит?

Отправлено ncuxonaT 04-03-2020 в 13:54:

ты ~~одноглазый~~ не читатель?

Отправлено Дядя Миша 04-03-2020 в 15:20:

А я пока декали делаю )

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-03-2020 в 19:52:

декаль без нормали, сама анализирует соседние сурфейсы и вычисляет оптимальную нормаль для проекции. Но я хз, будет ли такое востребовано.
Полностью ручные декали - это очевидно планарные патчи, которые юзер может "накладывать" как декали с точным контролем всех трансформаций.
А для постеров разумнее использовать классические infodecal как в халфе были. Поставил рядом со стеной, оно и забрызгало.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-03-2020 в 21:18:

Декаль-решётка на брашах и патчах. Не определюсь какую проекцию лучше оставить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-03-2020 в 22:17:

Ну вообщем-то и всё

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 05-03-2020 в 06:11:

Дядя Миша
А демонические тени таким способом дорого?

Отправлено thambs 05-03-2020 в 06:24:

Дядя Миша
А полноцветные декали удалось с туманом подружить?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено FiEctro 05-03-2020 в 06:26:

Дядя Миша
Как ты боришься с этим ?

Отправлено Дядя Миша 05-03-2020 в 08:07:

nemyax там нет какого-то особенного способа. Линейный перебор всех поверхностей.

Добавлено 05-03-2020 в 10:04:

Цитата:

thambs писал:
А полноцветные декали удалось с туманом подружить?

там и не было особой проблемы никогда. Проблема была в том, что на старых радионах polygonOffset валился в эмуляцию почему-то.

Цитата:

FiEctro писал:
Как ты боришься с этим ?

с чем именно?

Добавлено 05-03-2020 в 11:07:

Всё дело в том, что в разработке одно цепляется за другое, за третье в конечном итоге, я не могу ничего финализировать, потому что неясна финальная концепция. Ключевой элемент - это освещение. На нём завязано абсолютно всё. И как организован формат уровней и механизм сетевой интеракции и система материалов. Пора уже приступать к самому важному.
Динамический индирект это конечно хорошо, но если у нас в кадре сотня лампочек с тенями, производительность упадёт ниже плинтуса еще на этапе прямого света. Второй момент - генеричность. Освещение должно быть естественно увязано с уже существующей системой материалов, причём таким образом, чтобы реализация была снаружи - в скриптах.
У меня нет ни малейшего желания прописывать Get\Set для сотен юниформов внутри кода, как это сделал, например автор Unigine.
Впрочем в CryEngine точто такая же беда. Да и еще много где. Это гнилой подход, он не нужен. Внутри движка должны быть только общие механизмы.
Опять же надо продумать формат скрипта интеракции, где всё это будет описано, причём он должен описывать не только освещение, но весь путь рендеринга, включая множественные проходы. Это позволит создавать пользовательские модели рендеринга. В одной игре пусть будет форвард, в другой - отложка. И всё это должно быть реализовано в скриптах.
Эта задача прежде всего сложна тем, что я не вижу конечного решения, оно будет находится в процессе непрерывной корректировки, ну собсно как я пришёл к текущей системе материалов. В процессе я этот механизм переписывал не менее десяти раз, прежде чем получил текущую систему.
Причём зайчатки этот концепции я прорабатывал еще в 2015-м году, но тогда я писал на чистом Си и оч. быстро запутался. А может просто опыта нехватало, кто его знает.
Да и то что у меня получилось - далеко не окончательный вариант, к примеру сейчас доступ к тем или иным переменным жёстко прописан в коде, а там должно быть нечто вроде системы сейв-рестора с поиском переменной по имени в структуре. По крайней мере для энтить, потому что пользователь может расширять CBaseEntity. В том же дуум3, к слову. отвели просто набор из parm-parm7, что хочешь то и пихай в эти переменные. Но это конечно узкое решение.
Ну вот с механизмом интеракции всё это приобретёт уже законченный вид. Посмотрим, что получится в конечном итоге.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 05-03-2020 в 09:03:

Цитата:

Проблема была в том, что на старых радионах polygonOffset валился в эмуляцию почему-то.

Хм, у меня в p2 и на нвидии они просвечивали.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено FiEctro 05-03-2020 в 10:20:

Цитата:

Дядя Миша писал:
с чем именно?

С растягиванием проекционных декалей. Я там даже сслыку на скрин дал.

Отправлено Дядя Миша 05-03-2020 в 11:18:

Это параллельная проекция. Тебя же не удивляет, что тени солнца растягиваются точно так же?
Я же там еще и написал, что пока не определился с типом проекции.
Ну просто перспективную для декалей использовать как-то нелогично что ли.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 09-03-2020 в 22:03:

Вообщем, что я решил с вадами. С одной стороны - полностью отказываться от них нельзя. По крайней мере на время переходного периода.
Во первых, чтобы редактор отображал какие-никакие, а всё же текстуры.
Потом редактор переобучим. Есть и второй момент - это поле "wad" в настройках. Туда обычно попадают имена использованых вадов. Так вот, поскольку большинство карт уже сделано таким образом, что вместо пути к текстурам там идёт только одно имя и нет никакой возможности это как-то автоматически преобразовать и разрулить, то я придумал вот какую штуку.
Сам движок вады конечно грузить не будет (на данный момент еще умеет, но скоро я их вырежу), но в системе материалов останется переменная <wadname>. Как она будет действовать?
При загрузке уровня поле "wad" будет прочитано и имена вадов сохранены в список. Затем, при поиске текстур в материалах, как вы помните можно задавать локации - где бы еще поискать текстуру.
Например - таким образом

C++ Source Code:

addImageLocation( u_ColorMap, "textures/<wadname>/<texname>" );

и вот тут-то и вступают в дело те самые имена вадов, записанные в поле "wad". Каждый такой путь проверяется, на предмет валидности текстуры. перебирая имена вадов по списку точно так же, как это делала халфа.
Только вместо вадов у нас тут получаются реальные пути папок к текстурам, но алгоритм такой же. И вот мы просто раскладываем наши текстуры в textures\<имявада> и всё работает точно так же, как и нахалфе, в плане дублирующихся текстур в разных вадах. Разумеется этот путь я привёл просто для примера, пользователь сам его полностью определяет. Можно вообще отказаться от переменной <wadname> и слить все текстуры в одну папку, к примеру. Но для эмуляции старого функционала - вот такая переменная. Более подробно было в документации по системе материалов, кто успел - тот скачал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дикс 10-03-2020 в 08:24:

Другими словами для движка и вад и директория это одно и то же

__________________
igroprom.d3.ru

Отправлено Дядя Миша 10-03-2020 в 08:49:

Имя вада используется в качестве имени директории, да.

Избавиться от вадов не так-то просто, например в них хранятся шрифты. Надо разработать другой формат шрифтов теперь.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 10-03-2020 в 12:54:

Работаю над новым форматом шрифтов. Любопытно, что раньше я никогда не добирался до этого момента. Я конечно мог бы просто вытащить из вада старые шрифты, но они калечные, в них мало информации и ограничение на размер текстуры. В новых шрифтах я планирую сохранить больше всякой инфы про буквы, например размеры abc, а не только общую ширину.
А сам шрифт будет хранится в отдельной картинке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 10-03-2020 в 13:30:

А почему для шрифтов просто не прикрутить .ttf?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено thambs 10-03-2020 в 13:44:

Дядя Миша
Надо всё таки что бы они хоть налету кешировались из вектора при смене разрешения. Сейчас же у всех мониторы весьма широко варьируются, фиксированным растром на всех не обойдёшься.

Добавлено 10-03-2020 в 16:44:

Дядя Миша
Скажи, а p2st умеют читать внешние текстуры из папки? Я вот никак не подготовлю себе новый тулчайн, так что бы можно было с одним и тем же исходником работать и для nt и для xt, без ретекстуринга...

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 10-03-2020 в 17:12:

Цитата:

SNMetamorph писал:
А почему для шрифтов просто не прикрутить .ttf?

TTF либо стандартными виндовыми средствами, либо на линуксе через FreeType2. Таскать вместе с движокм библиотеку, которая весит больше чем сам движок я не планирую. Значит остаётся виндовый функционал, который используется для создания растровых шрифтов.

Цитата:

thambs писал:
Надо всё таки что бы они хоть налету кешировались из вектора при смене разрешения

Я не хочу со всем этим заморачиваться. Будет несколько разрешений, движок подберёт из них наиболее оптимальное.

Цитата:

thambs писал:
Скажи, а p2st умеют читать внешние текстуры из папки?

Они умеют, но это недокументированная особенность. Они даже кутришные шейдеры умеют читать, но я об этом никогда не распространялся.

Добавлено 10-03-2020 в 20:12:

С этими шрифтами постоянно вылезают какие-то грёбаные заморочки.
Ну навскидку, DIB, как я понимаю не может быть более текущего размера экрана. Т.е. шрифты размером 72 и более отрендерить просто не получится - вылет. Конечно шрифты такого размера не нужны, но сам факт.
Потом другая шняга - на рабочем компе русские буквы генерятся при CHARSET_ANSI, на домашнем - только при CHARSET_RUSSIAN. Винда вроде бы с одного диска ставилась. Что за чертовщина, что там по дефолту так переключено, что на одной работает, а на другой нет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 10-03-2020 в 17:32:

Цитата:

Дядя Миша писал:
Ну навскидку, DIB, как я понимаю не может быть более текущего размера экрана. Т.е. шрифты размером 72 и более отрендерить просто не получится - вылет.

почему нельзя частями делать?

Отправлено Дядя Миша 10-03-2020 в 20:15:

Да не, я разобрался, там в другом дело было. Стек переполнялся.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 11-03-2020 в 07:19:

Цитата:

Дядя Миша писал:
TTF либо стандартными виндовыми средствами, либо на линуксе через FreeType2. Таскать вместе с движокм библиотеку, которая весит больше чем сам движок я не планирую.

Есть, насколько я помню, еще махонькие stb-библиотеки для этих же целей.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 11-03-2020 в 11:07:

Я уважаю Баррета и всё что он делает, но рендеринг шрифтов - нетривиальная задачка.

Ну вот у него там примерчег:

C++ Source Code:

fread(ttf_buffer, 1, 1<<20, fopen("c:/windows/fonts/times.ttf", "rb"));

stbtt_BakeFontBitmap(ttf_buffer,0, 32.0, temp_bitmap,512,512, 32,96, cdata); // no guarantee this fits!

Типо никакой гарантии, что все буквы влезут в атлас, плюс этому коду надо указывать не имя системного шрифта, а путь до физического файла. Зачем мне, спрашивается, всё переделывать, если я уже сделал анализатор упаковки, который подбирает оптимальные размеры, наложил пост-процессы и прочее. Если бы я про него вспомнил парой дней раньше, может быть и заюзал бы.

Добавлено 11-03-2020 в 13:57:

Он фактически в этот хидер запихал софтрендер. Теперь спрашивается, если какие-то буквы некорректно отрендерятся или упадёт это всё - как исправлять ошибку, как это поддерживать? Ну нафиг, я не хочу с этим связываться. Есть виндовые функции, им я доверяю в этом плане.

Добавлено 11-03-2020 в 14:07:

Я единственно о чём жалею - слишком поздно нашёл его репозиторий, если бы мне его кто-то показал в 2010-м, я бы был в восторге, а щас - уже не нужно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 11-03-2020 в 11:22:

Так-таки и "c:/windows"? Даже без попытки порезолвить %windir%?

Отправлено Дядя Миша 11-03-2020 в 12:12:

Цитата:

nemyax писал:
Так-таки и "c:/windows"?

Ну этож просто примерчег закоменченный. Не важно.
У шрифтов в системе есть имя, по которому мы их берём. Реальное имя файла, естественно отличается, т.е. без этого механизма уже очень неудобно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 12-03-2020 в 10:19:

Так товарищи, а подскажите мне навскидку, как правильно выбирать point size шрифта в зависимости от разрешения экрана? Я пока придумал, разрешение поделить на 80 и получившееся число и будет нашим point size.
80 - это кол-во буков в консоли.

Добавлено 12-03-2020 в 13:19:

Конечно при разработке нового формата мне бы хотелось, чтобы визуально новые шрифты не слишком отличались от старых. Так например в халфе яркость шрифтов не 255, а 192 и у всех по дефолту есть обводка.

Первые результаты:
Старый шрифт

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 12-03-2020 в 10:19:

И новый. Джпипег цвета побил

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-03-2020 в 11:18:

Дядя Миша
Так сохраняй с минимальной компрессией в фотошопе, вообще хранить шрифты в жпеге крайне странная затея. Лучше уж тогда генерить из .ttf

Отправлено nemyax 12-03-2020 в 11:18:

Дядя Миша
Взял бы шрифт, где легко отличить I, l, 1. Например, Tahoma, Verdana, PT Sans.

Отправлено ncuxonaT 12-03-2020 в 11:50:

Мне казалось, для консоли моноширинные шрифты используют

Отправлено Дядя Миша 12-03-2020 в 12:02:

Цитата:

FiEctro писал:
вообще хранить шрифты в жпеге крайне странная затея

Шрифты не в джипеге, это я вам скриншот выложил в джипеге

Цитата:

ncuxonaT писал:
Мне казалось, для консоли моноширинные шрифты используют

любой шрифт с переменной шириной легко отрисовать как моноширинный.

Я тут подумал, что старый вариант консоли, где кол-во символов на строке варьировалось в зависимости от разрешения экрана - стрёмный. Ну потому что это придумал еще Кармак для моноширинных шрифтов, которых была всего одна штука. Сейчас, когда мы можем загружать на каждое разрешение свой шрифт (или с близким point size), это становится наоборот неудобно. Я принял классический размер консоли в 80 символов.
Вот что у меня в итоге получилось.
На этот раз сохранил в PNG чёб цвета непобились.

Добавлено 12-03-2020 в 15:02:

хм, форум в PNG не умеет, очуметь можно

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 12-03-2020 в 18:54:

Да уж, непросто избавиться от вадов. Намертво они въелись.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 13-03-2020 в 19:24:

Мне тут в голову пришла забавная мысль. Тот формат, который я разработал для шрифтов с таким же успехом можно использовать и для спрайтов и для внешних лайтмап, например, вообще для любых атласов.
Зачем там городить какой-то разный огород? Для всех единый удобный формат и вася-кот.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 14-03-2020 в 09:05:

Ну вообщем-то да, всё в эту схему укладывается и худ-спрайты и трава и партикл-фонты и импосторы. Таким образом в движке получится четыре типа объектов:
1. текстура
2. вот эти вот атласы, работающие в паре с текстурой
3. модели
4. уровни

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 14-03-2020 в 16:53:

Вот такой атлас получился.

Подаем на вход makespr для XashNT халфовский hud.txt. Он его читает, грузит с него все спрайты и объединяет их в атлас. Теперь у нас все элементы худа в одной текстуре. Можно так же просто подать на вход имя спрайта и он превратится в аналогичный атлас с внешним хидером.
Это для миграции с халф-лайфов. Для создания новых спрайтов надо просто наделать кадров и указать их на вход по маске. Ну возможны, конечно еще какие-то режимы работы, в будущем.

Добавлено 14-03-2020 в 19:53:

Между прочим поддерживаются поименованные кадры спрайтов. Этот хидер, который я разработал - это мета-контейнер на самом деле.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 14-03-2020 в 20:30:

Наконец-то дошли руки опробовать тот упаковщик атласа, котоым так восторгался Психопат. Ну это который строит подобие BSP-дерева из ректанглов. Опробывал, результат в аттаче. Можете сравнить с верхним.
И ярко видна вот эта тенденция оставить правый нижний угол пустым. Если бы это было в 3д, я бы конечно предложил порубать изначальный объем надвое, но это блин картинки, их нельзя так разрубать
Правда справедливости ради стоит отметить, что это единственный фейл упаковщика - на остальных картинках меньшего размера, он довольно неплохо справился. Впрочем единственная его заслуга - картинки лежат приятно глазу. Но не слишком эффективно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 14-03-2020 в 21:03:

Дядя Миша эффективно-эффективно, больше влазит. А размер атласа перед упаковкой ты как выбираешь?

Отправлено Дядя Миша 14-03-2020 в 21:13:

Цитата:

ncuxonaT писал:
А размер атласа перед упаковкой ты как выбираешь?

А, вот в том-то и дело. Размер атласа я тестирую. Алгоритм следующий:
1. список ректанглов сортируется по размеру - самые большие в начале списка.
2. находятся максимальные размеры одного элемента, начальный размер атласа принимается равным им. затем в цикле попеременно увеличивается высота и ширина на четыре пикселя и каждый раз запускается полное построение страницы. Валидным считается такой размер атласа, на котором упаковщик не вернул false.
3. Кармаковский код работает безо всякой сортировки, но, как выяснилось - если ему подать отсортированные ректанглы, то он воспрянет духом и упакует еще плотнее. Упаковщик с нодами без сортировки не работает в принципе.
4. Я повторюсь, протестировал все спрайтесы из халфовского худа, объединяя их по группам, согласно *.txt-спискам - ну там hud.txt, weapon_???.txt. В большинстве случаев оба упаковщика выдали почти идентичные результаты. Фейл наступил только вот на той картинке, что я приложил в аттаче.

Цитата:

ncuxonaT писал:
эффективно-эффективно, больше влазит

Ты смотришь на атлас и думаешь - как же он ловко всё пристроил ни единой лишней дырочки, оставил только одну громадную в правом нижнем углу. А ты пробывал посчитать её площадь и площади тех дырок, что оставляет алгоритм Кармака?
Я теперь понял, что это навроде ошибки выжившего. Мы видим эту дырку и нам кажется, что у нас просто такой резерв остался, потому что ректанглов было меньше чем вмещает в себя площадь квадрата. Но правда в том, что он пакует неоптимально. Что этой дырки вообще могло бы не быть, если паковать алгоритмом Кармака. А сама текстура будет почти в 2 раза меньше по размеру. Так что нет, жуйте сами свой панадол.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 14-03-2020 в 21:43:

Цитата:

Дядя Миша писал:
Ты смотришь на атлас и думаешь - как же он ловко всё пристроил ни единой лишней дырочки, оставил только одну громадную в правом нижнем углу. А ты пробывал посчитать её площадь и площади тех дырок, что оставляет алгоритм Кармака?

Я не пробовал считать площадь дырок, потому что это бесполезная метрика. Я упаковывал отсортированные наборы рандомных прямоугольников в атлас заданного размера. Кармаковский алгоритм упаковывал меньше.
Например, генерировал 3000 прямоугольников 2х2-72х72, сортировал их и упаковывал в атлас 2048х2048. Кармаковский алгоритм упаковывал 2000 и говорил "всё, дальше совать некуда". А алгоритм уголком упаковывал 2300.

Добавлено 15-03-2020 в 00:43:

Ладно, не такая большая разница была. Около 5%.

Отправлено Дядя Миша 14-03-2020 в 21:53:

Давай для начала определимся - алгоритм "уголком" без сортировки работать не может, алгоритм Кармака обычно без нее и работает и как-то даже в голову сортировать не приходит. А вот сегодня я отсортировал и очень удивился, насколько стало эффективнее. Ты сортировал исходный массив в обоих случаях?

Цитата:

ncuxonaT писал:
Я не пробовал считать площадь дырок, потому что это бесполезная метрика

А ну вот и я ж про то и говорю - ты видишь максимально плотную упаковку с одной дыркой и тебе кажется что алгоритм эффективнее работает. Хотя у него эта дырка by design. А рандомные небольшие дыры в алгоритме Кармака кажутся фейлами самого алогритма. Я ж говорю, это навроде ошибки выжившего.
На самом деле, я тут немного проанализировал варианты и понял, что кроме двух этих способов в сущности ничего больше и нет. Более плотная упаковка предполагает вращение картинки, а этого бы совсем нехотелось.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 14-03-2020 в 21:59:

Дядя Миша сортировал, конечно. Без сортировки это было бы бесполезное сравнение.

Цитата:

Дядя Миша писал:
А ну вот и я ж про то и говорю - ты видишь максимально плотную упаковку с одной дыркой и тебе кажется что алгоритм эффективнее работает.

Я же русским языком объясняю, почему считаю, что алгоритм лучше работает (потому что он запихивает больше кусков). Зачем ты мне приписываешь то, что сам же за меня и придумал?

Отправлено Дядя Миша 15-03-2020 в 08:29:

Я вон выше привёл пример, как оно работает. А твоих примеров я что-то не вижу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-03-2020 в 12:08:

Дядя Миша примеров чего?

Добавлено 15-03-2020 в 15:08:

Цитата:

Дядя Миша писал:
2. находятся максимальные размеры одного элемента, начальный размер атласа принимается равным им. затем в цикле попеременно увеличивается высота и ширина на четыре пикселя и каждый раз запускается полное построение страницы. Валидным считается такой размер атласа, на котором упаковщик не вернул false.

Если не задаваться вопросом "зачем паковать в npot текстуру", то ты хочешь сказать, что уголок смог запихнуть худ в 476х472, а на предыдущем этапе 472х472 он не справился, так?

Отправлено Дядя Миша 15-03-2020 в 12:43:

То что в bmp - 368х368 пикселей, алгоритм Кармака.
То, что в png - алгоритм "уголком" 476х472

Цитата:

ncuxonaT писал:
Если не задаваться вопросом "зачем паковать в npot текстуру"

Скорее наоборот. Последнее железо, которое валилось в эмуляцию с NPOT было GF6600. А вот текстурной памяти много не бывает. Я не вижу никаких причин не паковать сейчас текстуры в NPOT, особенно для худа. Ну да, для трёхмерки наверное воздержусь, но для GUI разницы никакой. Потому что, если паковать в POT, обе текстуры были бы 512х512 и ты бы каким-то неведомым образом определил, что уголок эффективнее. А я это доказал на самом наглядном примере - что кармаковский алгоритм уложился в меньшие размеры. И нельзя сказать, что размер атласа был выбран неправильно, я же говорю, там в цикле идёт серия тестов, до тех пор, пока упаковщик сам не скажет - ок, теперь мне достаточно места. Соответственно ширина и высота на каждой итерации растут по 4 пикселя.

Конечно я не исключаю варианта, что моя реализация упаковки уголком какая-то калечная (брал у того же Humusa). Ну ок, вот тебе исходный набор данных - халфовский hud.txt, все ректанглы для разрешения 640. Распарси текстовик и сам посмотри, что у тебя получится. Если он у тебя упакует эффективнее, скажи какую реализацию уголком ты юзаешь.
Потому что, повторюсь, она в целом показала почти идентичные результаты и зафейлила только вот на этом наборе данных. Тот же набор ректанглов для разрешения 320 она очень хорошо упаковала (но всё равно чуть-чуть хуже, чем кармаковский алгоритм).

Добавлено 15-03-2020 в 15:41:

В аттаче приложил пример упаковки для разрешения 320. То что tree - это вот как раз уголок.

Добавлено 15-03-2020 в 15:43:

Ну да ладно, вернёмся к нашым баранам.
Клиентский рендеринг худа в халфе писали какие-то садисты. Или эти люди очень не любили C++ или у них совсем не было времени красиво это оформить, скорее всего второе, если вспомнить, что первые итерации халфы со злобным барником не очень сильно отличались от кваки, а потом они сделали героическое усилие и меньше чем за год полностью всё переделали напрочь пуще прежнего.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-03-2020 в 13:18:

Дядя Миша уголок, 360х360

Отправлено Дядя Миша 15-03-2020 в 13:54:

ncuxonaT реализация откуда?

Добавлено 15-03-2020 в 16:54:

И как ты сортировал ректанглы, покажи функцию.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-03-2020 в 14:08:

Дядя Миша отсюда https://blackpawn.com/texts/lightmaps/default.html
Сортировал по большей стороне кусортом

Добавлено 15-03-2020 в 17:08:

https://github.com/juj/RectangleBinPack
вот тут кстати сказано, что этот алгоритм устарел, и некий метод гильотины лучше

Отправлено Дядя Миша 15-03-2020 в 14:38:

Цитата:

ncuxonaT писал:
Сортировал по большей стороне кусортом

Поздравляю, ты стал настоящим программистом. Информация о том, что ты сортировал именно кусортом несомненно важная

Что значит - по большей стороне? Приведи формулу.
Я к примеру вот так сортирую

C++ Source Code:

1	static int SortRectangles( const CHudElem a, const CHudElem b )

3	return b->w * b->h - a->w * a->h;

Цитата:

ncuxonaT писал:
некий метод гильотины лучше

Гильотина это вообще ультимативное решение, от всего помогает, даже от короновируса.

Добавлено 15-03-2020 в 17:35:

Поглядел мельком этот метод "гильотины", иш-ты эвристика. Походу ребята реально попытались приспособить BSP-дерево, потому что там сплиты и мержы.

Цитата:

ncuxonaT писал:
отсюда https://blackpawn.com/texts/lightmaps/default.html

Нет, у Хумуса реализация отличается, главным образом - в плане деления ректанглов. Ну ок, испытаю гильотину, испытаю и твой.

Добавлено 15-03-2020 в 17:38:

Забавно, начал читать ту статью и чувствую что где-то я этот же текст уже видел, но на русском.
А он вот он: https://www.gamedev.ru/pages/coriol...cking_Lightmaps

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-03-2020 в 14:42:

Дядя Миша в твоем варианте это выглядело бы как

C++ Source Code:

return max(b->w , b->h) - max(a->w , a->h);

Отправлено Дядя Миша 15-03-2020 в 16:59:

ncuxonaT благодарю, опробую и его тожы.

Добавлено 15-03-2020 в 19:59:

ncuxonaT не могу я твой код заставить работать правильно. Тот псевдокод содержит массу фактических ошибок, но то ладно.
Вот здесь вся хитрость:

C++ Source Code:

(if we're just right, accept)

  if img fits perfectly in pnode->rect

    return pnode

что значит fits perfectly? Прям равно-равно? Или какой-то зазор допускается?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-03-2020 в 17:11:

Дядя Миша прям равно. Там же дальше идёт разбиение, чтобы если было больше, то стало равно

Отправлено Дядя Миша 15-03-2020 в 17:29:

Да я уже разобрался. Там эти - 1 были лишние. Из-за них ничерта не работало.

Добавлено 15-03-2020 в 20:28:

Ну так, вроде бы верно работает, hud_640 собрался в 360х356, что близко к твоему результату.

Добавлено 15-03-2020 в 20:29:

ага, вот в чём фишка. У тебя функция сортировки менее оптимальная, замени на мою - еще туже будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-03-2020 в 17:40:

Дядя Миша сделал это за минуту до того, как ты написал)
впихнулось в 356х356

Добавлено 15-03-2020 в 20:40:

pic

Отправлено Дядя Миша 15-03-2020 в 17:56:

Ну видимо для данного алгоритма предел. Дальше можно гильотину попробовать, но помоему она картинки вращает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-03-2020 в 18:22:

Дядя Миша можно еще пихать в более прямоугольные атласы. Например, у меня упаковалось в 512х244, что аж на полтора процента меньше, чем 356х356

Отправлено Дядя Миша 15-03-2020 в 21:46:

Поглядел я эту гильотину - бинарный сплиттер с эвристикой. Ну наверное еще лучше упакует, но уже нет смысла так заморачиваться.

Добавлено 16-03-2020 в 00:44:

Халфовский худ базируется сплошь и рядом на допущениях, что в hud.txt строчки идут таким специальным порядком, разумеется ни в какой документации об этом не было написано. Мало того - если строчки переставить особым образом - клиент вообще вылетит.

Добавлено 16-03-2020 в 00:46:

Например dmg_bio 640 перенести в конец списка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 16-03-2020 в 00:21:

Вот это вот решение с халфовским hud.txt ооочень геморойное, если вдруг надо что-то куда-то перенести или изменить.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Ku2zoff 16-03-2020 в 02:06:

Цитата:

Дядя Миша писал:
если строчки переставить особым образом - клиент вообще вылетит

Даже спустя 22 года можно узнать что-то новое, из-за чего халфа вылетает. Со строками в delta.lst что-то подобное (только не касательно графики), если их отсортировать? Теперь понятно, почему "грамотно переписанные" моды вылетают на ровном месте.

Отправлено Crystallize 16-03-2020 в 04:37:

Цитата:

Дядя Миша писал:
Мало того - если строчки переставить особым образом - клиент вообще вылетит.

И ксаш вылетит?

Отправлено Дядя Миша 16-03-2020 в 12:21:

Цитата:

SNMetamorph писал:
Вот это вот решение с халфовским hud.txt ооочень геморойное

компилятор будет поддерживать сборку из набора именованых картинок, т.е. не надо будет дополнительно прописывать никакие текстовики.
Поддержка hud.txt это скорее для облегчения миграции.

Цитата:

Ku2zoff писал:
Со строками в delta.lst что-то подобное (только не касательно графики), если их отсортировать?

Ну в дельте можно добиться сортировкой снижения или увеличения траффика.

Crystallize я худ не трогал.

Добавлено 16-03-2020 в 14:07:

Очень крепко эти спрайты везде въелись в клиентскую часть.
Но по крайней мере я избавился от этих множественных кастов и сущностей.
И от Tri->SPriteTexture( gEngfuncs.GetSpritePointer( pModel ));

Эта хрень меня всегда бесила особенно. К слову, в сорсе эти зависимости так и не стали вычищать до конца - оставили какие-то виртуальные спрайты, которые налету создаются из текстуры либо из видеофайла. Причём загрузчик моделей в движке почему-то пользуется помощью клиентки в создании этих виртуальных ресурсов. Вообщем этот мрак, который довёл нашего Мастера до цугундера там тожы никуда не делся. Просто приобрёл несколько иные формы.

Добавлено 16-03-2020 в 15:21:

Следующий логичный шаг - внедрить эту же систему и в меню тоже.
Чтобы избавить от нагромождения непонятных маленьких картинок и чтобы гигантскую текстуру с кнопками превратить в симпатичный атлас с доступом по именам этих кнопок. Это ведь не просто какие-то атласы, я в них заложил механизм поиска наиболее подходящего разрешения, а так же проверку на bold и inatlic - все три параметра закодированы в имени шрифта. Причём это работает как на буквах, так и на картинках. В дальнейшем этот механизм ляжет в основу какого-нибудь собственного VGUI.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 18-03-2020 в 09:09:

Хех, я помню в некоторых ситуациях можно было скормить спрайтовой энтитии модельку, и оно её корректно отображало. Не ломаешь ли ты функционал?

Отправлено Дядя Миша 18-03-2020 в 09:17:

Движок грузит модельки по сигнатуре, а не по расширению. Другое дело, если энтить начнёт искать в своей модели какую-то инфу, типа анимаций, костей. Но в той же кваке это было приведено к единому интерфейсу, там всегда можно было заменять спрайты на модели и обратно.

Цитата:

FiEctro писал:
Не ломаешь ли ты функционал?

Например что?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 23-03-2020 в 13:37:

Работы потихоньку идут, переписываю меню. Как вы помните, над меню в своё время работали все кому ни лень. Там некоторый зоопарк сейчас.
Запилил красивую анимацию для нажатия кнопки. Теперь она не линейно подымается наверх, а по кубической безье-интерполяции и по трём контрольным точкам, как бы прыгает на своё место (ну типо как кутришные прыгалки), и одновременно превращается из надписи кнопки в надпись шапки. Я бы вам с удовольствием заснял видео или гифку, но я в этом абсолютно не соображаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 23-03-2020 в 16:04:

Дядя Миша ну экранку сделай))

Отправлено Дядя Миша 24-03-2020 в 14:21:

Ну вот такое оно, новое меню. Похоже на старое, но дьявол в деталях.
Шрифты теперь везде с перменной шириной буквы, есть ABC.
Раньше эта строка помещалась только с переносом.

Добавлено 24-03-2020 в 17:21:

А и кстати, этот диалоговый бокс теперь отдельный класс. Больше не надо мучиться, пытаясь его имплементировать в каждое меню и там массово снимать-выставлять флаги деактивации.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 24-03-2020 в 20:05:

Пока не забыл - посоветуйте нормальный видеоформат. В 15-м году я начал возиться с теорой, и уж хрен бы с ним с невеликим качеством, но меня выбесило отсутствие нормальной навигации и проблемы с синхронизацией звука. С другой стороны, если какой-то модный формат потянет для поддержки либы на 10 мегабайт, то такое тоже не нужно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 24-03-2020 в 20:38:

Дядя Миша из свободного только теора и vp8

Отправлено Дядя Миша 24-03-2020 в 21:26:

vp8 это webM как я понимаю. https://www.webmproject.org/code/ - где тут кодер-декодер? libwebm?

Добавлено 25-03-2020 в 00:23:

Ну и да, он же только для видео. А звук сохранять в тот же огг?

Добавлено 25-03-2020 в 00:26:

Хм, а есть же уже VP9. И что немаловажно - там потдержка альфа-канала и дептчмапы. Наверное его надо юзать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 24-03-2020 в 21:28:

Дядя Миша vp9 намного тяжелее кодируется/декодируется. Для звука огг ворбис или опус.

Отправлено Дядя Миша 24-03-2020 в 21:33:

ncuxonaT ага, как раз читаю про этот опус.
Вообще в чём разница между VP8 и VP9 с тз потребителя?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 24-03-2020 в 22:47:

С тз потребителя на моем компе фуллхд на пару мегабит жмётся vp8 со скоростью 12фпс, а vp9 со скоростью 4фпс.
У vp9 в большинстве случаев качество заметно лучше, но тем не менее иногда он сильно сливает.
В интернетах пишут, что есть быстрый декодер ffvp9, примерно сопоставимый по скорости с ffvp8.
https://yadi.sk/d/tXxr8oxuKYHdBA

Отправлено Дядя Миша 25-03-2020 в 07:06:

Что VP8 что VP9 это внутренний формат чисто для видео. Звук по прежнему идёт отдельно. Значит опять проблема синхронизации при сикинге.
У этих форматов есть нормальная покадровая навигация? Или опять бинарным поиском? Что-то я там не заметил функций для прыжка.

Добавлено 25-03-2020 в 10:06:

А вот на хабре было сравнение: https://habr.com/ru/post/96888/
говорят vp8 адски долго кодирует, по сравнению с x264. Правда это было давно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 25-03-2020 в 13:39:

Цитата:

Дядя Миша писал:
Что VP8 что VP9 это внутренний формат чисто для видео. Звук по прежнему идёт отдельно. Значит опять проблема синхронизации при сикинге.
У этих форматов есть нормальная покадровая навигация? Или опять бинарным поиском? Что-то я там не заметил функций для прыжка.

Такое вообще где-то бывает? Мне кажется, что даже в бинке, который вроде как стандарт индустрии, этого нет.

Цитата:

Дядя Миша писал:
говорят vp8 адски долго кодирует, по сравнению с x264. Правда это было давно.

По моим тестам на сегодняшний день vp8 кодируется на одном уровне со slower пресетом х264. Примерно в 2 раза медленнее medium пресета.

Отправлено Дядя Миша 25-03-2020 в 15:30:

Ну я как рассуждаю. Для чего в движке нужно видео в наше время?
1. показать логотип
2. внутри-игровые видео на текстуре

Теора худо-бедно справляется и с первым и со вторым. Плюс её в том, что к ней уже у меня написана имплементация, осталось только починить рассинхрон звука при сикинге, там какой-то бред на 0.3 секунды рассогласование идет. В 15-м году я так и не разобрался с этим. Я бы мог конечно выбрать новый кодек, VP8 или VP9, но сразу встаёт несколько вопросов:

1. чем в него кодировать? Для OGV у меня есть утилитка ffmpeg2theora. А чем собирать в webM со звуком я не имею ни малейшего понятия. То есть без звука наверное тем же ffmpeg, но мне-то со звуком надо. Есть ли какой-то общепринятый стандарт для webM со звуком?

2. Ну вот мы закодировали, какой у него будет контейнер? Ogg? Или нечто иное? Или он сам в себе контейнер? Теора спецом для огга делалась. Т.е. это формат из трёх частей - огг - контейнер, ворбис - звук, теора - видео. Как тут обстоят дела?

3. Долбаная навигация. Мне очень нравится как это сделано в том же ворбисе - раз и встал куда надо. Но то звук, а то видео. Спровидливозти ради на авишках со сжатым аудиоканалом я тоже какой-то рассинхрон ловил, так что это скорее проблема у меня, но как пользователю мне бы вот хотелось иметь вменяемый сикинг уже изкаропки. Неужели я хочу чего-то невозможного?

Кстати говоря в бинке должна быть навигация уже в API, почитай на сайте ихнем.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 25-03-2020 в 15:52:

Цитата:

Дядя Миша писал:
1. чем в него кодировать? Для OGV у меня есть утилитка ffmpeg2theora. А чем собирать в webM со звуком я не имею ни малейшего понятия. То есть без звука наверное тем же ffmpeg, но мне-то со звуком надо. Есть ли какой-то общепринятый стандарт для webM со звуком?

Все видео и аудио вместе и по отдельности стоит сжимать только ффмпегом, остальное от лукавого. У ffmpeg2theora есть только 2 плюса - оно меньше весит, и существует версия с экспериментальной версии теоры, у которой качество получше (у тебя кстати не она).

Цитата:

Дядя Миша писал:
2. Ну вот мы закодировали, какой у него будет контейнер? Ogg? Или нечто иное? Или он сам в себе контейнер? Теора спецом для огга делалась. Т.е. это формат из трёх частей - огг - контейнер, ворбис - звук, теора - видео. Как тут обстоят дела?

Какой хочешь. Хочешь ogg, хочешь webm. Контейнер на то и контейнер, что без разницы, что в него засунешь.

Цитата:

Дядя Миша писал:
Кстати говоря в бинке должна быть навигация уже в API, почитай на сайте ихнем.

Не знаю, что там на сайте, но когда проигрываю видео через рад видео тулз, то когда тыкаю в произвольное место таймлайна, он пробегает все кадры от начала видео

Отправлено Дядя Миша 25-03-2020 в 18:53:

Вообщем вот тепичный минус открытого софта - возьми кучу кирпичей и сам из них что-то сконструируй.

Цитата:

ncuxonaT писал:
и существует версия с экспериментальной версии теоры, у которой качество получше (у тебя кстати не она).

теора справляется с ксашевой заставкой, в принципе этого уже достаточно, я ж говорю.

Добавлено 25-03-2020 в 21:53:

Забавно как порой всё же действуют стереотипы на подсознание.
Вот в старом ксаше в меню, когда не выбран ни один сейв - рисовалась какая-то декалька из вада. Die Freeman или типа того. Хотя по уму надо было рисовать анимированный шум. Но когда я об этом задумывался, то просто приходил к мысли, что я не хочу с собой таскать текстуры шума. И тут же меня отвлекали какие-то другие задачи. А теперь я плотно занялся меню (но правда уже в XashNT), и опять встал этот вопрос. И я подумал - а какого собственно чёрта? Я щас рандом-лонгом нагенерю этих текстур белого шума сколько угодно. 3 минуты - и всё готово. А раньше мне это абсолютно в голову не приходило.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 26-03-2020 в 07:03:

По кодекам, что насчёт всяких там Intel YUV, Intel Indeo, Lagarith?

Отправлено Дядя Миша 26-03-2020 в 07:13:

Crystallize калечные они

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 26-03-2020 в 08:34:

Чем mp4 не устраивает?

Отправлено Дядя Миша 26-03-2020 в 09:50:

FiEctro а он разве свободный?

Добавлено 26-03-2020 в 12:50:

Я несколько удивлён, если честно. MPEG была основана в 1990-м году ЕМНИП.
В плане сжатия аудио и видео за 30 лет были испробованы абсолютно все возможные варианты, ничего более там изобрести просто невозможно, да вообщем-то и не нужно. Так казалось бы - ну сделайте какой-то общеупотребимый стандарт и вася кот. Но нет, там попрежнему зоопарк.
H264, H265, VP8, VP9. Щас еще что-нибудь выдумают. Хотя все эти пляски идут вокруг одного и того же набора алгоритмов. Фурье, дельта, ряд Тейлора и арифметическое кодирование.

Добавлено 26-03-2020 в 12:50:

А ну и Хаффман еще, конечно жы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 26-03-2020 в 18:26:

Дядя Миша тот же Хаффман разве не теоретически самое эффективное кодирование? Мол, принципиально другого и при этом эффективного не сделаешь.

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 26-03-2020 в 21:36:

Ну https://ru.wikipedia.org/wiki/%D0%9...%BD%D0%B8%D0%B5

Добавлено 27-03-2020 в 00:36:

Помните как Бабушкин предлагал взять большое число? )

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 27-03-2020 в 12:25:

Будущее меню сейвов. Каждая надпись в таблице - отдельная колонка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 27-03-2020 в 12:59:

Ну вот как-то так.

Добавлено 27-03-2020 в 15:59:

Опять джипег цвета побил

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 27-03-2020 в 13:09:

Дядя Миша ты же вроде писал пакер джипега который не артефачит?

Отправлено Ku2zoff 27-03-2020 в 13:25:

Crystallize да это форум ещё раз сжимает.

Отправлено thambs 27-03-2020 в 13:26:

Дядя Миша
А шрифты с альфа-каналом и размером побольше можно будет сгенерить?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 27-03-2020 в 18:02:

Цитата:

Crystallize писал:
ты же вроде писал пакер джипега который не артефачит?

Ты издеваешься штоли?

Или ты тонко предполагаешь что я умнее всей JPEG?

Цитата:

thambs писал:
А шрифты с альфа-каналом и размером побольше можно будет сгенерить?

А эти по твоему какие? Без альфа-канала штоли? Можно, конечно можно. Можно из ttf сгенерить абсолютно любой шрифт любого размера, сделать ему обводку, подчёркивание и размытие. Болды, италики, весь набор.

В новом ксаше я практикую вот какую концепцию: вся низкоуровневая часть пользовательской библиотеки является её же частью и находится в папке backend. Для меню - это соответственно базовые элементы интерфейса, для игровой части - физика, сейв-рестор, чейнджлевел. Всё это в пользовательских исходниках, обычно туда лезть и не надо, но если нужно, то можно переписать вообще полностью. А движок предоставляет на вход такие интерфейсы, которые точно никогда не поменяются - взаимодействие с консолью, файловой, механизм загрузки шрифтов и текстур.
То есть не возникнет ситуации, как в той же халфе, когда в API опять не хватает какой-то одной функции и придётся городить новые интерфейсы.
Меня это всегда ужасно бесило. До смешного доходит - в халфе даже запрет на сейв нельзя было сделать по нормальному.

Добавлено 27-03-2020 в 19:35:

Скролл-листы вообще были самой калечной частью старого меню. Тут предстоит много работы.

Добавлено 27-03-2020 в 21:02:

Я неоднократно говорил, что у меня работа со всеми этими менюшками вызывает отторжение. Но в данном случае работа идёт ровно. А почему? А потому что я работаю над бакэндом, мне не надо подбирать эти долбаные координаты положения окошек - они уже подобраны в старом меню.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 27-03-2020 в 19:56:

Эх, так нормального скриптового меню и не будет. Только захардкоженное.

Отправлено Дядя Миша 27-03-2020 в 21:08:

FiEctro

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 28-03-2020 в 01:30:

Цитата:

FiEctro писал:
скриптового меню

Я, если честно, не очень представляю как это так может быть.
Ну к примеру внешний вид и расположение элементов в окошке вполне можно в скрипты перенести. Но что делать с поведением-то? Ну вот прописали мы в скрипте кнопку, цвет ей прописали и размер, а что будет при нажатии происходить? Как это связать с кодом самой игры?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 28-03-2020 в 05:24:

Для скриптовых меню довольно много будет разных ограничений. Ну к примеру как делать условные кнопки, которые показываются не всегда?
Например кнопку консоли. Значит придётся городить целый язык, зачем это надо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 28-03-2020 в 07:00:

Цитата:

Дядя Миша писал:
Значит придётся городить целый язык

Ну язык C++ уже нагорожен. Ты же предоставишь апишку?

Отправлено Дядя Миша 28-03-2020 в 08:11:

Я ж говорю, фреймворк в исходниках будет внутри пользовательского кода.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-03-2020 в 08:57:

>> Для скриптовых меню довольно много будет разных ограничений. Ну к примеру как делать условные кнопки, которые показываются не всегда?
Например кнопку консоли. Значит придётся городить целый язык, зачем это надо.

Не думаю что там что то сложнее материалов или ентитей.

Отправлено Дядя Миша 28-03-2020 в 09:52:

Если кому-нибудь интересно, как я работаю:

итак, вот у нас есть старое меню. Это меню, если кто забыл, взято из Quake 2 Evolved 0.40 и довольно серъезно адаптировано к стилю WON-меню.
Ну как адаптировано - структура его не менялась особо, костылей налепили всем миром, Крейзи Рашшен помогал его писать, Адамикс (царство ему небесное) и Альбатросс. Изначально это был код Кармака, который ребята из TeamBlur расширили и дополнили. И вот такая у нас исходная каша.

Очевидно что для перевода на кресты, надо создать объекты, но процессу в первую очередь мешает необходимость постоянно видеть конечный результат. Поэтому старое меню остается в неизменном виде, а рядом пишется новое. Максимально тупым способом - то что по смыслу можно инкапсулировать - инкапсулируется. А то что не очень - оформляется в виде костыля. Таким образом я уже сделал уже три менюшки - менюху сейвов, менюху выбора скилла и главное меню. Ну и заодно анимацию шапок. И MsgBox конечно жы. На этом этапе наиболее полно раскрываются недостатки выбранного подхода и попутно отмечается что и как надо переделать в будущем. Оно конечно выглядит неплохо, но встают разные вопросы - например как обновлять данные, если они изменились. Как перезагружать меню при входе-выходе. Как изменять его размеры, если поменяется разрешение. Наконец, неплохо бы предусмотреть возможность таскать окошки по экрану. Поэтому новое меню дописано уже не будет. Оно будет лишь использовано как источник для второй итерации. И вот здесь уже будет учтено абсолютно всё, что не было сделано для первой имплементации. Почему так получается? очень просто. Некоторые вещи, особенно если ты их пишешь впервые не создают у тебя в мозгу должного представления, это неизбежный процесс. Читать умные книги и общие советы бесполезно - это твой код и он организован определённым образом. То есть первая итерация восполняет недостающие фрагменты картины, а вторая уже пишется с учётом полного виденья. В плохих случаях итераций может быть более двух. К примеру скриптовая система для рендеринга получилась только с пятой попытки. Собственно здесь и возникает важное отличие - если программист недостаточно опытный или просто ленивый, он видит что реальный код уже не укладывается в придуманную им модель, но продолжит городить свои костыли, потому что переписывать лень.
Это имеет практическое значние в том случае, если у тебя почти всё уложилось кроме пары моментов. И ты точно знаешь что расширять ничего не придется. В противном случае подход должен быть итеративным и ничего страшного в этом нет.

Добавлено 28-03-2020 в 12:52:

Цитата:

FiEctro писал:
Не думаю что там что то сложнее материалов или ентитей.

ты готов писать для менюх такие же сложные скрипты-замены, как и для материалов? При том, что материалы стремятся к унификации, а менюхи наоборот - каждую заново приходится создавать. Этот скрипт по объему будет сопоставим с сходным кодом и смысл полностью потеряется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-03-2020 в 11:36:

Да, новые виджеты на порядок удобнее старых получились. Такие не грех и в скрипт зопехать

Добавлено 29-03-2020 в 14:36:

Для примера

C++ Source Code:

1	CMenuMain :: CMenuMain()

3	int x = UI_BUTTONS_OFFSET_X;

4	int y = CL_IsActive() ? 180 : 230;

6	// add background

7	new CBackground( this );

9	// menu buttons

10	if( host->IsConsoleAllowed( ))

11	new CAnimButton( this, x, y, ID_CONSOLE, "Console" );

12	y += UI_BUTTONS_OFFSET_Y; // advances y in anyway

14	if( CL_IsActive( ))

16	new CAnimButton( this, x, y, ID_RESUME, "Resume Game", IDS_MAIN_RETURN );

17	y += UI_BUTTONS_OFFSET_Y;

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 29-03-2020 в 16:29:

>ID_CONSOLE
>ID_RESUME

Удобно.

__________________
Xash3D FWGS форк

Отправлено KiQ 29-03-2020 в 19:50:

Дядя Миша а за new потом самому подчищать в деструкторе, или автоматом делается при выгрузке либы меню? И потом, так и не пойму, если и так есть конвертор шрифтов из ttf, то почему бы не грузить из деномически прямо из движка? Все шрифты после загрузки кэшировать и потом переюзать, по типу setFont(CFontFactory->getFont("Arial.ttf", 20, FLAG_BOLD));

__________________
-Brain is dead-

Отправлено FiEctro 30-03-2020 в 07:52:

Цитата:

Дядя Миша писал:
Для скриптовых меню довольно много будет разных ограничений. Ну к примеру как делать условные кнопки, которые показываются не всегда?
Например кнопку консоли. Значит придётся городить целый язык, зачем это надо.

Речь идёт об разметке.

Цитата:

Дядя Миша писал:
ты готов писать для менюх такие же сложные скрипты-замены, как и для материалов? При том, что материалы стремятся к унификации, а менюхи наоборот - каждую заново приходится создавать. Этот скрипт по объему будет сопоставим с сходным кодом и смысл полностью потеряется.

Обычный язык разметки вроде того же html'a с этим неплохо справляется. Тут даже ничего выдумывать нового не надо.
Сиерра в своё время даже делала WON подобное меню для своего сайта по халфе, с анимациями, озвучкой и прочими финтиплюшками.

Отправлено Ku2zoff 30-03-2020 в 09:17:

Цитата:

FiEctro писал:
Обычный язык разметки вроде того же html'a с этим неплохо справляется.

Либа для поддержки html весит почти 19 мегабайт. Думаю, ДМ на такое не пойдёт. Писать собственный парсер - такое себе удовольствие. Тем не менее, идея неплохая.

Отправлено Дядя Миша 30-03-2020 в 09:35:

Цитата:

KiQ писал:
а за new потом самому подчищать в деструкторе

всё автоматически.

Цитата:

KiQ писал:
то почему бы не грузить из деномически прямо из движка?

ну потому что это непортабельное решение. К тому же шрифт у меня это более широкое понятие. В нём хранятся и буквы и кнопки меню и иконки худа. И спрайты будут в шрифтах и лайтмапы, если я всё же надумаю к ним вернуться.

Добавлено 30-03-2020 в 12:35:

Я вот всё думаю, как бы решить вопрос с масштабированием. Наверное отрендерю меню в FBO, а потом растяну его на весь экран.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 30-03-2020 в 09:51:

Цитата:

Ku2zoff писал:
Либа для поддержки html весит почти 19 мегабайт. Думаю, ДМ на такое не пойдёт. Писать собственный парсер - такое себе удовольствие. Тем не менее, идея неплохая.

У валвы вроде был свой парсер. html всеголишь как пример, можно какие то более простые языки разметок попробовать.

Отправлено Дядя Миша 30-03-2020 в 10:54:

По вадам, если еще не писал, расскажу как обстоят дела.
Итак, как вы наверное уже поняли - вадов в XashNT больше не будет. Но остаётся открытым вопрос - создана целая куча карт, где текстуры прописаны как имя без пути. Что же с ними делать? Сидеть в блокноте выполнять автозамену на каждую текстуру, меняя её имя на имя с путём?
Это дико неудобно. В движке останется поддержка механизма загрузки таких текстур в виде двух элементов. Первое - это конечно поле "wad" в ворлдспавне. Отсюда движок и другие утилиты смогут узнать список использованных вадов. Точнее говоря, в новых условиях, это уже не имена вадов, а неймспейсы. Эти неймспейсы подгружаются в особую переменную <wadname>. А уж как использовать эту переменную - это полностью дело юзера.
В дефолтном шаблоне загрузки материалов для уровня можно задать вот такую строчку:

C++ Source Code:

addImageLocation( u_ColorMap, "textures/<wadname>/<texname>" );

это просто как пример. И вот уже у нас начальное имя текстуры разворачивается в textures/<wadname>/<texname>. Но не всё так просто.
<texname> - это имя текущей текстуры. А <wadname> будет перебираться из всего списка, заданного в поле "wad" в том же самом порядке, в котором оно перебиралось и для настоящих вадов. Т.е. меняя порядок следования имён вадов в поле "wad" вы точно также сможете регулировать, откуда грузить ту или иную текстуру, если она продублирована в разных вадах. Это полностью копирует поведение халфы в отношении загрузки текстур из вадов и в то же время абсолютно ни к чему не обязывает пользователя, поскольку для каждого материала можно прописать абсолютно любое поведение. Здесь <wadname> лишь одна из доступных переменных в пути. Её можно вообще не использовать.
Можно прописать пути жёстко, можно выбрать какие-то иные правила загрузки, я напоминаю, что addImageLocation можно задать несколько раз.
Можно, к примеру сделать вот так

C++ Source Code:

addImageLocation( u_ColorMap, "textures/common/<texname>" );

addImageLocation( u_ColorMap, "textures/<mapname>/<texname>" );

и вот уже текстуры будут искаться в папке по имени уровня, а если их там нету - то в папке common. Вообщем вариантов масса.
Реальные вады останутся лежать в папке с игрой, до тех пор, пока они требуются редактору. В дальнейшем, я надеюсь, будет сделан плагин для джека, который будет парсить мои материалы, их абстрактная часть уже выделена в особый шареный фреймворк, который например, использует компилятор уровней. Ну и плагин к редактору сможет точто так же.

Добавлено 30-03-2020 в 13:54:

Цитата:

FiEctro писал:
html всеголишь как пример

я не вполне понимаю как html будет отображать кнопки из моего формата шрифтов. Может тогда уже встроить редактор меню прямо в само меню? Запустил с ключом -editmenu и переставляй-добавляй элементы. Потом нажал кнопку Save и новые скрипты записались в папку. Встроить такой редактор гораздо проще, чем городить отдельный. Благо все элементы для его создания по совместительству и элементы меню.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 30-03-2020 в 11:47:

Цитата:

Дядя Миша писал:
Запустил с ключом -editmenu и переставляй-добавляй элементы

В UT2004 так можно

Отправлено FiEctro 30-03-2020 в 13:01:

Цитата:

Дядя Миша писал:
я не вполне понимаю как html будет отображать кнопки из моего формата шрифтов.

Битмаповые шрифты - атавизм. Но вообще что то вроде такого:
https://codepen.io/Matnard/pen/mAlEJ

Цитата:

Дядя Миша писал:

Может тогда уже встроить редактор меню прямо в само меню? Запустил с ключом -editmenu и переставляй-добавляй элементы. Потом нажал кнопку Save и новые скрипты записались в папку. Встроить такой редактор гораздо проще, чем городить отдельный. Благо все элементы для его создания по совместительству и элементы меню.

Как вариант. Но по мне самих скриптов с разметкой вполне достаточно, нет особого смысла городить ещё и редактор.

Отправлено Дядя Миша 30-03-2020 в 13:15:

Цитата:

FiEctro писал:
Битмаповые шрифты - атавизм

ты где-то умных слов понахватался и теперь везде их вставляешь. Прямо как хипстор какой-нибудь. Или даже креакл.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 30-03-2020 в 13:53:

Цитата:

FiEctro писал:
Битмаповые шрифты - атавизм. Но вообще что то вроде такого:

Понимаешь, любые попытки заимстововать современные наработки где "все проблемы уже решены" приводят к необходимости вложить тысячу долларов, перейти на WebGL, поставить 2017 студию итд а результат будет требовать для работы Windows 7.

Отправлено FiEctro 30-03-2020 в 23:36:

Crystallize
Вечно вас куда то в крайности уносит.

Дядя Миша
Ну ты перерисуй хотя бы половину дефолтных виндовых шрифтов в битмапу, чтобы хватило всем. Но на деле это просто халтура, которая сваливается на плечи художников, которых нет. Плюс - огромные проблемы с локализацией, и кастомизацией, где под каждый эффект надо хранить свою картинку, как анимации кнопок в WON меню.

Я понимаю если бы это для пиксельной игры делалось, где графика заточена под олдскульность, пиксельность и тайлы. Тогда да, битмапа решает.

Отправлено XaeroX 30-03-2020 в 23:46:

Цитата:

FiEctro писал:
Но на деле это просто халтура, которая сваливается на плечи художников, которых нет.

Программу же можно сделать. Или вообще растеризовать вектор при загрузке. Хотя это стрёмно - на разных системах разные растеризаторы. Я например под виндой никак не могу добиться красивых битмап-шрифтов, поэтому делаю их под макосью. Вот там красота.

__________________

Отправлено ncuxonaT 31-03-2020 в 00:20:

XaeroX а можешь показать разницу?

Отправлено Government-Man 31-03-2020 в 00:55:

XaeroX
А вот кстати интересно, распространяется ли шрифтовая лицензия на растеризованные битмапы? Если я растеризую шрифт из винды или макоси, могу ли я включить его в коммерческий проект?

Отправлено XaeroX 31-03-2020 в 01:10:

Government-Man
Насколько я понял, не распространяется на системные шрифты. Насчет остальных - зависит от лицензии конкретного шрифта.

__________________

Отправлено FiEctro 31-03-2020 в 06:14:

Government-Man
Вроде распространяется, но это не точно. Как написал Ксерокс, в зависимости от лицензии каждого конкретного шрифта.

Отправлено Дядя Миша 31-03-2020 в 06:26:

Цитата:

FiEctro писал:
Ну ты перерисуй хотя бы половину дефолтных виндовых шрифтов в битмапу, чтобы хватило всем.

Есть утилита makefont - запускаешь и генеришь шрифт, какой нужен.

Цитата:

XaeroX писал:
Программу же можно сделать.

Программа была сделана в первую очередь.

Добавлено 31-03-2020 в 09:26:

Цитата:

Government-Man писал:
распространяется ли шрифтовая лицензия на растеризованные битмапы?

Вальва юзала Arial для консоли и Trebuchet MS для кредитсов. Никто ей ничего не предъявил. Кармак в ку3 взял Miscosoft Sans Serif в качестве системного шрифта. Вы спросите, как я догадался? А только у Trebuchet наклонные ноги у буквы M

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 31-03-2020 в 13:59:

Цитата:

FiEctro писал:
Вечно вас куда то в крайности уносит.

Так один человек же всё пишет. Если хочешь что-то продвинутое, то тут только брать чужой код, а он весь предполагает "современные подходы" к разработке.

Отправлено Дядя Миша 31-03-2020 в 16:32:

Цитата:

Crystallize писал:
Если хочешь что-то продвинутое, то тут только брать чужой код

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 31-03-2020 в 17:07:

Цитата:

Дядя Миша писал:
Я вот всё думаю, как бы решить вопрос с масштабированием. Наверное отрендерю меню в FBO, а потом растяну его на весь экран.

А если, например, наоборот, сжимать? По идее более четко будет. Ну, скажем FBO в 2 раза больше экрана. Короче тот же FSAA, только для интерфейса

__________________
-Brain is dead-

Отправлено FiEctro 31-03-2020 в 17:54:

Проблемы с масштабированием это ещё один минус ваших битмап. Если просто всё растягивать, шрифты преавратятся в мыльное говно. Тут либо собирать битмапы налету, либо заранее нагенерировать их под разное разрешение.
Тоже касается всяких кнопочек, которые бы желательно перегнать в SVG. А всякие свечения уже реализовывать программно. Кстати, может и битмаповые шрифты в нём хранить? Как компромисный вариант.

Вроде все эти вещи уже давно реализовал в своём порте наш дорогой друг Альбатрос, но вы по прежнему где то застряли в 2001м.

Отправлено Дядя Миша 31-03-2020 в 18:25:

Цитата:

KiQ писал:
По идее более четко будет

у меня нет набора картинок под любое разрешение. Да и вообще масштабирование - зло. Но что делать?

FiEctro я уже кажется объяснял, что рисовать в SVG могут не только лишь все, мало кто может это делать. Ты вот умеешь?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 31-03-2020 в 18:26:

Цитата:

FiEctro писал:
заранее нагенерировать их под разное разрешение

Ну ДМ так и предлагает, собственно, не?

__________________
-Brain is dead-

Отправлено Дядя Миша 31-03-2020 в 18:27:

Цитата:

FiEctro писал:
все эти вещи уже давно реализовал в своём порте наш дорогой друг Альбатрос

Натянул в менюху чужого говна - реализацию из STB, подключил фритайп и виндовые функции. Такой тепичный линуксовый подход, скинуть всё в кучу, пусть юзер сам разбирается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 31-03-2020 в 18:50:

Цитата:

Дядя Миша писал:
пусть юзер сам разбирается

Юзеру-то какая разница.

Отправлено ncuxonaT 31-03-2020 в 19:13:

Есть такое мнение (у автора Overgrowth, например), что нечего возиться с битмапами и атласами, а нужно просто рисовать весь текст фритайпом и забыть про проблемы с масштабированием и прочим

Отправлено XaeroX 31-03-2020 в 19:21:

ncuxonaT
Ну вот ты поиграешь в PW и посмотришь как выглядят там растровые шрифты, растеризованные на маке. А потом возьмешь программку vfont из SDK, сделаешь свой, подставишь его в игру и сравнишь.
У меня, увы, под рукой нет картинки для четкого сравнения.

Добавлено 01-04-2020 в 02:21:

Цитата:

ncuxonaT писал:
а нужно просто рисовать весь текст фритайпом и забыть про проблемы с масштабированием и прочим

Этож надо тащить с собой фритайп?

__________________

Отправлено Government-Man 31-03-2020 в 19:36:

ncuxonaT
Тогда придется вместе с игрой распространять и сами шрифты в векторном формате, а я не уверен, что лицензия на системные шрифты это позволяет.

Отправлено ncuxonaT 31-03-2020 в 19:43:

Цитата:

XaeroX писал:

Ну вот ты поиграешь в PW и посмотришь как выглядят там растровые шрифты, растеризованные на маке. А потом возьмешь программку vfont из SDK, сделаешь свой, подставишь его в игру и сравнишь.
У меня, увы, под рукой нет картинки для четкого сравнения.

Ну лан. Релиз уже вот-вот?

Цитата:

XaeroX писал:
Этож надо тащить с собой фритайп?

Возможно, это выгоднее таскания с собой атласов под разные разрешения.

Цитата:

Government-Man писал:
Тогда придется вместе с игрой распространять и сами шрифты в векторном формате, а я не уверен, что лицензия на системные шрифты это позволяет.

Зачем вообще использовать системные шрифты? Столько же шрифтов хороших под свободными лицензиями.

Отправлено Дядя Миша 31-03-2020 в 20:39:

Я свой выбор уже сделал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 31-03-2020 в 20:46:

Цитата:

ncuxonaT писал:
Возможно, это выгоднее таскания с собой атласов под разные разрешения.

Это философский вопрос, что выгоднее: таскать библиотеку под разные платформы, или атласы под разные разрешения.

__________________

Отправлено Crystallize 01-04-2020 в 08:14:

Цитата:

Дядя Миша писал:
?

Что-то продвинутое требует большого объёма работы, и в одного ты либо будешь сравнительно долго возться, либо возьмёшь чужие наработки ради ускорения процесса.

XaeroX Что там за чудо может быть с этим рендером шрифтов на Маке? Наверное окажется что растеризуется в 1К текстуру которая потом даунскейлится.

Отправлено Дядя Миша 01-04-2020 в 08:55:

Цитата:

Crystallize писал:
Что-то продвинутое требует большого объёма работы

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 01-04-2020 в 09:14:

Дядя Миша а, это мне уже промыли мозги корпоративизмом?

Отправлено thambs 01-04-2020 в 10:03:

Цитата:

XaeroX писал:
или атласы под разные разрешения.

Ещё чарсеты, если локализации поддерживаются.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 01-04-2020 в 10:07:

Crystallize может у тебя этот вирус?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-04-2020 в 10:10:

Crystallize
ДМ считает что всё что нужно уже давно написал Кармак, а все остальные занимаются изобретением велосипедов. Потому нафиг вообще эти либы?

Отправлено Дядя Миша 01-04-2020 в 15:55:

Цитата:

FiEctro писал:
ДМ считает что всё что нужно уже давно написал Кармак, а все остальные занимаются изобретением велосипедов

Некоторые типы вирусов резко снижают умственные способности.

Добавлено 01-04-2020 в 14:57:

Кармак, к слову, когда ему понадобились шрифты - подключил ваш любимый freetype2.

Добавлено 01-04-2020 в 18:55:

Наконец-то сделал авто-перенос по словам.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 02-04-2020 в 05:57:

Дядя Миша бэкпорты в Xash3D будут?

Отправлено Дядя Миша 02-04-2020 в 08:57:

Ku2zoff NT в разработке с 12-го года. До 19-го было очень много бэкпортов, в частности XashXT - суть один большой бэкпорт. Больше не будет.

Добавлено 02-04-2020 в 11:57:

Дело в том, что меня уже очень сильно ограничивает эта обратная совместимость, на фундаментальном уровне. Нет уже никакого смысла заниматься бэкпортами. Народу показываешь какой-нибудь рейтрейсинг в параное, а он спрашивает - а почему там вады?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 02-04-2020 в 21:45:

Наконец-то выкрутил настройки, чёб джипег не портил цвета.
Это уже виджеты второй итерации. Семпотично?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 03-04-2020 в 09:19:

Этот скроллист уже полностью ведёт себя как виндовый контрол - скроллбар не уезжает куда-то вверх или вниз, когда на него кликаешь мышью, двигается не рывками, а плавно, не отстает, при выборе элемента, список не съезжает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 03-04-2020 в 12:25:

Цитата:

Дядя Миша писал:
Больше не будет.

Ну а хотя бы меню? А то оно в ксаше малость стрёмное в плане взаимодействия с элементами. Особенно скроллящиеся списки. Если там конечно многое ещё от самого движка зависит, тогда не надо.

Отправлено Дядя Миша 03-04-2020 в 12:33:

Меню это уже использует механизм шрифтов из NT.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 03-04-2020 в 12:48:

Ну тады ой. Разве что сорцы откроешь, а ребята из FWGS адаптируют.

Отправлено Дядя Миша 03-04-2020 в 13:47:

Ku2zoff на кой тебе меню в ксаш-моде? Ты же под халфу делаешь.

Добавлено 03-04-2020 в 16:47:

Сегодня столкнулся с забавной вещью. Новое меню открывает LoadGame с заметным лагом. Виджетовое. А старое на условных итемах (это просто названия классов), не логало абсолютно. Сперва я думал - соберу в релизе - перестанет. Собрал, логает. Надо думаю, отпрофилировать. А там жеж таблица собирается из маленьких окошек с текстом и каждое такое окошко грузит шрифт заново. Посмотрел - да, именно так, логают эти окошки. Удивился. Шрифт должен браться из кэша, откуда лаг? А потом понял.
Загрузчик шрифтов использует нечёткую логику. Ему можно указать PointSize, Bold, Italic и он попробует это найти на диске. А если не найдёт - будет искать максимально похожее. Таким образом я не могу просматривать список уже загруженных шрифтов - я сперва должен на диске поискать при любом абсолютно раскладе. И вот каждый вызов FS_Search и даёт тот самый ощутимый лаг. Закэшировал сами списки поиска.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 04-04-2020 в 10:34:

Ku2zoff я наврядли буду заниматься чем-то, что продвигает идею битмапных шрифтов.

__________________
Xash3D FWGS форк

Отправлено Ku2zoff 04-04-2020 в 10:59:

Цитата:

Дядя Миша писал:
на кой тебе меню в ксаш-моде? Ты же под халфу делаешь.

В некоторые моды я играю под ксашем. Тормозов меньше. Именно под ксашем я юзер, которых большинство.

Отправлено Дядя Миша 05-04-2020 в 15:50:

Сделал раскошные слайдеры, прямо как покража на автомате.
Ничуть не хужы виндовых, весь функционал присутствует.
Собсно эти вот скроллисты и его слайдеры - это самый сложный элемент меню, с ним было больше всего возни. Из элментов у меня еще остались чекбоксы, спин-контролы, строка для редактирования и обычные слайдеры-ползунки. Ну это думаю быстро, оно элементарное, из единственного элемента состоит. А скролллист, тут целая куча элементов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-04-2020 в 19:58:

Законченный вид сейв-меню

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-04-2020 в 20:00:

Будущее Audio-меню. Сделал чек-боксы. С новыми виджетами создание меню стало чертовски быстрым. Для сишного меню, даже если там половина - копипаста, приходилось часа два сидеть и всё проверять. А если там еще и диалог был нужен, так вообще. А теперь это несколько минут.
Основное время отнимает создание новых контролсов. Теперь вот слайдеры надо делать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 06-04-2020 в 00:22:

Дядя Миша а вот эти кнопочки Закрыть/Свернуть так и будут висеть данью традицыи? Помню когда меню ковырял их убрал в первую очередь

__________________
-Brain is dead-

Отправлено Дядя Миша 06-04-2020 в 07:21:

На текстуре под них даже место нарисовано. Пусть будут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 06-04-2020 в 08:27:

Цитата:

KiQ писал:
эти кнопочки Закрыть/Свернуть так и будут висеть данью традицыи

Надо добавить ещё кнопочку полный экран/окно между ними. И хранить два отдельных разрешения в конфиге - для фуллскрина и для окна. Было бы удобно переключаться из режима в режим, когда что-то тестируешь. Но это моё ИМХО, случайно пришло в голову.

Отправлено Дядя Миша 06-04-2020 в 10:51:

Цитата:

Ku2zoff писал:
Надо добавить ещё кнопочку полный экран/окно между ними

Alt + Enter из любого состояния.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 08-04-2020 в 14:12:

Вот кстати говоря, про концепцию. В основе старого ксаша лежала концепция "работоспособность любой ценой". Т.е. от движка можно было отрывать части, не давать ему ресурсов и он всё равно пытался остаться в рабочем режиме, ругаясь в консоль. Практика показала, что этот подход не слишком удачный. Ну потому что юзер вообще абсолютно не читает, что в консоли написано, ему плевать. Его пока битой по морде не огреешь - он ничерта не заметит. Так что я отошёл от этой концепции. Если чего-то нет - проще остановиться с ошибкой. Ну не везде конечно, но и суррогатами пытаться подменить тоже смысла нет. То есть скажем, если нету текстуры травы - с ошибкой останавливаться глупо, юзер и так увидит что травы нету.
А если не хватает чего-то серъезного, то всё - стоп машина.
Новая концепция - оправдывать интуитивные ожидания юзера. Документацию обычно никто не читает, исследование происходит путём комбинирования. Значит надо по возможности стремиться свести кол-во мёртвых кейсов к нулю. Это тоже непростая задачка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Chyvachok 08-04-2020 в 17:21:

Цитата:

Дядя Миша писал:
То есть скажем, если нету текстуры травы - с ошибкой останавливаться глупо, юзер и так увидит что травы нету.

Вспоминается двиг сталкера который вылетает от любого чиха, скомпилировал модель но забыл с СДК текстуру перекинуть от нее - вылет вместо эмо текстуры, в звуках и текстурах крашить согласен глупо, движок крашающийся от каждого чиха утомляет.

В сталкаче мне подход с этим отдельным и громоздким СДК для всего тоже не нравиться, тоже пример как не надо делать, и с которым после установки ещё ковыряться надо, и если планируешь заниматься чисто моделями то этот левел и прочие редактора
составе СДК нафиг не нужны, но их все равно прийдется ставить и тот факт что в отличии от Хамера СЛК не юзает ресурсы из игры тоже неудобно, архивы игры надо в него распаковать из-за чего оно места много зря занимает.

Отправлено Дядя Миша 08-04-2020 в 20:02:

Не-не, движок не будет навязывать юзеру стиль работы. Кто хочет - с краешку ковыряет, кто хочет - полноценно работает.

Добавлено 08-04-2020 в 23:02:

Я вот давно заметил, приложение из себя может представлять полную ерунду, но если оно красиво оформлено - к нему на порядок повышается доверие. По этой же причине никто не воспринимает консольные тулзы всеръез. Выверт сознания.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Government-Man 08-04-2020 в 21:53:

Цитата:

Дядя Миша писал:
Я вот давно заметил, приложение из себя может представлять полную ерунду, но если оно красиво оформлено - к нему на порядок повышается доверие. По этой же причине никто не воспринимает консольные тулзы всеръез. Выверт сознания.

Странно, у меня наоборот. Софт с нестандартным интерфейсом у меня вызывает ассоциации либо с кейгенами либо с шароварным софтом середины 00-х просившим заплатить ему $99 за простейший функционал.

Ну то есть например в Юнити, Унреале и 3Д-максе тоже своя система интерфейса, но там понятно - когда софт весит несколько гигов, можно и свою систему гуя к нему написать. К тому же интерфейс там нормальный - без излишеств. А вот когда в проге для конвертирования видеофайлов вылезают фишечки и рюшечки, то сразу становится понятно, что авторы потратили на них больше времени, чем на полезный функционал.

Наибольший уровень доверия у меня вызывают именно консольные проги - там сразу понятно, что автора ничего кроме функционала не заботило.

Отправлено FiEctro 09-04-2020 в 08:14:

Щас бы игровые 3д движки делать консольными.

Отправлено thambs 09-04-2020 в 08:24:

Цитата:

Дядя Миша писал:
если оно красиво оформлено - к нему на порядок повышается доверие

Цитата:

По этой же причине никто не воспринимает консольные тулзы всеръез. Выверт сознания.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 09-04-2020 в 08:31:

thambs у тебя странные представления о красоте )

Добавлено 09-04-2020 в 11:28:

Цитата:

Government-Man писал:
Софт с нестандартным интерфейсом у меня вызывает ассоциации либо с кейгенами либо с шароварным софтом середины 00-х

Но я не говорил про нестандартный интерфейс. К примеру я считаю что мой модельвьювер красиво оформлен.

Добавлено 09-04-2020 в 11:31:

А, так, собсно про скриншоты. Теперь в меню Custom Game у модов появилась своя превьюшка, как у сейвов. Ограничения прежние - картинку превью нельзя класть в пак. Ну, собсно, как и gameinfo.txt

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 09-04-2020 в 16:16:

Цитата:

Дядя Миша писал:
По этой же причине никто не воспринимает консольные тулзы всеръез

консольные тулзы в большинстве кейсов даже намного удобнее, в плане конвертации или другой пакетной обработки, главное, чтобы были адекватные параметры строки, ну или напримерЮ они жевали бы скрипт через ~~рок'н'ролл~~драг'н'дроп

__________________
-Brain is dead-

Отправлено Crystallize 09-04-2020 в 16:36:

У q3map2 или у демомпилятора какого-то была классная фича, когда обработку карты можно запустить через контекстное меню Винды, выбрав "Отправить..." и висящую там ссылку на компилятор. Больше я такого нигде не видел.

Отправлено nemyax 09-04-2020 в 17:08:

Crystallize
В Send To можно впердолить любую программу, принимающую путь файла как безымянный аргумент.

Отправлено Дядя Миша 09-04-2020 в 17:15:

Ну вообщем-то да. SendTo - это вообще такая папка в моих документах.
берёшь и добавляешь туда что надо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 10-04-2020 в 01:26:

nemyax Дядя Миша впендюрить можно, но я думаю дело всё-таки в готовности самой программы принять ссылку на карту переданную таким образом? Это как с ксашем, он не запускает карты через виндовое "открыть с помощью...".

Отправлено SNMetamorph 10-04-2020 в 07:20:

Цитата:

Crystallize писал:
впендюрить можно, но я думаю дело всё-таки в готовности самой программы принять ссылку на карту переданную таким образом? Это как с ксашем, он не запускает карты через виндовое "открыть с помощью...".

А такое вручную можно приколхозить через реестр. Там можно и свои аргументы пропихивать, насколько я помню, насчет SendTo не знаю, но в контекстное меню точно можно.
К примеру вот как у меня прописался в контекстном меню VLC плеер.

C++ Source Code:

"C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" --started-from-file --playlist-enqueue "%1"

А ведь можно и вручную сделать что нибудь наподобии:

C++ Source Code:

"C:\Games\Xash3D\xash.exe" +map "%1"

Хотя бредово конечно. Ксаш наврятли поддерживает абсолютные пути.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 10-04-2020 в 12:54:

Тест возможностей новых виджетов

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 11-04-2020 в 20:30:

Дядя Миша увидел минимальные системные требования халфы, вспомнил, прослезился

__________________
-Brain is dead-

Отправлено Дядя Миша 11-04-2020 в 21:09:

У меня на работе воляется ретро-системник, PIII-733. Так вот посл. версия ксаша на ём бегала шустрее халфы,но не сказать, чтобы прям фонтан.
Страшто представить каково было играть на PI-133, учитывая что на ём даже квейк логал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Flash 12-04-2020 в 10:51:

Дык, поставь старую версию хл. Последняя версия хочет 1,6 минимум, а вот релизная версия и на первом пне могла пойти.

__________________
Tiger! Tiger! burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?

Отправлено Crystallize 12-04-2020 в 11:03:

Цитата:

SNMetamorph писал:
А ведь можно и вручную сделать что нибудь наподобии:
C++ Source Code:

"C:\Games\Xash3D\xash.exe" +map "%1"

Хотя бредово конечно. Ксаш наврятли поддерживает абсолютные пути.

А папку мода как указывать?

Отправлено Дядя Миша 12-04-2020 в 11:57:

Папка мода уже закодирована в пути к карте. Кстати NT умеет так загружаться.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 13-04-2020 в 10:02:

Про интерфейсы взаимодействия немного расскажу. В халфе это была основная головная боль, потому что между пользовательской дллкой и движком формировался-набирался некий уникальный интерфейс, и вот что в нём было - то и доступно пользователю. А если тот, кто формировал этот интерфейс о чём-то забывал, то всё, жопа. Или бывало так, что в интерфейс всё-таки добавлялись недостающие функции приходилось мучительно проверять их наличие по версиям, размеру апи и прочей глупости. Это дико неудобно, не говоря уже о том, что для каждой новой библиотеки надо было набивать этот интерфейс заново. Я отказался от этой порочной практики и ввёл таблицу интерфейсов. Таблицы поименованные, в имени дополнительно содержится и номер версии интерфейса. Таким образом для каждой новой пользовательской библиотеки одновременно доступен весь набор функций, достаточно просто её позвать. В обратную сторону это тоже работает, но как правило от пользовательской библиотеки достаточно одной-единственной таблицы экспорта. Но можно сделать и несколько.
То есть, все движковые функции, доступные на клиенте, будут доступны и на сервере и в меню тоже. Ну а если понадобится расширить какой-то интерфейс без потери бинарной совместимости, то от базового достаточно объявить наследный класс, добавить в него недостающие функции и дать ему новое имя в табличке. И всё, совместимость не теряется ни при каких обстоятельствах. Ну а если всё же случится беда, будет виндовая ошибка Pure Virtual Function Call или что-то вроде этого, вместо загадочного вылета по 0x000005, который мог означать вообще всё что угодно.

Добавлено 13-04-2020 в 13:02:

А, вот еще какой любопытный момент. Вот это физическое разделение таблиц экспорта в принципе позволяет сливать несколько пользовательских библиотек в одну, сохраняя разделение кода. Ну скажем клиент и сервер.
Оба в одной дллке, память не пересекается, но иногда, если очень-очень надо, они могут напрямую друг-другу что-то модифицировать, например в сингл-плеере. В халфе, где было именно 2 изолированные дллки такое не прокатит, народ порою шёл на грязные хаки - грузил из hl.dll client.dll, искал там торчащий наружу экспорт и по нему брал какую-то информацию.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Government-Man 13-04-2020 в 19:12:

Дядя Миша
А в сорсе видел как сделано? Там каждой подсистеме при инициализации передается функция, возвращающая интерфейсы по имени. Таким образом подсистему вообще не волнует, где и как интерфейс реализован - она лишь проверяет его наличие. И еще каждая дллка экспортит такую функцию - она возвращает интерфейсы реализованные в этой дллке.

Забавно, у меня тут недавно возникла аналогичная проблема. Вообще, я стараюсь избегать использования длл - модульность на бинарном уровне как правило бывает не нужна, но тут мне понадобилась отдельная длл.

Поскольку экзешник и длл собираются отдельно, нужно было обеспечить какую-то систему версионирования. Требований к системе у меня было только два:

1. Система должна понимать, что существуют обратно совместимые интерфейсы - если в интерфейс добавилась новая функция, то старый клиент все еще может использовать новый интерфейс также как он использовал старый.
2. Система должна быть удобной для использования во время активной разработки, когда в интерфейс постоянно добавляются новые функции, а старые иногда меняются или удаляются.

Вариантов у меня было два: абстрактные классы (они же "интерфейсы") и структуры с указателями на функции - как в хл.

Соответствие абстрактных классов п.1 для меня так и осталось загадкой. В теории они ему не соответствуют - конпилятор имеет право расположить указатели в vtable так как ему удобно. А вот как обстоит дело на практике я так и не понял. Вроде как MSVC распологает их в порядке объявления и вроде как я даже где-то когда-то видел код который этот факт использовал. Но тут встает другая проблема - клиент как-то должен узнать, что поддерживаются обе версии интерфейса. Сорс (см. пред. ссылку) для этого предлагает экспозить интерфейс два раза. Для сорса это не проблема - движок уже достаточно взрослый и интерфейсы в нем меняются нечасто. Но в развивающемся коде это приведет к тому, что этих версий придется поддерживать целый список, а это противоречит п.2.

В итоге я остановился на структурах с указателями. Порядок работы следующий:

1. Новые функции добавляются в конец структуры - больше ничего делать не нужно.
2. При поломке совместимости версия увеличивается на 1.

Запрашивая интерфейс, клиент передает номер версии и размер своей структуры. Если номер версии отличается, значит интерфейс не совместим - возвращаем false. Далее, если размер интерфейса на клиенте больше, значит у клиента более новая версия - возвращаем false. Если все в порядке - копируем столько байт структуры сколько запросил клиент (у него может быть более старая версия).

Еще в моей реализации клиент вызывает все интерфейсные функции через врапперы, имя которых соответствует именам функций, реализованных в длл. Это позволило реализовать статическую сборку, при которой вместо длл используется либ и никаких интерфейсов вообще не используется - все вызовы осуществляются напрямую.

Статическую сборку я использую для финального билда.

Отправлено Дядя Миша 13-04-2020 в 20:39:

Цитата:

Government-Man писал:
А в сорсе видел как сделано?

Ну у меня в чём-то похожая система, но проще, не такая замороченная.

Цитата:

Government-Man писал:
когда в интерфейс постоянно добавляются новые функции, а старые иногда меняются или удаляются.

пока над исходным кодом работает один человек на совместимость можно плевать. Главное - устаканить интерфейсы к релизу.

Цитата:

Government-Man писал:
Но тут встает другая проблема - клиент как-то должен узнать, что поддерживаются обе версии интерфейса

Ну это легко. Зовём обновлённый интерфейс, получаем хрен, зовём старый интерфейс.

Цитата:

Government-Man писал:
Запрашивая интерфейс, клиент передает номер версии и размер своей структуры. Если номер версии отличается, значит интерфейс не совместим - возвращаем false. Далее, если размер интерфейса на клиенте больше, значит у клиента более новая версия - возвращаем false. Если все в порядке - копируем столько байт структуры сколько запросил клиент (у него может быть более старая версия).

Всё верно, в NT 2015-го года именно такая схема и была реализована.

Вообще дллка нужна для того чтобы отделить неизменный код от изменямого. Скажем движок не меняется, а разные там энтити - вполне.

Цитата:

Government-Man писал:
Статическую сборку я использую для финального билда.

што ты там такое делаешь? Юнити?

Добавлено 13-04-2020 в 23:39:

И кстати к вопросу о неизменности - в идеале ядро движка не должно содержать ни одного константного пути. На практике просто надо свести их к минимуму.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Government-Man 13-04-2020 в 22:07:

Цитата:

Дядя Миша писал:
што ты там такое делаешь? Юнити?

Проекты на уече =)

Цитата:

Дядя Миша писал:
Вообще дллка нужна для того чтобы отделить неизменный код от изменямого.

Я преследовал две цели.

Во-первых, в какой-то момент интерфейс действительно должен устаканиться и тогда собирать уеч нужно будет горазо реже, а сравнительно небольшую игровую длл - часто. Но на деле эта проблема не то чтобы стоит остро - если не чистить промежуточные файлы сборки уеча, то по сути он тоже будет перекомпилировать только одну длл.

Основная задача в моем случае - отделить свой код от чужого. По задумке авторов уеча игры на нем делаются путем расширения классов движка. При этом код твоей игры какбы становится модулем движка и все это потом собирается кастомной билд-системой. Собрать свой код отдельно от движка ты уже не сможешь. В принципе это правильно - это удобнее и гибче, чем апи из сотни функций, но код игры при этом становится прочно завязан на архитектуру движка. Я решил избавиться от архитектурных ограничений и перенести большую часто своего кода в длл, отгородившись от движка при помощи апи.

Цитата:

Дядя Миша писал:
Ну это легко. Зовём обновлённый интерфейс, получаем хрен, зовём старый интерфейс.

Но длл тогда получается должна отзываться на каждую версию, которую она поддерживает? Если интерфейс меняется нечасто то это не проблема, а вот если часто - уже проблема, потому что версий накопиться целая телега.

Отправлено Дядя Миша 14-04-2020 в 07:44:

Цитата:

Government-Man писал:
По задумке авторов уеча игры на нем делаются путем расширения классов движка.

Ядро - суть абстракция, оно не знает ни про какие энтити и прочее. В движке у нас файловая, консоль, рендерер, менеджер моделей, менеджер сети, звуковая подсистема. В игровой части физика, AI, механизм выделения и освобождения энтить, таблицы дельта-кодирования по сети, сейврестор. Всё это завязано на конкретную игру и может кардинально изменяться. А из движка торчат только те функции, которые в принципе поменяться не могут - отправка сообщений в консоль, чтение-запись файлов, отправка приём сетевых сообщений и так далее.

Цитата:

Government-Man писал:
Но длл тогда получается должна отзываться на каждую версию, которую она поддерживает?

так я же говорю, новое API получается путём наследования старого + еще несколько функций.

Добавлено 14-04-2020 в 10:44:

Вот к примеру как реализован механизм смены\загрузки уровней в ядре?
Есть три функции:

C++ Source Code:

virtual void LoadGame( char const *pSaveFileName ) = 0;

virtual void LoadLevel( char const *pMapName, bool background ) = 0;

virtual void ChangeLevel( char const *pNewLevel, char const *pLandmarkName, bool background ) = 0;

Пользовательская часть вызывает их из любого места, движок сохраняет две или три переменных - имякарты\сейва, имя ландмарка, флаг бэкграунда, далее, в начале кадра, вызываются соответственно четыре экспорта из самой дллки.

C++ Source Code:

1	virtual bool SpawnServer( const char *mapname ) = 0;

2	virtual void ExecuteLoadLevel( const char *mapname ) = 0;

3	virtual void ExecuteLoadGame( const char *mapname ) = 0;

4	virtual void ExecuteChangeLevel( bool loadfromsavedgame, const char mapname, const char startspot ) = 0;

SpawnServer - это загрузка новой карты, в движке никакие пути не проверяются, что ты там собрался грузить движок не волнует абсолютно, хоть шрифт вместо уровня загрузи, если ты 2д игру делаешь с тайтлами.
Движок в ворлдмодель не лезет и ничего про нее не знает. Единственно что - он пытается у этой модели найти PVS и что-нибудь по нему отсечь, но если не находит, тоже не расстраивается.
Потом, соответственно, если SpawnServer вернул true вызывается одна из трёх функций ниже. Опять таки - движок в эти переменные не смотрит, кроме бэкграунда конечно. То есть вполне возможно реализовать такой абстрактный механизм, когда игра полностью контролируется из пользовательской части.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Flash 14-04-2020 в 10:22:

Может и не туда пишу, но поиск по форуму не пашет, поэтому спрошу здесь.
Кто редактировал XashMod_v062_JH1.fgd?
Подключил этот фгд, пропало несколько фгд, оказалось зачем-то снесли переменную targetx, а сам этот таргет так и остался в энтитях, плюс по-моему зачем-то триггер автосейва был продублирован (или это в другой версии фгд ксаша было...).

__________________
Tiger! Tiger! burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?

Отправлено Дядя Миша 14-04-2020 в 13:16:

Flash создай тему в ветке ксаш-мода по обсуждению FGD. Потому что постоянно по нему вопросы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 15-04-2020 в 08:44:

Так товарищи. По скриншотам вот какие у меня соображения назрели. На данный момент, как вы знаете есть два основных типа скриншотов.
команды scrshot и snapshot. Первая сохраняет скрины в папку мода\scrshots
Вторая - в корень игры. Я поймал себя на мысли, что первой командой за много лет не пользовался вообще никогда, она просто не нужна.
А у второй есть существенный недостаток - поскольку она работает через стандартную систему экзекции буффера, невозможно сделать скриншот в меню, а в консоли приходится вручную вбивать команду. Всё это дико неудобно. Поэтому я решил сделать так: повесить действие команды snapshot на кнопку Print Screen. А для эмуляции привычного функционала - писать его в буффер при зажатом альте. Думаю это будет наилучшим решением.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 15-04-2020 в 10:40:

Дядя Миша
Зопили скриншоты в jpg/png.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 15-04-2020 в 13:59:

Лаг будет на таком скриншоте. Да и не хочется тащить джипегу только ради сейва скриншотов. Ну посмотрим, может STB возьму.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 15-04-2020 в 14:13:

Дядя Миша
>Лаг будет на таком скриншоте.
Перекодировку/запись в отдельный тред?

>STB
Ух какая интересная штука. Спасибо за наводку.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 15-04-2020 в 14:38:

Цитата:

thambs писал:
Ух какая интересная штука.

Тю, я думал все давно уже знают.

В тред призывается Психопат, вот какая интересная мысль мне пришла в голову. У Кармака в третьем дууме есть волшебные функции BitsToFloat и FloatToBits. Они позволяют изготовить переменную с плавающей точкой для любого кол-ва бит. Ну ладно, ладно, не для любого. Минимум 4 бита надо.

Преимущества такого подхода очевидны - плавающая арифметика всегда имеет большую точность, нежели фиксированная точка. У него там эта штука использовалась для отправки флоатов по сети, практически без потерь. Но вот что я думаю. BestFitNormals при помощи таблички, по сути занимается подбором оптимального множителя для FixedPoint. Т.е. множителя, на котором потеря дробной части будет минимальна для выбранного значения. Преимущество подхода очевидно - для декодирования достаточно вызвать normalize. Минус в том, что это работает только для вектора и то что надо таскать с собой эту табличку. А что если эти самые флоаты сохранить в плавающую точку величиной с байт?
Взять скажем 2 бита для мантиссы и 5 бит для экспоненты (один бит на знак уйдет). И посмотреть насколько будет гулять точность, в сравнении с тем же BFN.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-04-2020 в 15:10:

Цитата:

Дядя Миша писал:
плавающая арифметика всегда имеет большую точность, нежели фиксированная точка.

Это не правда.

Какие ты видишь сценарии использования самодельных флоатов? Мне не приходит в голову ни одного варианта применения 2битной мантиссы.

Отправлено Дядя Миша 15-04-2020 в 15:59:

Цитата:

ncuxonaT писал:
Это не правда.

здрасти-приехали. На кой же тогда чёрт изобретали плавающую точку, если фиксированная лучше?

Цитата:

ncuxonaT писал:
Какие ты видишь сценарии использования самодельных флоатов?

ну вот нормали сохранить. Те же три байта, но точность должна быть выше, чем с BFN. Правда и распаковка - сложнее.

Добавлено 15-04-2020 в 18:59:

Собсно наилучший пример того, насколько губительно использование фиксированной точки отражается на точности мы все с вами долгие годы наблюдаем на халфовских модельках, у которых постоянно едут текстурные координаты. Я сперва рассудил, что раз координаты там всё равно никогда не выходят за пределы 0-1, то надо просто выбрать максимальный множитель для увеличения точности. Ну и взял 32768. Так вот - это нихрена не помогло по сути. Как оно съезжало, так и продолжило съезжать. Тогда я подумал, есть же халф-флоаты, попробую их. И да - с ними исчезли практически все проблемы. Ну кроме конечно тех случаев, когда моделлёр нарочно двигает текстуру неправильно, пытаясь компенсировать потерю точности, типо после округления, оно съедет обратно.
Фиксированная арифметика это полное днище, её вообще нельзя никак использовать. Ну разве что для квантизации пространства, да и то...

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-04-2020 в 16:08:

Цитата:

Дядя Миша писал:
здрасти-приехали. На кой же тогда чёрт изобретали плавающую точку, если фиксированная лучше?

"Преимущество использования представления чисел в формате с плавающей запятой над представлением в формате с фиксированной запятой (и целыми числами) состоит в том, что можно использовать существенно больший диапазон значений при неизменной относительной точности."

Цитата:

Дядя Миша писал:
ну вот нормали сохранить. Те же три байта, но точность должна быть выше, чем с BFN. Правда и распаковка - сложнее.

Как может быть выше точность у 2 бит мантиссы, если у BFN точность на уровне RBG16F (а там 10 бит мантиссы)

Добавлено 15-04-2020 в 19:08:

Цитата:

Дядя Миша писал:
Ну и взял 32768. Так вот - это нихрена не помогло по сути. Как оно съезжало, так и продолжило съезжать. Тогда я подумал, есть же халф-флоаты, попробую их. И да - с ними исчезли практически все проблемы.

Ты где-то напортачил, не должно было быть такого.

Отправлено thambs 15-04-2020 в 16:08:

Цитата:

Дядя Миша писал:
Фиксированная арифметика это полное днище, её вообще нельзя никак использовать. Ну разве что для квантизации пространства, да и то...

Её используют там где требуется фиксированная точность -- в типографии и бухгалтерии.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 15-04-2020 в 17:34:

Цитата:

ncuxonaT писал:
Ты где-то напортачил, не должно было быть такого.

Да с кем я спорю? Ну возьми в цикле прогони фикседпоинт и плавающую точку с разными значениями и посравнивай-потести. А потом умничай про "напортачил".

Цитата:

ncuxonaT писал:
если у BFN точность на уровне RBG16F

С хрена ли? Суть BFN в том, чтобы более эффективно использовать 24 бита для векторных значений. Выше этих 24 бит на три компоненты она не станет никоим образом.

Цитата:

thambs писал:
Её используют там где требуется фиксированная точность -- в типографии и бухгалтерии.

Не знаю насчёт типографии, но в бухгалтерии даблы поидее.

Добавлено 15-04-2020 в 20:34:

Нет, если нужна прям фиксированная-фиксированная точность, то переменную явным образом разделяют на две части.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-04-2020 в 17:52:

Цитата:

Дядя Миша писал:
Да с кем я спорю? Ну возьми в цикле прогони фикседпоинт и плавающую точку с разными значениями и посравнивай-потести. А потом умничай про "напортачил".

Можно попробовать. Но лучше покажи код со своей реализацией целочисленных текстурных координат.

Цитата:

Дядя Миша писал:
С хрена ли? Суть BFN в том, чтобы более эффективно использовать 24 бита для векторных значений. Выше этих 24 бит на три компоненты она не станет никоим образом.

Ну да, тут я наверное погорячился.

Отправлено Дядя Миша 15-04-2020 в 18:10:

Цитата:

ncuxonaT писал:
Но лучше покажи код со своей реализацией целочисленных текстурных координат.

Ты прикалываешься чтоли?

C++ Source Code:

int st = (s * 32768);

float s = st * (1.0f/32768.0f);

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-04-2020 в 18:50:

Дядя Миша это ты из головы написал сейчас. Вот как оно написано, при текстуре 1024х точность будет 1/32 пикселя, тогда как у халффлота точность на большей части была бы 1 пиксель.
Можешь показать весь кусок кода?

Отправлено Дядя Миша 15-04-2020 в 18:55:

Цитата:

ncuxonaT писал:
Вот как оно написано, при текстуре 1024х точность будет 1/32 пикселя

Воу-воу-воу, что ты несёшь? Причём тут размер текстуры??? Я же выше написал, что привёл фиксированную точку к диапазону 0-1 и взял множитель как можно больше, для увеличения точности. Можно сказать - максимально возможный для слова. А привязываться к размеру текстуры - это еще хуже. Не зря там в компиляторе написано FIXME.

Добавлено 15-04-2020 в 21:55:

PS. Кармак, к слову хранил st для моделей во флоатах, это чисто вальвовский прикол.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 15-04-2020 в 19:12:

Дядя Миша давай-ка повежливее, что за фамильярности. К размеру текстуры я привязываюсь только чтобы как-то измерить ошибку точности. Текстурные координаты в мдл хранятся в знаковых или беззнаковых шортах? Почему ты умножаешь на 32768, если диапазон знакового шорт от -32768 до 32767? В любом случае это вряд ли сильно влияет на сдвиг.

А Кармак в ку2 хранил st вообще в двух вариантах.

Отправлено Дядя Миша 15-04-2020 в 19:29:

Запилил поддержку рескейла шрифтов. Еще вчера я надеялся, что вот эти вот настройки можно было как-то задать при создании шрифта, но раз нет, так нет. Слева картинки, созданные ФиЭктро, справа - шрифт, с подогнанным скейлом.

Цитата:

ncuxonaT писал:
Текстурные координаты в мдл хранятся в знаковых или беззнаковых шортах?

Координаты идут в однородном потоке gl-комманд. Поток весь состоит из знаковых шортов.

Цитата:

ncuxonaT писал:
Почему ты умножаешь на 32768

А на сколько надо? В оригинале шло умножение на размер текстуры. Т.е. точность плавала вместе с этим размером. Очевидно, чем больше число, тем выше точность фиксированной точки. Я взял максимально возможное, чтобы не париться со знаком. Диапазон, еще раз повторюсь, от НУЛЯ ДО ЕДЕНИЦЫ, может просто когда я цифрами пишу 0-1, ты этого не замечаешь.

Добавлено 15-04-2020 в 22:26:

ЗЫ. по шрифтам отличия в качестве картинок, типа лёгкого блура, ну тут надо понимать, что оригинал генерился в разрешение 640х480 и уже предумножен на 1.6. Плюс DXT добавил артефактов в цвет, хотя это и странно конечно. Ну может еще джипег от себя добавил.

Добавлено 15-04-2020 в 22:29:

Но вот отличия в цвете кнопок - это стопудова косяк DDS, потому что я брал пипеткой оригинальный цвет из исходника.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 15-04-2020 в 19:37:

Дядя Миша
Там не блюр, а свечение вроде как.

Отправлено KiQ 15-04-2020 в 19:44:

Цитата:

Дядя Миша писал:
Ну посмотрим, может STB возьму.

то есть для шрифтов брать не хотел, а для скриншотов - можно?

__________________
-Brain is dead-

Отправлено ncuxonaT 15-04-2020 в 19:49:

Цитата:

Дядя Миша писал:
А на сколько надо?

На 32767? Но это не особо существенно.

Цитата:

Дядя Миша писал:
Диапазон, еще раз повторюсь, от НУЛЯ ДО ЕДЕНИЦЫ

Ты понимаешь, что на этом диапазоне у шорта будет постоянная точность, а у халффлоата плавающая? И чем больше разрешение текстуры, тем сильнее это будет заметно?
Вот я прогнал для теста флоаты от 0.9000 до 0.9020 с шагом в 0.0001, можешь сам посмотреть, где больше ошибка

code:
float		half		short		half_err	short_err
0,900000	0,899902	0,899991	0,000098	0,000009
0,900100	0,899902	0,900113	0,000198	0,000013
0,900200	0,900391	0,900204	0,000191	0,000004
0,900300	0,900391	0,900296	0,000091	0,000004
0,900400	0,900391	0,900388	0,000009	0,000012
0,900500	0,900391	0,900510	0,000109	0,000010
0,900600	0,900391	0,900601	0,000209	0,000001
0,900700	0,900879	0,900693	0,000179	0,000007
0,900800	0,900879	0,900815	0,000079	0,000015
0,900900	0,900879	0,900906	0,000021	0,000006
0,901000	0,900879	0,900998	0,000121	0,000002
0,901100	0,900879	0,901090	0,000221	0,000010
0,901200	0,901367	0,901212	0,000167	0,000012
0,901300	0,901367	0,901303	0,000067	0,000003
0,901400	0,901367	0,901395	0,000033	0,000005
0,901500	0,901367	0,901486	0,000133	0,000014
0,901600	0,901367	0,901608	0,000233	0,000008
0,901700	0,901855	0,901700	0,000155	0,000000
0,901800	0,901855	0,901791	0,000055	0,000009
0,901900	0,901855	0,901914	0,000045	0,000014
0,902000	0,901855	0,902005	0,000145	0,000005

Добавлено 15-04-2020 в 22:49:

Шрифты говно, конечно. В том плане, что буквы плавают вверх-вниз

Отправлено FiEctro 15-04-2020 в 19:53:

ncuxonaT
Ты чего злой такой?

Отправлено ncuxonaT 15-04-2020 в 20:04:

FiEctro почему злой? http://lurkmore.to/%D0%A8%D1%80%D0%...%B2%D0%BD%D0%BE

Отправлено Дядя Миша 15-04-2020 в 20:49:

Цитата:

KiQ писал:
то есть для шрифтов брать не хотел, а для скриншотов - можно?

А што, рендеринг шрифтов и сохранение в джипег это один и тот же код?

Я не против STB, я против любой отсебятины в плане рендеринга шрифтов. Да и альбатросс сказал, что там нет антиальясинга, а к примеру этот же бакслэш без него юзать вообще невозможно.

Цитата:

ncuxonaT писал:
можешь сам посмотреть, где больше ошибка

у фиксированной точки, естественно. Потому что на ней текстуры - съезжали. А на халф-флоате нет.

Цитата:

ncuxonaT писал:
буквы плавают вверх-вниз

да, есть такое.

Добавлено 15-04-2020 в 23:49:

Есть какая-то чёртовая моделька, банка штоли. Так вот при фиксированной точке на ней текстура съезжала гарантированно. А на халфе - нет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 15-04-2020 в 20:52:

Дядя Миша а я говорил не про рендеринг шрифтов, а загрузку ttf динамически в движок вместо стороннего конвертертирования По сути тот же конвертер, только налиту, логично же, что если и так тянуть STB, добавить такую возможность

__________________
-Brain is dead-

Отправлено ncuxonaT 15-04-2020 в 20:55:

Дядя Миша ты шрифт в атлас отрисовываешь виндовыми методами? Там хинтинг отключается?

Цитата:

Дядя Миша писал:
Есть какая-то чёртовая моделька, банка штоли. Так вот при фиксированной точке на ней текстура съезжала гарантированно. А на халфе - нет.

Может, там координаты выходили за 0-1?

Отправлено Дядя Миша 16-04-2020 в 07:54:

Цитата:

KiQ писал:
а загрузку ttf динамически в движок вместо стороннего конвертертирования

Ты хотя бы примерно понимаешь, как устроен TTF? Это, ну вот как если бы тебе надо было сделать оверврью карты, но ты бы писал для этого её полноценный рендерер в приложении. Хотя приложению бы требовалось только картинка-овервью. Загрузить TTF несложно, но их же надо отрендерить с учётом всех настроек, субпиксельного сглаживания, причём всё это сделать программно. Я уже молчу, что результаты рендеринга, к примеру отличаются на макоси, линуксе и винде. Т.е. буквы везде будут выглядеть по разному. Зачем мне это нужно?

Цитата:

ncuxonaT писал:
ты шрифт в атлас отрисовываешь виндовыми методами?

виндовыми.

Цитата:

ncuxonaT писал:
Там хинтинг отключается?

хинтинг это что такое?

Цитата:

ncuxonaT писал:
Может, там координаты выходили за 0-1?

так они же клампятся в самом компиляторе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 16-04-2020 в 10:06:

Как это? Рисовать виндовыми средствами шрифты боясь что они иначе будут выглядеть на макоси.

Отправлено ncuxonaT 16-04-2020 в 11:58:

Цитата:

Дядя Миша писал:
так они же клампятся в самом компиляторе.

Я не вижу каких-либо причин, по которым халф на диапазоне 0-1 имел бы большую точность, чем шорт. Самое простое и очевидное объяснение - ты где-то ошибся. Но не признаешься же никогда.

Цитата:

Дядя Миша писал:

хинтинг это что такое?

Хинтинг - это когда линии букв подстраиваются под пиксельную решетку. Текст получается четче, но уродливее. На примере первых версий фритайпа:

Отправлено thambs 16-04-2020 в 12:10:

ncuxonaT
На первой ШГ, читать больно!

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено ncuxonaT 16-04-2020 в 12:19:

thambs на второй ШГ, шрифт сам на себя не похож

Отправлено thambs 16-04-2020 в 12:21:

ncuxonaT
Второй ШГ, но хотя бы читается, а на первой мыло.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено ncuxonaT 16-04-2020 в 12:33:

thambs ну так старый фритайп, в новом видать лучше

Отправлено thambs 16-04-2020 в 12:46:

ncuxonaT
Но в игре в любом случае такие мелкие шрифты делать нельзя.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 16-04-2020 в 14:08:

Цитата:

ncuxonaT писал:
Я не вижу каких-либо причин, по которым халф на диапазоне 0-1 имел бы большую точность, чем шорт.

Мне самое главное было что? Чтобы текстуры не съезжали. И вот с халф-флоатом они не съезжали. А с фиксед-поинт продолжали съезжать. Конечно меньше чем в оригинале, когда умножение шло на размер текстуры, но съезжали всё равно. А с халфом это прошло моментально. Хочешь - сиди разбирайся почему так. Я не хочу. Тебе просто лень признать, что ты сам разбираться не хочешь, зато хочешь обвинять меня в том, что я - накосячил. И это за тобой уже далеко не первый раз. Вместо того чтобы разобраться, ты сразу включаешь режим "да ты идиот, у тебя всё неправильно". Хотя уже здоровый лоб и давно должен выйти из такого состояния.

Цитата:

ncuxonaT писал:
Хинтинг - это когда линии букв подстраиваются под пиксельную решетку

Ну это какой-то параметр для CreateFontA?

Добавлено 16-04-2020 в 17:08:

И вот еще что. Если я нахожу у тебя в рассуждениях или в коде какие-то косяки, я не пытаюсь тебя подловить специально. Ну нашёл и сообщил. А ты, такое ощущение, всё время пытаешься что-то найти, уцепиться и доказать.
И меня это честно говоря уже достало.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 16-04-2020 в 15:20:

Цитата:

Дядя Миша писал:
Ну это какой-то параметр для CreateFontA?

Хрен его знает. Может PROOF_QUALITY в iQuality. А может ANTIALIASED_QUALITY.

Цитата:

Дядя Миша писал:
Хочешь - сиди разбирайся почему так. Я не хочу. Тебе просто лень признать, что ты сам разбираться не хочешь, зато хочешь обвинять меня в том, что я - накосячил.

Как я могу разбираться в твоём коде, который ты не выложил?
В чём еще я могу разобраться? В теории? Я разобрался в теории, теория говорит, что в диапазоне 0-1 точность шорта выше, чем у халфа, потому что 15 бит против 10. В практике? Я разобрался в практике, я выше привел сравнение ошибки точности, у шорта она ниже в несколько раз. Я запекал АО (которое в диапазоне 0-1) в RGBA16 и в RGBA16F, и у первого точность была выше, а у второго начинали лезть ступеньки.
А твой опыт это "Вот я один раз попробовал, у меня не получилось, а по-другому получилось, значит я прав, а вы всё врети, ошибиться я не мог, подловить меня пытаетесь специально, разбираться ни в чём не буду, разбирайтесь сами". Так себя ведёт здоровый лоб?

Добавлено 16-04-2020 в 18:20:

Если тебе было интересно мое мнение про 8битные флоаты для нормалей - это не сработает, не стоит время тратить

Отправлено Дядя Миша 16-04-2020 в 15:52:

Слева картинка, справа реалтайм. Главное подобрать цвет и степень размытия. Теперь осталось шапки перевести на шрифты.

Добавлено 16-04-2020 в 18:52:

Цитата:

ncuxonaT писал:
Может PROOF_QUALITY в iQuality. А может ANTIALIASED_QUALITY.

Ну это у меня в качестве опцыы.

Цитата:

ncuxonaT писал:
Вот я один раз попробовал, у меня не получилось, а по-другому получилось, значит я прав, а вы всё врети, ошибиться я не мог, подловить меня пытаетесь специально, разбираться ни в чём не буду, разбирайтесь сами".

Ты дурак или притворяешься?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 16-04-2020 в 18:04:

Кстати, нашёл тут забавную либу для ttf, пишут, что скомаиленный код умещается в 3kb https://github.com/mcufont/mcufont

__________________
-Brain is dead-

Отправлено thambs 16-04-2020 в 19:37:

KiQ
Он ж фритайп требует, или это только для тестов?

Добавлено 16-04-2020 в 22:37:

А тесты у меня заваливает. Видимо, таки в бубунте фритайп патченный на предмет более менее приемлемого рендера шрифтов.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 17-04-2020 в 08:18:

Вроде как там собственный рендерер с антиалиасом.
Но все эти маленькие штуки на коленке не обеспечивают приемлимого качества. Там в аннотации написано - для микроконтроллеров. А куда микроконтроллеры обычно выводят текст? На двухстрочный монохромный ЖК-экранчик. Там многие косяки и артефакты просто неактуальны.

Добавлено 17-04-2020 в 10:17:

Слева pointSize 46, справа 21. Оба варианта апскейлены в какой-то степени (не замерял в какой именно). С точки зрения унификации кода второй вариант предпочтительнее, т.к. он использует тот же самый шрифт, что и для подсветки кнопок, при наведении мыши. Но как видите, из-за большого скейла уже лезут артефакты с соседней буквы.

Добавлено 17-04-2020 в 10:26:

Впрочем нет, это не из-за скейла. Это из-за блура кое-где оффсеты не соблюдены были. Исправил.

Добавлено 17-04-2020 в 11:18:

Шапки

Есть отличия конечно, но на FFP идеального соответствия добиться проблематично. Да наверное и не особенно нужно. Главное что теперь можно писать любую надпись.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 18-04-2020 в 06:19:

Дядя Миша на четвертой картинке шапка выглядит весьма жутко, да и в принципе ( а на второй еще жутче). В том прямоугольнике, куда вмещается надпись нужна альфа-маска с горизонтальным (а точнее цилиндрическим) градиентом. В Фотожопе это легко делается, но и тут можно алгоритм подобрать

Добавлено 18-04-2020 в 08:22:

Через модуль номера строки пикселей вычислить прогрессию и назначить альфу. Я просто сейчас слишком бухой чтобы формулу сходу накидать)

Добавлено 18-04-2020 в 08:36:

Дядя Миша или не добавлять блюр изначально в атлас, а делать его динамически при отрисовке как постэффект

Добавлено 18-04-2020 в 09:07:

Типа того

Добавлено 18-04-2020 в 09:19:

Я к тому, что просто оффсетами это не поправишь. Я с этим столкнулся, когда в своем 2D движке делал освещение шейдерами, когда обрезка делается прямоугольником и захватывает еще соседние области. То есть тут нужна маска или в целом размывать уже после отрисовки шрифта как постэффект

__________________
-Brain is dead-

Отправлено Дядя Миша 18-04-2020 в 07:10:

Цитата:

KiQ писал:
на четвертой картинке шапка выглядит весьма жутко

Так еще бы, я её четыре раза аддитивно рисую.

Цитата:

KiQ писал:
делать его динамически при отрисовке как постэффект

нету пока что шейдеров в меню.

Цитата:

KiQ писал:
когда обрезка делается прямоугольником и захватывает еще соседние области

ну так охранный бордюр нужен в один пиксель.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 18-04-2020 в 14:41:

Было-стало:

Спин-контролы еще не написаны, поэтому на новом меню нет такого элемента.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 19-04-2020 в 09:25:

У меня всё больше крепнет ощущение, что на крестах можно писать только итеративно. Но итеративность находится в серъезном противоречии с комнадной работой. Отсюда и говнокод. Все эти книжки по эффективному программированию бесполезно читать - после каждой итерации код становится лучше и лучше, с учётом его реального использования. При условии конечно, что до оптимального состояния его будет использовать только один человек. Судя по всему к этой итеративности стремятся и движкописатели, получая негодование коммунити - в новой версии опять всё изломали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-04-2020 в 10:13:

Новый вариант нравится больше, наконец избавился от этих уродских ку3шных шрифтов, правда поля с текстом съехали...

Отправлено Дядя Миша 19-04-2020 в 12:27:

Куда съехали?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-04-2020 в 13:39:

Дядя Миша
С центра, вон текст в поле для ввода и текст в кнопке, есть рамка и текст не по центру.

Отправлено Дядя Миша 19-04-2020 в 15:08:

Так я и не хотел, чтобы он был по центру.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 21-04-2020 в 08:27:

Вот кстати говоря. Это уже считается кернингом или надо их еще ближе двигать?
Хотя это те значения, которые вернул GetCharABCwidths.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 21-04-2020 в 13:48:

Если я правильно понял, что извлекает GetCharABCwidths, то нет, это не кернинг. Для кернинга нужно брать значения кернинговых пар и двигать в соответствии с ними (необязательно ближе). А что это за шрифт?

Отправлено Дядя Миша 21-04-2020 в 15:37:

Sans Serif же.

Добавлено 21-04-2020 в 18:37:

Ну так кернинговые пары, это по идее и есть A\C. для каждой буквы. B - это ширина видимой части.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 21-04-2020 в 16:17:

Это не совсем кернинг, это обычные метрики, но их в любом случае необходимо учитывать.

Кернинговые пары, это когда задействовано пара символов. Чтобы их извлечь, нужно уже уметь парсить формат файла шрифта и вытаскиывать из него данные о кернинге и считать расстояние именно между двумя символами. В принципе, это есть уже в 100500 раз упомянутом freetype2, см. документация. В винде само собой тоже есть.

ИМХО, мы не типографисты, поэтому того что сделал Дядя Миша достаточно для GUI, тем более игрового. Тем более Дядя Миша заранее считает метрики и атласы с глифами. Да, можно и скопировать информацию о кернинге и записать его в своём формате шрифтов, но стоит ли оно того? В принципе, с учётом просто метрик символы уже должны быть пропорционально размещены относительно друг друга.

__________________
Xash3D FWGS форк

Отправлено ncuxonaT 21-04-2020 в 16:26:

Нет, A и C - это то что называется side bearings, то есть расстояния от краев (которые могут быть отрицательными)

Кернинговые пары - это пары символов, для которых заданы дополнительные смещения относительно друг друга

Добавлено 21-04-2020 в 19:26:

В microsoft sans serif (если это он) кернинговых пар нету.

Отправлено Дядя Миша 21-04-2020 в 17:01:

Цитата:

ncuxonaT писал:
пары символов, для которых заданы дополнительные смещения относительно друг друга

Я так понимаю это необязательная информация, потому что для всех букв подобный массив займет четверть мегабайта, для ANSI. Да в целом и хрен бы с ними. Тут и так с табами намаялся, а если еще и кернинг учитывать

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 21-04-2020 в 18:23:

Дядя Миша а кернинговые пары не для всех возможных пар делают, только для нужных, типа AV, AT. В каком-нибудь Ариале 3400 глифов, но только 900 кернинговых пар.

Отправлено Дядя Миша 21-04-2020 в 19:15:

Да, я понял.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 22-04-2020 в 08:26:

Цитата:

Дядя Миша писал:
Папка мода уже закодирована в пути к карте. Кстати NT умеет так загружаться.

Это фича продуктов от ДМ или всегда было? В старых модах в ридми указывается и папка игры, и первая карта.

Отправлено Дядя Миша 22-04-2020 в 11:20:

Нет, это новая фича, раньшы небыло.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 23-04-2020 в 18:41:

Ну кстати по длительному размышлению я принял решение всё же оставить лайтмапы. Но - внешние, в таких же атласах, как и шрифты. Мало ли, может быть пригодятся для чего-нибудь. К примеру тени там хранить. Ну вообщем механизм разумнее оставить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 27-04-2020 в 12:42:

И еще вот какой момент. Я планирую вынести в GameUI системную консоль, чат и механизм обработки кнопок - движку они не нужны, не тот уровень абстракции. К тому же консолька сможет использовать те же виджеты, что и меню. Есть еще планы и игровой худ вынести туда же, но посмотрим.
В самом движке, следовательно останется только логгирование в текстовый файл. Ну и системная консоль, конечно тожы никуда не денется. Думаю это будет оптимальный вариант. Народ всё мечтал замутить окошки как в сорсе, теперь предоставится такая возможность - это всё будет в пользовательской части.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-04-2020 в 16:32:

Знаете, мне в голову пришла парадоксальная мысль. В финальной итерации XashNT будет во многом похож на Unity. Не по принципу, но по духу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 29-04-2020 в 16:38:

Дядя Миша
Что же в таком разе удержит людей от перехода на Юнити?

__________________

Отправлено thambs 29-04-2020 в 16:49:

Цитата:

Дядя Миша писал:
принял решение всё же оставить лайтмапы

Очень хорошее решение, обнадёживает.

Цитата:

Не по принципу, но по духу.

Именно на юнити, не на гздуум?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Crystallize 29-04-2020 в 17:19:

XaeroX совместимостью c Windows XP конечно!
И гарантией что там не будет блевотных постфильтров.

Отправлено Дядя Миша 29-04-2020 в 17:45:

Цитата:

thambs писал:
Очень хорошее решение, обнадёживает.

Может даже без лимита на лайтстили.

Цитата:

thambs писал:
Именно на юнити, не на гздуум?

А что гздуум? Это какой-то форк дуума.

Добавлено 29-04-2020 в 20:45:

Цитата:

XaeroX писал:
Что же в таком разе удержит людей от перехода на Юнити?

Я же сказал, по духу, а не по принципу. Принцип Юнити - это дать по дефолту максимальную блевотину, которая расползётся в подавляющее большинство игр. А дух - в возможности прикрепить всё что угодно, даже не имея доступа к исходному коду движка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Cybermax 30-04-2020 в 10:40:

GZDoom форк ZDoom (discontinued) с поддержкой современного железа. Есть ещё ветка LZDoom, рассчитанная на устаревшее железо.

Отправлено Дядя Миша 30-04-2020 в 11:29:

Cybermax я в курсе что такое GZDoom, но не заметил за ним ничего особенного. А что заметил - то описал в ветке по разработке римейка дуума. В частности рейтрейсед GPU-тени на базе BSP-дерева, прям как у меня. Правда там оно почему-то очень сильно тормозит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 30-04-2020 в 20:26:

Вот этот вот маленький хинт на удивление всю душу вымотал. Ну ладно бы, они на каждом шагу попадались, но он сука единственный на всё меню, и я конечно в этом плане ничего не готовил и не предусматривал.

Добавлено 30-04-2020 в 23:26:

Кстати, решил вот почитать про Unity в википедии, а там пишут, что он дико тормозной из-за сишарпа. Но сишарп он вообще неспешный, это общеизвестно. Зато весь такой безопастный. И вот у меня вопрос, а вы любите сишарп? Пишете public static final void?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 30-04-2020 в 21:02:

Дядя Миша обычный popup же. Си шарп не люблю, как и дотнет в принципе, а яву люблю, еще для мобилок на ней писал, ну даже когда еще тока зарегался здеся

__________________
-Brain is dead-

Отправлено thambs 30-04-2020 в 21:22:

Дядя Миша
А чем ключ отличается от кнопки?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 30-04-2020 в 22:39:

thambs
Ключ на клавиатуре, кнопка на мыши.

__________________

Отправлено Government-Man 01-05-2020 в 08:08:

Цитата:

Дядя Миша писал:
пишут, что он дико тормозной из-за сишарпа

Игры на Юнити по моим наблюдениям действительно имеют свойство тормозить, но я честно говоря сомневаюсь, что это из-за шарпа. Скорее из-за кривых рук разработчиков игр и закрытого движка, который не дает его нормально дебажить и оптимизировать.

Ну то есть я сомневаюсь, что шарп тормознее того же Унреал-скрипта на котором вполне себе делались игры.

Цитата:

Дядя Миша писал:
вы любите сишарп?

Люблю, пишу на нем всякие тулзы и другие нетребовательные к производительности проги.

Цитата:

Дядя Миша писал:
Пишете public static final void?

Пишу

Отправлено Дядя Миша 01-05-2020 в 08:53:

Цитата:

thambs писал:
А чем ключ отличается от кнопки?

так было написано в вон-версии. Вальвовцам виднее чем отличается.

Цитата:

Government-Man писал:
Скорее из-за кривых рук разработчиков игр и закрытого движка

Юнити уже пять версий сделали, ну что они не могут тормоза одолеть?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 01-05-2020 в 09:58:

thambs наверное всё-таки не ключ а клавиша.

Отправлено Cybermax 01-05-2020 в 11:57:

Все очень просто: keys на computer keyboard
и mouse buttons на мышке.

Отправлено Дядя Миша 01-05-2020 в 12:24:

Вообщем на данный момент идеология следующая: ядро движка не должно содержать внутри себя никаких константных путей. Вообще. В идеале конечно. На практике что-то обязательно придётся прописать, например gameinfo.txt будет читаться из движка, но это некритично, т.к. его можно бесконечно расширять, прозрачно для самого движка, он хранит его параметры как набор кей-валуев.

Всё что потенциально пользователь захочет поменять - выносится в пользовательские библиотеки и\или скрипты. На данный момент я планирую две пользовательских библиотеки со следующим наполнением:
GameUI.dll - основное меню, внутри-игровой худ, клиентская консоль, чат, менеджер кнопок. Вообщем 2Д-стафф.

progs.dll - интеракция с объектами, эдикты-энтить, механизм приёма и передачи дельта-состояний (прозрачен для движка, он просто отправляет и принимает пакеты), формирование вида от каждой энтити (возможность задать ref_viewpass) актуально, когда мы смотрим от лица той или иной энтити\мониторов\зеркал\камер (ну ладно, зеркала в движке это делают).

Единственное что при таком подходе повисает в воздухе - это usercmd. С одной стороны его бы неплохо было иметь в progs.dll, с другой - это нарушает тиеричность, да и кнопки, я напоминаю - в GameUI.dll. Физически кнопки конечно разделены на игровые состояния и обычные, вообщем там дальше уже по факту будет видно.

По идее этих двух пользовательских библиотек будет достаточно чтобы сделать абсолютно любую игру, хоть однопользовательскую, хоть многопользовательскую, хоть 2д, хоть 3д. Вообщем всё что угодно.
Если какие-то элементы нам не нужны - например сеть, мы просто их не используем. Точно так же и с сейврестором и чейнджлевелом, он может быть абсолютно любым, он находится полностью в пользовательской части. Поверх этого можно прикрутить скрипт-машину, шарп куси, да хоть яву, кому што нравится. Соответственно то, к чему пользователь не будет иметь доступа (закрыто в ядре).
1. сеть (только на уровне доставки и отправки пакетов)
2. системные средства - окошки, системная консоль, ввод\вывод, подключение графических библиотек, прочий бакэнд
3. файловая (на уровне пользователя только основные функции для работы внутри папки игры).
4. система консольных комманд и переменных (можно создавать свои, логику работы этих скриптов менять нельзя).
5. форматы трёхмерные - жестко определены, самостоятельно новых нельзя добавить
6. форматы двухмерные - жестко определены (текстуры)
7. форматы видео, звука - аналогично.
8. звуковой движок - можно отправлять звуки и музыку на воспроизведение, фундаментально вмешаться в его работу нельзя.
9. некоторые отладочные средства, жестко зашитые в самом движке (напримеры атласы текстур, лайтмап, дебаг-экраны)
10. менеджер шрифтов.
11. рендерер, но с оговоркой, что конвейер полностью программируемый и прозрачный, с возможностью создания собственного языка описания материалов, равно как и возможностью выбора типа рендеринга на пользовательском скриптовом уровне - можно будет сочетать динамику и статику в любых комбинациях, делать отложку и форвард по желанию, добавлять любые пост-процессы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 02-05-2020 в 10:45:

Код для предиктинга не собирается в двух вариантах как GoldSrc/Source, а один в ~~progs.dat~~progs.dll? Это очень здорово. Впрочем, вспоминаю, что ты про это уже писал...

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 02-05-2020 в 12:36:

В предиктинге самое главное что? Инкапсулировать тайм-машину, чтобы можно было откатывать стейты индиффирентно.
Оно не столько сложное, сколько жручее в плане памяти, да.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 03-05-2020 в 11:53:

С меню я управился, можно и приступать к рендереру, но сперва имплементирую лайтмапы, раз обещал. Они могут пригодится для разных вариантов, например тени - лайтмапой, свет деномический или Dual Lightmapping этот про который я рассказывал в своём обзоре, как резкие зубцы теней взяли и чуть-чуть сгладили Ну и лайтмаппер визлайт-матрицу мне построит для фуллдинамики. Вообщем лишним не будет.

Но под кутришный формат считать лайтмапы уже нет смысла, под эти страницы 128х128. Лайтмапы должны быть внешними в нормальных текстурах. Следовательно пришло время разработать и новый формат BSP.
Он не будет фундаментально отличаться от кутришного, но лишь в том аспекте, что кутришный формат почти генеричный, вертексы-индексы, дерево. Надо только выкинуть это идиотское разделение на брашы-патчи-флаеры, оно вообще не нужно. Я лучше туда сохраню варианты STRIP-режима. TRILIST, TRISTRIP вот это всё. А брашы остануться для коллизии.
Как вы помните, я нагенерил колоизационных брашей и для патчей и вообще для всякого. Так что план работ следующий:

1. имплементация нового формата уровней
2. лайтмаппер (лайтбейкер?)
3. новый рендерер с поддержкой динамического освещения

Ну тут сложно сказать - новый, он же кастомный, на скриптах. Надо вынести наружу возможности манипуляции с FBO, MRT и подключением нужных шейдеров в определённых точках. Т.е. возможность скриптования конвейера. Правда этому мешает тот факт, что мне бы неплохо иметь униформные модели с унифицированными VBO-мешами. Так что вероятно будут еще разработаны форматы для моделей, травки-муравки, импосторов, спрайтов (ну это понятно на базе шрифтов).

Вообщем самая такая визуально-наглядная часть работы. Вероятно будут скриншоты.

Добавлено 03-05-2020 в 14:53:

Когда всё вышеперечисленное будет сделано, работы останется относительно немного - сеть и игровые объекты (скриптование?).
Всё остальное уже готово. Но и занять оно может порядочно времени - может до конца года, я не знаю. Очень уж велик объем работы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 03-05-2020 в 12:15:

А почему формат кутри, а скажем не думтри?

Отправлено Дядя Миша 03-05-2020 в 13:24:

В Д3 нет особых отличий от ку3. Ну разве что всё текстовое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 03-05-2020 в 13:27:

Цитата:

Дядя Миша писал:
лайтбейкер?

хочешь использовать мой или похитить название?

Отправлено Дядя Миша 03-05-2020 в 13:36:

Название давно зарезервировано - calcrad.

Вообще с лайтмапами по хорошему давно уже надо разобраться, т.к. оно в первой кваке устроено уже никто не запекает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-05-2020 в 15:44:

Почитал я тут новость про Уинджин и комментарии пользователей:
https://gamedev.ru/industry/forum/?id=251515

Всё-таки товарищи, какая же пропасть лежит между пониманием и осознанием. Для программиста понять, что какая-то ерунда, которая лично для него вообще не заслуживает даже секунды внимания, для его пользователей может явиться непреодолимым препятствием, ставящим под угрозу выход всего проекта - может не хватить даже всей жизни. На этом уже погорел Крайтек, кстати.

Я сейчас попробую сделать очень громкое и весьма пафосное заявление, которое конечно не соответствует моему положению и уровню, прямо как тогда в 2004-м, ведь мало кто верил, что Xash3D будет действительно написан. Но это всё баловство по сути. Хотя бы потому, что никому никому ничем не обязан. А NT как изначально проект с упором на коммерческий сегмент, это другой расклад абсолютно. И вот знаете, по прочтении той темы, у меня окончательно сформировалось то, что зрело подспудно все эти годы и я наконец-то смог его окончательно сформулировать. Что же самое главное для игрового движка?

1. Несмотря ни на что, любой пользователь работавший со святой троицей назовёт вам массу недостатков любого из них. Т.е. возможность оттягать маленький кусочек рынка по прежнему сохраняется даже в 2020-м году.

2. Самое главное, ну впрочем как и много где - это работа с людьми, отношение. Пусть там чего-то нехватает или недоделато. Важно, понимание оперативной поддержки и личного участия в пользовательских проблемах. Пусть даже физически это и не всегда возможно. И вот за отношение люди готовы простить техническое несовершеноство отдельных подсистем и выдать проекту

3. Кредит доверия. По умолчанию он есть у любой новой вещи, но так же быстро убывает или наоборот растёт. Но в любом случае в момент входа на рынок он не должен быть нулевым, иначе со входа всё и в помойку.

4. Техническое. Даже в 2020-м году, даже при наличии рейтрейсинга, вменяемых алгоритмов реалтайм радиосити, удобных для разработчика так толком и не появилось. Возможно это именна та точка приложения, которая позволит мне приобрести изначальный кредит доверия аудитории. Тем более что мне и самому эта тема весьма интересна.

Ну а теперь, то самое пафосное заявление: если моему будущему проекты и суждено стать коммерчески успешным, то я вам обещаю и торжественно клянусь, никогда не забивать на проблемы реальных пользователей, хотя соблазн порой весьма велик.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 04-05-2020 в 15:50:

Цитата:

Дядя Миша писал:
то я вам обещаю и торжественно клянусь, никогда не забивать на проблемы реальных пользователей

...после того как заслали донат!

__________________

Отправлено Cybermax 04-05-2020 в 16:10:

Дядя Миша а есть ограничение на количество игроков по сети? То что называется массовый мультиплеер, может?

Отправлено Дядя Миша 04-05-2020 в 17:16:

Cybermax я этими вопросами не занимался, но можно иметь несколько сетевых моделей. Там как, если RPG игроков дохрена, но синхронизационные пакеты могут идти несколько раз в минуту. И классическая шутерная модель - игроков 32 штуки, но и пакеты идут 30-100 раз в секунду.

Добавлено 04-05-2020 в 20:16:

Кстати вот еще важный момент - разработчикам весьма важно иметь возможность допилить то, чего изначально не было. Скажем тот же VR подключить. И дело тут вовсе не в открытости\закрытости сорцев.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-05-2020 в 11:09:

Ну чтож, по предварительным результатам опроса, да и по общим соображениями, я вижу, что в первую очередь надо направить усилия на внедрение динамической системы окклюзии, т.е. избавится от предрасчётов PVS, которые могут занимать сколько угодно времени. Вероятно в дальнейшем я избавлюсь и от BSP, но пока что это некритично, сборка карты занимает несколько секунд, ну максимум - пару минут на каком-нибудь сепульчере. Но динамический окклюдинг нужен обязательно, виз слишком часто не справляется.

Добавлено 05-05-2020 в 14:09:

Цитата:

XaeroX писал:
...после того как заслали донат!

А между прочим в репозитарии Godot Engine есть такой файлик - список донаторов, и там золотые донаторы, платиновые и так далее. Они еще и по рейтингу сортируются. Но конечно это было до кризиса, когда нефть стоила выше нуля.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-05-2020 в 12:52:

Дядя Миша
А какие методы ты знаешь эффективного отсечения невидимой игроку геометрии в реальном времени? Например вот знаю фрустум, и LODы (хотя это не совсем отсечение, но в каком то смысле), но не более.

Отправлено Дядя Миша 05-05-2020 в 14:09:

FiEctro я ж написал - софтварный рендеринг в Z-буффер. Окклюедеры рендерятся на CPU, чтобы не было лага с получением данных.
Рендер этот довольно простой, там же не надо накладывать текстуры, только растеризация небольшого числа прямоугольников, плюс сам буффер малого разрешения. Ну и желательно его векторизовать, но это я по рассказам, не по опыту.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 06-05-2020 в 04:11:

Мне что-то всё таки кажется, что ни XashNT, ни волатила никому не будут интересны собственно как инструмент для разработки игр, по крайней мере в рамках HLFX. Хотя и сам очень надеюсь что так не случится. Но, всё-таки людям проще влиться туда, где уже есть некоторый набор ресурсов, документации/видеоуроков/статей, примеров игр откуда даже что-то можно стянуть к себе в проект.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 06-05-2020 в 09:22:

Погудели-пообсуждали и возвращаемся к работе. Итак, как же нам обойтись без виза. Сперва попробуем самый тупой метод - будем считать портал флоу налету. Это может оказаться довольно дорого, но попробуем.

Сохранил порталы в карту, вот так они выглядят. Да вы наверное и без меня знаете.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 06-05-2020 в 09:28:

Вообще как можно видеть - там же заведомо избыточные порталы получаются. Ну такой уж результат авто-порталлизации.
Надо будет их смержить потом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-05-2020 в 10:01:

В сорсе бы такие вещи делали детайлами. Кстати инструмент визуализации порталов классная штука.
Не знаю, может глупость сморожу, но что если отсекать ненужное не по геометрии, а по грубой Octree копии модели?

Отправлено Дядя Миша 06-05-2020 в 10:23:

Создал обратные порталы, так наверное более наглядно.

Цитата:

FiEctro писал:
а по грубой Octree копии модели?

Можно просто квантизовать всё пространство на AABB и рисовать сегментами. Но есть проблема - у нас же эти брашы уже и так разбиты на отдельные полигончики, ниже некуда. Для гигантских моделей, типа ЧАЭС это вполне рабочий метод, но сами модели придётся посечь на такие же сегменты. Что в свою очередь может негативно сказаться на бамп-маппинге или наложении лайтмапы.

Ладно. Для начала я хочу просто попробовать выполнять BasePortalVis в реалтайме и для отдельно взятого кластера. Это очень быстро, а вот будет ли достаточно эффективно...

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-05-2020 в 10:51:

Цитата:

Дядя Миша писал:
но сами модели придётся посечь на такие же сегменты. Что в свою очередь может негативно сказаться на бамп-маппинге или наложении лайтмапы.

А разве при разбиении нельзя сохранить нормали вертексов в исходном состоянии?

Отправлено Дядя Миша 06-05-2020 в 18:37:

Цитата:

FiEctro писал:
А разве при разбиении нельзя сохранить нормали вертексов в исходном состоянии?

не поможет. Интерполяция осуществляется внутри треугольника, а не между ними.

Опробовал я SimpleFlood в рантайме. Работает, даже фпс садит гораздо меньше, чем ожидалось бы. Но тут в действие вступает сразу несколько факторов. Если бы эта видимость бралась ну скажем только для рендерера, для камеры - то это одно. Виз он же для движка практически бесплатный, поэтому его юзают все, кому не лень, монстры постоянно проверяют, не появился ли игрок в зоне видимости, код AI дополнительно проверяет наличие игрока, на тему, надо ли играть секвенции или меня никто не видит, серверный кадр строит толстый PVS чтобы отсечь невидимые клиенту энтити. Т.е. за кадр эта штука может вызываться несколько десятков раз, а там рекурсия (пускай и весьма простая) и цикл на numportals * 2. Т.е. всё это просадит фпс куда быстрее чем даст профит от отсечения. Плюс предрасчёты при загрузке карты - сами по себе занимают какое-то время. Ну на c1a0d это полсекунды. Но вообще - неограниченно. BasePortalVis далеко не всегда управляется быстро. Иногда и до минуты маслает в мультитреде.
Вообще конечно использование именно этого кода не вполне корректно, если мы хотим, например посчитать видимость для фрустума камеры. Но тут вылезает другая тонкость - кластеры всё же достаточно большие, т.е. перерасчёт видимости происходит, когда игрок перемещается в другой кластер. Очевидно, если это делать для фрустума, то перерасчёты будут для малейшего движения мышкой. Однако есть одна категория объектов, у которых фрустум не меняется - это лайты. Собсно, в даркплейсе после ряда экспериментов именно для них и оставили портал-флоу.

Добавлено 06-05-2020 в 19:00:

Решил я поизучать как в д3 сделано. А там надо сказать такое обманчивое впечатление, потому что тричетверти компилятора - это по сути паста из ку3. А оставшийся код - это дамп в текстовые форматы, ну я никогда там особо не ковырялся, полагая что оно не представляет интереса. А вот как раз-таки и зря. В дуум3 уже никакие видимые сурфейсы к лифам не цепляются, там идёт группировка по ариям, т.е. большим блокам. И ариа-порталы могут работать в двух режимах. Классический - на двери и визпортал, ограничивающий видимость. И дерево для рендеринга уже не используется, самих арий достаточно немного (лимит на 1024 штуки), они могут быть какого угодно размера - ну скажем на всю карту. Второй любопытный момент связан с тем, что геометрия может разрезаться по размеру этих самых арий. И тут, как я уже говорил - начинаются швы на бампе. Так вот там какая-то хитрая система добавления т-джунков, которая это предотвращает. Впрочем, если маппер не поставил ни одного ареапортала, сами понимаете, это будет довольно тормозно.
Возможно имеет смысл поддерживать оба варианта - классический с визом и "модерновый". Благо что для этого не требуется каких-то фундаментальных изменений, достаточно лишь порезать геометрию.

Добавлено 06-05-2020 в 21:37:

Ну вот подразобрался. Объясню всё подробно, но сначала небольшой экскурс на тему, почему жы в наше время так сильно тормозят старые кушные форматы. Кто-то полагает что дело в БСП, кто-то думает что они просто устарели. Если говорить кратко, то в старых форматах нарушился баланс оптимизации. Поясню. Есть несколько типов оптимизации.
1. Не делать вообще ничего - бывают случаи, когда весь код можно полностью выкинуть без ущерба для функционала. Чаще всего - когда нагородили лишнева. Или же код писался вчерную для теста.

2. Посчитать всё заранее - компиляция. Баланс между процессорным временем и памятью.

3. аппроксимация - берём тяжёлый для выполнения код, упрощаем, получаем выигрыш в скорости при минимальных отличиях в результатах работы.

4. запуск тяжёлого кода предваряется лёгкой для выполнения проверкой.
Вот здесь как раз наш случай. По факту в старых форматах мы столкнулись с совершенно идиотской ситуацией, когда проверка на видимость стала дольше отрисовки. Почему такое произошло?

Очевидный ответ - форматы разрабатывались с учётом софтварного рендеринга, т.е. с отрисовкой на процессоре. Отправка данных на видеокарту капитально перебалансировала всю систему. Но к счастью шины у видеокарт тогда были узкие, прокачка данных была достаточно дорогой, поэтому для intermediate-режима мы наоборот получили прирост производительности. Собсно проблемы начались, когда нам захотелось иметь миллионы полигонов в кадре. Дерево, как я уже говорил очень подробное. Каждый полигон лежит на ноде. А если не помещается - будет разрезан и всё равно положен. При возможности делать очень большие уровни подобный подход сам по себе превратился в тормоз.
1. рекурсия по слишком большому дереве тормознее линейного перебора
2. отдельное отсечение каждого полигона фрустумом если не дороже, то зачастую сопоставимо с их отрисовкой (особенно если их очень много).
3. всё это крайне херово оптимизируется, из-за особенностей текстурирования брашей. Проблематично сделать три-стрипы, к примеру.
Возможность засунуть всю геометрию в единый VBO проблемы не решило - ну потому что мы по прежнему проверяем каждый полигончик отдельно на попадание во фрустум, а потом шлём его индексы на видеокарты.
В Ку3 лифы сделали больше размером, видимо как раз согласуясь с возможностями тогдашнего железа. Но это же зависит даже не просто от возможности добавлять детальные полигоны в лифы. Смысл в том, что рисовать даже по лифам - затратнее чем одним вызовом. Но вот при текущей организации не получается ни то ни другое. Потому что как ни крути, PVS всё же справляется со своими задачами неплохо, а отрисовке группами мешает тот факт, что сами брашы не предназначены для эффективной отрисовки. Я бы конечно мог просто их выбросить нахрен и вообще, но.. мы же хотим кубать, правильно?
И для меня уже пару лет это было. ну не то чтобы неразрешимым противоречием, просто я не мог определиться, как лутьше поступить. То ли выкинуть BSP совсем, порезать всё на квадраты и выполнить иерархическую окклюзию. То ли октри заюзать. Вообщем размышлял я до сегодняшнего дня, пока совершенно случайно не углубился в изучение дуум-тришной организации ареа-порталов (а там же нет виза, как вы помните). Конечно я весь этот код видел и раньше, но в том-то и дело, я просто был изначально уверен, что вся эта замута нужна в основном для построения и оптимизации теневых объемов (что вообщем-то правда - там действительно есть этот код). Но вот ту основную идею, которую я там сегодня разглядел...

Продолжение следует

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 06-05-2020 в 18:52:

Цитата:

Дядя Миша писал:
Но вот ту основную идею, которую я там сегодня разглядел...

...расставлять порталы между ариями будет маппер. Та-дам!

__________________

Отправлено Дядя Миша 06-05-2020 в 19:37:

Цитата:

XaeroX писал:
...расставлять порталы между ариями будет маппер. Та-дам!

Хочешь прикол? Мапперы эти порталы уже 18 лет расставляют. Причём, расставляя их они ждут от них именно работы порталов. И очень сильно расстраиваются, когда от этой расстановки просто полигонов прибавляется.
Я про хинт-брашы говорю

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-05-2020 в 08:31:

Есть еще вот какое соображение. Все Кармаковские компиляторы (и д3 не исключение), генерят скорее избыточное кол-во порталов, чуть ли не для отсечения каждого полигона. То есть порталы на дверных проёмах в этом кол-ве тоже присутствуют в обязательном порядке. Надо просто найти удовлетворяющие нашим требованиям и использовать их. А остальные проигнорировать. Крытерий очевидно один - портал всеми своими рёбрами должен касаться реальной геометрии.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-05-2020 в 19:52:

Да уж, не так-то просто расставить эти виз-порталы автоматически.
Но я пока еще не теряю надежды.

Добавлено 07-05-2020 в 22:44:

текущая реализация имеет тенденцию ставить авто-порталы в двух случаях:
1. в дверных проёмах (ну собсно, как и нужно)
2. декоративных углублениях, типа всяких ниш (в чём нет никакого смысла).

Отличить нормальный проход от ниши практически невозможно. Увы.

Добавлено 07-05-2020 в 22:52:

Вероятно я просто начал не с того. Надо сперва оценить эффективность отрисовки сгруппированной по материалам карты, разбитой по материалам.
Взять тот же сипульчер. Там примерно 700 тыщ вертексов, 150 тысяч полигонов (треугольников триста-четыреста тысяч) и 252 текстуры (материала). В принципе для любой современной видеокарты это тьху. Это у нас в идеале 252 дипа (по материалам). Там безо всякого виза фпс должен быть приличным. Но это касается только рендеринга, естественно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 07-05-2020 в 21:09:

Цитата:

Дядя Миша писал:
Отличить нормальный проход от ниши практически невозможно. Увы.

делать трассу вглубь портала, и если значение меньше n, то удалять портал?

Добавлено 08-05-2020 в 00:09:

Цитата:

Дядя Миша писал:
252 текстуры (материала)

а если одна текстура используется в нескольких материалах? Как в принципе оптимизировать переключения и синхронизировать их с порядком отрисовки? Или z-buffer все разрулит?

__________________
-Brain is dead-

Отправлено Дядя Миша 07-05-2020 в 22:03:

Цитата:

KiQ писал:
делать трассу вглубь портала

Ну сделал и что ты узнал?

Цитата:

KiQ писал:
Как в принципе оптимизировать переключения

Переключать пореже

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-05-2020 в 01:49:

Цитата:

Дядя Миша писал:
Ну сделал и что ты узнал?

если трасса уперлась во что-то, значит это ниша а не коридор. Для верности пускать две трассы в противоположные стороны.

Отправлено Дядя Миша 08-05-2020 в 07:20:

Crystallize когда будешь свой движок писать - именно так и сделай Это штука будет покруче чем LithTech.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-05-2020 в 11:04:

Дядя Миша ну то есть конечно не вглубь портала а наоборот, наружу.
Кстати у порталов есть такое свойство как PYR?

Отправлено KiQ 08-05-2020 в 11:35:

Цитата:

Дядя Миша писал:

Ну сделал и что ты узнал?

ну, скажем, пускаем две трассы в обе стороны, если одна из них уперлась в геометрию ближе, чем на N юнитов, то убираем портал. Хотя возможна и ситуация, когда прямо перед порталом натыканы брашевые ящики, так часто в КС бывает, например, тогда закономерный фейл.
А вообще насколько критична повертексная точность порталов? Допустим, если аппроксимировать геометрию карты в аксиальные браши, расставить порталы по упрощенной модели, а потом вычесть из них реальную геометрию?

__________________
-Brain is dead-

Отправлено Дядя Миша 08-05-2020 в 11:55:

Ну чтож, поскольку я не знаю что такое PYR, давайте я вам лучше поясню, чем я сейчас занимаюсь (как продолжение к верхнему посту).

Я уже неоднократно говорил, что основная проблема брашей - это их неприспособленность к рендерингу видеокартой. Из-за проекционного наложения текстурных координат их проблематично клеить в шареные треугольники, но даже если бы это и было возможным, наступает другая проблема - как эффективно отсекать видимость? На базе портального октри-рендерера, но это обычно предполагает аксиальное разбиение на кубические сектора, что уже само по себе очень неудобно. Есть еще HOM (он кстати использовался в сталкере) - дизайнер ставит сферы видимости и вкладывает их друг в друга. Тоже не слишком удобный подход. И как правило всё это базируется на необязательности иметь замкнутую геометрию. Но дело в том, что в настоящее время геометрию замкнуть куда легче чем во времена создания первокваки - просто делаем скайбокс и всё.
Но при таком подходе, как вы понимаете уже виз начинает сходить с ума, обрабатывая бессмысленную информацию. При том, что виз весьма удобная штука, в том числе и для AI-монстров, да и для сетевой оптимизации.
Проблема виза заключается в его дикой избыточности для современных подходов. Когда он помогал отсечь несколько лишних полигонов, чтобы их не пришлось рисовать софтварному рендереру, это всегда было хорошо. В ку3, оставив виз практически прежним, детализацию предложили делать встраиваемыми моделями, которые на виз не влияли и время компиляции не увеличивали, но в то же время рисовались за один вызов, если были видны. Это несколько исправило положение, но всё равно по современным меркам (т.е. где-то с 2007-го года), было явно недостаточным. Doom3 со своим подходом время сильно опередил, больше скажу, этот подход практически идеально ложится на все части старой архитектуры, снимая практически все проблемы и не добавляя новых. Ну вот кроме потребности расставлять эти виз порталы, но за это будет еще отдельный разговор. Ксерокс, мне вон рассказал, что в том же унреале их с самого начала надо было расставлять. Этож не окклюдеры, которые поставишь и гадай будет от него толк или не будет. Так вот.
Как шла эволюция виза?
1. первый квейк - визблоки намертво привязаны к лифам. Один визблок = один лиф. В лифе от одного до 256 полигонов (кажется в старых компиляторах был стековый массив с ограничением именно на столько, впрочем могу напутать). Теоретически в одном лифе конечно могла быть и вся карта, но это редкий случай, а на ку1 помоему совсем невозможный.
Соответственно если из позиции игрока нам этот лиф не виден. то не видны и все его полигоны.
2. второй квейк - над лифами появилась надстройка в виде кластеров и арий. Кластеры там были ну не точто бы сильно нужны, скорее как индексация для PVS и PHS, чтобы не хранить по два оффсета на сурфейс.
Но было и другое преимущество - мы получили возможность давать разным лифам один и тот же кластер, делать PVS более толстым по желанию. Что в свою очередь позволяло имплементировать детайл-брашы, которые занимали разные лифы, но у которых был один и тот же кластер. Виз считал видимость именно по кластерам, т.е. детайлы не замедляли скорость рассчёта. В принципе можно было обойтись и без кластеров в формате структур, но тогда бы пришлось сохранять эту информацию куда-то еще (что, собственно и сделал китаец в VHLT). Т.е. с ними код становится более удобным и читаемым, но нарушает бинарную совместимость.
3. третий квейк. Здесь арии получили специальный разделитель - ареапортал браш, а двери не надо было линковать со специальной энтитью или искать этот ареапортал по номеру, как было в ку2. Здесь эту задачу разрешили очень изящным образом - ареапортал-браш на самом деле не занимался выключением видимости, он просто делил одну арию на две. А дверь при вызове LinkEdict, просто искала в прикасающихся лифах их принадлежность разным ариям и соответственно могла их соединять и разъединять. Т.е. потенциал был заложен уже тогда, но использовался лишь для дверей. Основное отсечение всё равно происходило по классическому PVS, но зато в Q3 появилась возможность вставки произвольных моделей на карту, которые не влияли на построение видимости и рисовались за один вызов (если на них был один шейдер). Всё это повторюсь было еще актуальным для intermediate mode, когда выбора качать или не качать вертексы через шину каждый кадр у нас еще не стояло. А в 99-м году такого выбора разумеется не было, VBO появился в емнип в 2002-м году, долгое время устаканивался, из-за чего его боялись юзать вплоть до 2006-го года. Или если быть точным, даже не то чтобы боялись, ну просто смысл VBO в абсолютном отсутствии обновлений. А все необходимые действия надо выполнять в шейдерах. Если же обновлять сам VBO, то производительность даже ниже чем с бегинами (при соответствующих объемах данных). Я об этом в своё время писал и негодовал. Плюс еще и шейдеры, в момент их появления были сильно ограничены в возможностях, модели 1.0 и 1.1 использовать невозможно в принципе, разве что для туторов "как сделать развевающийся флаг на Cg". Собсно реальное использование началось именно с модели 1.2 (поэтому вы можете так часто видеть в GLSL-шейдерах прагму #version 120). Причём в отличие от того же DX, уже с этой версии большинства возможностей хватало для реализации очень и очень многого. А чего нехватало - можно было подключить расширением.

4. Doom3. У Кармака была прямая телепатическая связь с производителями видеокарт, поэтому то, что массово начали использовать с выходом кризисов-сталкеров, он мог внедрять уже в 2003-м году, не боясь, что это не сработает. И вполне естественно затачивал форматы хранения под это дело. К тому же в самом D3 положение усугублялось тем, что отложку на тот момент не потянул ни один компьютер (да и в железе еще ничего такого не было реализовано), т.е. нас ожидал овердрав по отрисовке источников динамического света. В 2003-м году. До 16 лайтов на сурфейс. Еще и с ~~конями~~тенями. Вообще ужас. При таких вводных, рисовать по треугольничку и всё это прокачивать каждый раз по шине смертоубийство. Собственно, Кармак уже тогда сделал прицел на VBO. Но брашевая геометрия, повторюсь для этого не особенно годилась. И виз по своей природе не очень-то этому способствовал, но сам виз было желательно сохранить, он ведь удобный и надёжный. Но скорее всего не было и желания фундаментально менять принципы, на которых фактически держалось уже не одно поколение движков и которые себя весьма хорошо зарекомендовали, плюс у дизайнеров уже выработались определённые правила работы. Всё это накладывало свой отпечаток. Итак, что же было сделано?
(продолжение следует)

Добавлено 08-05-2020 в 14:55:

Цитата:

KiQ писал:
А вообще насколько критична повертексная точность порталов? Допустим, если аппроксимировать геометрию карты в аксиальные браши, расставить порталы по упрощенной модели, а потом вычесть из них реальную геометрию?

Я боюсь ты не очень понял. Я не создаю никаких порталов "под дверные проёмы". Порталы генерирует сам компилятор с незапамятных времён. Обычные такие порталы, по ним еще виз считает видимость. Я просто среди этих сотен тысяч порталов отбраковываю те, которые могли бы мне пригодится в качестве ареапорталов. Только и всего.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 08-05-2020 в 12:19:

Цитата:

Дядя Миша писал:
не знаю что такое PYR

Думаю, имелся в виду pitch-yaw-roll.

Отправлено Дядя Миша 08-05-2020 в 12:28:

Не знаю, обращали ли вы внимание, но уже в ку3 дефолтное описание хинта превратилось вот в это

C++ Source Code:

1	textures/common/hint

3	qer_nocarve

4	qer_trans 0.30

5	surfaceparm skip

полностью аналогично скипу

C++ Source Code:

1	textures/common/skip

3	qer_nocarve

4	qer_trans 0.40

5	//surfaceparm nodraw

6	//surfaceparm nonsolid

7	surfaceparm skip

Это не хитрая кодерская задумка, хинты просто дропнули на уровне дизайнера, т.к. пользы от них не было абсолютно. Т.е. браш оставили, а влияние от него - убрали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-05-2020 в 13:22:

nemyax именно.

Отправлено Дядя Миша 08-05-2020 в 16:14:

Crystallize портал это портал, причём тут углы? Портал это окошко такое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 08-05-2020 в 17:10:

Дядя Миша ну портал же может быть ориентирован? Вообще надо бы мне накидать на досуге портальный рендер, а то что-то я так до конца так и не въехал в их концепцию, а через практику оно приходит...

__________________
-Brain is dead-

Отправлено thambs 08-05-2020 в 17:18:

Дядя Миша
Скажи, а портал может только в одну сторону просматриваться в целях оптимизации?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено KiQ 08-05-2020 в 17:33:

thambs думаю через него пропускается луч из взгляда игрока, соответственно как ты собираешься просматривать в обе стороны?

__________________
-Brain is dead-

Отправлено Дядя Миша 08-05-2020 в 17:40:

Цитата:

KiQ писал:
ну портал же может быть ориентирован?

Пля, ты от Crystallize штоле заразился?

Портал - это окно, дырка в стене. Дырка может быть ориентирована?
Как часто ты ориентируешь дырки?

Цитата:

KiQ писал:
а то что-то я так до конца так и не въехал в их концепцию

Вот очень хорошая картинка с сайта Фабиана

Проёмы - это порталы. Порталы принадлежат той или иной области. Если не виден портал, значит не видна и вся область. Разумеется область должна быть герметично закупорена, т.е. любой выход из нее должен быть закрыт порталом. Но если это не так, портал флоу просто затечёт обратно и область не будет разбита на две. Технически это даже не ошибка, хотя наверное имеет смысл выдавать предупреждение.

Цитата:

thambs писал:
Скажи, а портал может только в одну сторону просматриваться в целях оптимизации?

Порталы и так смотрят в одну сторону, их обычно по две штуки ставят, один туда, другой обратно.

Добавлено 08-05-2020 в 20:40:

Кстати говоря, в Сорсе тоже баловались с такими порталами, но без разрезания всей геометрии, толку от того немного.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-05-2020 в 18:39:

Цитата:

Дядя Миша писал:
Портал - это окно, дырка в стене. Дырка может быть ориентирована?
Как часто ты ориентируешь дырки?

Цитата:

Дядя Миша писал:
Порталы и так смотрят в одну сторону, их обычно по две штуки ставят, один туда, другой обратно.

Неловко вышло.

Если у стенки была некая нормаль и мы проделали дырку в стенке, то у дырки будет та же самая нормаль, так?

Я к чем у заговорил про возможность ориентации порталов, я-то их по твоим скриншотам представлял как браш, и соответственно поэтому сначала предложил пускать из них трейсы вперёд и назад для детекции ниш. Но в связи с твоим недоумением я подумал-а мало ли что, может быть к порталу не применимы термины вперёд и назад, может быть у него и ориентации-то не бывает и нельзя различить перед и бок?

Отправлено nemyax 08-05-2020 в 18:49:

Crystallize
Нормаль это не ориентация.

Отправлено Дядя Миша 08-05-2020 в 19:23:

Цитата:

Crystallize писал:
то у дырки будет та же самая нормаль, так?

Нормаль, у дырки?

Здоров ли ты сегодня?

Вообще говоря нам достаточно ректангла в 2д. Вся эта замута с нормалями - это другой способ оптимизации, оно необязательное, их так просто легче контролировать.

Цитата:

Crystallize писал:
представлял как браш

портал - одна из сторон браша. ну как хинт-браш, у которого остальные стороны покрыты скипом. С точки зрения дизайнера.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-05-2020 в 20:05:

Цитата:

Дядя Миша писал:
Нормаль, у дырки? Здоров ли ты сегодня?

Ну а что, в Кварке браши отрицательные, а дырка-это отрицательная декаль, ты говорил что П2 (или NT?) позволяет такие сделать.

Отправлено Дядя Миша 08-05-2020 в 21:01:

Отрицательный браш в кварке - это просто браш с приоритетом. Т.е. CSG всегда знает что вычитается из чего.

Цитата:

Crystallize писал:
а дырка-это отрицательная декаль

Я говорил что можно глубину модифицировать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 09-05-2020 в 12:36:

Продолжим. Здесь пожалуй уместно сделать небольшое историческое отступление. Так любопытно получилось, что в первом дууме и в третьем - по одному компиляторы и принципы построения уровня в чём-то схожи. Там - секторы, тут арии. И там и там они могут быть какой угодно формы, неконвексные. Это же свойство активно используется для распространения звуковых волн в игре. Правда на этом сходство как бы и кончается.
В первом дууме секторы - это геометрия с одинаковой высотой пола и потолка. Любой алгоритм ведь строится на допущениях, как только они перестают отвечать нашим требованиям - всё рушится. Естествено что в квейке мы уже не могли разделять пространство на секторы с разной высотой пола, можете себе представить сколько было бы секторов в таком случае. В принципе надо признать, что PVS, он изначально делался именно под уровни первого квейка и именно в контексте этих зловещих колидоров он работал оптимально. Уже в ку2 с этим начались проблемы, в ку3 пришлось довольно многое поменять, а в д3 и вовсе отказаться от такого подхода. Итак, в д3 фактически произошёл возврат к секторам, но на качественно новом уровне. Сектор\ария это выделенный пользователем кусок уровня, который рисуется за один раз. Ничего страшного при этом не происходит - невидимые части отсекаются на видеокарте. С одной стороны такой подход может резко влиять на фпс при смене секторов (вспомним недавние жалобы на Волатилу, что открытие дверей резко роняет фпс), с другой стороны - это целиком и полностью контролируется пользователем, в отличие от тех же хинтбрашей, которые лишь подсказки доброй воли. Т.е. пользователь может поделить уровень на куски таким образом, чтобы каждый новый кусок попавший в видимость не слишком сильно ронял фпс. Опять таки на открытом пространстве не придётся ждать бесполезную работу по обсчёту видимости.

Как же устроены эти арии? В сущности они уже были во втором квейке, да. Но! Всё это время они использовались как надстройка над обычным PVS. Сам виз их игнорировал кстати. Это был просто еще один слой абстракции - такой толстый-претолстый пвс, который мог выключить разом из видимости целую область. По команде от закрытой двери. Но обычный PVS работал классическим образом - всё так же отсекая по одному-два полигончика где-нибудь там. То есть херово работал, если честно. Виз очень сильно завязан на разбиение деревом, а дерево строится не учитывая вообще никакой виз, его больше волнует конвексность пространства. Можно сортировать плоскости по аксиальности, делать эти разрубы каждые 1024 юнита, но факт остается фактом - добавление нового маленького брашика, может полностью перебалансировать вашу систему виз. Но из-за высокой дискретности разбиения пространства это в сущности мало кто замечал. Чтобы добится большей предиктабельности вот как раз и ввели эти хинты. Только они все равно не гарантируют ничего по сути. Фактически они работают как виз порталы с негарантированным результатом. Может станет лучше, а может и не станет. Вообщем на сегодняшний день это действительно несеръезно. Но повторюсь, PVS как концепция дико удобен, от него очень нехочется отказываться.

Чтоже было сделано в D3. Простая и в то же время гениальная вещь. Как я говорил, у нас было три слоя абстракции - сперва видимость считалась по лифам. Потом по кластерам и наконец по ариям. В ку1 были только лифы. В ку2 добавились кластеры для игнорирования детайл-брашей (но при этом детайл-брашы не были детальными - они не текли (т.е. из них можно было делать уровень), они разбивали другие браши) и арии для выключения дверей. В ку3 концепцию еще более углубили - теперь ареапорталы стали такими же брашами и появилась возможность их расставлять для блокирования видимости. Ну или хотя бы просто для группировки объектах в разных ариях. Но не было сделано самого главного - видимые сурфейсы никак не были привязаны к этим самым ариям. Связь была очень условная, особено в ку3 где полигоны могли одновременно принадлежать нескольким лифам, а лифы в свою очередь - разным ариям. То есть не было вот этой чёткости, когда мы могли рисовать одну арию и точно знать, что всё, что к ней относится - больше ни к чему не принадлежит. Что же для этого надо сделать? Ну очевидно покромсать геометрию по кромкам самой арии? А как это сделать, ария это больше виртуальное понятие - номер в ноде. Плюс у нас геометрия и так уже покромсана BSP-деревом.

И вот тут начинается самое любопытное. Во первых, дерево, где ноды принадлежат разным ариям позволяет очень точно раскромсать уровень на арии ПРОИЗВОЛЬНОЙ ФОРМЫ. Причём эта самая форма задается лишь расставленными порталами. Не надо, как в иных движках заключать её в браши-объемы, достаточно лишь ограничить порталами. К тому же FloodAreas отследит, было ли реальное разделение на несколько арий, ну если вы к примеру поставили ареапортал в чистом поле. Но важный момент - геометрия кромсается вся, не только брашы, но и патчи и тримодели. Впрочем это можно запретить (в том же D3 флаг discrete например для автоспрайтов или зеркал). После того как всё покромсано соответствующими нодами - начинается самое любопытное. Геометрия начинает склеиваться обратно в большие батчи по типу материала.
Таким образом, каждая ария у нас представляет некоторый аналог студиомодели с точки зрения отрисовки - удалены лишние треугольники, всё стрипифицировано и сгруппировано по материалам, а поскольку в одной арии возможно не так уж и много материалов, то и соответственно батчей тоже немного. Правда сам механизм определения видимости чуть тяжелее, чем классический кушный. Но это компенсируется лёгкостью отрисовки. Есть и еще один неочевидный плюс такого подхода. Теперь при помощи таких порталов очень легко задавать туманные области. Ограничиваем вход-выход, их может быть сколько угодно. Если это небольшое углубление - ставим портал, вот вам и вода с туманчегом. Ну или просто вода. Сам виз в его классическом представлении тоже остается, но строится он уже на учете пользовательских ареапорталов и арий. А поскольку их смешное кол-во (в тоже д3 в среднем штук 40-50), считается такой виз от силы 5-10 милисекунд. Становится возможным включить его прямо внутри BSP (а в д3 оно вообще при загрузки карты считалось каждый раз, но это глупость конечно).

Вообщем это весьма перспективный и не утративший своей актуальности подход. Он ведь позволяет эффективно рассчитать и течение света сквозь порталы в реалтайме. И решить эту проклятую проблему с солнцем, которую кстати не решили в сталкере и не факт что решили в метро. Вот возьмем сталкеровский НИИ Агпропром. Там есть такой спуск потземлю. В оригинале его сделали отдельным уровне. В LostAlpha сделали частью общей карты, но когда ты спускаешься вниз, то прямо видно как гаснет солнце. Очевидно они не смогли эффективно отделить верх от низа. С системой порталов это вообще не представляет никакой проблемы. На входе в подземелье ставим один портал, на выходе - другой. Между порталами - шахта с лестницей. Дальше солнце просто определяет видимость - оно может осветить условно арию 0 (аутдор), немного арию 1 (шахту с лестницей) ну и собственно всё - до подземелья лучи уже не добивают. К тому же мы можем эффективно оптимизировать и аутдоры тоже, причём в автоматическом режиме - здесь нам на помощь приходит то самое авторазбиение на квадраты в BSP. Лепим эти арии, каждые 1024 юнита. Ну и дальше ограничиваем видимость либо туманом либо классически по фрустуму.
(продолжение следует)

Добавлено 09-05-2020 в 15:34:

Цитата:

Дядя Миша писал:
Становится возможным включить его прямо внутри BSP

Возможно кто-то это истрактует неправильно, я имел в виду, что код рассчёта видимости можно объеденить с компилятором BSP, нет больше смысла выносить в отдельную тулзу.

Добавлено 09-05-2020 в 15:36:

Кстати еще любопытный момент (но это неточно), склееная геометрия с удалёнными лишними вертексами и шареными ребёрами скорее всего позволит более эффективно накладывать лайтмапы. Т.е. разом на развертку, вместо того чтобы выделять куски под каждый полигончик.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 09-05-2020 в 13:54:

Дядя Миша
Останецца две утилиты для коптиляции?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 09-05-2020 в 15:48:

thambs типа того. Но насчёт лайтмаппера я пока не знаю, он вероятно будет необязательным. Сделать его надо просто для референса, чтобы сравнивать запечённое освещение с реалтаймом.

Добавлено 09-05-2020 в 18:48:

Вообще BSP компилятор будет очень эпичным. Вероятно ни в одном движке больше не будет такого тяжёлого препроцессинга геометрии как у меня.

CSG по брашам, CSG по сурфейсам, разрезание по дереву, разрезание по ариям, склеивание всего обратно с выкидыванием лишних ребёр, глобальный т-джунк. Но при всём при этом, вероятность выпадения полигонов будет минимальной или вовсе отсутствовать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 09-05-2020 в 16:18:

Цитата:

Дядя Миша писал:
Сделать его надо просто для референса, чтобы сравнивать запечённое освещение с реалтаймом.

Как насчёт просчёта лайтмап на GPU? Видимо лайтбейкер3000 тут будет бесполезен из-за другого формата BSP.

Отправлено ncuxonaT 09-05-2020 в 16:43:

Crystallize лайтбейкеру плевать на формат, он может хоть чёрту лайтмапу посчитать. Если конвертировать чёрта в obj.

Отправлено Дядя Миша 09-05-2020 в 17:28:

Давайте всё же в порядке очерёдности. Сейчас надо получить максимальный прирост производительности даже без PVS. У меня прогресс шёл следующим образом:
1. Новый движок с халфовским форматом (3%..5%) просто из-за отсутствия всякого мусора совместимости и видоизменённому игровому циклу.
2. Построение оптимизирующего виз-три для халфовского формата (10%..%400) к производительности.
3. переход на кутришный формат (200%..%600) к производительности.
Теперь вот финальная стадия оптимизации. Ну посмотрим. Старые форматы никуда не делись, будет с чем сравнивать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 10-05-2020 в 16:03:

Опробовал дуумтришные оптимизации-триаунгуляции. Ну что можно сказать?
Навскидку - очень неплохо. На том же сипульчере 180 тысяч полигонов собралось в 2500 сурфейсов. Фпс даже безо всякого виза - порядка 250.
И это при том, что там сейчас переходной период, я вообще себе смутно представляю что там рендерится, а что отсекается, я просто отправил эти батчи как MST_TRIANGLE. С другой стороны нельзя прямо сказать, что этот код показывает чудеса оптимизации. Ну что-то там удаляет конечно, факт.
Но всё равно имхо многовато треугольников остается. Зато здесь т-джунктион с хэшем - быстро работает. Сипульчер компилился 5-минут.
Вообще там код с явными ляпами, к примеру идёт прямое сравнение флоатов. Из-за чего постоянно лезут тучи варнингов. Заменил на эпсилоны - почти все ошибки исчезли. Странно это всё, как они с таким кодом вообще свой дуум собирали. Ну да ладно, смысл есть, а это главное.

Конечно там еще весьма много возни предстоит, как это всё запеределать и увязать с текущим форматом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 10-05-2020 в 16:15:

А нельзя делать прямое сравнение флоатов, если они получены явным образом? Ну то есть не в результате математических операций.

Отправлено Дядя Миша 10-05-2020 в 20:43:

В том-то и дело, что там в коде идёт сравнение с результатом дотпродукта, а не с прямой записью констант. Даже при условии, что мы действуем в 2д пространстве это откровенно стрёмный кейс. Я вообще удивился как оно работало. Потом вспомнил - у меня же компилятор на даблах. Переключил на флоаты - действительно ошибок стало кратно меньше. Ну это не дело.
Там главное даже камент есть, что неплохо бы заюзать хэширование.

Добавлено 10-05-2020 в 22:26:

Полностью заткнул все ошибки и предупреждения. Что для этого потребовалось сделать?
1. переключиться в режим одинарной точности (перекомпилить)
2. поскольку оптимизация происходит в 2D и использует построение ортогонального базиса - надо непременно юзать ту функцию, которую использовали в D3. MakeNormalVectors. Они все "типа правильные", но код потом намертво привязывается к конкретной реализации и глючит с другой.
3. мало этого - в MakeNormalVectors пришлось еще и заюзать табличный InvSqrt. И вот только тогда все ошибки исчезли. Ну что можно сказать? Зашибись! Отличный оптимизатор.

Добавлено 10-05-2020 в 22:31:

В D3 вообще много такой табличной математики для флоатов. Неудивительно что они не боялись их сравнивать напрямую кое-где.

Добавлено 10-05-2020 в 23:36:

На домашнем компе сепульчер сразу стартанул под 650 фпс
напомню что предидущий рекорд был 420. И это еще на толком не отстроенной системе, я чёрт знает что там рисуется сейчас. Виз-то старый.

Добавлено 10-05-2020 в 23:41:

Вон он, весь сепульчер в кадре. ~350 тысяч полигонов. Я ж говорил, что это должно быть быстро.

Добавлено 10-05-2020 в 23:43:

Так это еще индексы по шине качаются.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 13-05-2020 в 11:36:

Тут выяснился один недостаток нового подхода, я думаю вы уже догадались в чём он заключается. В ку3 детайлы не карвились по границам дерева, они просто добавлялись в карту в любом случае. И были видны из какого-то лифа. Здесь же идёт строгое обрезание по секущей плоскости ноды. Иногда (не часто), маппер намеренно располагает детайл ЗА ограничивающим брашем (ну например этот браш невидимый). В ку3 этот детайл бы добавился в уровень в любом случае, а здесь получается, так что невидимая геометрия BSP попросту отрезает его, сама карта при этом, естественно собирается без утечек, но визуально на месте этих патчей-моделей остаются дыры, причём, поскольку мапперы еще и любят их точно совмещать, их отрезание сильно зависит например от режима точности. В одинарном режиме отсекает практически всё, в двойном - ну кое-что.
Т.е. добавление просто считает, что детайл попал в солидную ноду.

Взять вот карту Сока для примера, Focal Point. У него там солидные структуры по бокам лестниц и прямо на них же положены планарные детальные ромбовидные патчи. Патчи там очевидно потому, что брашы такие формы проблематично текстурировать, в радианте не было таких инструментов вроде. И вот оно лежит точно на ноде и отсекается.

Надо подумать как лучше разрешать подобные ситуации.

Добавлено 13-05-2020 в 14:26:

Принял такое решение: если детальный полигон лежит точно на секущей плоскости ноды - делаем его копию и пускаем обе копии дальше вниз по дереву. Одна копия наверняка попадёт в солидный лиф и будет уничтожена, вторая попадёт в валидную арию. Но даже если каким-то чудом в видимый лист попадут обе копии - лишнюю уничтожит оптимизатор.
Но детайлы не должны уничтожаться никоим образом. И уж тем более не должны зависеть от точности эпсилона.

Добавлено 13-05-2020 в 14:36:

C++ Source Code:

1	if( keepon && !counts[SIDE_FRONT] && !counts[SIDE_BACK] )

3	if( fnormal )

5	// put front face in front node, and back face in back node.

6	if( DotProduct( fnormal, normal ) > NORMAL_EPSILON ) // usually near 1.0 or -1.0

7	*front = in;

8	else *back = in;

  else

12	vec_t sum = 0.0;

13	for( i = 0; i < in->numpoints; i++)

15	dot = DotProduct( in->p[i], normal );

16	dot -= dist;

17	sum += dot;

20	if( sum > NORMAL_EPSILON )

21	*front = in;

22	else *back = in;

  return;

Китайская логика. То есть оно как бы лежит точно на плоскости, но при этом мы всё равно пытаемся найти на какую сторону её поместить.
Это вот и есть тот самый корень всех бед и выпадающих полигонов. Т.е. это по большей части определять бесполезно. У нас определение намертво завязывается на точность вещественного, это обязательно сглючит. Чуть-чуть подвигаешь полигоны - сглючит в другом месте.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 13-05-2020 в 11:38:

Дядя Миша
Можешь скрины сделать? По тексту не понятен конкретный брашевый кейс.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 13-05-2020 в 12:42:

Это просто ошибка в логике. ChopWindingInPlace к примеру не уничтожает виндинг, лежащий на плоскости независимо от того, находится ли он чуть-чуть за или чуть-чуть перед ней. Ну просто потому что мы в этом случае вступаем на очень зыбкую почву, когда наши предположения целиком завязаны на точность вещественных. Такой код не будет нормально работать уже.

Добавлено 13-05-2020 в 14:49:

Вот скрины

Там где на первом скриншоте дырка - на самом деле большой нулл-браш от пола и до потолка, типа колонны (вы можете скачать исходник этой карты у Сока на сайте и сами посмотреть). Верхняя и нижная часть идут под углом градусов в 8, поэтому не отсекаются. Средняя часть, видимая на втором скриншоте - никакой не браш, это планарный патч, который тут заюзали. скорее всего чтобы легче было текстурировать. А коллизия обеспечивается вот как раз этим невидимым брашем. Плюс наверное эти патчи еще и в мета-сурфсы превратили, я уже не помню. Ну вот. И получается, что этот невидимый браш создаёт плоскость у ноды. И патч ложится точно на него. И естественно отсекается, как попавший в солид-арию за плоскостью ноды. Чего, естественно быть не должно.

Добавлено 13-05-2020 в 15:00:

ЗЫ. У Кармака в D3 более изящное решение - проверить куда смотрит нормаль секущей и сравнить с текущим виндингом. И уже в зависимости от этого положить спереди или сзади. Здесь в чём плюс - мы уже не завязаны на точность. Смотрим только на знак дотпродукта.

Добавлено 13-05-2020 в 15:13:

Это вот тот самый случай, про который я и говорю - если задача в принципе не решается в одном измерении\подходе, ну значит надо поменять сам подход.

C++ Source Code:

1	vec_t sum = 0.0;

2	for( i = 0; i < in->numpoints; i++)

4	dot = DotProduct( in->p[i], normal );

5	dot -= dist;

Вот этот у нас пытается для каждого вертекса исходного виндинга определить максимальный отступ от плоскости. Но это же бессмысленно! Нам уже WindingOnPlaneSide дал чёткий ответ, что полигон лежит точно на плоскости. Дальше мы на граничной точности вещественных пытаемся что-то определить. Иногда получается хорошо, иногда не очень. Это не может быть надёжным. Просто представьте на секунду, что dot во всех случаях вернул 0.0. И что тогда? А с нормалью - это не математика, это чисто логическое допущение, что если уж плоскость и полигон смотрят в одну сторону, то и полигон следет расположить перед секущей. И это допущение прекрасно работает (ну впрочем я еще потестирую, на коллоизационных брашах, у меня там с ними как раз были такие проблемы).

Добавлено 13-05-2020 в 15:42:

Вся Edge Of Forever в камере. Неплохо для дохлой GT640? Раньше я вообще боялся на нее взглянуть отсюда.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 14-05-2020 в 16:00:

Так, ну чтожы. Похоже я нашёл идеальный подход для создания каких угодно уровней. Который не устареет в будущем, у которого виз не будет считать часами, на базе которого можно реализовать те самые миллионы полигонов в кадре без особых тормозов. И при всём при этом - он по прежнему привычен для классического маппинга брашами. Но позволит делать весь уровень моделями или там террайнами.

Так что теперь основная задача: финализация формата уровней.
Потом можно будет заняться освещением.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Cep}I{ 14-05-2020 в 16:18:

Цитата:

Дядя Миша писал:
Так, ну чтожы. Похоже я нашёл идеальный подход для создания каких угодно уровней. Который не устареет в будущем, у которого виз не будет считать часами, на базе которого можно реализовать те самые миллионы полигонов в кадре без особых тормозов. И при всём при этом - он по прежнему привычен для классического маппинга брашами. Но позволит делать весь уровень моделями или там террайнами.

Не имеющий аналогов в мире?

д.Миша прости, но я не мог удержаться

Цитата:

Дядя Миша писал:
Вся Edge Of Forever в камере. Неплохо для дохлой GT640? Раньше я вообще боялся на нее взглянуть отсюда.

Это я так понимаю с освещением скомпилено?

А как все это будет выглядеть на открытых пространствах? Или при мельтешении в кадре куче всяких зомбей, например? Или если графония добавить?
Не просядет ли в итоге фпс и не захлебнется все это дело?

Отправлено Дядя Миша 14-05-2020 в 17:24:

Цитата:

Cep}I{ писал:
Не имеющий аналогов в мире?

Я ж написал откуда была взята основная идея - Doom3.

Цитата:

Cep}I{ писал:
Это я так понимаю с освещением скомпилено?

Нет, освещения еще нет.

Цитата:

Cep}I{ писал:
А как все это будет выглядеть на открытых пространствах? Или при мельтешении в кадре куче всяких зомбей, например? Или если графония добавить?
Не просядет ли в итоге фпс и не захлебнется все это дело?

Основная идея в том, чтобы сам формат не выступал ограничителем скорости, чтобы он сам не тормозил отрисовку. Чтобы производительность зависела от мощности видеокарты, а не каких-то устаревших ограничений.
В этой области сложно придумать что-то новое или оригинальное, но у меня было дополнительное условие, как вы помните - чтобы народ мог кубать под новым ксашем по прежнему. А кто не хочет кубать - пусть делает весь уровень одной моделькой, как в метро или сталкере. Или ландшафтом.
То есть идея в том, чтобы формат органично переваривал разные подходы к левел-дизайну. И естественно всё будет проверяться на практике, как на тяжёлых моделях, так и на тяжёлых брашевых уровнях. Можно будет взять какую-нибудь сцену из уе или юнити и тоже попробовать. Ну это потом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 15-05-2020 в 14:57:

Слева оптимизированная сетка, справа неоптимизированная.

Я специально выбрал такой ракус, потому что во первых эта оптимизация влияет на вертексные цвета, во вторых в ней по идее есть смысл только при использовании полного иссечения всех треугольников по дереву, а не просто расталкивание их по границам арий. Правда в чём смысл этого полного иссечения, я честно говоря так и не понял. Сначала всё разрежем, потом склеим обратно, кое-где рёбра свапнутся. А самая мякотка в том, что без оптимизации этой - фпс даже немного выше
Может в самом D3 это для теневых объемов как-то использовалось, не знаю.
Впрочем есть еще вариант без полного иссечения по дереву, но с оптимизацией. Надо будет еще его опробовать

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 15-05-2020 в 15:23:

Дядя Миша

Цитата:

Мне кажется, или с обведённым ребром что-то не то?

У меня пара вопросов по вот этой конкретной карте в связи с тем, что у меня в ксене похожие юзкейсы будут.

1.Смешивание текстур на полу, песок пререходит в гравий. Насколько я помню, в оригинале симонок там расставлял какие-то браши со спецтекстурой на першинах полигонов. Если у меня такая нора сделана моделью, то возможно-ли этот переход прямо на ней нарисовать, например через цвета вершин?

2. Вот когда такая сложная геометрия, то замощение модели текстурами без швов и растяжений становится нетрививальной задачей. Есть ли готовый способ, что бы как-то автоматизировать это наложение в шойдере, так что бы в целом замостить поверхность лоскутами максимального размера, в местах совемещения разных лоскутов с разными осями зайдействовать какое ни будь смешивание?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 15-05-2020 в 15:35:

thambs очевидно они не склеились.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 15-05-2020 в 21:08:

Цитата:

thambs писал:
расставлял какие-то браши со спецтекстурой на першинах полигонов.

Он сперва пытался дотпродуктом альфу нагенерить, но потом дополнительно этих брашей натолкал в вертексы. Главное народ не ленивый.

Цитата:

thambs писал:
Если у меня такая нора сделана моделью, то возможно-ли этот переход прямо на ней нарисовать, например через цвета вершин?

Я помню эту модель. Думаю вполне. Там много всяких вариантов.

Цитата:

thambs писал:
так что бы в целом замостить поверхность лоскутами максимального размера, в местах совемещения разных лоскутов с разными осями зайдействовать какое ни будь смешивание?

Там несколько вариантов автогенерации текстурных координат, да.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 16-05-2020 в 14:37:

Дядя Миша, а сработает ли такой вариант: в коде кастомного рендера XashXT сделать копию бсп дерева конкретно для отрисовки, а потом его оптимизировать тем подходом какой ты использовал, еще когда только начинал работу над рендерером в XashNT? Ведь поскольку код рендерера целиком можно менять, то вроде бы как не обязательно придерживаться именно бинарной совместимости, и можно немножко доугой вариант дерева впихнуть, с которым оптимизации будут работать. Возможно ли такое реализовать, или же все таки есть какие-то фундаментальные различия, которыми нельзя пренебречь?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 16-05-2020 в 15:20:

Сработать-то оно сработает, но особой пользы не принесёт. Точнее принесёт её меньше чем могло бы. Потому что это же дерево крайне желательно использовать не только для отрисовки, но и для проверки видимости на сервере. Там дикие тормоза просто из-за целой кучи этих накопленных лифов, оно идёт по хеадноде, дерево большое. Т.е. надо и на сервере тоже такое дерево. Ну можно наверное заморочиться, но я этим заниматься точно не буду. Могу код дать, но вас жы в больничку увезут с воспалением мозга.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 17-05-2020 в 02:13:

Цитата:

Дядя Миша писал:
Сработать-то оно сработает, но особой пользы не принесёт. Точнее принесёт её меньше чем могло бы. Потому что это же дерево крайне желательно использовать не только для отрисовки, но и для проверки видимости на сервере. Там дикие тормоза просто из-за целой кучи этих накопленных лифов, оно идёт по хеадноде, дерево большое. Т.е. надо и на сервере тоже такое дерево. Ну можно наверное заморочиться, но я этим заниматься точно не буду. Могу код дать, но вас жы в больничку увезут с воспалением мозга.

Как я понимаю, со стороны сервера это отразится оверхедом на CPU? Это конечно не оптимально, как оно могло бы быть, но всё же меньшее из зол. Ну во всяком случае я бы попробовал новое дерево прикрутить, будет хорошо если поделишься кодом.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 17-05-2020 в 07:37:

Цитата:

SNMetamorph писал:
Как я понимаю, со стороны сервера это отразится оверхедом на CPU?

Что именно отразится?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 17-05-2020 в 08:09:

Цитата:

Дядя Миша писал:
Что именно отразится?

Цитата:

Дядя Миша писал:
Потому что это же дерево крайне желательно использовать не только для отрисовки, но и для проверки видимости на сервере. Там дикие тормоза просто из-за целой кучи этих накопленных лифов, оно идёт по хеадноде, дерево большое. Т.е. надо и на сервере тоже такое дерево.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 17-05-2020 в 09:14:

Так я открытым текстом говорю - тормоза на сервере, что тут понимать-то?
Ты на рыбалку? Да нет, я на рыбалку.

Добавлено 17-05-2020 в 12:09:

Я уже писал, но повторюсь. Вот возьмем тот же сипульчер. Пять тысяч энтить. Дерево со всеми оптимизациями - примерно 11 тысяч нодов и лифов.
Сервер обрабатывает каждую энтить. Ищет лифы, из которых её видно. В кваке статичный массив для каждой энтити на 16 лифов, в халфе 48. Но из-за детальных нодов, там получается зачастую, что этих самых лифов на каждую энтить приходится от 50 до 400. А как устроен механизм определения видимости, если кол-во лифов превышено? Идёт по хеадноде рекурсия. Для дерева в 11 тысяч нодов. И так - для каждой видимой энтити из этих пяти тысяч. Там можно вообще рендеринг кадра отключить - фпс не подымется выше 150. И это мы не учитываем физику, к примеру, почти всё время сжирает это определение видимости. То что должно помогать в ускорении превратилось в ключевой тормоз - слишком подробное дерево.

Добавлено 17-05-2020 в 12:14:

ЗЫ. Нагнал я вам. 10 тысяч лифов - это для кутри, где детальные ноды заведомо выброшены из дерева. В халфовском\кушном формате, там за 65 тысяч нодов и лифов. Из-за чего кстати её не в состоянии загрузить Darkplaces. Он же "для ускорения" распаковывает виздату.
Ну вот и давайте посчитаем. 65000 х 65000 = 4225000000 поделить на 8, получается 503 мегабайта бесполезно занятой памяти. Но в сипульчере не ровно 65к лифов, там больше. Корочи оно вылетает с Out of memory, причём это не исправить заменой short на int. Там в архитектуре интересное допущение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 17-05-2020 в 09:32:

Ужосы какие

__________________
-Brain is dead-

Отправлено Дядя Миша 18-05-2020 в 20:08:

Наконец руки дошли и до портального тумана. В ку3 туман был видимо прикручен в самый последний момент, поэтому технология имела ряд оговорок и была очень неудобна в использовании. Во первый туман надо было задавать строго аксиальным брашем, во вторых у него могла быть только одна видимая сторона. Конечно эту информацию о тумане надо как-то сохранять в VBO, что уже само по себе не фонтан. Ради какого-то тумана занимать столько места в вертексе. Переход на новую технологию даёт более генеричную информацию, по сути мы вообще не храним туман явным образом, только портальный шейдер, если он конечно не был помечен как невидимый. Единственное отличие от кутришного тумана для дизайнера - видимую сторону надо всегда задавать явным образом. Потому что это всё же портал, а не иллюзия объема. На скринах не туман, как может показаться, а дебажная визуализация порталов для тумана (разумеется эту информацию можно будет использовать и для видимости и для AI). Проволка показывает, что плоскость портала разрезала всё - и уровень и модельку на стене. Кутришный туман резал только брашы и немножко патчи, но дизайнеры знали, что патч он мог с лёгкостью превратить в кусок говна, поэтому старались не вкладывать их в туман

Добавлено 18-05-2020 в 23:08:

Ну чтож, имплементация тумана прошла успешно. Вообще на этих порталах можно столько интересных штук придумать. Ну зато код избавился от спецификации этого тумана. Теперь туман реализуется при помощи видимого ареапортала с настройками тумана. Надо еще будет затестить комнатку с множественными выходами.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 18-05-2020 в 20:36:

Дядя Миша
Область со впуклостями возможно заполнить, или она должна быть конвексной?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 18-05-2020 в 21:10:

Когда доделаю - будет можно. Туман очень классное средство визуализации заполнения областей видимости.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 19-05-2020 в 12:57:

Очень предварительный тест портального тумана
Волатила так не умеет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-05-2020 в 13:05:

Обрезается он как то резко

Отправлено XaeroX 19-05-2020 в 14:35:

Дядя Миша
Почему не умеет? Туман как туман. Такой даже в хлфх 0.6 был, я в ретро-скриншотах показывал.

__________________

Отправлено Дядя Миша 19-05-2020 в 15:29:

Цитата:

FiEctro писал:
Обрезается он как то резко

ну так портальный же. Портал его и обрезает, в этом и смысл.

Цитата:

XaeroX писал:
Почему не умеет? Туман как туман

ну вот конкретно эта ария выпуклая. А если более сложная форма?
Или несколько входов и выходов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 19-05-2020 в 16:44:

Дядя Миша
Покажи, пожалуйста, скриншот, как выглядит туман, если несколько входов в этот цилиндр.

__________________

Отправлено ncuxonaT 19-05-2020 в 16:57:

и если сам цилиндр туман

Отправлено Дядя Миша 19-05-2020 в 16:58:

XaeroX ну как доделаю обязательно покажу.

Добавлено 19-05-2020 в 19:58:

Цитата:

ncuxonaT писал:
и если сам цилиндр туман

Туман очевидно не может быть цилиндром. Тумана-то вообще нет. Но можно сделать затуманенный лайт, ну это попожжы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 19-05-2020 в 17:43:

туман должен быть обязательно ограничен чем-то как вода в банке?

Отправлено XaeroX 19-05-2020 в 17:47:

Дядя Миша
Что значит, тумана нет? Туман затуманивает то, что внутри или позади. Ему не обязательно иметь стенки, по идее.

__________________

Отправлено Дядя Миша 19-05-2020 в 18:06:

Цитата:

Crystallize писал:
туман должен быть обязательно ограничен чем-то как вода в банке?

тумана нет.

Цитата:

XaeroX писал:
Ему не обязательно иметь стенки, по идее.

мне страшно представить что никто из вас не понимает, как именно работает туман, поэтому я упорно гоню эту мысль прочь.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 19-05-2020 в 18:08:

Дядя Миша
Правильно делаешь, гони такие мысли. Я прекрасно понимаю, как "работает" туман. Поэтому и пытаюсь тебя наставить на правильный путь, вместо вот этого отрицалова "коронавирус не опасен, земля плоская, тумана нет".

__________________

Отправлено Дядя Миша 19-05-2020 в 18:12:

Цитата:

XaeroX писал:
Туман затуманивает то, что внутри или позади

Тогда как это расценивать? А что если наш Фиэктра...

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 19-05-2020 в 18:16:

Дядя Миша
В данном случае я говорил не о ку3шном тумане, который рисуется на объектах и соответственно, не может затуманить то, что не в объёме, а о реальном тумане, как в природе. IRL туман это капли жидкости, которые рассеивают свет, и они могут занимать какой-то объём. Даже цилиндр - правда, не очень долго, т.к. туман может растекаться, как жидкость, что нетрудно наблюдать в природе, например, в горах по утрам.

Такой туман можно сделать в скринспейсе, в волатиле тикет давно висит, но я не добрался, т.к. пока для нужд PW хватает обычного ку3шного.

__________________

Отправлено Crystallize 19-05-2020 в 18:23:

Цитата:

Дядя Миша писал:
тумана нет.

Мы с тобой оба знаем о чём разговор, зачем цепляться к словам?

Отправлено Дядя Миша 19-05-2020 в 19:44:

Цитата:

XaeroX писал:
не о ку3шном тумане, который рисуется на объектах и соответственно, не может затуманить то, что не в объёме

Вообще говоря абсолютно любой туман, кроме трёхмерного затуманить ничего не может, но трёхмерный туман существует только вместе с источником света, поэтому и я сказал

Цитата:

Дядя Миша писал:
Тумана-то вообще нет. Но можно сделать затуманенный лайт, ну это попожжы.

Вы разумеется это пропустили мимо ухов и начали упражняться.

Цитата:

XaeroX писал:
Такой туман можно сделать в скринспейсе

Ты опять похоже не понял. Форму он откуда возьмёт?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 19-05-2020 в 19:54:

Цитата:

Дядя Миша писал:
Форму он откуда возьмёт

Из браша, например.

__________________

Отправлено Дядя Миша 19-05-2020 в 20:32:

Ну это уже не будет туман в форме цилиндра, это будет затуманенный браш, а такой туман на поверхности всегда выглядит как говно и непохоже на туман. Ладно проехали.

Собсно скриншоты, для понимания сути портального рендеринга:
Area 0:

Area 1:

Final Result

Можно так же и физику привязать к сектору, но пока такая задача не стоит.

Добавлено 19-05-2020 в 23:32:

На входе в домик стоит areaportal браш. Ну я думаю, это и так понятно.

Народ мне долгие годы доказывал что он хочет и может расставлять разные там хинты для оптимизации, так что я полагаю это не сильная заморочка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-05-2020 в 21:29:

А можно как в дуумоподобных движках умещать большие пространства внутри маленьких?

Отправлено Дядя Миша 19-05-2020 в 21:47:

ну вот это и достигается отключением тех или иных порталов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-05-2020 в 21:53:

А как быть с объектами внутри?

Отправлено XaeroX 19-05-2020 в 22:28:

Дядя Миша
Всё это уже было в движке 1998 года (Unreal), порталы эти, комнаты в комнате. Даже у Борескова (кажется) была книжка "как написать портальный рендерер". Ты бы лучше что-нибудь эдакое показал, вот та же комната с туманом, где есть несколько точек входа в него, и всё это правильно работает.

__________________

Отправлено Aynekko 20-05-2020 в 06:43:

Сделали бы trigger_fog брашевый, тем более триггеры не влияют на утечку при компиле - просто поместить нужную комнату в браш от двери до двери - вот и туман

Отправлено Дядя Миша 20-05-2020 в 10:05:

Цитата:

FiEctro писал:
А как быть с объектами внутри?

ну так объекты всегда знают в какой арии они находятся, это же очевидно. Та же функция, которая в квейке возвращала номер текущего лифа, возвращает и номер арии.

Цитата:

XaeroX писал:
вот та же комната с туманом, где есть несколько точек входа в него, и всё это правильно работает.

да покажу, но не всё же сразу. Я вам скажу по секрету, мне этот туман до одного места на самом деле. Но им очень удобно визуализировать portal flow.

Цитата:

Aynekko писал:
просто поместить нужную комнату в браш от двери до двери - вот и туман

ну ты не сделаешь этот триггер точно по форме комнаты, а если надо несколько комнат затуманить? Это всё очень неудобно. К тому же повторюсь, туман тут просто как КДПВ для читателей. В порталы можно и воду наливать и всякие там партиклевые газы, это гораздо удобнее чем проверять те же контентсы, потому что контентсы влияют на физику игрока.
А здесь можно будет задавать зоны, как в тех же старых унреалах, не знаю, осталось ли это свойство в новых.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 20-05-2020 в 13:24:

Цитата:

Дядя Миша писал:
ну ты не сделаешь этот триггер точно по форме комнаты

~~Ты меня недооцениваешь~~
А мне и не нужно делать его по форме комнаты. Если триггер находится вне карты, так и черт с ним. Пусть рисует.
Вот у меня например в моде нет аптечек, а есть регенерация хп. Так у меня просто вся карта одним кубом trigger_hurt обтянута и все. И с туманом так же можно.

Отправлено Дядя Миша 20-05-2020 в 13:25:

Ну вот трёхдырковый туман. Единственный момент - я поленился проверить чему равна его плоскость, какому из трёх порталов, по хорошему у такого тумана планес вообще надо занулять, но они типа в одну сторону смотрят, так что фиг с ними уже, потом занулю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 20-05-2020 в 13:29:

А можно таким образом половину коробки сделать с туманом, а вторую нет?

Отправлено KiQ 20-05-2020 в 13:51:

Цитата:

Aynekko писал:
вся карта одним кубом trigger_hurt обтянута

С отрицательным значением шоле?

Мсье знает...

__________________
-Brain is dead-

Отправлено Aynekko 20-05-2020 в 14:02:

Цитата:

KiQ писал:
С отрицательным значением шоле? Мсье знает...

Ага, ну как говорится, чем могём

Отправлено ncuxonaT 20-05-2020 в 14:04:

Чому туман в "а" плотнее, чем в "b"?

Отправлено Дядя Миша 20-05-2020 в 14:37:

Цитата:

FiEctro писал:
А можно таким образом половину коробки сделать с туманом, а вторую нет?

ну ежели её посирёдке разделить еще одним ареапорталом, то можно.
Тут главное что - соблюдать замкнутость пространства, иначе туман утичёт наружу на всю карту

Цитата:

Aynekko писал:
Так у меня просто вся карта одним кубом trigger_hurt обтянута и все. И с туманом так же можно.

Так глобальный туман наоборот сделать очень легко.

Цитата:

ncuxonaT писал:
Чому туман в "а" плотнее, чем в "b"?

А выше прочитать?

Добавлено 20-05-2020 в 17:35:

Кстати, я не говорил, но в новом ксаше можно иметь на карте сколько угодно небес и скайбоксов разных. И можно туманить скай-порталы.
Впрочем насчёт затуманивания скапорталов - это мне только сейчас пришло в голову.

Добавлено 20-05-2020 в 17:37:

Да всё это ерунда по сути, главное сейчас - построить портальный рендерер. А картинки это так, чёб вы камментили.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Flash 20-05-2020 в 16:59:

А как насчёт гуя? С инвентарём и записками. И кастомными эхфектами на весь экран, чб, инверсия, *любая подгруженная картинка\анимация*.

__________________
Tiger! Tiger! burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?

Отправлено nemyax 20-05-2020 в 18:20:

Цитата:

Aynekko писал:
Ага, ну как говорится, чем могём

А если тебе понадобится внутри большого маленький с положительным хуртом? Всё поломается?

Отправлено Aynekko 20-05-2020 в 18:52:

Цитата:

nemyax писал:
Всё поломается?

Не, они друг друга взаимоисключают. Ну грубо говоря, если ты находишься в большом хурте который прибавляет 10 хп/сек и попал в маленький, который ранит на 20хп/сек, то будешь получать 10 хп урона примерно.

Отправлено thambs 20-05-2020 в 19:09:

Дядя Миша
Как настройки арей задаются?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 20-05-2020 в 19:18:

thambs какие именно настройки? У арий нет никаких настроек, у них только номер. Ария это больше виртуальное понятие, она не существует, так же, как и туман.

Добавлено 20-05-2020 в 22:18:

Я вот думаю, может их в сектора переимновать. Будет ассоциация, не с хэви металлом, а с панк-роком.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 20-05-2020 в 19:21:

Дядя Миша
Да, сектора термин знакомый и рассовый.

Цитата:

Ария это больше виртуальное понятие, она не существует, так же, как и туман

Ну вот этот несуществующий туман к несуществующей арии ты в этом вашем кварке как привязываешь?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 20-05-2020 в 19:31:

Цитата:

Дядя Миша писал:
Ария это больше виртуальное понятие, она не существует, так же, как и туман.

Ария это область пространства, заключённая между ареапорталами. Если на карте нет ареапорталов, то вся карта представляет собой одну арею.

__________________

Отправлено Дядя Миша 20-05-2020 в 19:38:

Цитата:

thambs писал:
Ну вот этот несуществующий туман к несуществующей арии ты в этом вашем кварке как привязываешь?

ну я ареапорталу даю совмещённый материал, который одновременно и туман и ареапортал. Но это я так, скорее для теста сделал.

Цитата:

XaeroX писал:
Если на карте нет ареапорталов, то вся карта представляет собой одну арею.

Необязательно. Ария - это замкнутое пространство с энтитями. Допустим у нас есть две комнатки, не связанные между собой. Но зато мы можем телепортироваться туда и обратно. Это тоже две арии.
ЗЫ. ария это же площадь в переводе, но это ИМХО неправильно, площадь в моём представлении как-то больше двухмерная, незамкнутая.

Добавлено 20-05-2020 в 22:37:

ЗЗЫ. забавно но всё это мне очень напоминает структуру уровней первого дуума за единственной поправкой - там сектора обязательно разбивались на конвексные субсектора, которые суть лифы.

Добавлено 20-05-2020 в 22:38:

Так, ну ладно. Теперь мне надо раскромсанные кусочки порталов собрать обратно воедино.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 20-05-2020 в 19:39:

Цитата:

Дядя Миша писал:
Допустим у нас есть две комнатки, не связанные между собой. Но зато мы можем телепортироваться туда и обратно. Это тоже две арии.

Да, ты прав, совсем забыл про такую ситуацию.

__________________

Отправлено KiQ 20-05-2020 в 19:56:

Цитата:

Дядя Миша писал:
Я вот думаю, может их в сектора переимновать. Будет ассоциация, не с хэви металлом, а с панк-роком.

Можно переименовать в зоны, будет ассоциация со сталкиром

__________________
-Brain is dead-

Отправлено Дядя Миша 20-05-2020 в 20:41:

Склеил порталы обратно, туманчег стал более корректным. Но повторюсь, там жы нет какого-то специального механизма, который бы выбирал при загрузке ближайшую плоскость тумана для вертекса. Сделать несложно, но как-нибудь потом.

Добавлено 20-05-2020 в 23:41:

Сейчас он фактически приклеился к средней плоскости. А надо каждому вертексу выбрать, какая плоскость для него ближе. Впрочем кутришный туман - повертексный, табличный, его надо сделать попиксельным, но повторюсь, всё это дело десятое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 20-05-2020 в 20:43:

Цитата:

Дядя Миша писал:
ЗЫ. ария это же площадь в переводе, но это ИМХО неправильно

Ну так сектор, то бишь огрызок круга, тогда ещё хуже. Может, partition или domain?

Отправлено thambs 20-05-2020 в 20:52:

nemyax
Ну не, не обязательно, достаточно многозначный термин. Вот например есть Sector C, Sector D, Sector B, а так же Sector A, Sector E и Sector F.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 20-05-2020 в 21:09:

И правый сектор еще

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 21-05-2020 в 11:13:

Ну вот объемный множественный туман в рамках одной арии. Выглядит конечно диковато, особенно извнутри, но это потому, что код был изначально рассчитан на одну видимую плоскость, надо переписать GLSL.

Добавлено 21-05-2020 в 14:10:

Добавлено 21-05-2020 в 14:09:

Ну вот туман, предложенный ФиЭктрой, один выход заткнут красным порталом-туманом, второй жолтым.

При кутришном повертексном наложении, очевидно, лучше оно выглядеть не будет. Впрочем это не главное. Главное то, что корректно отрабатывает видимость порталов и кол-во арий поддаётся контролю. При дуумтришном подходе была велика вероятность, что если вот такую штуку заткнуть двумя порталами, то внутри она еще поделится на две арии, т.е. это вообще не то, чего бы ожидал дизайнер.

Добавлено 21-05-2020 в 14:13:

Так это еще полбеды, если бы она поделилась чётко посередине. Но она же делится "как нода ляжет". Но кстати говоря, это подход налагает и дополнительные ограничения - теперь кроме обычной утечки есть и утечка ареапорталов. И их тоже надо подгонять вплотную, чтоб никакого зазора не было. Впрочем, я думаю это всё равно лучше - один раз подогнать, чем каждый раз часами ждать пока отработает виз.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-05-2020 в 12:50:

Отлично! А покажи ту фишку с отключаемыми зонами, для имитации комнаты "большей внутри чем снаружи". Ещё интересно, а вектор гравитации в них изменять можно?

Вот видос для вдохновения, хотя здесь оно фейковое, использует самые обычные порталы и копии комнат.

Отправлено KiQ 21-05-2020 в 14:19:

FiEctro скидывать ДМ-у видео для вдохновения на юнете - моветон, чтоли, не знаю...

__________________
-Brain is dead-

Отправлено Дядя Миша 21-05-2020 в 14:42:

Цитата:

FiEctro писал:
А покажи ту фишку с отключаемыми зонами, для имитации комнаты "большей внутри чем снаружи"

Хех, да етож фейк по сути. Вас дурят, а вы видётесь ) Тут в чём смысл всей этой замуты - у нас совершенно точно известен ректангл сквозь который видно еще одну комнату. Значит на место одной мы например можем подставить другую. Кстати это и в сорсе тоже было. В той же Stanley Parable активно юзалось.

Цитата:

FiEctro писал:
Ещё интересно, а вектор гравитации в них изменять можно?

Нам самое главное - знать номер зоны, для которой применяются кастомные настройки, а так можно делать всё что угодно. Т.е. большинство задач - отделить одно от другого.

Добавлено 21-05-2020 в 17:42:

У этих порталов единственное ограничение - с ними не умеет работать ни один сторонний физ. двиг, но мне это некритично, т.к. я и не планировал их использовать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 21-05-2020 в 15:33:

Дядя Миша таки выпиливается поддержка физикса? Жаль, а я кокраз GTX1650 прикупил

__________________
-Brain is dead-

Отправлено Дядя Миша 21-05-2020 в 15:52:

Я никогда и не говорил, что планирую использовать сторонний физический движок в XashNT. Что значит выпиливается?

Добавлено 21-05-2020 в 18:52:

Цитата:

KiQ писал:
Жаль, а я кокраз GTX1650 прикупил

и какая тут связь?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 21-05-2020 в 15:58:

Цитата:

Дядя Миша писал:
и какая тут связь?

Физикс нативный же

Цитата:

Дядя Миша писал:
Я никогда и не говорил, что планирую использовать сторонний физический движок в XashNT

Ну я в целом про PhysicsInterface

__________________
-Brain is dead-

Отправлено Дядя Миша 21-05-2020 в 16:59:

Цитата:

KiQ писал:
Физикс нативный же

чем он нативный?

Не, ну ты всеръез веришь что физику твёрдых тел можно на GPU обсчитывать? Туда переносят всякую хрень, партиклы, занавески, надувных коров, чтоб они в реках не тонули. Вообщем всё то, что не требует обратной связи с игроком.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 22-05-2020 в 07:31:

В сорсе оказывается допущен ужастный баг, из-за которого вся эта затея с ареапорталами смысла почти не имеет. Отсюда же растут и многочисленные проблемы с разбиением воды, которая то исчезает, то появляется кусками, ну знаете. Дело в том, что ареапортал тоже разбивает геометрию штатно, подобно обычной секущей плоскости, но фишка-то в том, что он не должен этого делать случайным образом! А в сорсе у ареапортал-брашей нет абсолютно никакого приоритета в разбиении. Должно быть так: сперва дерево разбивается в штатном режиме. Потом, когда подходящих плоскостей уже не осталось - используется финальная секущая ареапортала. Только в этом случае сектора нарезаются правильно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 22-05-2020 в 08:29:

Дядя Миша это может быть причиной недохождения директа от солнца до некоторых брашей которые находятся в прямой видимости?

Отправлено Дядя Миша 22-05-2020 в 11:30:

Crystallize а там ареапорталы есть?

Добавлено 22-05-2020 в 12:56:

Вообще с этими ареапорталами прямо целое искусство, не так-то просто их расставлять, да. Ну ничего, будет вам новый скилл.

Добавлено 22-05-2020 в 14:30:

Забавная вещь выяснилась. Оказывается кластер-порталы для ботов идеально годятся на роль ареапорталов. А вот хинты - не очень.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 22-05-2020 в 16:13:

Дядя Миша да, в домике на coast03 окна и двери затянуты ареапорталами, и солнце почему-то через окна не светит.

Отправлено Дядя Миша 22-05-2020 в 17:20:

Неисключено. да

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 22-05-2020 в 17:46:

Цитата:

кластер-порталы

Штоэта?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 22-05-2020 в 18:07:

Да это для ботоф какая-то подсказка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 22-05-2020 в 18:17:

Цитата:

Дядя Миша писал:
Забавная вещь выяснилась. Оказывается кластер-порталы для ботов идеально годятся на роль ареапорталов. А вот хинты - не очень.

Тоже из-за приоритета в разбиениях или совсем по другой причине?

Отправлено Дядя Миша 22-05-2020 в 19:03:

Crystallize сами брашы на уже готовых картах расставлены как надо. Я про это.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 22-05-2020 в 19:13:

Цитата:

Дядя Миша писал:
Да это для ботоф какая-то подсказка.

Не совсем. Это для навмеша. Там очень много арей создаётся, и граф доступности ареи из ареи разрастается сильно. Поэтому ареи собираются в кластеры, а кластер-порталы их делят (обычно в коридорах и прочих узких местах). Между кластерами свой отдельный граф досягаемости, который получается сильно меньше.
Может быть, я однажды допишу свой цикл статей по устройству AAS.

__________________

Отправлено Дядя Миша 23-05-2020 в 08:00:

Похоже дуумтришные оптимизации треугольников придётся выбросить.
Ну или полностью переписать, они абсолютно не годятся для моих задач.
И вот почему - оптимизация происходит в 2д пространстве, т.е. на общей плоскости. Ну нетрудно догадаться, что такое справедливо только для брашей. А для вставленных моделей он просто формирует десятки тысяч цепочек с одним треугольником внутри. Причём уже просто на копирование этих цепочек уходит адски много времени без цели и смысла. В самом D3 это понимали, поэтому перестали включать статические модели в общую геометрию на этапе компиляции - их рендерер грузил, что тоже небыстро.
Но для параметрических поверхностей специализированная оптимизация справляется куда лучше общей. Для брашей это соответственно CSG, Merge и ClipSidesIntoTree. Для патчей RemoveLinearColumnsRows и StitchPatches.
Для моделей - простая индексация вертексов. Ну и собсно всё, переставлять эджы там нет никакого смысла, тем более я заметил, что после этой оптимизации FPS наоборот даже немного падает. Точно так же нет и смысла резать треугольники строго по дереву для full carve - это уже CSG делает. Так что от оптимизатора требуется единственная вещь - рассортировать треугольники по нужным ариям, разрезая его, когда он попадает точно на границу двух арий.
Вот так забавно получается, что код из D3 использоваться не будет - только некоторые идеи.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 23-05-2020 в 12:45:

Цитата:

Дядя Миша писал:
Похоже дуумтришные оптимизации треугольников придётся выбросить.

Ну это только модельки типа грешников на стенке, так-то концепция формата не замедляющего отрисовку, осталась?

Отправлено Дядя Миша 23-05-2020 в 13:28:

Концепция в том, чтобы рисовать сразу весь сектор целиком. В секторе мешы отсортированы по материалам. Сколько материалов - столько и мешей.
То есть получается любопытная ситуация в кадре треугольников в десятки раз больше, а фпс - выше. Но разбиение на сектора выполняет левел-дизайнер. Я в этом проблемы абсолютно не вижу - ареапортальный браш ставится один раз в дверном проёме и маппер точно знает, что в этом месте карта будет поделена на два сектора, в отличие от хинта, который может и не помочь. Причём он бы скорее всего и так бы туда этот хинт залепил, ну просто другой текстурой покрасит. Я вот вообще заметил, что народ очень любит оптимизировать вручную. Ну так надо дать им в этом больше возможности. Всего каких-то пять лет назад я считал совершенно иначе.
Ну вот вы видите Волатилу, построенную на этих принципах.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 23-05-2020 в 13:34:

Цитата:

Я вот вообще заметил, что народ очень любит оптимизировать вручную.

Из-за предсказуемости. Кстати, подумалось тут, а для этих секторов какие-то предвычисления объёма/размеров/материалов на этапе коптиляции можно проводить, например, что бы автоматически привязать к ним roomtype?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 23-05-2020 в 15:31:

Цитата:

Дядя Миша писал:
Я вот вообще заметил, что народ очень любит оптимизировать вручную.

Ну так. Впрочем, лишь бы кубать не пришлось.

Отправлено Дядя Миша 23-05-2020 в 15:35:

thambs вообще без проблем.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 24-05-2020 в 10:50:

Вот какую интересную фигню я заметил. Использование nvtristrip УМЕНЬШАЕТ фпс, вместо того, чтобы его увеличивать.

Пробовал менять размер кэша, играться с параметрами, итог всегда один. Простая индексация вертексов даёт лучший результат, нежели индексы, пропущенные через nvstristrip.
Вот примерчег:

Слева стриптнутая геометрия (рисуется через GL_TRIANGLE_STRIP), справа обычный лист, рисуется через GL_TRIANGLES. Если кто не понял, поясню, strip-режим позволяет экономить индексы, в отличие от листа. Правда это же осложняет и простейшие операции, поэтому на правой картинке поликаунт неверный, он совпадает с левой, но его нельзя посчитать, просто поделив индексы на 3. Поэтому он там неверный. То есть вот такая ситуация.
Может быть дело в том, что я использую glMultiDrawElementsBaseVertex, а для классических режимов будет прирост? Интересное кино.

Добавлено 24-05-2020 в 13:50:

Поигрался с SetCacheSize, наилучший результат получается при подстановке значения 1024 - фпс возрастает до 650. Но всё равно он меньше чем без использования NvTriStrip. И да, с таким размером кэша кратно увеличивается время работы. Без него карта собирается 9 секунд, а с ним - минуту.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 24-05-2020 в 15:49:

Дядя Миша возможно зависит от итераций обхода вертексов, при стрипе еще операция возвращения в исходный вертекс или типа того

__________________
-Brain is dead-

Отправлено Дядя Миша 24-05-2020 в 16:09:

Просто все эти оптимизаторы были актуальны в эпоху третьих гефорсов. Их давно пора сдать на свалку истории. Современному железу эти пляски не нужны.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 24-05-2020 в 17:18:

Дядя Миша на овердроу не проверял? может, nvtristrip делает такие стрипы, что овердроу сильно большой.

Отправлено Дядя Миша 24-05-2020 в 17:50:

ncuxonaT откуда там овердраву взяться? Ты уверен что правильно понимаешь значение этого термина?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 24-05-2020 в 18:12:

Дядя Миша вроде бы уверен.

Вот скрины из презентации оптимизатора мешей AMD Tootle. Сортировкой кластеров они здорово понижают овердроу.
У тебя горы не выпуклые, овердроу по-любому присутствует.

Отправлено Дядя Миша 24-05-2020 в 21:11:

Для включённого Z-Test понятия overdraw бессмысленно.
Это если дракончик полупрозрачный и замкнутый, там да. Наблюдатель не будет его наблюдать извнутри. А что ты с горами сделаешь?

Добавлено 25-05-2020 в 00:11:

И вообще у меня к AMD-шным разработкам крайнее недоверие. Я еще не забыл ихний TrueForm.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 24-05-2020 в 21:18:

Цитата:

Дядя Миша писал:
Для включённого Z-Test понятия overdraw бессмысленно.

Ты, верно, шутишь? Если порядок треугольников такой, что сначала рисуются дальние, а потом ближние, то одни и те же пиксели каждый раз перерисовываются.

Отправлено Дядя Миша 25-05-2020 в 05:48:

Цитата:

ncuxonaT писал:
то одни и те же пиксели каждый раз перерисовываются.

Мда

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 25-05-2020 в 06:37:

Дядя Миша ты бы хоть отвечал так чтобы у вас была дискуссия которую можно читать, а не "ой, всё!", нам же тоже интересно

Отправлено Дядя Миша 25-05-2020 в 07:01:

Отремонтировал декали. В декалях ведь главное что? Чтобы они накладывались и на мир и на энтить одновременно. В халфе меня это всегда бесило.

У этих декалей есть еще один плюс - они переживают сейв\рестор. Ну потому что наносятся компилятором. Это скажем так, нечто вроде infodecal, но если без имени для активации - очевидно их может нанести сам компилятор. Ну примерно как лампочки без имени. Тот же принцип.
Алгоритм нанесения совпадает, так что разобрать какие декали нанёс компилятор, а какие движок невозможно.

Добавлено 25-05-2020 в 09:39:

А. Им теперь углы указывать обязательно, в отличие от халфовских. Ну то есть они конечно пытаются найти средневзвешенную нормаль, но на полисупе порой такая ерунда получается.

Добавлено 25-05-2020 в 10:00:

Поглядел я этот AMD Tootle. В комплекте идут замкнутые мешы, ну естественно. Как предлагается отремонтировать уровень, когда игрок находится внутри меша и может смотреть на треугольники в любом порядке? Вот в кваке с софтрендером, там дерево их правильно сортировало с любой точки зрения. Поэтому там был нулевой овердрав.
А сейчас по факту их дешевле одним дроколом нарисовать, чем пытаться отсортировать по кирпичику. Хотя конечно никто не запрещает.

Добавлено 25-05-2020 в 10:01:

А, он еще и с рейтрейсером, ну вообще чудесно. Это сразу втопку. Даже объяснять лень.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 25-05-2020 в 10:09:

Цитата:

Дядя Миша писал:
А сейчас по факту их дешевле одним дроколом нарисовать

Так они и рисуют одним, только индексы предварительно сортируют. Короче сравнивать овердроу со стрипами и без них ты отказываешься, так?

Отправлено Дядя Миша 25-05-2020 в 11:19:

Овердрав солидных объектов смысла не имеет. Да ты почитай тему на геймдеве, я создал вчера. Там народ пишет, что давно уже разницы нет.
Есть и более ранние темы с аналогичным выводом.
Я не вижу смысла в этой сортировке в первую очередь потому, что она значительно замедлит компиляцию, практически ничего не дав взамен.
Потому что, если я рисовал скажем 20к, а нарисую 40к - и то фпс почти не просядет, а ты хочешь чтобы от этой оптимизации был эффект?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 25-05-2020 в 11:49:

Цитата:

Дядя Миша писал:
Овердрав солидных объектов смысла не имеет.

Не понимаю, почему ты так считаешь. Можешь включить блендинг (не выключая тест глубины) и посмотреть, сколько раз одни и те же места перерисовываются.

Цитата:

Дядя Миша писал:
Потому что, если я рисовал скажем 20к, а нарисую 40к - и то фпс почти не просядет

Я думал, мы пытаемся понять, почему от стрипов фпс падает, хотя должен расти.

Отправлено Дядя Миша 25-05-2020 в 12:28:

Цитата:

ncuxonaT писал:
Я думал, мы пытаемся понять, почему от стрипов фпс падает, хотя должен расти.

он и растёт, если разбить меш на маленькие кусочки, а потом их стрипифицировать. Само утверждение, что при стрипификации фпс непременно должен вырасти - ложное. Это зависит от железа.

Добавлено 25-05-2020 в 15:28:

Я слишком хорошо помню времена, когда смена поколений железа на корню убивала все оптимизации. Скажем, до восьмого поколения жирафов, подход используемый в ку3 - рисовать понемногу, трансформировать на CPU, был выгоднее. И даже DrawArrays шустро работал. На восьмом жирафе это резко затормозилось. Опять таки раньше GPU были векторные, теперь они скалярные. Я помню когда в середине нулевых все поголовно увлекались mmx_mempcy который работал быстрее кртшного. Вышел Core2Duo и поставил ситуацию с ног на голову. Но даже если и допустить, что от стрипификации по прежнему должна быть польза. Ну вот навскидку:
1. рисовать выгоднее большими батчами, очевидно.
2. большие батчи тристрип обрабатывает очень долго
3. после этой обработки фпс наоборот падает
Что тут дальше проверять? Тебе хорошо, у тебя не стоит никаких глобальных задач, ты можешь и месяц потратить на эти исследования.
Ну так вперёд, если интересно. Потом расскажешь.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 25-05-2020 в 18:45:

С видимой геометрией пока что всё, теперь колоизация.
Какие варианты есть вообще в принципе?
Самый очевидный - коллизия по сурфейсам. Этого я пока что делать не хочу. С одной стороны оно не требует какой-то предварительной подготовки геометрии, с другой подобная коллизия не слишком надёжна и тяжела в рассчётах. Но конечно можно будет потом попробовать и такую коллизию.

Городить какие-то специальные ускоряющие структуры, BVH, BIH или Kd-tree, я пока что тоже не планирую. Обойдемся уже имеющимся BSP. Опять-таки потом можно будет сравнить, благо BSP самый сложный из всех в построении. Остальные деревья можно строить налиту, резать ничего не надо. Ну и в качестве примитивов для коллизии я планирую по прежнему использовать брашы. Тот баг с залипанием у нечётных сторон я успешно исправил, но дело даже не в этом. У брашей есть важные плюсы:
1. конвексные структуры быстры в детектировании пересечений
2. параметрические конвексные структуры не только быстры, но еще и абсолютно надёжны даже при одинарной точности плавающей.
3. пересечение с плоскостью - самый простой, быстрый и надёжный тип проверки столкновения.
4. у брашей, кроме всего прочего есть еще и такой замечательный параметр как объем. Конечно для конвексных тел его можно использовать в любом случае, но это как-то непринято и не всегда быстро. А определение столкновения с брашем автоматически вычисляет подобные вещи, что очень удобно. Опять же брашами легко задавать объемы среды.

То есть мне в данной ситуации надо решить две задачки: построить коллизию для произвольных патчей и для произвольных моделей.
На данный момент есть как специальные, так и общие кейсы. Основная цель - минимизация кол-ва брашей. Способов аппроксимации коллизии брашами существует несколько штук, но об этом - в следующий раз.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KorteZZ 26-05-2020 в 09:31:

Тут в ксашмоде такая штука, что trigger_hurt с отрицательным уроном лечит игрока лишь до ста процентов, а func_door с отрицательным уроном - лечит до бесконечности. Также такая штука, что сигнал от кнопки игрока через keycatcher и сигнал от триггер мультипла отличаются и например, фанк_пуш реагирует на них по разному. Такие мелочи сильно влияют на логику и могут вовсе сломать её, если их не знать.

Будут ли подобные вещи исправлены в NT?

__________________

Killing Floor: Horzine Outbreak

Отправлено Дядя Миша 26-05-2020 в 11:23:

Подобные вещи к движку отношения не имеют

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 26-05-2020 в 11:31:

>> Ну и в качестве примитивов для коллизии я планирую по прежнему использовать брашы.

т.е. об уровнях модельками можно позабыть?

Отправлено Crystallize 26-05-2020 в 11:56:

Цитата:

KorteZZ писал:
Будут ли подобные вещи исправлены в NT?

я думаю можно не ждать NT чтобы их исправить, а прямо в XT

Добавлено 26-05-2020 в 18:56:

Цитата:

FiEctro писал:
т.е. об уровнях модельками можно позабыть?

ДМ уже аппроксимировал треугольники брашами, может сделает так же.

Отправлено Дядя Миша 26-05-2020 в 12:02:

Цитата:

FiEctro писал:
т.е. об уровнях модельками можно позабыть?

наоборот. У этих уровней будет отличная коллизия по брашам.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KorteZZ 26-05-2020 в 12:08:

Дядя Миша
Но ведь к движку ведь будет и ксашмод, нет? Или мод нужно будет самому писать? А я то не кодер. В этом случае мне проще остаться на старом ксаше, для которого есть мод. Голый двиг то мне зачем? Смысла нет.

__________________

Killing Floor: Horzine Outbreak

Отправлено Дядя Миша 26-05-2020 в 12:28:

Цитата:

KorteZZ писал:
Но ведь к движку ведь будет и ксашмод, нет?

останется да. В качестве базового набора. Народ к нему уже привык.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KorteZZ 26-05-2020 в 12:58:

С одной стороны хорошо, но с другой - если ксашмод не будет развиваться, адаптироваться, то тоже профита для мапперов не особо много будет.

__________________

Killing Floor: Horzine Outbreak

Отправлено nemyax 26-05-2020 в 13:09:

Цитата:

Дядя Миша писал:
останется да. В качестве базового набора

Ты его параллельно переписываешь?

Отправлено Дядя Миша 26-05-2020 в 17:00:

Переписываю, да.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 31-05-2020 в 10:43:

Цитата:

Дядя Миша писал:
Переписываю, да.

Перенеси туда из П2 trigger_textwindow и систему субтитров.

Отправлено Дядя Миша 24-06-2020 в 16:09:

Оказывается народ из патчей сооружает целые замкнутые конструкции, расставляя их особым образом. Я-то привык полагать, что вот сделали патч, вогнули - получилась арка внутрь. А наружу, соответственно всё заполнено солидом. Так вот нет, они снаружи лепят еще один патч, который образует наружную часть этой арки. Ну хорошо, при моем подходе к коллоизиации, мне достаточно несложно учесть такие групповые конструкции и построить для них солидные структуры. Потому что когда строишь без учета этих групп, они друг-друга перекрывают и получается монолитная стенка вместо арки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 24-06-2020 в 16:13:

Что мутил с движком в прошедший месяц?

Отправлено Дядя Миша 25-06-2020 в 06:26:

Совсем не до кодинга было. Даже не прикасался.

Напомню, текущая задача - работа над компиляторами, разработка нового формата уровней, на данный момент - колоизация патчей, потом моделей.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 25-06-2020 в 12:05:

Просто по группам сортировка была во первых изначально неверная, это я исправил, а во вторых, она больше для устранения краков. Если из таких групп генерить коллижен-брашы, там слишком много солидного строительного материала, при построении дерева. Ладно бы эти патчи все торчали наружу уровня, но так далеко не всегда бывает. Поэтому я остановился вот на каком варианте. Строю группы (которые касаются друг-друга контрольными точками), дальше сортирую список по объему каждого патча и проверяю, какие еще патчи попадают в этот объем и одновременно принадлежат этой же группе (т.е. гарантированно соприкасаются друг с другом), группы при этом получаются довольно мелкими (3-5 патчей), но зато результаты построения дерева из них всегда правильные. Так, к примеру удобно делать эти обналичники из трёх патчей (внутри, снаружи и фронтальная поверхность). А если бы я каждый из этих трёх патчей превратил в браш отдельно, то они бы просто превратились сплошной солид, вместо арки. Причём это не везде происходит и зависит от стиля маппера. В ку3 к примеру такие арки никто не делал, и там проблемы не было.

Добавлено 25-06-2020 в 14:56:

Собсно, весь этот огород из-за того, что патчи двухмерны по своей природе и кутри для них соответственно строит двухмерную коллизию, а дизайнеры пытаются её как-то запечатать такими же патчами сверху и снизу.
И при генерации брашей надо учитывать все три патча как единую конструкцию. Необязательно их конечно три, может быть и больше и меньше.

Добавлено 25-06-2020 в 15:05:

Приложил карту для наглядности. фанк_группы - это вот как раз результат работы автоматической группировки. Из такой группы строится маленькое BSP-дерево, которое уже создаёт коллоизационные брашы для патча.
Но там несколько режимов работы, не всегда оптимально использовать дерево.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 27-06-2020 в 09:07:

Про виз немного расскажу. Почему его алгоритм не менялся с незапамятных времён и в принципе подходит для любых вариаций на тему. Виз, как вы помните, не имеет дела с деревом. Он имеет дело с некоторыми замкнутыми примитивами, которые соеденены между собой порталами. Сам примитив может быть как конвексный, так и не очень. Важно чтобы он был полностью замкнутый - это проверяется еще на этапе построения BSP. Если мы оперируем лифами для первой кваки - примитив очевидно будет конвексный.
Для простоты представим его как аксиальный, некоторые стороны будут порталами. Каждый портал имеет две стороны, или точнее говоря - является проходом между двумя лифами. Portal flow - это поток, который идёт точно по размерам портала. Допустим в соседнем лифе напротив портала - солидная стена (для виза это выглядит просто как отсутствие портала на противоположной стенке), а портал находится под углом 90 градусов (коридор повернул). Тогда этот лиф помечается как видимый, а вот уже следующий за ним - невидимый. Впрочем там проверка конечно более сложная, т.к. учитывается видимость для позиции, а не для направленного взгляда (а для порталов видимость оптимально считать именно через попадание во фрустум, но их блин слишком много в классических форматах от Кармака, чтобы налиту это делать, хотя в Darkplaces есть реализация такого подхода). Плюс в том, что видимость считается полностью автоматически. Минус - в том, что дерево строится исходя из минимального кол-ва разбиений, поэтому отсечение видимости порой выглядит очень странно. Чтобы хоть как-то это исправить ввели хинт-брашы, которые заставляют сделать разрез. Прикол в том, что мы не гарантируем, что получившаяся нарезка сделает именно то, что нам надо, это хорошо работает только на самой простейшей геометрии. Да и народ, зачастую не в курсе, что хинты увеличивают кол-во полигонов. А когда это понимают - отказываются от их использования.
Ну так вот - в ку2 уже, когда были введены детальные брашы, чтобы заставить виз работать быстрее, лифы объединили в кластеры. Это очень просто - те порталы, которые находятся между двумя такими лифами уничтожаются, а остальные принадлежат одному кластеру. Кластер по идее уже может быть неконвексным. Принцип работы виза не поменялся.
Ну и наконец то, что я делаю сейчас - вместо кластеров арии, которые задает левел-дизайнер ручной расстановкой порталов. Хотя в некоторым смысле это регресс, т.к. предполагает ручную работу, но на самом деле он практически неощутим. На те же самые места, куда предполагается расставить порталы, дизайнер бы точно так же влепил хинт-брашы. Причём результат от их использования был бы гораздо менее очевиден.
А тут работает простое правило - если человек видит результат своих усилий, ему это проделывать совсем несложно.
Ну и сам рассчёт виза при таком подходе не может занимать больше секунды даже на самых слабых машинах.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 03-07-2020 в 08:29:

makebsp практически готов и я им очень доволен. Карты собирает очень быстро, формат достаточно абстрактный (к примеру компилятор не заглядывает в контентсы примитивов и вообще там мало встроенных параметров), а все компиляторные энтити вынесены в скрипт и дизайнер может наделать своих, какие ему надобны. Пример:

C++ Source Code:

1	// any entity passed through this commands first

"default"

4	// rename keys to default

5	renameKey( "modelscale", "scale" );

6	renameKey( "modelscale_vec", "scale" );

8	if( angle )

10	// support quake legacy

11	convertYawAngle( "angle", "angles" );

12	removeKey( "angle" );

15	// load entity transformation (may be identity)

16	loadTransform( "origin", "angles", "scale" );

18	// any entity from embedded level should be gone structural brushes

19	if( embedded_level == true )

20	removeBrushes( C_STRUCTURAL );

23	// Q3Map2 internal entity

"_skybox"

26	setKeyValue( "skybox", "1" );

27	renameKey( "_scale", "scale" );

30	"func_group"

32	loadIndexMap( "alphamap", "shader", "layers" );

33	movePrimitives( "classname", "worldspawn" );

34	removeEntity();

37	"func_detail"

39	addCompileFlags( C_DETAIL\|C_TRANSLUCENT );

40	movePrimitives( "classname", "worldspawn" );

41	removeEntity();

44	"misc_model"

46	includeModel( "model" );

47	// includeMap( "model" );

48	addCompileFlags( C_DETAIL );

50	// loading indexmap right after model including

51	loadIndexMap( "alphamap", "shader", "layers" );

52	transformModel( "self" );

54	if( target ) movePrimitives( "targetname", "target" );

55	else movePrimitives( "classname", "worldspawn" );

57	removeEntity();

То есть эти энтити больше не захардкодены внутри компилятора.
Виз встроен внутрь, работает очень быстро - несколько милисекунд, как правило. Ну оно и понятно - даже на самых простейших картах, типа c1a0d из халфы, кол-во порталов на дереве могло легко достигать 4-5 тысяч. А тут мы имеем дело с порталами, которые расставляет сам дизайнер и вероятность того что он раставит более ста штук - минимальна. Да и нет необходимости ставить их столько. Принципы прежние - там где вы раньше ставили хинт-брашы, теперь ставите порталы, можно даже конвертнуть старые хинт-брашы в порталы, просто переназначив им материал. Теперь на очереди освещение, утилита называется dolight как в сталкере

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 03-07-2020 в 08:53:

Ты порталы вообще не зови порталами, люди скажут "да ну возиться и т.д.". Просто скажи что хинт-браши теперь обязательны.

Отправлено FiEctro 03-07-2020 в 08:58:

Это что получается, теперь после компиляции вся карта целиком рисоваться будет, если эти браши не поставить?

Отправлено Дядя Миша 03-07-2020 в 09:11:

Цитата:

FiEctro писал:
теперь после компиляции вся карта целиком рисоваться будет, если эти браши не поставить?

именно так. Но поскольку сурфейсы сгруппированны по материалам и вся геометрия лежит в видеопамяти, мы наблюдаем тот самый эффект, о котором так долго твердили большевики - это не сильно медленее карт с визом, а чаще - даже быстрее. Во всяком случае это касается обычной лоу-поли геометрии до полумиллиона полигонов в кадре.

Добавлено 03-07-2020 в 12:03:

Но с порталами конечно еще быстрее.

Добавлено 03-07-2020 в 12:11:

А да, виз естественно AI использует, чтобы монстры не видели игрока через полкарты. И теперь есть точный контроль над тем, что именно перейдет на следующий уровень, т.к. порталы вручную ставятся.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-07-2020 в 09:25:

А зачем БСП тогда вообще нужен? Загружай напрямую obj какой нибудь.

Отправлено Дядя Миша 03-07-2020 в 11:44:

Цитата:

FiEctro писал:
А зачем БСП тогда вообще нужен?

BSP еще как нужен. Он же удаляет внешние полигоны, Portal Flow первичный делается через него, создаются площади, наконец индексация пространства для коллизии и для поиска параметров. Но в данном случае дерево никак не влияет и не ограничивает дизайнера, как это было в халфе.

Добавлено 03-07-2020 в 14:44:

Так, ну чтожы. Наконец-то лайтмапы. Лайтмапы хранятся всегда снаружи в виде DDS-картинок, их можно удалить, если предполагается использование только динамического освещения, их можно пересохранить в bmp и нарисовать какую-нибудь каляку-маляку. Ну и всё в таком духе.
Думаю на каждую страницу придётся две лайтмапы - RGB+shadow и DeluxVectors. Конечно можно заюзать float-лайтмапы и сохранить там, например сферические гармоники или разложенные кубемапы, но мне бы для начала получить обычное освещение. Тому шо проект полностью пустой, лайтмаппер с нуля пишется. Здесь мне поможет лайтмаппер моделек из паранои, написанный в прошлом году. Он же как раз для трианглов делался, а у меня в этом формате все модели - трианглы. Есть и второй момент - TJunc может там добавить дохрена излишних точек, то есть визуально полигон квадратный, а внутри чёрт знает сколько треугольников.
Понятное дело, если каждый такой треугольник освещать отдельно. во первых будут швы, а во вторых - прощай индексация вертексов. Собсно, это и есть самая сложная задача - построить такую развертку, которая бы учитывала текущие шареные вертексы, удалить из нее внутренние рёбра.
Нечто вроде развёртки для моделей. Вероятно придётся несколько снизить эффективность упаковки вертексов, разбив их по принадлежащим материалам. То есть все шареные вертексы смогут принадлежать только лишь одному материалу. Иначе эта развёртка будет размером со всю карту и такое далеко не всегда получится уместить на страницу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-07-2020 в 12:54:

>> Он же удаляет внешние полигоны

Ну в obj тоже нет внешних полигонов, если ты их специально не сделаешь.

>> Portal Flow первичный делается через него, создаются площади, наконец индексация пространства для коллизии и для поиска параметров.

Подобные вещи вроде ты делал при первом запуске карты для физики

>> Собсно, это и есть самая сложная задача - построить такую развертку, которая бы учитывала текущие шареные вертексы, удалить из нее внутренние рёбра.

Ну вот с моделькой бы такой проблемы не было, любая сгенерированная развертка не эффективна с точки зрения оптимизации и даёт очень противоречивые результаты.

Отправлено Дядя Миша 03-07-2020 в 13:08:

Ну и да, пока не забыл, давайте уже окончательно разжую как виз работает, чтобы больше не возвращаться к этой теме.

Итак, у нас есть некоторая геометрия (важно, чтобы она была полностью замкнутой). Мы к ней применяем BSP-разбиение и получаем ту же самую геометрию, которая кое-где рассечена секущими плоскостями. И у нас теперь есть лифы. Для ку1\хл, лифы конвексные, для ку3 - произвольные.
Но это не важно. Теперь мы для наших лифов строим порталы. Порталы строятся очень просто - как вы знаете, если взять браш точно по размерам дерева и рассечь его всеми плоскостями дерева (но разумеется соблюдая очередность сечения от корневой ноды к лифу), то те обломки брашей, которые дойдут до лифа - превратятся в точное подобие тех брашей, которые изначально сокрыты в дереве (часть видимых полигонов браша содержится уже в самом лифе). С порталами мы поступаем аналогично - создаём геганцкий портал размером с дерево (под размером "с дерево" я имею в виду tree->mins, tree->maxs, т.е. bbox всех полигонов, которые в него включены) и сечём их нодами. Портал после рассечения удаляется и заменяется на два. А там еще на два ну и так, пока не дойдем до лифа. Некоторая сложность тут в том, что во первых нам не нужны порталы в нодах, поэтому когда портал делится надвое секущей ноды, он перемещается в детей ноды, а из секущей ноды - удаляется, во вторых порталов же обычно две штуки - прямой и обратный. Впрочем, кмк, Кармак написал этот код в 95-м штоли году и он с тех пор ничуть не менялся, может быть поэтому он сложноват для понимания. Ну не суть.
Да, единственный момент уточню, в функции MakeNodePortal каждый портал клиппится при помощи соседей, что может ввести в заблуждение. Но не будем забывать, что соседней портал - это просто такая же секущая от соседней ноды, т.е. абсолютно тот же принцип, что и с созданием брашей, но даже проще, потому что портал это плоскость, а браш всё-таки должен получиться замкнутый.

Так вот. Теперь у нас есть лиф с порталами. Тут важно понять вот какую вещь, для простоты будем оперировать исключительно конвексными лифами в виде кубега. Вот у нас кубег и все шесть его сторон покрыты порталами. Что это значит? Это значит, что из этого лифа можно видеть в шесть разных направлений. Но представим, что этот лиф в углу комнаты, и соответственного у три стороны - видимые поверхности, а еше три - порталы. А теперь представим что лиф у нас очень жирный и занимает весь тупик, откуда только один выход (вполне реальная ситуация). И у него пять солидных сторон, а шестая - портал.
А теперь, собственно то фундаментальное понятие\допущение, на котором и работает виз. Поскольку у нас пять сторон солидных, то мы можем видеть только по направлении из шестой стороны-портала. И, как вы понимаете, мы никоим образом не можем заглянуть за все эти стороны.
Ну потому что наш портал из лифа не висит в ваккуме, а надёжно прилинкован еще к одному точно такому же лифу. А из того лифа допустим смотрят уже три портала и так далее. Вот почему и важно поддерживать замкнутость уровня, чтобы всё это не вытекло обратно на само-себя. Правда дырка в одном месте далеко не всегда приводит к общим утечкам, так что порой даже карты с дырками вполне нормально выглядят. Но как минимум с них не получится удалить наружные полигоны. Кстати наружные полигоны тоже удаляются очень просто - у нас есть глобальный аутсайд лиф (нулевой), который находится снаружи уровня.
То есть это как бы гигантский такой браш, который покрывает всю карту. Но если на карте нет утечек, то мы соответственно не сможем на него выйти изнутри. Внутренности определяются по наличию точечных энтить внутри карты, к слову. Другого способа нет. Поэтому если вы создали где-то пустую комнатку без единой энтити, то компилятор вам выдаст сообщение: no entities in open -- no filling или что-то в таком духе.
Те лифы, к которым не удалось добраться сквозь порталы, помечаются как внешние, мы можем их удалить из дерева вместе со всем, что к ним прилинковано.

Но вернёмся к нашим лифам. Поскольку для определения видимости нам достаточно держать в уме только знание о том, что там где нету порталов - там непроходимая стена, то и соответственно нет и никакой необходимости использовать для работы виза реальную геометрию.
Поэтому .prt файл содержит только список лифов (ну или кластеров или арий, не суть важно), к которым прилинкованы эти порталы. Виз, осуществляется в два прохода (просто для оптимизации и ускорения).
Сперва делается очень грубая прикидка, результаты которой сохраняются в карту в режиме -fast. Потом, по результатам этой прикидки порталы сортируются таким образом, чтобы в начале списка были порталы с наименьшим кол-вом потенциально видимых лифов, а в конце - с наибольшим. Это сокращает общее время рассчёта, но время рассчёта, как вы знаете из-за этого очень быстрое вначале и замедляется в конце.
Можете отключить сортировку порталов, будет более равномерно, но в целом медленее (-nosort в большинстве компиляторов). Смысл этой оптимизации в том, чтобы к моменту, когда мы добрались до рассчёта порталов, из которых потенциально видно очень много - все остальные были уже рассчитаны и мы могли использовать эту информацию, руководствуясь принципом парности - если из B не видно A, значит из A не видно B. Проще говоря мы исключаем двойную работу.
Ну и наконец остаётся, собственно просчитать видимость одного портала из другого. Это очень простая и быстрая операция, если бы не долбанный комбинаторный взрыв, когда кол-во проверок растёт в геометрической прогрессии. Собсно суть проверки - убедиться в том, какие из порталов попадают в окошко видимости нашего портала. Фишка тут в том, что поскольку видимость потенциальная, мы не можем использовать угол зрения, фрустум и так далее. Поэтому для портала, попавшего в наше поле зрения производится максимум обрезание по одной из плоскостей исходного портала. И вот этот уже кусочек (ну или целый, если весь попал), делает точно такую же проверку на видимость соседа. И если он больше ничего не увидел - здесь видимость для исходного портала и заканчивается. Ну а потом, когда вся портальная видимость проссчитана мы просто конвертируем портальную видимость в видимость лифов\кластеров\арий. Это очень простая операция. Смотрим какому лифу принадлежит портал и для него, соответственно выставляем биты тех порталов, которые принадлежат к соответствующим лифам.

Собственно портальные методы отсечения - вешь широко известная, но её обычно применяют в реалтайме, сделать предрассчёты придумал именно Кармак. Когда порталов не очень много, можно использовать куда более эффективное отсечение по фрустуму, собственно в Doom3 так и сделано. Но и в Darkplaces баловались чем-то подобным, хотя там польза от такого метода может опасно приблизиться по времени к скорости отрисовки и куллинг потеряет всякий смысл. Но это делалось для неотвиженных карт

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-07-2020 в 13:27:

А почему отсекают именно по фрустуму, а не рейкастом? Фрустум же идёт дальше препятствия, а рейкаст не будет рисовать то что за стенкой.

Отправлено Дядя Миша 03-07-2020 в 16:15:

FiEctro перечитай еще раз. Для объемов с порталами понятия "за стенкой" не существует.

Добавлено 03-07-2020 в 17:02:

Больше скажу. PortalFlow по фрустуму работает лучше связки Frustum+PVS.

Добавлено 03-07-2020 в 19:15:

Эх, в компиляторе света опять целая куча скучной подготовительной работы
Сурфейсы загрузить, дерево построить, векторы посчитать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 03-07-2020 в 16:25:

Цитата:

Дядя Миша писал:
если взять браш точно по размерам дерева и рассечь его всеми плоскостями дерева (но разумеется соблюдая очередность сечения от корневой ноды к лифу), то те обломки брашей, которые дойдут до лифа - превратятся в точное подобие тех брашей, которые изначально сокрыты в дереве (часть видимых полигонов браша содержится уже в самом лифе).

А мы можем так декомпилировать карту для халфы? Или это вообще не в ту степь?

Отправлено Дядя Миша 03-07-2020 в 18:17:

Crystallize ну я вам и предлагал когда-то написать такой декомпилятор. Народ отказался.

Добавлено 03-07-2020 в 21:17:

Там в принципе восстанавливается всё. Ну кроме конечно внешних сторон брашей, но кому они нужны.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-07-2020 в 13:03:

В построении лайтмап для треугольника, наиболее важный момент, конечно, это не строить лайтмапы, для, собственно, треугольников, а попытаться объединить как минимум пару треугольников в квадрат. Почему - понятно, если аллокать лайтмапу для треугольника, во первых будет перерасход места в атласе, во вторых, мы не сможем корректно записать для какого-то из шареных вертексов координаты лайтмапы - они же не совпадут, как вы понимаете. Да и общая скорость отрисовки ухудшается. В параное я такое сделал просто для теста, т.к. на тот момент впервые с этим столкнулся, всё же лайтмапы на моделях более сложный кейс, нежели на аксиальных квадратных плоскостях. Итак, в первую очередь, еще до, непосредственно, освещения и отрисовки, нам предстоит найти все смежные треугольники.
Эти треугольники могут лежать на одной плоскости, а могут и не лежать, это зависит от того, какая нормаль у вертексов. Если нормали разные, то вертексы продублируются и эти треугольники уже не станут смежными.
Почему мы не можем накладывать лайтмапы на такие треугольники надеюсь тоже понятно. Если нет - поясню. Вот типичная комнатка, у которой стены покрыты одной текстурой и образуют замкнутый квадрат. Как это спроецировать над лайтмапу? Ну очевидно, что никак, задача не имеет чёткого решения. Через тяжёлый матан можно найти один из допустимых вариантов, но я не люблю с таким связываться, т.к. подобные вещи никогда не сходятся к точному решению. Если задача нерешается при одних условиях, значит условия надо менять.
Итак, как же нам найти смежные треугольники? Самый простой способ - через текстурные векторы. Если у треугольника они совпадают, значит они все принадлежат одной площади. Заодно это исключает и вышеописанный случай с комнаткой. Следующий шаг - найти adjacent-рёбра. Хм. Приымыкающие, очевидно. Это можно сделать рекурсивно, через матрицу примыканий. И сформировать из них группы. В принципе этого можно и не делать, но тогда, если у нас где-то будет разрыв между треугольниками, на лайтмапе очевидно останется неиспользованное место, которое, тем не менее будет просчитано с освещением.
К слову сказать вышеописанный подход я уже опробовал и результатами остался доволен, например, он мне автоматически собрал в одну группу ландшафт на карте shaderlab_terrain. В оригинальном q3map2 требовалось в шейдере явно указывать, что это треугольники, принадлежащие одной группе, потому что к ним применено авто-текстурирование.
Вообще в лайтмаппере вот такие вот побочные вещи отнимают больше всего времени.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 04-07-2020 в 16:09:

Цитата:

Дядя Миша писал:
Итак, как же нам найти смежные треугольники?

Сравнивать у вершин сразу x, y, z, u, v.

Цитата:

Дядя Миша писал:
Следующий шаг - найти adjacent-рёбра. Хм.

Можно перегнать треугольники в структуру данных, которая оперирует смежностью, и ходить по графу в своё удовольствие.

Отправлено Дядя Миша 04-07-2020 в 20:50:

Цитата:

nemyax писал:
Сравнивать у вершин сразу x, y, z, u, v.

Индексацией вертексов занимается BSP, который оперирует двойной точностью, лайтмаппер одинарной. Мне нет нужды сравнивать их координаты, я сравниваю сразу их индексы.

Цитата:

nemyax писал:
Можно перегнать треугольники в структуру данных, которая оперирует смежностью

да я просто построил bordering-матрицу для смежных рёбер, рекурсивно.
Это очень просто и быстро. Чем-то виз напоминает

Добавлено 04-07-2020 в 17:18:

Лайтмаппер к слову полностью самописный, на тех принципах, на которых я его делаю, мне просто неоткуда взять код, такого нигде нет.

Добавлено 04-07-2020 в 19:23:

Давайте расскажу вам принцип работы лайтмаппера на CPU. Ничего особенного сложного в целом там нет, дьявол кроется в деталях реализации.
И если реализация делает что-то не то - полезут швы. Швы это неизбежное зло лайтмаппинга, потому что освещение низкого разрешения, как правило. Если считать в полном, то швов практически не бывает, но это слишком долго, там смысл теряется. Лайтмапы-то размытые, приятные глазу.

Для выделенного сурфейса делается проекция в 2д, эта проекция у нас будет соответствовать нашей лайтмапе. Разумеется. предпочитительнее делать квадрат или прямоугольник, чтобы не было швов на стыке треугольников, да и экономнее во всех смыслах. Далее, для этой плоскости выделяются два массива векторов. Первый массив - это точки, второй - цвета лайтмапы. Можно еще и третий - делюкс-векторы или еще какую-нибудь инфу, типа теней. Принцип понятен. Самое главное зло лайтмап - это вот эти точки. Это как бы переходное пространство из 3д в 2д. Позиции точки в массиве соответствует точно такой же пиксель яркости лайтмапы.
Сами точки должны быть спроецированы на плоскость в 3д. Собственно на этом этапе и начинается всякая чертовищна. Почему она происходит?

1. полигон неаксиальный, из-за конечной точности флоата, часть точек может оказаться за полигоном. И трасса естественно туда не достанет и пиксель станет чёрным. Это бы конечно не проблема, если бы лайтмапы считались в полном разрешении, но точки-то гигантские! Вот эта чернота и залезет на соседа, появится шов-не шов, но пятно, переходящее в черноту.

2. полигон сложной формы, опять таки часть точек на него не попадает, но те, которые заденут хоть краешком - здрасти приехали. С подобными вещами хорошо бороться консервативной растеризацией, насколько это понятие вообще применимо к лайтмаппингу. Или взять срнедневзвешенные значения с девяти соседей (так ку3 поступает).

3. полигон размером меньше одного люкселя! В q3map2 додумались такие полики аппроксимировать повертексным освещением, ну кстати неплохое решение, вполне.

4. швы в основном вылазят, если считать лайтмапу не в родном разрешении. Почему так происходит? Благие намерения. Сделаем разрешение в 2-4 раза больше, чтобы точки на поверхность легли более точно. И посчитаем для них лайтмапу. Прекрасно. Теперь начинается самая чертовщина - мы скейлим нашу лайтмапу обратно вниз. Так вот можете себе представить, что алгоритмов, которые бы эффективно и средневзвешенно это сделали таким образом, чтобы пограничные света у соседних полигонов совпали - в приоде не существует. Причём, дело похоже даже совсем не в алгоритме, просто ресемпл идёт изолоировано для каждого полигона, но при этом учитывает яркость своих соседей. Вот на соседнем полигоне в центре темнее, а на первом - светлее. Лайтмапу с обоих полигонов ресемплили. И так получилось, что края, где они соприкасаются - тоже получились разной яркости. Причём разница там может быть порядка нескольких едениц. ну скажем 233 233 233 и 240 240 240. Выглядит это именно как шов. Хотя если эти картинки показать вам по отдельности, каждый скажет, что на них одинаковый оттенок.
Психопат рассказывал про какой-то алгоритм, который эти швы замазывает, но помоему он сам домазался до того, что убил всё освещение своими замазками. Впрочем и китаец делал нечто подобное с похожим результатом.

5. теоретически швы могут вылезать еще из-за особенностей билинейной фильтрации, но тут я пока не готов рассказать как это происходит и надеюсь, мне не придётся с этим столкнуться. Главное не скейлить полигоны с лайтмапами, поидее получится тоже самое что и с буквами, если нет охранного бордюра.

Ну вот, теперь когда мы разобрались с точками, дальше мы получаем прямой свет. Это очень просто - по стандартной формуле освещения, получаем освещённость нашей точки, перебирая все лампочки, которые наставил дизайнер. Это очень быстрый способ лайтмаппинга и на геймдеве его даже используют для рассчётов при старте приложения. Ну потому что очень быстро. Но, как вы наверное уже догадались, нам будет кое-чего нехватать. А именно теней. За тени у нас отвечает быстрая трасса. Пускаем трассу между лампочкой и нашей точкой, если прошла без помех - собираем свет от этой лампочки. Вроде почти так же просто, если не углубляться в дебри того как работает трасса

Но мы и не будем.

Повертексное освещение устроено аналогично, только вместо на лайтмапе точек - сразу вертексы. Аналогично устроен и лайтгрид\лайтпробы. Единственное, нам нужно придумать как именно располагать наши пробы - регулярная сетка, нерегулярная, ну вообщем тут фантазия неограничена, равно как и то, что мы туда будем записывать.

Про индирект расскажу в другой раз, когда до него доберусь. А пока что моя задача - вот как раз генерация этих долбаных точек. К слову, при разработке NT я активно юзаю визуальную отладку, прямо почти для всего. Вот и сейчас, планирую, столь масштабную задачку, как генерацию этих точек визуализировать в pts-файл. Правда рисовать их буду не партиклями, а через VBO, а то чёт тормозно.

Добавлено 04-07-2020 в 21:50:

Визуализировал точки для простейшего случая.
Но есть группы, в которых якобы одна общая нормаль,а на самом деле это террейн. Там придётся искать пересечение с реальной поверхностью.
ну это уже потом, теперь надо атлас построить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 04-07-2020 в 21:24:

Цитата:

Дядя Миша писал:
Психопат рассказывал про какой-то алгоритм, который эти швы замазывает, но помоему он сам домазался до того, что убил всё освещение своими замазками.

Это где это я убил освещение замазками?

Отправлено Дядя Миша 04-07-2020 в 21:57:

ncuxonaT на CSM ты скрины выкладывал, вспоминай. Это кажется был скрин с грасс_теста.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 04-07-2020 в 22:50:

Дядя Миша вот же грасс тест, без нормальных нормалей запеклось всё треугольниками, а замазывание швов только сделало переходы плавнее
https://csm.dev/threads/novye-kompi...603/post-939327
https://csm.dev/threads/lightbaker3...434/post-941138

Отправлено Дядя Миша 05-07-2020 в 10:44:

ncuxonaT

Цитата:

А что за окантовка вокруг тёмных треугольников?

Цитата:

это швы удалялись, но вышло не очень

Я же помню, там какая-то гадость была.

Цитата:

-seam_quality n - Качество удаления швов. Больше - лучше. По умолчанию n = 100.

Zopa! Это чтожы для каждой карты вручную подбирать параметр?

Добавлено 05-07-2020 в 13:44:

А вот как выглядят точки для Non-planar поверхности. Понятное дело, что так их использовать нельзя - надо сделать локальную трассу по средневзвешенной нормали и найти пересечение с ближайшей плоскостью.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-07-2020 в 12:04:

А вот я сделал локальную трассу в пределах группы и опустил точки в места их пересечения с плоскостями.

ЗЫ. Надеюсь вам всё это интересно, а то пишу-пишу, никто не камментит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 05-07-2020 в 14:43:

Дядя Миша
Что такое нон-планарная поверхность? Это патч? Процедурно генерируемая хейтмэпа?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 05-07-2020 в 15:39:

thambs это у которой полигоны лежат не на одной плоскости.
Ну вот эти горы на картинке фактически - один меш, рисуются за один вызов, все треугольник пошарены друг с другом. Реально наложить одну лайтмапу на все разом. Это наилучшее решение проблемы швов и пятен.

Добавлено 05-07-2020 в 18:39:

Да, грасс_тест поидее тоже превратится в одну сплошную поверхность, но я его давно уже не собирал, надо будет проверить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 05-07-2020 в 18:30:

Дядя Миша
Это автоматически объединяется?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 05-07-2020 в 18:49:

thambs если вертексы шареные, то да.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Raid 06-07-2020 в 06:31:

Цитата:

Дядя Миша писал:
Надеюсь вам всё это интересно, а то пишу-пишу, никто не камментит.

Никто не пони-мает о чем речь рискну предположить. А это чо, ландшафты какие были в играх вот старых? Полигонов не видать.

Добавлено 06-07-2020 в 09:31:

А вообще вон total tris. Ну, раз такие пироги то и вопрос: помнится была игра такая - Z.A.R. Называется. Там вот как раз пиксельные ландшафты были. А если им например разрешение увеличить и сглаживание по горизонту добавить, чо будет? Но там, правда, и монстры и оружие спрайтовые были.

__________________
Ты себя ведёшь как маленький ребёнок, который на улице увидел говно и обрадовался - говно-говно, смотрите кто-то насрал, ну и дела! © Дядя Миша

лиса.забирать.сыр.кусочек = ворона.уронить.сыр.кусочек( 1шт ); © FiEctro

Отправлено Crystallize 06-07-2020 в 07:19:

Цитата:

Raid писал:
А это чо, ландшафты какие были в играх вот старых?

Воксели чтоли?

Отправлено FiEctro 06-07-2020 в 08:48:

Почему на скринах оно полосатое? И планируется ли решить вопрос бензиновых разводов на лайтмапах?

Отправлено Crystallize 06-07-2020 в 09:20:

FiEctro если ты про то когда яркой лампочке диапазона не хватает то это в компиляторе решается в три строчки.

Добавлено 06-07-2020 в 16:20:

но на самом деле я такие разводы жёлтые вижу у реальных лампочек.

Отправлено Raid 06-07-2020 в 09:42:

Цитата:

Crystallize писал:
но на самом деле я такие разводы жёлтые вижу у реальных лампочек.

Профдеформацыя.

Отправлено FiEctro 06-07-2020 в 10:15:

Цитата:

Crystallize писал:
FiEctro если ты про то когда яркой лампочке диапазона не хватает то это в компиляторе решается в три строчки.

Так что за 20 лет так никто и не решил?

Отправлено Дядя Миша 06-07-2020 в 10:31:

Цитата:

Raid писал:
А это чо, ландшафты какие были в играх вот старых?

Это отладочные точки я рисую через GL_POINTS. Издалека они сливаются и выглядят как воксели. Полосатые-разноцветные - это я им таких цветов нагенерил. Чтобы не сливались.

Цитата:

FiEctro писал:
вопрос бензиновых разводов

картинку бы.

Добавлено 06-07-2020 в 13:31:

Сохранил лайтмапу в виде картинки, правда пока она пустая.
Ну теперь надо загрузить лампочки и посчитать, собственно освещение.
С внешними картинками хорошо еще и то, что их сразу можно изучать в паинте.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-07-2020 в 10:43:

Цитата:

Дядя Миша писал:
Сохранил лайтмапу в виде картинки, правда пока она пустая.
Ну теперь надо загрузить лампочки и посчитать, собственно освещение.
С внешними картинками хорошо еще и то, что их сразу можно изучать в паинте.

Помнишь карту которую ты делал для проверки точечных источников освещения, как далеко они светят? Вроде там было видно хорошо эти разводы, если память меня не подводит.

Отправлено Дядя Миша 06-07-2020 в 11:12:

FiEctro а, так это просто RGB24 точности нехватает. Ну я планирую лайтмапы сохранять в DDS, в том числе и в халфы\флоаты по необходимости.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 06-07-2020 в 11:14:

Цитата:

FiEctro писал:
Так что за 20 лет так никто и не решил?

А китаец не решал кстати?
Возможно что мапперы всегда думали что это нерешаемо и вообще боялись лезть в компиляторы, а кодеры всегда были заняты мудреными вещами типа детайлов и клипнодов.

Отправлено Дядя Миша 06-07-2020 в 11:54:

Самое мерзкое - заниматься вот этими подготовительными работами.
Уже и лайтмапу сохранил, теперь её надо осветить, значит распарсить источники света и выполнить простейшее освещение. Ну пока без теней.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Raid 06-07-2020 в 12:01:

Цитата:

Crystallize писал: мапперы всегда думали что это нерешаемо и вообще боялись лезть в компиляторы, а кодеры всегда были заняты мудреными вещами типа детайлов и клипнодов.

Рискну предположить что бэцкэнд - полагаю это именно данный случай, требующий глубокого пони-мания низкоуровневых вещей - был всегда слишком сложен, а видимый эффект был не такой очевидный как те же детейлы или прочие рюшечки (если мы про текстурки, конечно). На норот больше действуют блестящий HDR-ом унитаз в узеньком клозете на древнем-древнем движке, чем большое количество полигонов, размазанное в целом по уровню и видимое в основном в виде цифр.

Отправлено ncuxonaT 06-07-2020 в 12:20:

Покажите хоть картинку с разводами этими

Отправлено FiEctro 06-07-2020 в 14:16:

ncuxonaT
Любая тёмная комната освещаемая только с помощью радиосити, либо большая комната, освещаемая маленькой лампочкой. На лайтмапе будут видны красные и зелёные разводы, хотя сама лампочка белая.

Отправлено Crystallize 06-07-2020 в 14:35:

ncuxonaT
https://www.vogons.org/download/fil...26824&mode=view

Добавлено 06-07-2020 в 21:25:

Китаец сделал на это фикс в версии 31.

Цитата:

----Added the feature of preserving lightmap color of overly bright spots.
Because the maximum brightness value that can be stored in the lightmap is limited to 255, we have the problem of how to handle the overly bright spots.
Previously, the brightness that exceeds the limit is simply clipped by maximum value, in R,G,B channels separately. And Goldsrc engine does this too when rendering the lightmap, and with a even smaller limit.
But this will cause a distortion in color for the overly bright spots, which doesn't look good.
To solve this problem, the compiler now preserves color when reducing the brightness. And the brightness is now reduced to 188, not 255, so that it is also below the limit of Goldsrc engine and will not be clipped in game.
You can locate overly bright spots with hlrad parameter '-drawoverload'.

Добавлено 06-07-2020 в 21:35:

Вот только я не понимаю, почему мы до сих пор исскусственно ограничиваем яркость лайтмап: до 232, 196, 188. Это такая попытка получить аутентичный внешний вид?

Отправлено ncuxonaT 06-07-2020 в 15:11:

FiEctro может, у тебя монитор не откалиброван?

На правом столбце равномерно серый градиент, или разбитый на разные цвета?

Crystallize видимо, китаец решил, что лучше ограничивать. Но мне такие равномерные залысины не нравились, поэтому в лайтбейкере это сделано через тонмаппинг.

Отправлено Crystallize 06-07-2020 в 15:27:

ncuxonaT создай уже тему и выложи аттач с лайтбейкером.

Отправлено ncuxonaT 06-07-2020 в 15:33:

Crystallize он на КСМе выложен, а новых версий не было еще

Отправлено Дядя Миша 06-07-2020 в 15:56:

Цитата:

ncuxonaT писал:
На правом столбце равномерно серый градиент, или разбитый на разные цвета?

каким образом его можно откалбировать?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 06-07-2020 в 16:04:

ncuxonaT да я и на КСМ его не видел.

Отправлено Дядя Миша 06-07-2020 в 16:09:

ncuxonaT Crystallize я вам не мешаю?

Осталось написать только фазу собирания света и можно рефакторить то, что получилось.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Raid 06-07-2020 в 16:12:

Цитата:

ncuxonaT писал:
Crystallize он на КСМе выложен, а новых версий не было еще

Прозрачность бы доделал что ли, раз уж начал. Не помню почему именно не стал его юзать, хотя ГПУ компил это, конечно, очень быстро.

Отправлено Дядя Миша 06-07-2020 в 20:09:

ncuxonaT полная чертовщина с твоей картинкой. Открываешь в браузере - там одни цвета. Открываешь в AcdSea - там другие цвета. И только в паинте правая колонка чернобелая. Но! Если двигать картинку вверх-вниз, то да, просвечиваются цвета, мерцают.

Добавлено 06-07-2020 в 20:38:

Кажется понял. Паинт же не ресемплит картинку, отсюда и цвета.

Добавлено 06-07-2020 в 23:09:

Первый результат. Без теней.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 06-07-2020 в 20:28:

Дядя Миша
Вот тут на небе https://hlfx.ru/forum/attachment.ph...=&postid=195396 точки -- они какую-то функцию выполняют?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 06-07-2020 в 20:43:

thambs никакую абсолютно. Я забыл их убрать для небесных плоскостей на тот момент.

Фейковые тени через корейский рандом. На рассчёт ушло 10 секунд в сингл-треде
Завтра уже трассу прикручу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 06-07-2020 в 20:45:

Сама лайтмапа, если кому интересно.

Добавлено 06-07-2020 в 23:45:

Корейский рандом, это вотакое

C++ Source Code:

1	int TestLine( const vec3 &start, const vec3 &end, bool indirect )

3	if( indirect )

5	if( COM_RandomLong( 0, 10 ) == 0 )

6	return CONTENTS_SKY;

7	return CONTENTS_EMPTY;

9	return CONTENTS_SKY;

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-07-2020 в 23:18:

10 секунд на фейковый директлайт? Блендер с реалтайм рендером, радиосити и материалами в разы быстрее работает

Отправлено Crystallize 07-07-2020 в 06:53:

FiEctro в Блендере развёртки ручные и все текстуры в одном атласе наверное а тут всё автоматом и текстуры кусками.

Дядя Миша ты будешь в NT делать те самые триггеры которые срабатывают на любой скорости объекта?

Отправлено Дядя Миша 07-07-2020 в 09:37:

Цитата:

FiEctro писал:
10 секунд на фейковый директлайт?

непосредственно на рассчёт света ушла 1 секунда, если тебя это так интерисует.

Добавлено 07-07-2020 в 12:37:

Между прочим у внешнего хранения лайтмап есть одна забавная особенность. Эту внешнюю лайтмапу можно отредактировать в котошопе, например увеличить в несколько раз, размыть по всякому или нейросеткой и она корректно будет отображаться в игре. К тому же каждая страница лайтмапы может быть какого угодно размера, т.е. больше нет надобности все страницы делать одинакового размера. В этом была необходимость, пока они хранились внутри непрерывным массивом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-07-2020 в 09:39:

Дядя Миша
Мне вот интересно, а возможно будет выгрузить карту в меш, запечь для неё лайтмапу в блендере и заменить ту что сделал компилятор? Или там всётаки порядок хранения различается? Заложи возможность генерации геометрии не только в bsp но и какой нибудь obj, только треугольники подчисти

Цитата:

Дядя Миша писал:
Между прочим у внешнего хранения лайтмап есть одна забавная особенность. Эту внешнюю лайтмапу можно отредактировать в котошопе, например увеличить в несколько раз, размыть по всякому или нейросеткой и она корректно будет отображаться в игре. К тому же каждая страница лайтмапы может быть какого угодно размера, т.е. больше нет надобности все страницы делать одинакового размера. В этом была необходимость, пока они хранились внутри непрерывным массивом.

Ты же сам говорил что ресайз разрешения лайтмапы приводит к швам?

Отправлено Дядя Миша 07-07-2020 в 11:20:

Цитата:

FiEctro писал:
Ты же сам говорил что ресайз разрешения лайтмапы приводит к швам?

если мы ресайзим ЛОКАЛЬНЫЕ куски, а потом их склеиваем, то накапливаются ошибки, естественно. Но если ты берёшь целую страницу и скейлишь её, то ошибок не будет. Ну вот для примера, как в халфе подгружали хай-рез текстуры, ничего же вылазило, текстурирование оставалось на месте. Тут такой же принцип.

Цитата:

FiEctro писал:
запечь для неё лайтмапу в блендере

а на кой?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 07-07-2020 в 11:31:

Цитата:

FiEctro писал:
а возможно будет выгрузить карту в меш, запечь для неё лайтмапу в блендере и заменить ту что сделал компилятор?

Я с этого и начинал. Сначала конвертировал бсп в обж, запекал свет в 3дмаксе или блендере, потом вставлял обратно. Но 3дмакс и блендер настолько долго пекут освещение, что пришлось писать лайтбейкер.

Цитата:

Дядя Миша писал:
Но если ты берёшь целую страницу и скейлишь её, то ошибок не будет.

Ну вообще, если швы были замазаны под билинейную фильтрацию, любой скейл вернет их обратно.

Отправлено Дядя Миша 07-07-2020 в 11:55:

Цитата:

ncuxonaT писал:
Но 3дмакс и блендер настолько долго пекут освещение

Цитата:

FiEctro писал:
Блендер с реалтайм рендером, радиосити и материалами в разы быстрее работает

Определитесь уже.

Цитата:

ncuxonaT писал:
Ну вообще, если швы были замазаны под билинейную фильтрацию

Так я и говорю, что не планирую ничего замазывать. Собрать аверейдж с соседей невалидной точки, не более того.
Швы, это вообще такое дело, я подозреваю (но пока не буду утверждать наверняка), что их наличие завязано на принципе хранения самих лайтмап и возможности объединения смежных сурфейсов. Вот ситуация - две полигона с разной текстурой, ну скажем пол из двух брашей. Будет ли между ними заметен стык лайтмапы? Очевидно нет - т.к. стык двух текстур в глаза бросается куда сильнее и не считается чем-то плохим. Теперь вот у нас пол из двух брашей с одной текстурой. Если между брашами будет стык на лайтмапе, это сразу бросится в глаза. Если мы на эти два браша наложим единый кусок лайтмапы, никакого стыка, там естественно не будет. То есть это основной метод для борьбы со швами - смежные поверхности обязаны иметь общую лайтмапу. Но есть кейс где реализовать подобное не так просто, например конвексный замкнутый патч. Ведь точки проецируются на плоскость, а патч - замкнутый.
И здесь уже возможны варианты как поступить. Можно разбить патч на квады (формально геометрия не режется, разбивка идёт на уровне шареных вертексов, путём формирования груп со смежными рёбрами). Можно разбить такой патч на две половинки, следя, чтобы ни один из мешей не имел сумму нормалей более 180 градусов. Аналогично и на ландшафтах, если там, к примеру пещеры всякие или нависающие горки.
Ну то всё потом, опытным путём выяснится. Я напоминаю, что лайтмаппер я пишу главным образом для референса, чёб сравнивать с реалтаймом.
Потому что для реалтайма будет обкатываться множество техник разной степени достоверности, по итогам, я может быть получу картинку как в движках нового поколения. И может быть что-нибудь такое изобрету. Велосипед какой-нибудь.

Добавлено 07-07-2020 в 14:55:

Цитата:

Дядя Миша писал:
путём формирования груп со смежными рёбрами

Чтобы было понятнее - эти группы неявные, они нигде не хранятся в карте.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-07-2020 в 19:47:

Пытаюсь тут разобраться с параметрами компиляции для q3map2.
Почти половина настроек - какие-то голимые фейки, нигде нету серъезного подхода. Вот скажем китаец заморочился, построил небесную полусферу с нормалями и по ней делает небесный радиосити. Что делает q3map2?
Ну правильно, создаёт кучу солнц-лампочек с заданным шагом для симуляции того же эффекта, а потом получившееся дерьмо пытается сгладить фильтром.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 07-07-2020 в 20:08:

Цитата:

Дядя Миша писал:
создаёт кучу солнц-лампочек с заданным шагом для симуляции того же эффект

Я так же делаю. А что такое небесная полусфера с нормалями? Типа виртуальной геометрии, которая разбивается на патчи, и участвует в расчете радиосити наравне с патчами реальной геометрии?

Отправлено Дядя Миша 07-07-2020 в 22:27:

ncuxonaT погляди исходники VHLT, хорошая штука. Выпускает лучи по полу-сфере и проверяет, ушёл ли луч в небо или нет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 07-07-2020 в 22:38:

Дядя Миша в чем разница между пустить в небо 1000 лучей и пустить лучи от 1000 солнц?

Отправлено Дядя Миша 07-07-2020 в 22:54:

ncuxonaT правда не понимаешь? От одного солнца ты лучи собираешь в строго определённые точки, от множества солнц и получается множество теней, которые потом заглаживаются фильтром и выглядят как говно.
Множество солнц можно использовать, как некоторые мапперы, для достижения эффекта солнечного света, приходящего со всех сторон.
Была парочка карт в таком сюрреалистичном стиле.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 07-07-2020 в 23:06:

Дядя Миша правда, не понимаю. При большом количество солнц это множество теней размывается, и заглаживать их уже ни к чему. И если лучи пускать в разные стороны - будет то же самое. Если лучей мало, и их направления совпадают для всех люкселей, станут видны отдельные тени. Если направления лучей варьировать для каждого люкселя - будет шум. Чем больше лучей, тем меньше шума или отдельные тени сильнее размоются.

Отправлено Дядя Миша 08-07-2020 в 15:26:

Решил проверить обновлённый STB_DXT (они там какие ошибки исправили).
Результат в аттаче, файлы названы, согласно режимам качества STB, squish референсный (макс качество).

Разница в скорости. squish без SS2 сжимает эту картинку 41 секунду. squish с SSE2 делает тоже самое за 2.2 секунды. STB при любом уровне качества тратит 0.05 секунд. Это вообще хороший пример того, что грамотная оптимизация работает лучше тупого использования новых инструкций.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 08-07-2020 в 15:33:

Цитата:

Дядя Миша писал:
Это вообще хороший пример того, что грамотная оптимизация работает лучше тупого использования новых инструкций.

А в чём именно там оптимизация заключалась, расскажи пожалуйста в двух словах?

__________________

Отправлено Дядя Миша 08-07-2020 в 15:38:

Цитата:

XaeroX писал:
А в чём именно там оптимизация заключалась, расскажи пожалуйста в двух словах?

Таблички построили

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 08-07-2020 в 22:24:

Бензиновые разводы возникают на этапе конвертирования Lightvalues из вещественного в unsigned char. Надо будет уделить этому вопросу внимание.
Построил группировку треугольников по смежным рёбрам и сглаживание нормалей. Пора делать рейтрейсер, а то фейковые тени уже надоели.

Добавлено 09-07-2020 в 01:24:

Кстати, надо будет добавить такую фишку, как множественное небо с разным светом от него. Меня это всегда бесило, что на карте может быть только одно небо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 09-07-2020 в 01:18:

Дядя Миша
Я когда игрался с VRAD, просто брал коэффициент превышения VectorMaximum() над 255 и уменьшал весь вектор во столько раз.

Отправлено Дядя Миша 09-07-2020 в 07:49:

Не факт, что ренормализация цвета вообще корректная операция. Может её и нельзя делать. Для единичного цвета - можно, а для целой лайтмапы не знаю. Может надо найти вообще со всех лайтмап пиковое значение и поделить все луксели на него. А когда это делается локально, вот и получаются бензиновые разводы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 09-07-2020 в 08:05:

Для чего вообще нужна эта ренормализация цвета? Я думал лайтмапы пишутся в сыром виде.

Отправлено Crystallize 09-07-2020 в 09:59:

FiEctro ну допустим в ХЛ2 лайтмапы во флоатах, которые перед записью в карту конвертятся в четыре числа: rgb24 и степень. А в ХЛ1 они просто зачем-то обрезаются порогом 196 или 232 у ДМ, это вроде чтобы работало на Вуду, но хз если честно. И тут как повезёт, если какой-то компонент до обрезания был сильнее других то он обрежется сильно, а другие намного слабее или не обрежутся вообще. И у этого люкселя скакнёт насыщенность которая суть разница значений разных каналов.

Отправлено Дядя Миша 09-07-2020 в 11:38:

Цитата:

FiEctro писал:
Для чего вообще нужна эта ренормализация цвета? Я думал лайтмапы пишутся в сыром виде.

Лайтмапа считается в вещественных числах, а записывается в картинку 24 бита, очевидно, каждый канал может хранить максимум 0-255. А во флоате там могут быть любые значения, источники света-то суммируются.
Отсюда же все эти залысины и бензиновые разводы. Просто потому что каждый цвет нормализуется по СВОЕМУ максимальному значению, а не по общему для всех лайтмап. Вместо нормализации происходит разброд и шатания. Этож не векторы, так просто нельзя делать.

Добавлено 09-07-2020 в 14:38:

Цитата:

Crystallize писал:
А в ХЛ1 они просто зачем-то обрезаются порогом 196 или 232 у ДМ, это вроде чтобы работало на Вуду

не знаю насчёт вуду, но там какие-то магические числа при скейле лайтмап, это всё тянется еще с софтрендера.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 09-07-2020 в 11:54:

Вы щас как будто тонмаппинг изобретаете

Отправлено Дядя Миша 09-07-2020 в 11:58:

На самом деле здесь масса вариантов как исправить эту ситуацию.

1. Можно, как я уже сказал найти пиковое значение света для всех страниц атласа, сохранить его, ну например в ворлдспавн, предварительно умножив на него все значения света. Это в некотором смысле даст такой же эффект, как и BestFitNormals - сдвигаем значения диапазона, оставляя его границы нетронутыми. А потом просто умножить в шейдере каждый пиксель лайтмапы на это значение и получим почти HDR.

2. Сохранить лайтмапы в RGBe как в сорсе. Четвертый байт отводится под экспоненту. Минус в том, что скорее всего этот формат не имеет никакой аппаратной поддержки, его не сожмёшь в DXT и он занимает больше места, а я бы может четвертый байт хотел под тени заюзать.

3. сохранить лайтмапы в half-float. Они займут еще больше места, но зато это будет HDR.

4. вообще не хранить лайтмапы, хранить только тени, свет рассчитывать деномически в шейдере и умножать на запечённые тени (насколько я знаю, впервые такой подход был опробован еще в Сталкере, думаете как там смена дня и ночи на лайтмапах сделана? Вот именно так). В Юнити тоже есть такой механизм, насчёт UE не знаю. Но скорее всего да.

В принципе можно осуществить поддержку всех вариантов. ну или отобрать самые интересные на пленуме ЦК.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 09-07-2020 в 12:09:

Цитата:

Дядя Миша писал:
1. Можно, как я уже сказал найти пиковое значение света для всех страниц атласа, сохранить его, ну например в ворлдспавн, предварительно умножив на него все значения света. Это в некотором смысле даст такой же эффект, как и BestFitNormals - сдвигаем значения диапазона, оставляя его границы нетронутыми. А потом просто умножить в шейдере каждый пиксель лайтмапы на это значение и получим почти HDR.

И получится адовый бандинг. Будет пиковое значение, например, 10 - вместо 256 градаций получим 25.

Цитата:

Дядя Миша писал:
2. Сохранить лайтмапы в RGBe как в сорсе. Четвертый байт отводится под экспоненту. Минус в том, что скорее всего этот формат не имеет никакой аппаратной поддержки, его не сожмёшь в DXT и он занимает больше места, а я бы может четвертый байт хотел под тени заюзать.

Можно хранить как RGBA и сжимать в DXT5. А вообще есть всякие непривычные форматы типа GL_RGB10_A2, GL_RGB9_E5 и GL_R11F_G11F_B10F. Сжать их не выйдет, конечно.

Отправлено FiEctro 09-07-2020 в 12:18:

Цитата:

Дядя Миша писал:

Лайтмапа считается в вещественных числах, а записывается в картинку 24 бита, очевидно, каждый канал может хранить максимум 0-255. А во флоате там могут быть любые значения, источники света-то суммируются.

А чому сразу не считать лайтмапу в нужных пределах?

Отправлено Дядя Миша 09-07-2020 в 12:25:

FiEctro разверни свою мысль

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 09-07-2020 в 12:52:

Ну зачем рендерить с большим цветовым диапазоном, чтобы потом его обрезать? Почему нельзя отрендерить сразу в нужном качестве?

Отправлено Дядя Миша 09-07-2020 в 13:16:

Какой еще световой диапазон?
Ты на карту поставил лампочку и задал ей яркость 300. Очевидно 300 уже не влезает в границы байта. Но за счёт формулы затухания до сурфейса доходят меньшие значения. Но не от одной лампочки, а от разных. Они складываются. Где-то обязательно будет больше 255. Ты никак на этот процесс не повлияешь. Можно привязать эти настройки к физически корректным формулам, но проблема никуда не исчезнет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 09-07-2020 в 13:28:

Дядя Миша
Почему тогда в других рейтрейсерах при запекании в лайтмапу этой проблемы нет?

Отправлено Дядя Миша 09-07-2020 в 15:26:

FiEctro нет какой именно проблемы? Которую ты сам себе придумал?

Добавлено 09-07-2020 в 18:26:

Цитата:

ncuxonaT писал:
Будет пиковое значение, например, 10

Попробуй еще раз прочитать то, что я написал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 09-07-2020 в 15:49:

Цитата:

Дядя Миша писал:
Попробуй еще раз прочитать то, что я написал.

Попробовал, ничего не изменилось. Может, по-другому напишешь? Или на картинках покажешь.

Отправлено Дядя Миша 09-07-2020 в 16:05:

ncuxonaT если пиковое значение не превысило 255, зачем его записывать?

Прикрутил рейтрейсер, гауссом пока не гладил.
Считалось это две минуты с половой на одном потоке, долговато конечно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 09-07-2020 в 16:06:

Дядя Миша
Там скраю карты шов?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено ncuxonaT 09-07-2020 в 16:26:

Цитата:

Дядя Миша писал:
ncuxonaT если пиковое значение не превысило 255, зачем его записывать?

Я же говорю про нормализованный диапазон 0-1. Хочешь в целых числах - пожалуйста. Если пиковое значение 2550, на лайтмапе будет адовый бандинг.

Цитата:

Дядя Миша писал:
Прикрутил рейтрейсер, гауссом пока не гладил.
Считалось это две минуты с половой на одном потоке, долговато конечно.

Какое разрешение лайтмапы? Радиосити нет, только небо? Сколько лучей на небо?

Добавлено 09-07-2020 в 19:26:

FiEctro вот тема про лампочки, на каком скрине бензиновые разводы? https://csm.dev/threads/radius-osve...alf-life.38602/

Отправлено Дядя Миша 09-07-2020 в 16:37:

Цитата:

thambs писал:
Там скраю карты шов?

там конец карты.

Цитата:

ncuxonaT писал:
Я же говорю про нормализованный диапазон 0-1. Хочешь в целых числах - пожалуйста. Если пиковое значение 2550, на лайтмапе будет адовый бандинг.

Ты слушаешь только себя. Отучайся. Разжую подробно, еще раз.

1. Анализиурем все люксели всех страниц атласа для конкретной карты.
Находим пиковое значение. Если пик ниже 255, ставим множитель в 1.0.

2. делим все люксели на наш пик, если он более 255. Здесь приходится полагаться на практику, крайний пик навряд ли превысит 1.2 - 1.5. Просто из дизайнерского опыта, никто не будет ставить рядом сотни лампочек.

3. Здесь есть потенциальная проблема, что некоторые слишком тёмные люксели могут потенциально стать ниже 1 1 1 и соответственно превратиться в 0 0 0. Можно их принудительно ограничить на 1 1 1, хотя это и не совсем корректно.

4. При рендеринге умножаем лайтмапу обратно на наш множитель. Фокус тут в том, что дальше мы умножаем её на диффузку, поэтому итоговое значение не превысит 0-255, даже при рендеринге в RGBA8.

В чём смысл этой затеи - более эффективное использование диапазона RGB24. Я ж почему и сказал, что это чем-то похоже на BFN, там ведь тоже весь трюк сводится примерно к тому же самому.

Цитата:

ncuxonaT писал:
Какое разрешение лайтмапы?

386х386.

Цитата:

ncuxonaT писал:
Радиосити нет, только небо?

нету, разве я писал, что прикрутил радиосити?

Цитата:

ncuxonaT писал:
Сколько лучей на небо?

148 тысяч прямых и наверное около миллиона вторичных пополусфере, но это неточно, надо счётчик прикрутить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 09-07-2020 в 17:14:

Ох, ладно, по пойдем по порядку

Цитата:

Дядя Миша писал:
Здесь приходится полагаться на практику, крайний пик навряд ли превысит 1.2 - 1.5.

Это очень странное допущение. Например, рядом с ярким источником пик может быть и 10, и 20.

Цитата:

Дядя Миша писал:
3. Здесь есть потенциальная проблема, что некоторые слишком тёмные люксели могут потенциально стать ниже 1 1 1 и соответственно превратиться в 0 0 0.

Потенциальная проблема в том, что диапазон, который сейчас записывается в 0-255, будет ужат, например, в 0-100, а потом разжат обратно, и вместо плавного перехода вылезут ступеньки.

https://i.ytimg.com/vi/cGijQgw18e0/hqdefault.jpg

Цитата:

Дядя Миша писал:
4. При рендеринге умножаем лайтмапу обратно на наш множитель. Фокус тут в том, что дальше мы умножаем её на диффузку, поэтому итоговое значение не превысит 0-255, даже при рендеринге в RGBA8.

Точно имел в виду то, что написал? Лайтмапа (200 200 200) * множитель 2 * диффузка (200 200 200) = (314 314 314)

Цитата:

Дядя Миша писал:
Я ж почему и сказал, что это чем-то похоже на BFN, там ведь тоже весь трюк сводится примерно к тому же самому.

BFN работает только потому что нормали - единичные вектора.

Цитата:

Дядя Миша писал:
148 тысяч прямых и наверное около миллиона вторичных пополусфере

Как много. А что такое вторичные по полусфере?

Отправлено Дядя Миша 09-07-2020 в 21:14:

Цитата:

ncuxonaT писал:
диапазон, который сейчас записывается в 0-255, будет ужат, например, в 0-100

Ты не читаешь, что я пишу. Ты слушаешь только себя. Вот откуда ты взял, что я собираюсь ужимать диапазон до 0-100? Бесполезный разговор, я не буду больше ничего объяснять.

Цитата:

ncuxonaT писал:
Лайтмапа (200 200 200) * множитель 2 * диффузка (200 200 200) = (314 314 314)

Откуда ты эти числа выковырял?

В особенности множитель.

Цитата:

ncuxonaT писал:
BFN работает только потому что нормали - единичные вектора.

не забудь рассказать это Крайтеку, они оценят.

Цитата:

ncuxonaT писал:
А что такое вторичные по полусфере?

Опять придуряешься? Индирект от солнца собрать.

148 тысяч трасс, это кстати немного. Рейтрейсер на них тратит 0.3 секунды. Дерево дольше строится.

Добавлено 09-07-2020 в 22:20:

Вот статистика по рейтрейсеру (время его работы включает так же и сам процесс освещения, но думаю этим можно прнебречь, т.к. основное время уходит именно на трассировку)

Цитата:

137502 total traces
EmitDirectLight: time: 0.304986 secs

Это чисто прямой свет. 1 люксель = 1 трасса. 137 тысяч лучей

Цитата:

19250687 total traces
EmitDirectLight: time: 49.967801 secs

Включил индирект, выпуск лучей по полусфере. 19 миллионов лучей

Цитата:

49861097 total traces
EmitDirectLight: time: 96.683332 secs

Индирект + sun spread. 49 миллионов лучей.

Все замеры проводились в однопоточном режиме. Рейтрейсер, напомню, вальвовский, переделанный обратно с SSE2 на FPU. Я потестил оригинал и скорость его работы была в пределах халфовского BSP-дерева почему-то. Т.е. достойно, но ожидалось явно большее. Тогда я его переписал обратно на FPU, исправил несколько ошибок и делений на ноль (вроде как SSE2 к подобным вещам относится индиффиррентно) и ВНЕЗАПНО получил прирост скорости более чем в 10 раз.

Добавлено 09-07-2020 в 22:25:

Кстати обратите внимание. Наш Психопат уже тогда спрашивал "что значит по полусфере". То есть он просто издевается или нарочно наши слова к сведению не принимает. Слушает только себя, как я и говорил. Нам такие товарищи точно не нужны. Пусть отдохнёт в бане некоторое время.

Добавлено 09-07-2020 в 23:03:

Смотрю вот в исходники q3map2 фейк на фейке. Все эти девиансы, джиттеры и прочее, в конечном итоге сводятся к тому, чтобы нагенерить параметрических лампочек. Но есть один важный аспект - когда я буду дублировать этот лайтмаппер на GPU в реалтайме, работать с такими фейковыми лампочками будет куда быстрее и удобнее, нежели с честными формулами. Плюс оно еще и со всеми кваками совместимо по получившемуся освещению. Попробую солнышек нагенерить, дурацкое дело нехитрое.

Добавлено 10-07-2020 в 00:14:

То что слева - интерпретировало deviance как sunspred и честно выпускало лучи по полусфере. А skyLight в свою очередь, отправился в diffuse_light. 49 миллионов трасс, считалось 2 минуты 30 секунд в одном потоке.
То что справа - методы из ку3\q3map2, через слэш, потому что первым это всё же придумал Кармак, а потом эту идею развили и углубили. 18 фековых солнц. Два с половиной миллиона трасс, считалось 5 секунд в одном потоке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 10-07-2020 в 03:04:

Мораль не совсем очевидна. Т.е. параметрические лампочки вместо честных формул это хорошо (по крайней мере в контексте прицела на GPU) а параметрические солнца вместо трейсов до скайдома это плохо?

Цитата:

Дядя Миша писал:
То что слева - интерпретировало deviance как sunspred и честно выпускало лучи по полусфере. А skyLight в свою очередь, отправился в diffuse_light. 49 миллионов трасс, считалось 2 минуты 30 секунд в одном потоке.
То что справа - методы из ку3\q3map2, через слэш, потому что первым это всё же придумал Кармак, а потом эту идею развили и углубили. 18 фековых солнц. Два с половиной миллиона трасс, считалось 5 секунд в одном потоке.

Я сначала смотрел на правую картинку как на более совершенную потому что там тень выделяет кривизну под холмиком, а теперь уже и не знаю.

Добавлено 10-07-2020 в 09:36:

Цитата:

ncuxonaT писал:
FiEctro вот тема про лампочки, на каком скрине бензиновые разводы? https://csm.dev/threads/radius-osve...alf-life.38602/

Ни на каком, там либо все каналы одинаковые, либо есть только один, поэтому эффект не проявляется.

Добавлено 10-07-2020 в 10:04:

Цитата:

Дядя Миша писал:
Кстати обратите внимание. Наш Психопат уже тогда спрашивал "что значит по полусфере". То есть он просто издевается или нарочно наши слова к сведению не принимает.

Да это смахивает на культуру какого-нибудь Хабра: сразу начинать задавать кучу вопросов докладчику, просто по привычке.

Отправлено FiEctro 10-07-2020 в 06:23:

ncuxonaT
https://csm.dev/attachments/test_dyn_0000-jpg.120083/

Вот тут слева очень хорошо эти разводы видны

Отправлено Crystallize 10-07-2020 в 06:50:

FiEctro ну там ещё и гамма выкручена

Отправлено Дядя Миша 10-07-2020 в 07:52:

Ну вот, теперь, когда первые результаты получены, можно спокойно заняться рефакторингом. В первую очередь надо правильно распарсить все типы лампочек.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 10-07-2020 в 16:13:

Визуализировал кусочки атласа.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 10-07-2020 в 16:32:

Дядя Миша
Что кодируют цвета?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 10-07-2020 в 17:49:

сурфейсы на которые ляжет один блок лайтмапы. Там где разноцветные треугольнички - дело плохо, прямо как в параное.
Собсно, наложение двухмерной лайтмапы на трёхмерную геометрию это и есть самый важный момент любого лайтмаппера. Свет посчитать-то тьху, по стандартным формулам, трассу ускорить вообщем-то тоже реально.
Но вот грамотно спроецировать полигоны на плоскость - задача не из лёгких.
Если мы конечно не собираемся следовать порочному принципу один треугольник = одна лайтмапа. Это и швы и изыбточность самих лайтмап, ничего хорошего. В идеале бы конечно наложить всю карту на одну лайтмапу, но так всё равно не получится по куче причин.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-07-2020 в 09:57:

Дядя Миша
А какие способы знаешь по оптимизации трассы?

Отправлено Дядя Миша 11-07-2020 в 17:08:

Цитата:

FiEctro писал:
А какие способы знаешь по оптимизации трассы?

Самый лучший способ - избегать рекурсии. Трасса по дереву обычно рекурсивна и это рубит всю производительность. Ну вот тот рейтрейсер из сорса нерекурсивный, видать потому и такой шустрый.
Какие еще способы? предрассчитать в геометрии всё, что можно предрассчитать, ну это и так понятно. Быстрые тесты для отсечения по ббоксу. Но главное - избегать рекурсии.

Добавлено 11-07-2020 в 20:08:

Потихоньку рефакторю лайтмаппер, заворачиваю сущности в классы.
Лайтмаппер уже вполне работоспособен, но надо правильно расставить эти грёбанные точки. На 80% результат работы зависит именно от того, насколько они удачно станут. Ну и еще на 20 от интерполяции и размытия лайтмапы, ну то в посл. очередь, т.к. иначе я вообще перестану понимать что происходит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 12-07-2020 в 11:10:

Так, ну чтожы, лайтмапы я построил, выглядят уже неплохо, невалидных точек исчезающе мало. Но есть чёрные пятна. Пятна, как нетрудно догадаться, берутся из неправильной нормали, например точка находится точно на стыке треугольников. В халфе приходилось заниматься преборазованием из одного текстурного пространства в другое, чтобы найти interface normal, к счастье мне всё это не потребуется. Достаточно построить глобальный triangle neighbors. Кстати из-за этих же нормалей и швы кое-где проглядывают, но тут конечно надо следить. Одно дело - черное пятно и совсем другое - шов между двумя сурфейсами.
Дело в том, что в карту должны попасть именно корректно сглаженные нормали, иначе на спекуляре тоже швы будут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 12-07-2020 в 13:42:

Цитата:

FiEctro писал:
Почему тогда в других рейтрейсерах при запекании в лайтмапу этой проблемы нет?

ну может они сразу во флоат или халф-флоат пишут?

Добавлено 12-07-2020 в 20:42:

Цитата:

FiEctro писал:
А чому сразу не считать лайтмапу в нужных пределах?

Цвета поедут ещё хуже чем сейчас наверное. Там ещё и лайтмапа пересчитывается в гамму 0.5 и обратно. Ты же фактически предлагаешь считать по технологиям уровня Сеги Мегадрайв где 255+1=0. Я думаю "сразу в нужной точности" ты получишь на ровном месте скачки яркости как минимум по 16 значений.

Отправлено Дядя Миша 12-07-2020 в 17:11:

Немножко скриншотов:

На финальной картинке ничего не видно, но мне надо добиться идеала на голой лайтмапе. Буду строить соседей для треугольников, искать шареную нормаль, она как раз от всех этих пятен и швов помогает. Гораздо лучше чем все эти чистилки и замазывалки.

Добавлено 12-07-2020 в 20:04:

Легенда:
синие поверхности - это те, которым в материале указано использовать повертексное освещение.
Зелёные квадратики - это инвалидные точки, которые так и не смогли найти валидное положение. Прошу заметить, что кваки обычно хаатычно дёргают позицию во все стороны, проверяя солидность лифа, а я этого еще не делал.

Добавлено 12-07-2020 в 20:11:

А, да, сетку жеж забыл показать

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 13-07-2020 в 16:02:

Овербрайты-то планируются?

__________________
-Brain is dead-

Отправлено thambs 13-07-2020 в 16:05:

Дядя Миша
Что понимается под "валидным положением"? Алсо, а лайт-текстуры тоже светят точками, или там какое-то хитрое интегрирование?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 13-07-2020 в 16:56:

Цитата:

KiQ писал:
Овербрайты-то планируются?

некорректный вопрос. Это всё снаружи, в скриптовой системе материалов. Добавить дело десяти минут.

Цитата:

thambs писал:
Что понимается под "валидным положением"?

ну чтобы не за плоскостью и не в солиде. Хотя да, на солиды я еще непроверял.

Цитата:

thambs писал:
Алсо, а лайт-текстуры тоже светят точками

Лайт-текстуры пока что не светят совсем, только солнце, споты и поинтлайты.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 14-07-2020 в 10:44:

Не, сглаживание нормалей не помогает, а почему, потому что возможна дублицированная геометрия - в ку3 CSG-то не было, к примеру. У меня он допустим есть, но отключаемый. И получается, балка идёт до угла, в углу такой прикладок, 45 градусов. И вот на его краю, соответственно нипочём не сгладишь - там же под ним нет ребра, просто плоскость. Да и мелкие треугольники, там тоже ничего хорошего. Трипланарная проекция идёт лесом, с ней кашы не сваришь. LSCM слишком сложный в реализации и тяжелый в работе. Но есть и более другие варианты.

Добавлено 14-07-2020 в 13:40:

Кстати, напомните, что вы там просили, какую возможность оставить?
Запекать лайтмапу прямо в блендере? Технически это возможно, но выглядеть будет дико, потому что в блендере одни лайтформулы, а у меня в компиляторе совершенно другие. Хотя если речь идёт о запекании лайтмапы для всего уровня, то да, это может представлять некоторый интерес, но опять таки - блендер не нагенерит информации для реалтайм лайтинга.

Добавлено 14-07-2020 в 13:44:

Впрочем с моей текущей системой материалов у движка нет единой концепции рендеринга - реалтайм\предрассчитанное. Наоборот предполагается, что её выберет сам пользователь. Кому-то важен реалтайм, а кому-то по душе мягкий свет запечённого освещения. Но кстати возможность переключения между лайтмапами и реалтаймом - это тоже на совести пользователя. В движке нет никакого мультирендеринга, там абстрактный конвейер, с возможностью переключения на лету между разными патчами. Сами патчи, тоже разуумется пользователь пишет - в скрипте, в шейдерах. Можно вообще сделать чисто повертексное освещение, такую стилизацию.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 14-07-2020 в 11:41:

Я думаю можно провести эксперимент. Если будет меш с нормальной развёрткой. Было бы интересно пособирать карту чисто из моделей с -nocsg, как минимум загрузить оригинальный меш спонзы, вот только как быть с детектором дырок? Компилятор же видит модели просто как точечный объект? В общем не очень понятна какая должна быть система миграции геометрии .map -> csg -> .obj -> .bsp? Хотелось бы увидеть твоё видение как это всё должно работать. В целом .obj если не ошибаюсь поддерживает объекты, можно прямо в 3д пакете расставлять лампочки и энтитии, вот правда я не очень понимаю в каком виде у них хранятся свойства.

Отправлено nemyax 14-07-2020 в 12:15:

Цитата:

FiEctro писал:
В целом .obj если не ошибаюсь поддерживает объекты

Да, поддерживает.

Цитата:

FiEctro писал:
можно прямо в 3д пакете расставлять лампочки и энтитии, вот правда я не очень понимаю в каком виде у них хранятся свойства

С этим засада. Я пытался найти популярный формат геометрии, который бы хранил заданные пользователем ключ-значения для объектов, но без толку. Даже коллада их не держит.
Но с другой-то стороны, энтити с ключ-значениями можно прекрасно писать в .map и использовать его в паре с OBJ.

Добавлено 14-07-2020 в 15:15:

Цитата:

FiEctro писал:
как быть с детектором дырок

Дырка обнаруживается очень просто. Каждое ребро должно принадлежать ровно двум полигонам с одинаковым winding-ом. Если для какого-либо ребра это несправедливо, то всё, у тебя дырка.

Отправлено Government-Man 14-07-2020 в 12:45:

FiEctro
nemyax
Зачем скрещивать ежа с ужом, если можно использовать каждый софт для того, что он делает хорошо? 3д-пакет - для редактирования геометрии, а игровой редактор - для расстановки лампочек и энтить.

Отправлено nemyax 14-07-2020 в 12:52:

Government-Man
Затем, что в триде-редакторе имеются средства для привязки и автопривязки энтитей к конкретной геометрии. И тебе не надо скакать между хорошо делающими свою работу софтами, чтобы туда-сюда подгонять.

Отправлено thambs 14-07-2020 в 12:56:

Цитата:

Каждое ребро должно принадлежать ровно двум полигонам с одинаковым winding-ом.

Так же будет дырка если отдельные полигоны идеально прилегают друг к другу без t-junctionа.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 14-07-2020 в 13:12:

thambs
Частный случай непошаренного ребра.

Отправлено Дядя Миша 14-07-2020 в 13:27:

Цитата:

FiEctro писал:
Было бы интересно пособирать карту чисто из моделей с -nocsg, как минимум загрузить оригинальный меш спонзы

CSG работает только для брашей, на модели не влияет.

Цитата:

FiEctro писал:
вот только как быть с детектором дырок?

Ну если у меша спонзы нет щелей, то нету и дырок. Я правда не знаю, будет ли вам охота подгонять всё точно, моделлеры в этом довольно небрежны.
С другой стороны - нет необходимости это проделывать для каждого полигончика, надо только отделить детайлы от структуралов. Ну это и через материал можно. Для построения дерева и детектирования дырок брашы не нужны, они оперируют точно такими же полигонами, ну да, желательно выпуклыми.

Цитата:

FiEctro писал:
Компилятор же видит модели просто как точечный объект?

Смотря какой. NT-шный грузит модель, достаёт треугольники и встраивает их в карту, прямо в дерево. И режет на зоны-порталы.

Цитата:

FiEctro писал:
Хотелось бы увидеть твоё видение как это всё должно работать.

я блендер не знаю. Поэтому и спрашиваю совета у товарищей.

Цитата:

nemyax писал:
Каждое ребро должно принадлежать ровно двум полигонам с одинаковым winding-ом.

да ну глупости какие. Дырка будет, если в этом месте портал не создастся.
Точнее говоря изначальный портал дырку закроет, но потом его чем-нибудь порежет.

Цитата:

nemyax писал:
Я пытался найти популярный формат геометрии, который бы хранил заданные пользователем ключ-значения для объектов, но без толку.

Ищи, вроде бы не такое уж сложное требование. Даже странно.

Добавлено 14-07-2020 в 16:27:

Корочи, ну её нахрен эту трипланарную проекцию, так толку не будет.
Посмотрел как в сталкере сделано.
У них там очень простая и эффективная замута под странным названием
Orbitrary Oriented Ortho - Projection
найди где мы опечтались, что называется. Впрочем в сталкере такого хватает, там к примеру есть класс Menager.

Так вот, суть алгоритма - берём все фейсы соседей, добавляем их в одну группу (Deflector в терминологии сталкера). Ну это и так понятно, это то, что я вообще сделал в первую очередь, еще для трипланарной проекции.

Далее, находим самый здоровый полигон и от него начинаем добавлять в группу дефлектора, начиная именно с него. Понятно почему, чтобы в новой проекции все мелкие фейсы прилепились вокруг большого и не сильно искажали финальный размер куска лайтмапы.

При добавлении, нам надо следить за тем, чтобы атлас не замкнулся сам на себя, поскольку, как вы понимаете, геометрия может быть замкнутая, а лайтмапа нет, это же получилась бы бесконечная лайтмапа.
Это тоже очень просто - делаем дот между соседями, смотрим, чтобы там угол не превышал некоего глобального значения, наверное где-то в настройках компиляции. Ну понятно, чтобы атлас не завернулся сам на себя.
Теперь как матрица строится. Очень просто. Сумма нормалей всех треугольников (несглаженных), умножается на 1.0 + FLT_EPSILON * TriArea. Типа чтобы регулировать вклад нормали в зависимости от площади треугольника.
Дальше от полученной нормали (она кстати может и не получиться, всякое бывает), строим ортогональный базис, ну типа MakeNormalVectors и обычную ModelView через LookAt. И всё! Теперь мы нашей матрицей каждый вертекс трансформируем и используем его x,y как координаты лайтмапы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 14-07-2020 в 13:31:

Цитата:

Дядя Миша писал:
Orbitrary

Праезвольный?

Цитата:

Дядя Миша писал:
Ищи, вроде бы не такое уж сложное требование

Ну вот мап разве что.

Отправлено Дядя Миша 14-07-2020 в 13:56:

nemyax может они имели в виду орбиту?

Добавлено 14-07-2020 в 16:56:

Кстати да, в сталкере Instant Radiosity, как и в халфе. А вы думали, чего на статике такая приятная картинка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 14-07-2020 в 14:15:

>> я блендер не знаю. Поэтому и спрашиваю совета у товарищей.

Это скорее .obj, впрочем если хочешь какой то другой фомат, там .blend или .fbx говори, сохраню их.

Отправлено Crystallize 14-07-2020 в 14:35:

Цитата:

Дядя Миша писал:
При добавлении, нам надо следить за тем, чтобы атлас не замкнулся сам на себя, поскольку, как вы понимаете, геометрия может быть замкнутая, а лайтмапа нет, это же получилась бы бесконечная лайтмапа.

По приколу замкнутый атлас раскрыть как зонтик, чтобы получилось кольцо, и спроецировать на квадраную лайтмапу.

Цитата:

Дядя Миша писал:
Кстати да, в сталкере Instant Radiosity, как и в халфе. А вы думали, чего на статике такая приятная картинка.

Она приятная уже потому что Radiosity или конкретно потому что Instant? Как кстати они избегают комбинаторного взрыва на открытых картах?

Отправлено Дядя Миша 14-07-2020 в 18:23:

Цитата:

Crystallize писал:
Как кстати они избегают комбинаторного взрыва на открытых картах?

Для солнца вопрос некорректный, там GI вообще по другому работает, в том числе и в халфе. ~50% лучей все равно уходят обратно в небо. Т.е. нам же не надо замащивать патчами небесную коробку, так что по сути никакого взрыва там и нету. Но оптимизация есть, очень простая, примерно такая же как в халфе- радиус, в который попадают все источники, свет считается только от них. В халфе-то по PVS, т.е. более корректно это было. Ну для открытых пространств пофигу обычно.

Теперь, когда я объяснил, как там лайтмапы проецируются, у вас наверняка остался самый важный вопрос - ну ок, построили мы там эту проекцию рассчитали UV и толку? Как нам теперь найти точки в 3D, соответствующие нашей проекции? Вопрос нихрена не праздный, т.к. пространство свёрнуто (в смысле одно измерение убрали) и реконструировать его обратно не получится ни через какую матрицу. Можно конечно действовать напрямую - с определённым шагом в 3д опять расставлять точки на треугольнике и трансформировать их в пространство люкселя, но такой подход скорее всего даст неравномерную лайтмапу либо какие-то разрывы.
Поэтому используется всё же обратный способ преобразования.
Берётся итератор лайтмапы по width\height. Для получившихся uv барицентрически считается попадание в треугольник. Ну там скорее всего с небольшими бордюрчиками, чтобы не попасть по шву. И вот если он у нас попал, мы просто барицентрик UVW преобразуем в WorldSpace - у нас же треугольник, это готовая матрица фактически, для преобразования туда-обратно. И вот у нас уже сразу есть абсолютно валидная позиция для сбора прямого света, аналогично барицентрически считается и нормаль. А результаты сбора идут сразу в люксель.
И всё, никакой чертовни с подгонкой этих ворлд позиций на валидные места, никаких трасс, ни-че-го. И с этой точки сразу зовём GatherSampleLight или как он у них там называется LightPoint, неважно.

Но кстати, в сталкере нет светящихся поверхностей. Там только солнце, поинтлайты и виртуальные вторичные источники.

Добавлено 14-07-2020 в 18:37:

Кстати еще один любопытный момент - для каждого треугольника потом отдельно рендерятся эджы. Но я хз зачем это, может из-за джиттера в основном проходе?

Добавлено 14-07-2020 в 18:41:

И бардюры там есть по дефолту, видать для бикубической фильтрацыы.

Добавлено 14-07-2020 в 18:43:

Лайтмайппер в двух режимах работает. Либо классические RGB-люксели, либо полусферы пишет. Второе, я так понимаю, для освещения персов.
Так что не удивлюсь, если в движке увижу лукап в лайтмапу.

Добавлено 14-07-2020 в 18:44:

Да, еще вот какой момент - я смотрю сорцы Open X-Ray, не оригинальные.
Мож там энтузазисты чего-то попереписывали.

Добавлено 14-07-2020 в 18:45:

Хотя, стоп, полусферы, это жы для Bent Normals. Для реалтаймового GI.

Добавлено 14-07-2020 в 18:58:

Да, я ж собственно за процесс маппинга сказать хотел, но чёт увлёкся.

Вообщем какой я вариант предлагаю, надеюсь это приемлимо.

1. кубаем в блендере целую команту с произвольной архитектурой, ну или не комнату, а зал, ландшафт, корочи сектор. Дальше ставим этот сектор на карту через какой-нибудь misc_model, окружаем скайбоксом, прорезаем в скайбоксе дырдочку-выход из сектора, туда лепим ареапортал.

2. Повторяем пункт 1, совмещаем оба сектора в пространстве через этот портал. Есть вариант, накубать сразу всю карту, а потом разделить целую геометрию порталами. Есть вариант эти брашы вокруг модели сгенерить автоматически, но тогда из такого помещения не будет выхода.

Есть вариант полностью отказаться от брашей, но это очень неудобно, потому что брашами хорошо задавать объем сложной формы - воду, триггеры. Собсно, для этого они по большей части и нужны. Ну и примитивную невидимую геометрию для генерации порталов. Но это уже по желанию.

Добавлено 14-07-2020 в 18:59:

ЗЫ. я как-нибудь попробую построить BSP без брашей, для триангл-модели, типа той же спонзы, посмотрю, будут ли утечки.

Добавлено 14-07-2020 в 21:23:

Из серии "это любопытно". В сталкере по дефолту четыре люкселя на метр.
В халфе - люксель на каждые 36 сантиметров, т.е. втрое выше.
Правда тут непонятно, это на квадратный метр. Если да, тогда всё наоборот.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 15-07-2020 в 07:19:

>> Есть вариант полностью отказаться от брашей, но это очень неудобно, потому что брашами хорошо задавать объем сложной формы - воду, триггеры. Собсно, для этого они по большей части и нужны. Ну и примитивную невидимую геометрию для генерации порталов. Но это уже по желанию.

Можно в самом движке сделать xash.exe -editmode где ты просто загружаешь модель или map файл на проект сцены ( scene.xsh например ), и задаёшь объектам которые уже расставлены в 3д редакторе параметры прямо в этом моде, там же ты сразу можешь протестировать поведение твоих дверей, триггеров и т.д. , расставить лампочки, монстров, инфоплеер старт и теже самые триггеры. Задать дерево объектов парент системы, подцепить скрипты и т.д.

Пишешь в консоли buildmap *mapname*, движок сворачивается, запускает компилятор который компилирует всё это дело в bsp, запускает движок и включает твою карту уже в игровом режиме. Вроде как примерно так анрил энджин и работает.

В случае с map можно ещё и импортировать сразу значения этих объектов. И те кто любят кубать по старинке, ничего не надо будет делать дополнительно, они просто загружают карту на сцену и компилируют. Только у них ещё появится возможность протестировать все энтитии прямо в движке не компилируя карту. И здесь ещё один плюс! Можно будет редактировать эти объекты на уже откомпилированной чужой карте без исходников, либо вообще загрузить любую другую карту из первой халфы или кваки как меш, импортировать объекты и заново скомпилить под новый движок!

Для очень мелких дырок кстати можно сделать fill gaps чтобы их компилятор автоматически затыкал. Странно что в халфовских компиляторах этого так и не сделали.

Так же и главное меню игры можно сделать отдельным БСП с заскриптованными кнопочками и камерой.

Отправлено Cybermax 15-07-2020 в 08:15:

Цитата:

FiEctro писал:
Так же и главное меню игры можно сделать отдельным БСП с заскриптованными кнопочками и камерой.

Меню без стандартных пунктов, а карта с интерактивными объектами, ты это имеешь ввиду?

Отправлено Дядя Миша 15-07-2020 в 08:15:

Цитата:

FiEctro писал:
Для очень мелких дырок кстати можно сделать fill gaps

да дырки не так уж и важны, повторюсь

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 15-07-2020 в 08:29:

Цитата:

Cybermax писал:
Меню без стандартных пунктов, а карта с интерактивными объектами, ты это имеешь ввиду?

Ога. Просто набор игровых объектов со скриптами вида "я кнопка опций". Вынести в отдельный слой UI, сделать ортографическую проекцию. Вообще конечно бы хотелось чтобы практически всё было на скриптах, это будет супер гипко и удобно, если конечно само ядро будет иметь богатый набор функций.

Отправлено KiQ 16-07-2020 в 07:18:

Цитата:

FiEctro писал:
Так же и главное меню игры можно сделать отдельным БСП с заскриптованными кнопочками и камерой

Тебя Unity покусал?

Я-то думал это там костыль такой, а ты как фичу предлагаешь

__________________
-Brain is dead-

Отправлено Cybermax 16-07-2020 в 08:23:

KiQ а чем тебе не нравится вместо главного меню карта на которой можно взаимодействовать с всякими объектами, кнопочки всякие нажимать?

Отправлено Дядя Миша 16-07-2020 в 10:01:

Цитата:

KiQ писал:
Тебя Unity покусал? Я-то думал это там костыль такой, а ты как фичу предлагаешь

Здрасти-приехали. В первом квейке так скилл выбирали. Это всё оттуда идёт.

Добавлено 16-07-2020 в 13:01:

Мне вот какую штуку надо понять. Может ли лайтмапа быть единым куском на разных материалах. Для текстур там очевидно будут разные координаты, значит вертекс не смержится. Тогда выходит, что и нормали надо сглаживать по группам, на которые легла единая лайтмапа. Чёт у меня всё перемешалось в голове не могу сообразить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 16-07-2020 в 10:16:

Цитата:

KiQ писал:
Тебя Unity покусал? Я-то думал это там костыль такой, а ты как фичу предлагаешь

Зато меню будет отвязано от ядра и его можно будет кастомизировать любому мапперу с минимальными знаниями языка.

Дядя Миша
Лайтмапа имеет отдельную развертку по сути это просто группа вертексов, а накладывается она уже посредством шейдера в самом материале, вспомни lightmapgeneric в сорсе. Ничего не мешает запечь 2-3 лайтмапы и использовать их для разных материалов, например тех же стекол и воды.

Вот если интересно поколупаться:

Отправлено Дядя Миша 16-07-2020 в 11:57:

Цитата:

FiEctro писал:
Лайтмапа имеет отдельную развертку

Ничего себе.

Я вот что пытаюсь понять. Допустим у нас два планарных полигона.
На них разные текстуры, но есть смежное ребро. Таким образом на об этих полигона надо наложить единую лайтмапу. Вертексы со смежного ребра не должны расшарится, потому что не совпадёт развёртка текстуры. Но даже если и совпадёт - материалы-то разные. С другой стороны, материалы рисуются по индексам, а индексы точно свои у каждой группы. То есть при расшаривании вертексов проверку на материал делать необязательно.
Но! При таком подходе нам надо, во первых проверять все вертексы, а не только принадлежащие определённой группе. И для этих групп уже делать сглаживание. Вот где моя ошибка была - я строил группы внутри одного материала и вертексы шарил аналогично. Ну еще и потому, что кутришный подход сам по себе предполагает локальные индексы - чтобы все, принадлежащие сурфейсу вертексы были доступны в диапазоне, указанном, как startVert - numVerts. Но для загрузки в VBO это не так уж и важно, по сути. Надо все вертексы расшарить по лайтмап-группам. Тогда наверно получится что-то путнее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 16-07-2020 в 13:03:

А зачем нормали вообще сглаживать, да ещё и по материалам? Я всегда считал что это свойство задаётся для вертексов меша. В сорсовском хаммере вроде даже смутч группы были для этого, как в 3д максе.

Отправлено Дядя Миша 16-07-2020 в 15:26:

чтоб освещение было гладкое

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 18-07-2020 в 17:41:

https://slideplayer.com/slide/4462806/

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 18-07-2020 в 20:23:

Какой-то овердоз формул

__________________
-Brain is dead-

Отправлено Дядя Миша 20-07-2020 в 16:54:

https://hlfx.ru/forum/showthread.ph...5767#post195767

Цитата:

FiEctro писал:
Да, блендеровцы даже в вики пишут - LSCM использовать возможно только для очень простых разверток.
А какие ещё есть способы развернуть модель?
Я вот нашел UV Slim для старого блендера, но он как то растягивает шкуру в круг, что я не очень понимаю что с этими кусками дальше делать.

Развертка для текстуры и развёртка для лайтмапы, хотя и кажутся похожими, но на самом деле очень сильно отличаются. Для текстуры, ориентация UV-кусочка не имеет особого значения по двум причинам. Во первых там pixel-perfect попадание, во вторых кусочек заполняет художнег.
Для лайтмапы, наоборот это критически важно. Ну потому что если повёрнутая лайтмапа ляжет на аксиальную плоскость, то её тени тоже будут зубцами - билинейка тут ничего не может сделать. Даже гауссом сглаживать бесполезно. Второй момент - для лайтмапы естественные швы предусмотрены на углах, более 89 градусов, очевидно никакое сглаживание на заставит свет заглянуть за угол, это же не пушка, которую можно положить набок. Плюс, даже если все эти алгоритмы, начиная от простейших и заканчивания решением СЛАУ, типа того же LSCM вдруг облажались, то всегда предполагается дальнейшая ручная правка моделлёром. Для лайтмап, очевидно, ничего подобного выполнить нельзя. Можно только контролировать исходную геометрию, чтобы там не было двойных ребёр и прочей пакости.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-07-2020 в 00:20:

Дядя Миша
Ну для лайтмапы допускается большое количество швов, вплоть до того чтобы каждый полигон был отдельным островком на развертке. Плюс сама геометрия редко когда имеет сложную искривлённую геометрию.

Для обычной же UV того же человека, или какого нибудь шамблёра критично чтобы количество швов было минимально, так ещё и текстура там сходилась пиксель в пиксель. Я конечно понимаю что большинство моделеров просто нарежут её на кучу маленьких кусочков, и это будет правильно. Но в моём случае ещё необходимо произвести запекание в текстуру не только геометрии, но и партиклей (всякие мех и волосы которые рендер запекания в текстуру не поддерживает), и вот тут уже количество этих кусочков сильно влияют на качество модели. Отказ от кусочков же приводит к куда большим дефектам при авторазвертке, то её перекашивает на какой то произвольный угол, то пляшет плотность самой сетки, когда голова у человека размером с кулак и такое я встречаю довольно на многих моделях.
И я был готов мириться с любым дерьмом, но то что в абсолютно любом развертывальщике развертка накладывается сама на себя, это уже какой то позор. Неужели так трудно определить дистанцию вертексов между собой чтобы они не перекрывались? И по сути все пакеты используют одни и те-же алгоритмы, с одними и теми же дефектами, отлчие состоит только в дополнительном инструментарии. С чёртовой развесовкой таже песня, состоящая чуть более чем полностью из плясок с бубном.

Когда разберусь с этими бедами, мне вручат медальку "почётный шаман мира 3д"

Отправлено Дядя Миша 21-07-2020 в 07:33:

Цитата:

FiEctro писал:
Неужели так трудно определить дистанцию вертексов между собой чтобы они не перекрывались?

из трёхмерного пространства в двухмерное всегда нетривиальная задача.
Это наоборот легко.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 25-07-2020 в 10:55:

Так товарищи. Вероятно в этом году увидит свет первая публичная версия, которая в дальнейшем будет обновляться, сохраняя совместимость.
Чтобы народ мог реагировать на разные крэшы и вылеты, а так же вносить свои предложения, в некоторой степени определяя дальнейшую судьбу развития.

Что мне осталось сделать до первого такого релиза:
1. дописать лайтмаппер до боле-мене вменяемого состояния (в аттаче картинка, как он сейчас работает).
2. разработать новый формат моделей (форматы спрайтов\шрифтов уже созданы).
3. в рендерере фундаментальная система проходов, контролируемых пользователем, возможность написать отложку или любую мульти-пасс систему, вообще не затрагивая код. Мне абсолютно не улыбается это делать, потому что рендеринг это эксперименты на 90% и каждый раз лезть в код и что-то там перекомпиливать дико неудобно. В принципе рендерер, как вы знаете уже процентов на 70 именно так устроен, но проходы он пока что не поддерживает и нет связи между различными таргетами. Т.е. можно написать какой угодно однопроходной рендерер, а вот скажем зеркала или динамические источники света подключить пока не получится, вот этот функционал и надо реализовать. И потом уже спокойно в скриптах экспериментировать со всякими моделями непрямого освещения, хоть LPV, хоть рейтрейс.
4. плагин для Джека с поддержкой нового формата моделей и материалов.
Вот собсно, эти четыре момента - они основные, если я успею за полгода.

Это не значит, конечно, что движок уже готов на 100%, это значит, что получившийся продукт можно будет изучать, осваивать и потихоньку портировать на него свои наработки, как с дальним прицелом, так и для проверки на прочность конструкции.

Добавлено 25-07-2020 в 13:55:

Аттач забыл

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 25-07-2020 в 13:22:

А карты модели делать можно будет? И в каком формате им кормить модели?

Отправлено Дядя Миша 25-07-2020 в 13:45:

Цитата:

FiEctro писал:
А карты модели делать можно будет?

ну пока через вставку точечной модели в скайбокс. Впрочем, для Метро того же, карты именно так и делаются. Только там скайбокс не нужен.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 26-07-2020 в 13:22:

Вы таки будете удивлены, но даже обычный линейный свет во всех трёх кваках немного различался, ниже скриншоты.

Quake 1:

C++ Source Code:

angle = (1.0 - 0.5) + 0.5 * angle;

add = (light->photons - dist) * angle;

add = max( add, 0.0 );

В первом квейке был не Фонг, а Халф-Ламберт, из-за чего там освещение персов так идеально гармонировало с лайтмапой. Просто они были освещены единой моделью освещения.

Quake 2:

C++ Source Code:

add = (light->photons - dist) * angle;

add = max( add, 0.0 );

классический линейный свет по Фонгу

Quake 3:

C++ Source Code:

add = light->photons * 0.9375 - dist * angle;

add = max( add, 0.0 );

Тут непонятно. С одной стороны, это свет, который идеально вписывается в заданный радиус, т.е. фактор освещённости превращается в мировые юниты. С другой стороны - корректно ли это? Обратите внимание на убранные скобки, множитель практически не влияет, я его вставил, потому что он есть в самом ку3.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 26-07-2020 в 13:25:

Сделай ещё ХДР лайтмапы как в Лост коасте

У Психопата имхо самое красивое освещение получилось, остальное какое то кривое гамно, которое ещё не те цвета что выставил маппер рисует.

Отправлено Crystallize 26-07-2020 в 14:01:

Цитата:

Дядя Миша писал:
Обратите внимание на убранные скобки

скобки Кармак убрал, не ты?

Цитата:

FiEctro писал:
У Психопата имхо самое красивое освещение получилось, остальное какое то кривое гамно, которое ещё не те цвета что выставил маппер рисует.

Пишешь три строчки гамма-коррекции и будет те цвета рисовать.

Отправлено Дядя Миша 26-07-2020 в 16:16:

Цитата:

Crystallize писал:
скобки Кармак убрал, не ты?

Странный вопрос. Я вам показываю модели освещения из разных квак и сам скобки убираю?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 26-07-2020 в 16:33:

ИМХО ку3шный вариант самый паршивый, видите вот это уродливое белое пятно по центру с чёткими гранями? Оно занимает практически всё освещаемое пространство, когда на первых двух вариантах хоть это пятно по прежнему и присутствует, но переход уже не такой жёсткий, и мапперам нет необходимости увеличивать радиус этого уродства.

Отправлено XaeroX 26-07-2020 в 16:50:

Я полностью согласен с FiEctro в обратную сторону. Вариант в ку3 самый корректный и красиво выглядящий, разумеется, при правильных радиусах и при наличии радиосити (которой в ку3мапе нет, но могла бы быть).
Проблема в том, что он напрямую не совместим с халфовской моделью. Но и это поправимо, в принципе. В vmap я сделал поддержку обеих моделей, ну вы помните, я показывал халфовские карты под волатилой.

__________________

Отправлено Дядя Миша 26-07-2020 в 17:28:

Цитата:

FiEctro писал:
ИМХО ку3шный вариант самый паршивый

это не имеет никакого значения, дизайнер сам будет задавать формулы освещения, причём сразу для реалтайма и лайтмапы, чтобы они совпадали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 26-07-2020 в 17:39:

Цитата:

Дядя Миша писал:
причём сразу для реалтайма и лайтмапы, чтобы они совпадали.

Для матчинга статики и динамики можно просто считать статик-лайты так же, как динамики - по радиусу с квадратичной аттенуацией, а не по фотонам. А статики оставить с полноценным затуханием. Я в волатиле так и сделал, и вы можете посравнивать картинки на статике и динамике.

__________________

Отправлено Дядя Миша 26-07-2020 в 17:57:

Ну если формулы одинаковые, какая разница где считать?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 27-07-2020 в 04:32:

Цитата:

Дядя Миша писал:
Просто они были освещены единой моделью освещения.

Так они же освещались люкселем под ногами, а не какой-то отдельной моделью освещения.

Отправлено Дядя Миша 27-07-2020 в 09:55:

Для квадратичного радиуса затухания обычные значения света подходят мало. Ну вообщем-то, как это имеет место быть для area light, вы же обращали внимание, что там значения идут от нескольких тысяч.

В Quake3 любое значение точечного лайта умножается на 7500. Не знаю почему именно 7500.
В халфе, как мы помним квадрат самого себя делится на 10 и опять умножается на себя. Таким образом.
Для халфы:
Интенсивность 100.
l1 = 100 * 100 / 10;
intensity *= l1; // 100 * 1000
Результат 100 000 едениц умножить на DLIGHT_SCALE 2.0 (по умолчанию директ в халфе умножается на 2). Т.е. 200 000

Для Quake 3
Интенсивность 100.
intensity = 100 * 7500;
Результат 750 000 едениц.
В 3.75 раз выше.

Добавлено 27-07-2020 в 12:38:

Слева халфа, Справа ку3

Добавлено 27-07-2020 в 12:55:

В халфе экспоненциальная функция получается. Потому что при яркости 200, халфа уже даст 1 600 000, а ку3 1 500 000 соответственно.
При значении 300, 5 400 000 и 2 250 000.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 27-07-2020 в 19:57:

Цитата:

Дядя Миша писал:
С одной стороны, это свет, который идеально вписывается в заданный радиус, т.е. фактор освещённости превращается в мировые юниты. С другой стороны - корректно ли это?

О, я так делал в старой версии After Engine, когда приделывал 2D нормал-мэппинг. А то в 2D очень уж неудобно когда радиус лайта нечеткий

__________________
-Brain is dead-

Отправлено Дядя Миша 29-07-2020 в 09:56:

Наконец-то удалось как следует протестировать альтернативный упаковщик "уголком", за который так топил наш друг.
В обычных условиях оценить эффективность затруднительно, это надо считать неиспользованные пиксели, причём на одном и том же наборе данных, а тут никогда не угадаешь. Но вчера у меня появилось одно очень простое соображение. Вот у нас есть глобальный список лайтмап-кусочков, которые должны быть упакованы в атласы. Как мы обычно делаем в таком случае? Мы их пакуем-пакуем-пакуем, а если AllocBlock вернул false, то атлас считается заполненным, но ведь это в корне неверно! Это всего лишь означает, что в атласе уже нет места для этого конкретного куска. Он слишком большой. Но вероятно есть места для меньших кусков? Алгоритм реализуется очень просто - мы каждый раз пытаемся добавить в очередную страницу атласа все имеющиеся у нас кусочки лайтмап (разумеется помечая уже добавленные). Если AllocBlock нас послал - мы просто пропускаем этот кусочек и пытаемся добавить еще какой-нибудь. И так, пока не пробежим весь список. Разумеется он отсортирован от большого к малому.
И вот на таких вводных, я наконец-то получил чистые условия. Уголок действительно пакует эффективнее, т.к. он вообще не оставляет дыр при таком подходе. На той же q3dm1 я получил 5 идеально заполненных лайтмап без единого свободного пикселя. И шестую - заполненную процентов на 30. С Кармаковским алгоритмом я получил шесть неидеально заполненных лайтмап и седьмую, слегка начатую.
Но тут еще конечно вопрос, почему сам алгоритм оставляет довольно большие дыры в некоторых местах. Скорее всего особенность работы by design. Потому что, как я понял, для упаковщиков 70% успеха - это грамотная сортировка и подача. То есть всё свелось к тому, может ли алгоритм теоретически обеспечить 100% заполнение или нет. Да не случайным образом, а выдавая стабильные результаты. Ну вот пять полностью заполненных страниц вполне меня убедили в этом.
Полагаю это и есть самый валидный тест упаковщиков.

ЗЫ. картинки прикладываю, правда на данный момент их поровну, но дырки в заполненных атласах на кармаковском алгоритме видны невооруженным глазом, причём уже нельзя сказать "ну он их так расположил".

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 29-07-2020 в 18:38:

Дядя Миша
А вот ту формул(ы) освещения, она вкомпилена будет, или её можно будет задать/выбрать в конфиге?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 29-07-2020 в 19:25:

Цитата:

thambs писал:
А вот ту формул(ы) освещения, она вкомпилена будет, или её можно будет задать/выбрать в конфиге?

Как раз собирался написать об этом. Формулы задаются в настройках энтити, ну там же, где и остальные функ_группы. Пример:

C++ Source Code:

"light"

3	if( target ) setupNormal( "target", "origin" );

5	if( light )

7	// Quake1, Quake2, Quake3 light definition

8	setupIntensity( "_color", "light", 300.0 );

10	if( "targetname" == false && "spawnflags" == 1 )

12	// linear lighting

13	scaleIntensity( "self", 0.9375, 1.0, 1.0 );

14	setupAttenuation( 0.0, 1.0, 0.0 );

    else

18	// quadratic lighting

19	scaleIntensity( "self", 7500.0, 1.0, 1.0 );

20	setupAttenuation( 1.0, 0.0, 0.0 );

24	if( _light )

26	// GoldSource light definition

27	setupIntensity( "_light", "_light", 300.0 );

28	scaleIntensity( "self", "self", "self", 0.1 ); // scaled cubic

29	setupAttenuation( 1.0, 0.0, 0.0 ); // quadratic, linear, constant

Т.е. для компилятора не существует никаких "встроенных" энтить, их всегда определяет сам пользователь. Ну это не окончательный вариант, скорее прикидочный. Хочется красиво сделать, но из-за долбаных магических чисел приходится городить вспомогательный огород, типа scaleIntensity. Но вообще через эти настройки воспроизводится любой тип затухания. В теории можно будет еще и фотометрические профили подгружать, но то потом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 30-07-2020 в 21:15:

Выработал неплохой алгоритм для относительно бесшовного наложения лайтмап на поверхность. Неидеально конечно, но тут два момента.
1. алгоритм предиктабельный. Т.е. полигоны, которые не группируются всегда одни и те же, на всех копиях геометрии, случайные пятна исключены.
2. существует возможность кастомного объединения групп по заданным углам. Ну типа как в q3map2 была настройка q3map_lightmapAxis. Например, с её помощью я весь потолок на спонзе объеденил в группу и он стал гладеньким без единого шва.
3. для пачтей развёртка лайтмапы генерируется на базе её сетки. которая всегда двухмерна, а следовательно идеально раскладывается в UV.

Собсно, проблема какого рода осталась, причём абсолютно везде. Эти швы невозможно уничтожить в принципе. Допустим у нас есть круглая колонна.
Пусть это будет патч, т.е. идеальное разложение на UV. Ну и что? Она всё равно не замкнута в 2D. В месте соприкасания потенциально будет шов. Ведь в 2д не замкнёшь поверхность саму на себя нипочём. В случае автоматической генерации всё еще грустнее. Такая колонна разобъется на 4 кусочка, соответственно XY в 4 стороны. Ей можно назначить кастомный угол разбиения, но тогда она превратится в кольцо на лайтмапе, т.е. будет искажение поверхности. Получается, что на высокой колонне будут растянутые люксели. Впрочем это общие проблемы развёрток, тут ничего особо не поделаешь.

Добавлено 31-07-2020 в 00:15:

Скриншоты

Всё что вы видите - это набор треугольников, здесь нет никаких квадов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 30-07-2020 в 21:35:

На спонзе тени на полу поломались.

Отправлено Дядя Миша 30-07-2020 в 21:45:

Это полигоны огня тень отбрасывают.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-07-2020 в 00:02:

На арках у основании над столбом к слову тоже какая то дичь происходит, причём видно прямо что цвет лайтмапы на полигоне радикально отличается от всех остальных его соседей, что аж швы вылазят. Компилятор запекает свет до того как нарезал лайтмапу на кусочки или после? И можно скриншоты с высоким разрешением лайтмапы? Какой алгоритм составления UV карт там (до того как он их пакует)?.

Отправлено Crystallize 31-07-2020 в 04:53:

Цитата:

Дядя Миша писал:
Ей можно назначить кастомный угол разбиения, но тогда она превратится в кольцо на лайтмапе, т.е. будет искажение поверхности.

Сделай особый формат битмапы который основан не на декартовых а на полярных координатах.

Отправлено Дядя Миша 31-07-2020 в 09:27:

Цитата:

FiEctro писал:
На арках у основании над столбом к слову тоже какая то дичь происходит

ну так это уже другая лайтгруппа.

Цитата:

FiEctro писал:
И можно скриншоты с высоким разрешением лайтмапы?

лайтмапа сразу считается в родном разрешении. Никогда не понимал эту дурь - сперва посчитать в высоком, а потом даунсэмплить. Точнее говоря, оно для блура нужно, но там даже не в два раза, там на несколько процентов она больше становится. А вот так, чтобы в два, в четыре раз больше - я таким никогда не занимался. Оно только время жрёт, не давая ничего.

Цитата:

FiEctro писал:
Какой алгоритм составления UV карт

Snap to nearest axial.

Добавлено 31-07-2020 в 10:28:

А знаете, я уже почти верю, что Сталкер лайтмапу неделями рассчитывает. Потом расскажу почему. Там не единственный промах, там целый комплекс неудачных решений.

Добавлено 31-07-2020 в 12:25:

Потихоньку паззл складывается. Слева P2ST, справа makebsp.

Я вам тогда еще говорил, что P2ST умеет переваривать кутришные карты, в том числе и патчи, но в первую очередь делал это для себя - для референса. Он и модельки из ase умеет грузить, правда освещает их совсем погано.
Но в данном случае мне важно, чтобы совпали лайтформулы, точнее то, что я задал в настройках компилятора. Чтобы можно было вывести любую лайтформулу под старый тип игры или же создать свою собственную.

Добавлено 31-07-2020 в 12:27:

Вообще любопопытная получилась ситуация. NT на данный момент умеет грузить халфовские карты, кутришные карты и свой собственный формат. И всё это нужно только для того, чтобы обеспечить в дальнейшем лёгкую миграцию, т.е. я выброшу потом эту поддержку, останется только родной формат.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-07-2020 в 10:47:

>> Snap to nearest axial

Не удалось найти в гугле.

Отправлено Raid 31-07-2020 в 13:31:

Цитата:

FiEctro писал:
>> Snap to nearest axial

Не удалось найти в гугле.

Тут по-моему вообще ничего не гуглится, из того что происходит. Тоталитарная секта свидетелей Кармаковых или как там.

Отправлено Дядя Миша 01-08-2020 в 09:27:

Кстати, к вопросу о достоверности.

Слева p2st с тремя баунсами. Справа ку3 фейковый, небесная поверхность - один большой излучающий полигон.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-08-2020 в 09:36:

Так второе это просто эмбиент.

Отправлено Aynekko 01-08-2020 в 15:31:

Тени конечно ужас, вот про них я и говорил с ними что-то будет делаться в NT?

Отправлено thambs 01-08-2020 в 15:46:

Дядя Миша
Отчего на первом такая странная интерполяция?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Crystallize 01-08-2020 в 16:45:

Баунсов справа нету?
Кстати, я после ковыряния в сорцах VRAD так понял что если в коде радиосити домножать не на Patch1 а на Patch2 то будет освещение как в Сорсе.

Отправлено Дядя Миша 01-08-2020 в 17:22:

Цитата:

FiEctro писал:
Так второе это просто эмбиент.

Просто эмбиент выглядит вот так:

Запомни и больше не позорься.

Цитата:

Aynekko писал:
Тени конечно ужас, вот про них я и говорил

Пригладил:

Цитата:

thambs писал:
Отчего на первом такая странная интерполяция?

китайская.

Цитата:

Crystallize писал:
Баунсов справа нету?

неа. Небесная плоскость излучает слабый свет. В ку3 вся "вторичка" так устроена. Даже хвалёный q3map2, в котором есть радиосити, он на самом деле по дефолту выключен, потому что ждать. пока он управится можно часов пять-шесть.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-08-2020 в 17:39:

Цитата:

Дядя Миша писал:
Просто эмбиент выглядит вот так:

Запомни и больше не позорься.

Добавь AO и будет тоже самое. И почему кубик, а не спонза?

Отправлено Дядя Миша 01-08-2020 в 19:26:

Цитата:

FiEctro писал:
Добавь AO и будет тоже самое

тебе просто нравится нести бред

Добавлено 01-08-2020 в 22:26:

Ты вообще понимаешь, что AO это локальный радиосити с одним переотражением?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 01-08-2020 в 19:35:

Дядя Миша
А точка соответствующая люкселю локализована в его центре, или он пускает несколько пространственно-разнесённых лучей и сворачивает результат с соответствующим ядром?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 01-08-2020 в 21:49:

thambs ни то ни другое. PTPFF там. Впрочем есть некоторые параметрические трюки, позволяющие обойтись и без него. Из простых способов мне понравился кламп дистанции луча на sqrt( area ).

Поясню. Любая формула затухания света так или иначе базируется на дистанции от люкселя до оригина источника. Чем точка ближе, тем, очевидно выше яркость. Ну вот если полигон к источнику света максимально близко, то получается пятно. С этим легко бороться, ограничив минимальную дистанцию луча на некоторое значение. Для субдивайд-ареалайтом оптимальный кламп на sqrt( area ); Конечно PTPFF даёт куда более приятный результат.
Ссылка: https://www.youtube.com/watch?v=VKlg5sI_pxI
а то опять начнете "не гуглится".

Решил я тут посравнивать как q3map2 выходит из сложных ситуаций. Ну например, как эту чёртову колонну осветить без швов. Набрал все известные мне мантры - q3map_lightmapAxis y, q3map_lightmapMergable, q3map_shadeAngle 179 и q3map_forceMeta.

То что получилось - на левом скрине. Потом этот же шейдер сунул своему компилятору. Результат на правом скрине. Фактически сработала только одна команда: "q3map_lightmapAxis y" остальные мало на что влияют в данном случае, а для моего компилятора часть команд это вообще заглушки, они не требуются.

Добавлено 02-08-2020 в 00:49:

Дырки на тенях это edge rendering, не обращайте внимания.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 02-08-2020 в 10:31:

Судя по всему эта задачка с наложением лайтмап вообще не имет однозначного решения. Потому что даже в UE4 пользователю на выбор предлагается несколько вариантов. Таким образом дефолтный вариант должен лишь обеспечивать приемлимый уровень качества. Да, на лайтмапе будут кое-где швы в неудобных местах, но если хочется довести до идеала, придётся немного подшаманить. Само шаманство обычно заключается в некоторых подсказках компилятору, то есть речь не идёт о ретопологии и прочих жутких вещах. А то я как-то читал статью про наложении лайтмап в уече.
Вот эту кажется: https://docs.unrealengine.com/en-US...ping/index.html

Добавлено 02-08-2020 в 13:31:

А впрочем, чего я туплю? Вон он этот уеч в открытом доступе, надо посмотреть как там сделано. Среди методов и алгоритмов которые известны разработчику неплохо бы еще и понимать, какие из этих методов используются в продакшене, а не только восторгаться абстрактными демками как наш друг.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-08-2020 в 10:34:

Без адекватной развёртки бесшовную лайтмапу нормально не построить, я сам в юнити с этим столкнулся. А адекватную развёртку можно сделать только ручками, я задавался этим вопросом в соседней теме. Ни один алгоритм не даст приемлимого качества, всегда надо будет допиливать ручками.

Отправлено Дядя Миша 02-08-2020 в 12:54:

Я думаю сделать три-четыре варианта для лайтмапных развёрток.

1. орто-проекция. Используется по дефолту для брашей и моделей. На брашах практически всегда даёт идеальный результат из-за простой геометрии. К тому же надо понимать, что используемая техника - это не совсем то, что было в кваках, она сложнее, там идёт группировка сурфейсов под допустимыми углами. Так же можно задать единый кастомный угол ортопроекции и получить совсем сглаженный меш, но лайтмапу может и растянуть.

2. UV на основе регулярной сетки. Этот метод идеально подходит для параметрических поверхностей, типа кривых безье, которые представляют собой двухмерную сетку. А раз сетка двухмерная, то у нас уже фактически готовая развертка. На данный момент она неотключаемая для патчей, но потом я введу кастомизацию.

3. пользовательский способ: генерация развёртки на основе текстурных UV с проверкой на самопересечения. Ну собсно, как в UE4.

4. пользовательский способ, двухпроходной. Генерация развёртки на основе ковариантной матрицы (ортопроекция), а затем на базе этой развёртки LSCM генерирует боле-мене приличную.

5. пользователь ручками создаёт развёртку для лайтмапы.

Думаю этих вариантов достаточно для удовлетворения всех условий и ситуаций.

Добавлено 02-08-2020 в 15:51:

И в связи с этим, очевидно встаёт вопрос, какой из форматов поддерживает множественные UV? Потому что smd такое не умеет, а следовательно негодится.

Добавлено 02-08-2020 в 15:54:

Цитата:

Дядя Миша писал:
Генерация развёртки на основе ковариантной матрицы (ортопроекция), а затем на базе этой развёртки LSCM генерирует боле-мене приличную.

Ортопроекция обычно создаёт развёртку под непрямым углом и сильно растягивает геометрию. Поэтому и в два прохода. Я еще пробовал boundary-размотку, но чёт она мне совершенно не понравилась. Да и то верно, стали бы изобретать LSCM если бы справлялся простейший алгоритм.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-08-2020 в 13:10:

Цитата:

Дядя Миша писал:
И в связи с этим, очевидно встаёт вопрос, какой из форматов поддерживает множественные UV? Потому что smd такое не умеет, а следовательно негодится.

.blend, .fbx, .dae вроде получилось, вот с .obj к сожалению не вышло.

Цитата:

Дядя Миша писал:
Ортопроекция обычно создаёт развёртку под непрямым углом и сильно растягивает геометрию. Поэтому и в два прохода. Я еще пробовал boundary-размотку, но чёт она мне совершенно не понравилась. Да и то верно, стали бы изобретать LSCM если бы справлялся простейший алгоритм.

Да LSCM тоже не справляется, иногда даже делает только хуже. Я тут подумал, что развёртка очень хорошо работает с кольцами. Ну вроде цилиндров или коробки. Не знаю насколько это полезно, но может есть алгоритмы поиска таких колец? Вроде это не особо сложная задача.

Вот почему я писал что рано или поздно народ придёт к вокселям. Все эти UVшки, чистой воды фейк, попытка натянуть 3д на 2д.

Отправлено Crystallize 02-08-2020 в 14:19:

FiEctro а изображать ту же круглую колонну при помощи квадратных вокселей это намного лучше?

Отправлено thambs 02-08-2020 в 14:42:

Crystallize
Как координата вокселя соотносится с координатами на поверхности?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Crystallize 02-08-2020 в 14:49:

ну да это я уже чисто про геометрию

FiEctro ты предлагаешь в принципе отказаться от моделей брашей и развёрток? А то может ты имеешь в виду воксели в смысле трехмерного массива из лайтпроб, лайтгрид из ку3.

Отправлено FiEctro 02-08-2020 в 15:25:

Crystallize
Ничего я не предлагаю.

Отправлено Дядя Миша 02-08-2020 в 16:06:

Цитата:

FiEctro писал:
.blend, .fbx, .dae вроде получилось, вот с .obj к сожалению не вышло.

Может Nemyax чего подскажет.

Цитата:

FiEctro писал:
Да LSCM тоже не справляется, иногда даже делает только хуже

Ну я вообще настороженно отношусь к солверам с комплексными числами. Я не математик, для меня это чёрный ящик.

Цитата:

FiEctro писал:
Я тут подумал, что развёртка очень хорошо работает с кольцами

Кольца сильно искажают проекцию. Да оно, гладенько, но там где по смыслу должны быть десятки люкселей умещаются 2-3 растянутых. А LSCM как раз с этим и борется.

Цитата:

FiEctro писал:
Все эти UVшки, чистой воды фейк, попытка натянуть 3д на 2д.

Тогда ты принципиально должен ориентироваться на местности только по глобусу, ведь любая карта - фейк.

Цитата:

Crystallize писал:
а изображать ту же круглую колонну при помощи квадратных вокселей это намного лучше?

ты будешь смеяться, но чтобы превратить круглую колонну в квадратную достаточно снапнуть её вертексы к люксельной сетке, я так уже делал. Жаль скринов не сохранилось. Вообщем-то это не панацея, хотя да, иногда даёт неплохие результаты.

Цитата:

thambs писал:
Как координата вокселя соотносится с координатами на поверхности?

я парой страниц выше объяснял. Да в сущности все эти точки можно рассматривать как воксели. Лайтмапы именно так и строятся.

Добавлено 02-08-2020 в 19:06:

И да, про LSCM еще вот какой момент. Вы не забывайте, что он не генерит координаты с нуля, ему надо скормить какую-то базовую сетку. Так вот многое еще зависит от качества этой сетки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 02-08-2020 в 16:30:

Ещё glTF по идее держит не менее двух UV-наборов.

Отправлено FiEctro 02-08-2020 в 16:42:

Цитата:

Дядя Миша писал:
Кольца сильно искажают проекцию. Да оно, гладенько, но там где по смыслу должны быть десятки люкселей умещаются 2-3 растянутых. А LSCM как раз с этим и борется.

Ясно, ну тогда только вручную.

Цитата:

Дядя Миша писал:
Тогда ты принципиально должен ориентироваться на местности только по глобусу, ведь любая карта - фейк.

https://sun1-97.userapi.com/pW_DBMT24cEeQArxoiyKRJX7t_exjldH2I2Ajw/9Z_g7lCQzLg.jpg

Отправлено Дядя Миша 04-08-2020 в 17:34:

Вот что я хотел отметить. Когда только-только начинаешь программировать - никаких проверок ни на что не делаешь. Ессно оно вылетает при каждом удобном случае. Когда ты уже набрался достаточно опыта - лепишь эти чёртовы проверки везде, даже там где по смыслу они не особо нужны. И тем самым просто загоняешь проблему еще глубже. Чтобы её потом было невозможно отдебажить. По хорошему код должен работать таким образом, чтобы не допускать появления невалидных данных в принципе.
А если допустил, значит это нештатная ситуация. Поэтому если где-то вылетает - не надо там ставить проверку. Надо разобраться как там вообще появились невалидные данные. Т.е. ошибка где-то вообще в другом месте.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 04-08-2020 в 18:13:

Дядя Миша
Ты же сам понимаешь что не бывает идеальных алгоритмов. Везде приходится идти на уступки и компромисы. С теми же развертками, какой то метод работает в одних случаях лучше, а какой то в других лучше чем этот.

Отправлено Government-Man 04-08-2020 в 18:53:

Цитата:

Дядя Миша писал:
По хорошему код должен работать таким образом, чтобы не допускать появления невалидных данных в принципе.

А как ты проверишь, что код не допускает появления невалидных данных?

Отправлено Дядя Миша 04-08-2020 в 19:16:

Цитата:

Government-Man писал:
А как ты проверишь, что код не допускает появления невалидных данных?

в основном - прецендентным образом. 90% прецедентов находятс во время первичной имплементации, тестирования и отладки. Оставшиеся 10% можно ловить всю жизнь.

Цитата:

FiEctro писал:
Ты же сам понимаешь что не бывает идеальных алгоритмов

это тут вообще не к месту. Я не про то, что результат устраивает пользователя, я про то, что при обработке данных не должно быть инвалидных значений. Если источник данных допускает появление таких значений, разумно это отловить при загрузке. Но в дальнейшем их ловить нет никакого смысла, ибо если они появились где-то дальше - надо искать ошибку в алгоритме, а не лепить проверки, не докапываясь до сути появления.

Government-Man в UE4 по прежнему | это DotProduct, а ^ CrossProduct?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Government-Man 04-08-2020 в 21:19:

Цитата:

Дядя Миша писал:
в UE4 по прежнему | это DotProduct, а ^ CrossProduct?

Да, хотя я все-равно предпочитаю использовать FVector::DotProduct() и FVector::CrossProduct() - так нагляднее, хотя и многословнее.

Отправлено Дядя Миша 04-08-2020 в 21:36:

В UE3 не было. Вообще за такое руки надо отрывать. Один из самых мерзких антипаттернов. Вообще в UE3 довольно много антипаттернов, навскидку.
Как в четвертом не знаю, сорцы не дают без регистрации.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-08-2020 в 21:16:

Инстансинг

Ну вот и встала в полный рост проблема. Я еще, когда над параноей работал, прекрасно это понимал, собсно куча одинаковых моделей на карте - это очень плохо во всех отношения. Это не только избыточные данные на диске, но и видеопамяти. Ну хорошо, на грасстесте от силы древеьев мало, ёлочи и той штук 30 не наберётся. А если я захочу ТЛез32? Сосны, поляно, медвед. 65 тысяч килоёлок. Сколько такая карта будет весить?
Одна ёлка занимает полтора мегабайта. Значит карта из уникальных ёлок будет весить 122 гигабайта. То есть вообще не вариант. И да, 65 тысяч килоёлок, это ТЛез16 всего-то навсего. Инстансинг, напомню хранить только то, что отличается. Матрица трансформации и освещение. С динамикой вопросов нет. Как быть со статикой? С лайтмапой на самом деле очень просто - надо завести в описании модели оффсет до реального места в атласе и номер страницы. А вот повертексное так уж не запишешь.
Но я так рассуждаю - если уж на модели есть лайтмапа, то и фиг с ним, с повертексным-то. К тому же возможность встроить модель внутрь карты, никуда не исчезнет, она тоже останется.
Но сделать инстансинг - полдела. Мне еще предстоит работать промежуточный бинарный формат кэшированных моделей. Объясню почему. Генерация лайтмапы, равно как и построение конвексного хулла - весьма небыстрое дело. Есть резон построить это один раз, сохранить в кэш, а в дальнейшем просто брать при компиляции эту модельку из кэша. Ну или вообще хранить снаружи, чтобы не усложнять. Или использовать оба варианта. Возможно что промежуточный бинарный формат станет одним из основных неанимированных форматов мешей для движка. Как оптимальнее - станет понятно уже по факт имплементации.
В принципе в параное есть зачатки такого кэша, она создаёт файлы .TBN и .CLIP видели наверное.

Добавлено 08-08-2020 в 00:11:

Вообще до смешного доходит. makebsp трудился над грасс-тестом две с половиной минуты. Знаете чем он занимался? Генерил текстурные координаты персонально для каждой одинаковой ёлки. В сумме 0.3-0.5 секунд, но и ёлочи тоже порядочно ведь на карте.

dolight строил KD-tree для эффективной трассировки 22 секунды.
А собственно рассчёт освещения длился 13 секунд. Лайтмапа, к слову немаленькая, 1024х1024. Чёрные треугольники - это не артефакты, они просто развернуты в сторону от солнца. Вообщем узкое место совсем не там, где его можно было-бы ожидать.
ЗЫ. лайтмапа пропорциональная, форум не пускает.

Добавлено 08-08-2020 в 00:16:

Вообще видно наглядно, как все старые "проверенные" технологии из 90-х отваливаются, когда речь заходит о получении боле-менее достойной картинки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 08-08-2020 в 12:00:

Поскольку разработка движка ведётся примерно так же, как выполняется программный код, это меня приводит порою к очень далёкому отклонению от изначальной цели. Ну скажем, решил я разработать новый формат шрифтов. А где шрифты - там и спрайты. Значит надо переписать худ и меню, чтобы оно использовало новые картинки. Вот и разработка рендерера (эксперименты с динамическим освещением). вполне логично пришла к тому, что неплохо бы иметь референс в качестве лайтмапы, а где лайтмаппер, там и новый формат уровней, а в новом формате уровней неплохо бы предусмотреть возможность embedded-моделей - ну это, чтобы не дублировать их, а хранить одну копию только. Но поскольку для этих моделей неплохо бы предусмотреть какой-то промежуточный кэш, потому что вычисление координат лайтмапы, сглаживание нормалей, рассчёт конвекс-меша, всё это, очевидно занимает какое-то время, лучше сделать кэш. Но какой смысл лепить для кэша какие-то искуственные форматы? Лучше уж сразу его сделать чем-то типа студиомодели, чтобы его можно было использовать и так и эдак. Но всё равно, поскольку этот формат встраивается в карту, логично обеспечить сходность структур, чтобы всё совпадало. И тут я прихожу к мысли, что разделение на уровни и модели - излишне. У них весьма много общего - коллизия, BSP-дерево, сурфейсы, вертексы (у вертексов хранится либо повертексное освещение, либо номера костей), сурфейсы. Ну вообщем отличия только в том, что у BSP есть виздата с порталами, а у моделек - кости. Вполне логично объединить всё это в общий формат с чанками. Получим доброкачественный комбинаторный взрыв, возможности которого по настоящему смогут раскрыть только будущие пользователи движка.
Опять же не придется городить разные просмотровщики для моделей и уровней. Но есть и еще один важный момент - у моделей, как известно есть анимации, а у брашей их нет. Но и тут всё довольно удачно складывается - дело в том, что хранить анимации в модели неудобно и сейчас так уже практически никто не делает. Вместо этого используется банк анимаций. Наделал человек персонажей, к примеру. Они все разные, но у них один и тот же скелет. Какой смысл вкомпиливать эти анимации в каждую модель заново, дублируя? Никакого. Банк анимаций будет строится автоматически, при компиляции каждой новой модельки, если конечно они в нее добавлены. Доступные анимации будут находиться тоже автоматически, по сравнению скелетов. У скелета должны совпасть кол-во костей, имена костей и их иерархия. Ну можно еще конечно позицию-вращение проверять, но это пусть Nemyax скажет, важно это или нет.

Добавлено 08-08-2020 в 15:00:

Мне тут кстати забавная мысль пришла в голову. Для таких объединённых форматов можно будет использовать именованные аттачменты на уровнях, в качестве каких-то точек-локаций, которые не будут жрать эдикты. Ведь очень же часто возникает ситуация, когда надо указать точку, под которую отводится целая энтить. Ну там спавн телепорта или инфо_плеер_старт.
А тут аттачменты. Можно будет сделать сквозной поиск через энтити и такие вот точки в особых случаях. Патч-корнеры всякие так можно хранить.
Или спавнеры тех же эмбеддед моделей, если мы не хотим, чтобы они занимали эдикт. Опять таки энтити в движке доступны весьма условно, а вот такие точки - всегда.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 08-08-2020 в 17:12:

Цитата:

Дядя Миша писал:
Ну можно еще конечно позицию-вращение проверять, но это пусть Nemyax скажет, важно это или нет.

Важно для чего? Если взять скелеты одинаковой топологии с разными трансформами костей, то анимация для первого конечно развалится на втором. Но это всё равно не повод искусственно запрещать такие переносы.

Отправлено thambs 08-08-2020 в 17:26:

Дядя Миша
Интересно, несколько таких 'моделей' можно будет собрать в единый префаб/сущность/контейнер?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 08-08-2020 в 20:12:

Цитата:

thambs писал:
Интересно, несколько таких 'моделей' можно будет собрать в единый префаб/сущность/контейнер?

Так в том-то и соль! Эта схема идеально ложится на все мои задумки.
Можно такую модель использовать как карту. Можно в карту вкомпилить модели. Единственное условие - они все должны быть статические. Ну оно и понятно - встроенным моделям анимация ни к чему всё же. Нет, ну что-то такое процедурное типа ветра конечно можно будет сделать, но и только.
Через какие-то функции. Впрочем оно везде так, кроме разве что кризиса, где эти йолки реально можно было рубить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 09-08-2020 в 14:08:

Ничего не понял, но напомнило мне то что я описывал тут

Отправлено Дядя Миша 10-08-2020 в 13:00:

Слева p2st честный радиосити. Справа - фейковые баксплэши. Яркость немного не совпадает, да, потом подкручу.

Ну это так, навскидку.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 10-08-2020 в 13:06:

Цитата:

фейковые баксплэши

Что это?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено FiEctro 10-08-2020 в 13:08:

Пол и стены пересвечены, а потолок чёрный.

Отправлено Дядя Миша 10-08-2020 в 13:50:

Цитата:

thambs писал:
Что это?

на расстоянии 24 юнита от излучающей поверхности спавнится фейковый поинтлайт с яркостью 0.05 от исходной яркости этой поверхности.

Цитата:

FiEctro писал:
Пол и стены пересвечены, а потолок чёрный.

пересвечены потому что яркость не настроена. Потом подгоню и еще раз сравним. В принципе, прямой радиосити тоже несложно делается - надо просто наспавнить вместо патчей - кучу таких же маленьких лампочек. А результат сохранять сразу в лайтмапу, вместо патчей. Это даст оптимизацию по памяти. Не возникнет ситуации, когда памяти хватило на прямой свет, а на индиректе всё вылетело на последних секундах рассчёта.
Единственный минус такого подхода, в отличие от Instant Radiosity - каждый баунс по времени считается столько же, сколько и первый. С другой стороны, кол-во лампочек на каждой итерации должно уменьшаться. Правда это не получится так красиво уложить как СЛАУ с патчами. Ну посмотрим.

Добавлено 10-08-2020 в 16:48:

Ну в этой задаче самое главное что - иметь конвейер, который ложится на архитектуру GPU. То есть мы в принципе не можем уйти от схемы лампа-свет. Никаких ухищрений с патчами-интерполяциями тут быть не может, это не ляжет на видеокарту никак в реалтайме.

Добавлено 10-08-2020 в 16:50:

Ну и да, лампочки должны быть параметрическими, без чёткого разделения на типы, проще говоря - без лишних условий. Т.е. вот эти вот light_point, light_spot, light_sun не должны присутствовать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 10-08-2020 в 13:52:

Цитата:

когда памяти хватило на прямой свет, а на индиректе всё вылетело на последних секундах рассчёта.

А это сколько?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено nemyax 10-08-2020 в 13:54:

Цитата:

Дядя Миша писал:
лампочки должны быть параметрическими, без чёткого разделения на типы

Тогда как направленный свет делать?

Отправлено Дядя Миша 10-08-2020 в 14:04:

Цитата:

nemyax писал:
Тогда как направленный свет делать?

это детали внутренней реализации, со стороны дизайнера это так и будет выглядеть как обычные лампочки. И давать такой же эффект.

Цитата:

thambs писал:
А это сколько?

индиректу обычно требуется раза в полтора больше чем директу. Как повизёт вообщем.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 12-08-2020 в 10:36:

Сегодня важный день

Готовность движка достигла 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. Но совместимость эта не находится в движке, наоборот он про нее ничего не знает. Совместимость достигается формированием пользовательских настроек и материалов. Разумеется, каждый волен настроить и создать для себя уникальную рабочую среду и вести разработку в дальнейшем именно в ней.
Это и есть ключевая особенность будущего движка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 12-08-2020 в 10:45:

Дядя Миша
Ох, интригует. Таки надеюсь, что во второй половине осени смогу вернуться к работе и перенести свои наработки на NT.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено FiEctro 12-08-2020 в 12:59:

>> Скажу только лишь, что изначально мы с Ксероксом рассуждали примерно в одном направлении - GoldSource отличный движок, но многое в нём устарело, мешает груз совместимости со устаревшими форматами, в частности текстурами в вадах. Надо просто взять и отрезать всё лишнее и получится совершенно свой, простой и удобный движок. Я отказался от этой идеи еще в 2016-м году, а Ксер проследовал по этому пути до контса и у него получилась Волатила. Насколько эта концепция удачна - судить пользователям.

Я не раз предлагал разбить ядро на модули. Чтобы он поддерживал как старый ксаш так и новый. И переключаться между ними так же как между модами, и позволять пользователям писать свои (например форки). Само ядро не должно быть ориентировано ни на какие форматы или игровой код.

Всё остальное пользовательские модули, которые можно ложить прямо в корень ксаша ввиде дллок:
xash.dll, xashnt.dll, albatrosfork.dll, beiskaarja.dll

Отправлено Дядя Миша 12-08-2020 в 13:29:

Цитата:

FiEctro писал:
Чтобы он поддерживал как старый ксаш так и новый

что ты имеешь в виду под поддержкой старого ксаша?

Поддержка и так останется, но на этапе разработки. Бинарная совместимость не нужна. Я больше скажу - благодаря моей концепции системы материалов, вы даже Волатилу сможете сэмулировать, если это кому-то потребуется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-08-2020 в 14:06:

Материалы то понятно, а что с другими форматами делать?

Отправлено KorteZZ 12-08-2020 в 15:18:

Интересно. Надеюсь, первые рабочие сборки можно будет потрогать довольно рано

__________________

Killing Floor: Horzine Outbreak

Отправлено Дядя Миша 12-08-2020 в 16:25:

FiEctro формат будет свой. У всякого движка свой формат. Если движок поддерживает только чужие форматы, это не движок, а вьювер.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 12-08-2020 в 16:27:

Цитата:

Дядя Миша писал:
вы даже Волатилу сможете сэмулировать, если это кому-то потребуется.

Волатила на три четверти состоит из Ксаша!

Отправлено Дядя Миша 12-08-2020 в 19:33:

Нету там ничего общего, да это и неважно. Разные идеологии.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-08-2020 в 13:44:

Да ктож теперь знает? Я помню в википедии было написано...

Цитата:

Дядя Миша писал:
Нету там ничего общего, да это и неважно. Разные идеологии.

Если Волатила за Путина, то за кого Ксаш?

Отправлено Дядя Миша 13-08-2020 в 15:23:

Цитата:

FiEctro писал:
Я помню в википедии было написано...

Так ты же сам её редактировал

Нормально народ к делу подходит - сам отредактировал, сам сослался.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 13-08-2020 в 16:39:

Буржуям можно давать линк на эту тему?

Отправлено Дядя Миша 13-08-2020 в 17:49:

Crystallize кому именно?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 13-08-2020 в 18:07:

Цитата:

Дядя Миша писал:
Нормально народ к делу подходит - сам отредактировал, сам сослался.

Фейк-ньюс, прям как CNN!

__________________

Отправлено Дядя Миша 23-08-2020 в 17:01:

Дошли наконец-то руки немного уделить времени. Ну и естественно - надо скомпилить ЧАЭС. Потому что, если движок не сможет переваривать такие локации и делать это достаточно быстро - под сомнение ставится целесообразность его разработки. Итак, с матами, перекурами, превышениями лимита памяти, но я всё-таки это скомпилил.

C++ Source Code:

1	BuildKDTree: 57.549385 secs

2	CullLights:

3	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (0.76 secs)

4	80542 lights culled

5	DirectLighting:

6	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (13.27 secs)

7	4480438 total traces casted, 3140144 luxels illuminated

8	total lightmap pages 71

9	CreateLightmapPages: 121.817964 secs

Особый цымес - сортировка лайтмап по атласам заняла 2 минуты (из-за алгоритма с деревом, Кармаковский бы справился за пару секунд, но не так плотно), построение KD-tree заняло почти минуту. И цельных 14 секунд - собственно освещение. Не, ну трасса хорошая, я еще в том году говорил.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 23-08-2020 в 18:40:

Дядя Миша
Побегал по нему?

Отправлено Дядя Миша 23-08-2020 в 20:01:

Рано еще бегать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 25-08-2020 в 18:14:

А что на динамике?)

__________________
-Brain is dead-

Отправлено Crystallize 25-08-2020 в 18:25:

Цитата:

Дядя Миша писал:
сортировка лайтмап по атласам заняла 2 минуты

Это хорошо?

Отправлено Дядя Миша 25-08-2020 в 19:03:

Фпс абсолютно не радует. Какие-то жалкие 700 тысяч полигонов без света, без лайтмапы. Надо оптимизировать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 25-08-2020 в 19:25:

Дядя Миша
Это всё одним куском рисуется, или там виз?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 25-08-2020 в 20:50:

Одним куском. Но фпс ниже некуда. Здесь должно быть около тысячи.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 26-08-2020 в 20:58:

Чего тут у вас нового?

Отправлено Дядя Миша 27-08-2020 в 08:23:

Да вообщем-то ничего. Пока нет времени на разработку.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 28-08-2020 в 19:39:

Я уже говорил, что материалы состоят из нескольких частей и дефолтная часть имеет название по типу модели. С пересмотром концепции это утратило актуальность. Связка должна быть по формату описания вертекса, а сам формат вертекса будет плавающий, свободный.

Добавлено 28-08-2020 в 22:39:

Пока я тут изучал, как эффективнее внедрить этот механизм, мне в голову пришла одна идея, естественным образом дополняющая мою систему материалов. Поясню. На данный момент, механизм является Data-Driven процентов на 80. Что это значит? А это значит, к примеру, что если у нас в шейдере объявлен какой либо юниформ, но при этом не используется, то после компиляции шейдера, его локация будет равна -1. И в списке внешних данных он попросту не появится - т.е. эти данные не будут подготовлены движком и как следствие - не будут отнимать время на бесполезные рассчёты. На первый взгляд это бесполезная оптимизация, если речь идёт о каком-нибудь юниформ-векторе. Но скажем, когда мы передаём кости - это уже ощутимо. Но это распространяется и на текстуры! Если шейдер не использует какой-то текстурный юнит, его текстура просто не будет загружена. То есть уже экономия текстурной памяти. Аналогично надо сделать и с VBO-массивом. Он будет формироваться при загрузке динамически. Это финальный штрих по полному управлению видеопамятью из шейдера. Причём для этого используется встроенные средства GLSL.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-08-2020 в 11:40:

Видимо разработка NT проходит под девизом "Se vogliamo che tutto rimanga come è, bisogna che tutto cambi"

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 08-09-2020 в 14:32:

Ну чтож, судя по всему, пора переходить на октодерево. BSP вообще не справляется, да мне он по сути и не нужен.
Единственное, что от него полезное использовалось - в паре с генерацией порталов - обрезание наружних невидимых полигонов. Но народ давно их вручную красит, так что не имеет никакого значения.
Заодно и наличие\отсутствие дырок не будет влиять на процесс сборки.
К тому же октри всегда строится налиту, его незачем хранить в карте.
И это будет универсальное единое дерево, как для мобов, так и для статики.
В квейках приходилось поверх лепить еще одну абстракцию, что было неудобно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 08-09-2020 в 14:46:

Почему именно октодерево, а не BVH? По тестам, BVH работает быстрее, а весит меньше
https://pdfs.semanticscholar.org/e0...b3f863ed6ea.pdf

Отправлено Crystallize 08-09-2020 в 15:01:

Цитата:

Дядя Миша писал:
Но народ давно их вручную красит, так что не имеет никакого значения.
Заодно и наличие\отсутствие дырок не будет влиять на процесс сборки.

Это тот народ который строчки в delta.lst сортирует и моды по 20 лет делает. Так себе пример, короче говоря.

Отправлено Дядя Миша 08-09-2020 в 15:53:

ncuxonaT может и BVH. Посмотрим. Еще BIH есть, напоминаю.

Добавлено 08-09-2020 в 18:53:

Crystallize в "большом" геймдеве тоже все удаляют невидимые полики, а тех кто не удаляет - бьют по рукам малой сапёрной лопаткой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-09-2020 в 16:03:

Дядя Миша речь не про большой-маленький геймдев а про ручую-автоматическую работу.

Отправлено Дядя Миша 08-09-2020 в 16:33:

Помоему все брашы и мешы по дефолту окрашены в nodraw, а дизайнер уже текстурит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-09-2020 в 17:11:

Дядя Миша кубают люди не с текстурой нодрав. Я сразу как есть кубал. Это только сорсовцы везде пихают свою оранжевую или серую клетчатую текстуру по дефолту. Это часть их культуры. ©

Отправлено Дядя Миша 08-09-2020 в 18:10:

Оказывается AABB-tree это частный случай BVH.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 08-09-2020 в 18:21:

Crystallize
Ну это какраз очень правильная культура. Как всё покрасишь — так остальное в нодрав.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено XaeroX 08-09-2020 в 19:20:

Цитата:

Дядя Миша писал:
Ну чтож, судя по всему, пора переходить на октодерево. BSP вообще не справляется, да мне он по сути и не нужен.

Вот и умерла эпоха?

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

__________________

Отправлено Дядя Миша 08-09-2020 в 20:42:

Цитата:

XaeroX писал:
Вот и умерла эпоха?

На текущем этапе разработки BSP там скорее как топор в каше.
Для открытых пространств он не годится. Точнее говоря - не годится чтобы с его помощью эффективно находить видимое в пирамиде. Поэтому я его не юзаю. Он щас только для трассы и контентсов используется. Ну опять таки - нам надо два дерева, AABB и BSP. Хотя мы могли бы прекрасно линковать вообще всё в единое дерево, а само дерево строить налиту.
С видимостью\окклюженом тоже самое - это всё через кастомные порталы реализуется. Брашам дерево тоже не нужно. Не ну можно конечно его оставить из принципа. Надо посмотреть сколько памяти octree занимает, так-то бсп тоже прилично весит, если считать все его индексы.

Добавлено 08-09-2020 в 23:42:

Зашёл на любимый сайт ФиЭктро почитать про всякое. Ну и про октри в том числе. А там такое:
http://www.ray-tracing.ru/articles183.html

Между прочим в сталкере лайтмаппер считал свои лучи вот как раз на основе октодерева + неэффективный хэшинг по сурфейсу (я его как раз выкинул и заменил на AABB tree). Так что неудивительно что там лайтмапы считались неделями.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 09-09-2020 в 08:02:

Цитата:

Дядя Миша писал:
Зашёл на любимый сайт ФиЭктро почитать про всякое. Ну и про октри в том числе. А там такое:

Цитата:

Забудьте про это, октодерево неэффективно и сложно.

А что, при траверсе октодерева как-то иначе кладут на стек, чем при траверсе бсп? С подвыподвертом набрасывают?

Отправлено Дядя Миша 09-09-2020 в 10:30:

BVH можно вообще без стека

Добавлено 09-09-2020 в 13:30:

А вообще, перееду я всё-таки в телегу. Комментить особо нечего, а за прогрессом следить - самое то. Ну и хоть посмотрю сколько там будет подписчиков.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 09-09-2020 в 19:52:

Дядя Миша ссылку бы

__________________
-Brain is dead-

Отправлено Дядя Миша 09-09-2020 в 21:13:

KiQ на что?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Cybermax 09-09-2020 в 22:15:

Дядя Миша мне кажется KiQ про твой ТГ. Если в подписи поставить ссылку на него, народ будет подписываться, мне думается.

Отправлено KiQ 10-09-2020 в 00:33:

Дядя Миша на телеграмм)

__________________
-Brain is dead-

Отправлено Crystallize 10-09-2020 в 01:15:

Цитата:

Cybermax писал:
Если в подписи поставить ссылку на него, народ будет подписываться, мне думается.

Ну это само собой, я например до сих пор не знаю какой тг у дяди миши.

Отправлено Дядя Миша 10-09-2020 в 12:46:

В телеграм я пока не пишу, естественно выложу ссылку.

Итак, дальнейшая работа над декомпилятором уровней сталкера продолжена быть не может. Почему? Очень просто. Вопрос и раньше вставал, но теперь уже без вариантов - надо заняться коллизией.

Нет нормального механизма. Собственно вариантов коллижен-детектора в природе существует два штуки: полигональный и конвексный. Я не рассматриваю случаи столкновения сфера vs бокс, сфера vs цилиндр, так как речь, естественно, о коллижен детекторе произвольной геометрии.
Полигональный - это конкавный детектор, т.е. геометрия может быть произвольной формы. Конвексный работает только с выпуклыми телами, а невыпуклые тела разбиваются на выпуклые (декомпозиция). Частным случаем конвексного детектора являются и нашы брашы. Просто в большом геймдеве их брашами давно никто не называет, ну конвексный объект и всё.
С брашами преимущество было в том, что дизайнер заранее строил уровень из конвексных объектов. Но в подходе к генерации брашей заложена мина - их качество очень сильно привязано к точности вещественных чисел. А точность вещественного падает (экспоненциально?) при удалении от центра (нуля). Вальва в сорсе даже замутила такой хак, что все брашы перед созданием сурфейсов принудительно перемещались в центр, а потом возвращались обратно - для большей точности результатов. Но это конечно так себе выход - ошибки всё равно накапливаются. Именно поэтому кстати BSP\CSG и работают с двойной точностью вещественного, уж слишком видна разница. Но зато с такими объектами очень просто реализуется коллизия - минимум операций, всегда предсказуемые результаты. Собственно, когда встал этот вопрос - как коллидить с объектами произвольной формы, Кармак из каждого полигончика сделал такой тонкий браш.
Но с оговорками. Во первых это было сделано только для параметрических поверхностей - т.е. патчей. Которым можно регулировать уровень разбиения и таким образом создавать более грубое приближение. Но уже для вставляемых на карту моделей делать что-то подобное он отказался (в ку3 кстати где-то было коммент на эту тему в исходниках, слишком много полигонов). Впрочем тогда и компутеры были слабже. Так-то подход неплох в целом. Например я использовал его в XashXT генерируя брашы налиту и каждый кадр для физических объектов. Разумеется, тех объектов, которые мне сделал PhysX из полигональных.
А там действовало жесткое ограничение - максимум 256 полигонов на твёрдое тело. К тому же брашы генерились только непосредственно перед коллизией (когда монстр\игрок оказывался слишком близко от тела и не перестраивались, если его положение не менялось, поэтому оно практически не тормозило). Именно поэтому мне многие говорили, что в XashXT очень приятное взаимодействие игрока с физтелами - его как буто реально чувствуешь, а не проваливаешься в него или оно улетает куда-то от малейшего прикосновения. Но в целом такая схема оправдана быть не может. Всё же слишком много операций. В Параное-2 я пошёл еще дальше, физикса там уже не было (Элбер сказал, что на физику ему плевать, но рагдолл бы не помешал). Там я этот подход переписал на качественно новый уровень, ввёл хэширование плоскостей и другие ускоряющие операции. Да и сами брашы коллизий сохранил в кэш, чтобы не строить его каждый раз при загрузке уровня. Но и всё равно, генерация таких вот брашей для той же ЧАЭС занимала порядка получаса, а плоскостей получалось около 10 миллионов
Происходило это потому, что каждый такой браш, полученный из полигончика создаёт дополнительно вовсе не четыре стороны, как может показаться (для треугольника). Дело в том, что сам механизм трассировки плотно завязан на аксиальность плоскостей. Иными словами брашы, повёрнутые на любой угол, отличный от 90 градусов нормально коллидить не будут. По крайней мере с оригинальным кодом от Кармака. Потому что вокруг каждого браша должен быть во первых описывающий его объем AABB который всегда аксиальный (из него кстати для любого браша можно узнать его AABB - первые шесть сторон всегда аксиальны и отсортированы в едином порядке, это справедливо и для ку2 и для ку3). Второй момент заключается в том, что на проблемные места - острые углы, добавляются бевелы - скосы. Чтобы трасса не застряла в этом проблемном угле. Игрок это никак не ощущает на самом деле. Для него наоборот физика очень мягкая и предсказуемая. Но как вы понимаете, таким образом, у нас во первых каждый браш должен состоять минимум из шести сторон. А бывает и до 32-х, причём реальный полигон там только один, четыре закрывающих, еще парочка аксиальных, остальное бевелы.
Т.е. нетрудно догадаться, сколько места займет такая вот коллизия, даже несмотря на отсутствие в данных вертексов и тот факт, что там нет дублирующихся данных. На этот вопрос очень легко ответить - для той же ЧАЭС коллизия, построенная таким вот образом весила порядка 80 мегабайт. Сталкеровский оригинальный cform - 20 мегабайт. Да и строился он наверняка быстрее, хотя я и не проверял.
Так что в принципе превращать полигоны в брашы - не очень хорошая идея, когда у вас этих полигонов слишком много. Есть более экономный вариант, как вы понимаете. Для этого нам надо превратить нашы полигоны в конвексные брашы. Т.е. не каждый полигончик превратить в отдельный браш. А выполнить конвексную декомпозицию. Из-за чего кол-во брашей в такой коллизии падает в десятки раз, а качество коллизии - наоборот только возрастает. Т.е. на первый взгляд сплошные плюсы.
Но не всё так просто. Во первых нам надо еще построить конвексный хулл для нашего объекта. Хулл можно построить двумя способами - собственно декомпозицией, voxel-based аппроксимацией и вписанием объекта.
Последний вариант - самый простой. Мы просто берём минимальный нулевой объем и добавляем в него новую точку, а умный алгоритм из этого облака точек уже сам создаёт конвексный хулл (это кстати к вопросу, почему физ.движки не требуют полигоны, а именно точки для создания конвексных хуллов). Алгоритм простейший, скорость работы высокая. На выходе что-то очень конвексное. Если этот объект динамический и размерами меньше игрока, то пофиг. Если это статическая геометрия, ну скажем домик деревянный с интерьером, метод очевидно не конает - внутрь зайти будет невозможно. Остаётся декомпозиция. Можно декомпозировать через BSP-дерево, т.к. любой объект, пропущенный сквозь него становится конвексным. А потом мы просто берём полученные конвексные брашы и мержим их друг с другом, пока это возможно. Я использую этот подход для патчей и он себя неплохо зарекомендовал. Для произвольного набора треугольников ситуация сильно хуже. Нет никакой возможность различить где реальная геометрия, а где остатки от исходного браша, иссечённого деревом. Дерево можно строить и наоборот - добавлением, но там получается строго обратная проблема - часть брашей исчезает. В реальном игровом уровне такой проблемы не стоит, т.к. дерево сечёт изначально конвексные объемы. Так что метод рабочий, но да, не слишком надёжный для большого полигонажа. Опять таки он из плоскостей делает объемные штуки, что не всегда удобно. Про VHACD распространяться не хочу - очень долго и очень затратно по памяти. Воксели вообще много жрут, это понятно. Но какую-нибудь сраную модельку, которую BSP декомпозирует за полсекунды, воксельное дерево может считать до полуминуты. Так что этот вариант я не рассматриваю.
Ну и наконец вариант третий - полигональный детектор. Плюс в том, что нам не надо переводить наши полигоны в какие-то принципиально иные сущности - т.е. мы реально трейсим геометрию. Так же геометрию очень легко симплифицировать через тот же Progressive Mesh, например (собственно в Сталкере так и сделано). Но есть у такого подхода два минуса. Во первых, поскольку мы трейсим реально полигон, за ним нет никакого объема (ну в крайнем случае там будет солидный лиф, если мы поместили всё это в BSP-дерево). Поэтому из-за каких погрешностей вещественных очень легко получить результат когда объект пролетает насквозь или застревает в текстурах, ну понятно. Второй минус вытекает из первого - невозможно таким образом сделать нахождение в среде, типа воды или кислоты. В Doom3 где коллизия полигональная задачу решили при помощи брашей. Т.е. браши там остались только для тестирования на нахождение внутри геометрии, в том числе - внутри воды.
Так что вот такие варианты.

Добавлено 10-09-2020 в 15:43:

Итак, исходя из вышесказанного, ~~кокова кота выбы выбрали?~~ что тут можно сделать? У полигональной трассы, не говоря уже тяжёлый алгоритм, собственно трассировки, присутствует некоторая избыточность. Т.е. эти данные в любом случае займут довольно много места, именно поэтому коллоизационные поверхности симплифицируют. Пытаться построить из произвольной модели конвексную декомпозицию - занятие, скорее всего довольно-таки долгое. Особенно если моделей много и они сложные.
И да, чаще всего это всё равно будет приближение. Превращать каждый полигончик в отдельный браш - это очень быстро, но влечёт за собой большие расходы памяти. Но есть один метод. На самом деле - все вот эти скосы и аксиальные планесы, точнее код, который их добавляет к брашу, обладает одной примечательной особенностью, над который вообще мало кто задумывается, а именно - ему плевать на замкнутость браша! Ему плевать на то, сколько у браша сторон. Для нас как бы самое важное - это построить виндинг, а для нормального браша это реализуется только путём взаимного обрезания сторон, как вы понимаете. Но мы рассмотрим вырожденный случай - браш из одного полигона. Прикол в том, что этому брашу бевелы и ограничивающее пространство добавляются точно так же как и настоящему брашу. Это не голословное утверждение - в параное именно такой подход и используется. Т.е. если бы я там делал из полигонов настоящие тонкие брашы, можете не сомневаться, там на ЧАЭС было бы не 10 миллионов плоскостей, а все 40. Второй момент - таким полигонам вовсе необязательно состоять непременно из трёх точек. Проще говоря, там может быть сколько угодно сторон. Главное чтобы он продолжал оставаться конвексным. Это в свою очередь открывает широкие возможности по оптимизации исходной геометрии, поскольку брашы фактически строятся из полигонов, без добавления лишнего. Плюсы такого подхода:
1. не надо ничего глобально переписывать, изменения минимальны
2. надёжность такой коллизии полностью идентична обычным брашам, причём, алгоритм даже не знает что перед ним какие-то полигоны
3. поскольку полигон двухмерен, его легче оптимизировать, наконец можно строить брашы из группы аксиальных полигонов, которые примерно направлены в одну сторону, независимо от того, сколько их там, бевелов будет добавлено кратно меньше, чем если бы мы попытались сделать браш из каждого полигончика. Строго говоря, такая конструкция уже вообще не является брашем с точки зрения редактора или дизайнера. А вот с точки зрения коллижен детектора - очень даже является.
4. униформное хранение данных. Плоскости индексированы, а у сами плоскостей дополнительно индексированы нормали. Т.е. при разумном подходе можно очень сильно сократить данные.
5. скорость работы. Даже при тех десяти миллионов полигонах, помещенных в простейшее AABB-дерево, коллизия на ЧАЭС была довольно таки надёжной и быстрой. А ведь можно было сделать на порядок умнее.
6. Наконец никто не мешает пропустить набор треугольников через дециматор и получить на выходе упрощенную копию. К слову сказать - дециматоры тоже очень быстро работают, это весьма простая операция.
Но конечно надо будет затестировать различные варианты и посмотреть, какие лучше годяцца.
Учитывая вышесказанное, как вы уже догадались, я в первую очередь попытаюсь дожать именно коллизию по полигоно-брашам. И если результат меня устроит (ну скажем общий объем данных коллизии будет меньше чем в сталкере), то тогда уже можно будет рассмотреть вопрос об используемом дереве.

В заключение хочу сказать пару слов о том, почему я иногда выбираю те или иные решения. На самом деле, я не ставлю себе догмы, что BSP устарел и его надо срочно дропнуть и не особо оглядываюсь на другие проекты, ну типа в сталкере октри, значит и мне тоже надо. В первую очередь, я всегда пытаюсь выжать максимум из уже имеющейся технологии, сделать что-то такое, чего возможно еще никто не делал.
Это интересно. А пихать в движок всего подряд по принципу - на дворе 2020й год, нам срочно нужны воксели - не очень.

Добавлено 10-09-2020 в 15:46:

И да, я очень люблю униформный подход, он потенциально обеспечивает будущие возможности, о которыхна момент разработки никто не задумывается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 10-09-2020 в 13:12:

Звучит заманчиво. Ну мне везде заманчиво, где не надо кубать.

Отправлено ncuxonaT 10-09-2020 в 13:40:

В сталкере геометрия для коллизий считалась автоматически для целой карты?

Отправлено Дядя Миша 10-09-2020 в 14:22:

ncuxonaT сам формат cform я еще не разбирал, но визуально он выглядит как сплошная полигональная геометрия. А уж из скольких кусков он состоит и как эти куски помещены в дерево, я не смотрел.
У превращения полигонов в браши есть главный минус - такая дата много весит. Во всём остальном сплошные плюсы. То есть задача - симплифицировать эту геометрию. Но ведь для полигональной коллизии это тоже нужно. Значит в любом случае этим займусь.

Добавлено 10-09-2020 в 17:22:

Цитата:

ncuxonaT писал:
В сталкере геометрия для коллизий считалась автоматически для целой карты?

если вопрос о том, что считал геометрию (я отвечал немного на другое), то да, компилятор из видимой автоматически делал. Утилита qSlim. Она же и прогрессивные мешы создаёт для видимых.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 10-09-2020 в 15:04:

Цитата:

Дядя Миша писал:
Хулл можно построить двумя способами - собственно декомпозицией, voxel-based аппроксимацией и вписанием объекта.
Последний вариант - самый простой. <...> Остаётся декомпозиция.

>два способа, по факту перечислены три формулировки
используй скобки пожалуйста, а то бывает так:

>вижу три формулировки
"последний вариант-самый простой"
ок, остаётся ещё два.
"Остаётся декомпозиция"
я: ????

Отправлено Cybermax 10-09-2020 в 15:08:

Отправлено Crystallize 10-09-2020 в 15:11:

Цитата:

Дядя Миша писал:
Для нас как бы самое важное - это построить виндинг, а для нормального браша это реализуется только путём взаимного обрезания сторон, как вы понимаете.

Так получается что природа брашевой геометрии состоит не в BSP-дереве, а именно в виндинге?

Отправлено Дядя Миша 10-09-2020 в 17:17:

Цитата:

Crystallize писал:
>два способа, по факту перечислены три формулировки

Ох. Voxel-based это тоже разновидность декомпозиции.

Цитата:

Crystallize писал:
Так получается что природа брашевой геометрии состоит не в BSP-дереве, а именно в виндинге?

Природа в том, чтобы была возможность манипулировать сторонами браша всегда при этом получая конвексный объект. С плоскостями это проще всего получается. Если бы объект был вертексным, проверка на конвексность заняла бы гораздо больше времени. А так всё просто - любые нековексные включения тут же уничтожаются при построении браша. Т.е. генерация из плоскостей реальной геометрии - гарантия конвексности. Ну и конечно тот факт, что у браша не может быть слишком много сторон - обычно 128 максимум.

Добавлено 10-09-2020 в 20:17:

Цитата:

Crystallize писал:
не в BSP-дереве

да дерево тут вообще непричём

Дерево это способ разделения пространства. Просто так уж получилось, что BSP чуть ли не единственное, которое реально режет геометрию, из-за чего с ним не любят связываться. Впрочем есть разновидность BSP дерева, которое ничего не режет, но оно менее эффективное, т.к. опирается на уже существующие разрезы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 11-09-2020 в 09:36:

Вот что мне удалось выяснить. Основных алгоритмов существует две штуки.
Quadric Error Metrics (QEM) от Мишеля Гарланда. Имплементация называется qSlim, была впервые выпущена в 1998-м году, а в 2006-м её автор устроился в NVidia, где вероятно пребывает и по сей день. Но это это не точно.
Вот страничка https://mgarland.org/software/qslim20.html

Собствено именно эту реализацию использует XRay. Алгоритм хороший, но при пороговых значениях полигонов начинает быстро терять детали. Зато в оригинальной имплементации масса всяческих настроек и обратная связь, отслеживания пороговой деградации меша. Ну то есть, когда кол-во полигонов снижается до критического уровня и он перестаёт сохранять свою форму в рамках заданной погрешности.

Второй вариант Progressive Mesh от Stan Melax. Это тоже известный чувак в геймдеве. Вот его страничка http://www.melax.com, алгоритма там уже нет, но насколько я понял, он так и называется по имени автора - Melax.
У него есть git где всё это и выложено: https://github.com/melax/sandbox
Имплементация PM называется bunnylod, именно её я когда-то использовал для симплификации мешей в VHLT CB для ускорения трассировки. Впрочем я не проверил тогда результат визуально, так что возможно где-то ошибся - в тенях частенько бывали дыры.

Его алгоритм на порядок проще и даёт гораздо более устойчивые варианты при слишком низком поликаунте, там где QEM уже обсирается.
Но нет никаких настроек. На git обновлённая версия алгоритма, оригинальную можно найти например здесь: https://github.com/dougbinks/BunnyLOD И кстати, автор убрал ссылку, но сам файл лежит на прежнем месте: http://www.melax.com/bunnylod.zip
У самого Стэна так же есть множество любопытных вещей, которые занимали нашы умы в начале нулевых, в частности - геомод на BSP-дереве (sandbox\testbsp, sandbox\testbool), на сайте есть уже откомпиленное. Вы же всё спрашивали за геомод, ну вот.

Теперь надо выбрать между этими двумя алгоритмами или использовать оба. Тут вот какой еще важный момент - вертекс можно перемещать без особых проблем, нормально можно рассчитать заново, но это не касается координат текстуры и лайтмапы.

Добавлено 11-09-2020 в 12:36:

То что касается меша коллизии, здесь как бы ответ однозначен - надо симплифицировать по максимуму. Качество коллизии от этого только вырастает. А вот насчёт видимой геометрии - тут всё не так однозначно.
Помните я говорил, что лоды в наше время не имеют определяющего значения, потому что главная нагрузка идёт на пиксельный конвейер, а он в свою очередь эффективно лодируется мипами? На gamedev.ru народ в начале десятых тоже жаловался, что от использования лодов фпс в лучшем случае вообще не меняется или даже немного падает. Когда у нас был фиксированный конвейер и вертексы-индексы прокачивались по шине, смысл конечно был. Сейчас - не знаю. Но в любом случае надо провести эксперименты конечно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-10-2020 в 19:39:

В телеге появились каменты! Так что все условия созданы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 05-10-2020 в 19:55:

Цитата:

Дядя Миша писал:
Так что все условия созданы.

Вентилятор закрутился?

__________________

Отправлено KorteZZ 06-10-2020 в 02:28:

Дядя Миша
У тебя есть канал? Или только открываешь?

__________________

Killing Floor: Horzine Outbreak

Отправлено Дядя Миша 06-10-2020 в 08:47:

Канал есть, но там чертовщина какая-то творится. Я там еще ничего не написал, а на него уже 3 человека подписано
очуметь можно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 06-10-2020 в 08:54:

Так на будущее подписываются. Я тоже подпишусь, только ссылки не видно что-то.

__________________
Мой мод на Xash

Отправлено thambs 06-10-2020 в 09:20:

Дядя Миша
А ссылку на канал где нойти-то?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 06-10-2020 в 12:40:

Так в том-то и дело, что нигде
Я её никому не давал и ничего там не писал. А у меня уже три подписчика.
Наверное товарищи Маёры

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 06-10-2020 в 12:41:

Цитата:

Дядя Миша писал:
Наверное товарищи Маёры

Ты не писал, а они тебя за это всё равно в ГУЛАГи посодют.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Crystallize 06-10-2020 в 16:21:

Дядя Миша перебрал варианты unclemike, anklemike, xash3d, zveryuga. Не нашёл. ~~кто на Angel Lanta был?~~

Отправлено nemyax 06-10-2020 в 16:31:

Дядя Миша
Ну эти трое самые догадливые, береги их!

Отправлено Дядя Миша 06-10-2020 в 17:04:

nemyax буду беречь, особенно если учесть, что третий - это я.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 10-10-2020 в 10:56:

Ради интереса сконвертил карты из мода RavenKeep в формат, понятный XashNT. Надо сказать мой оптимизатор дерева и тут прекрасно управился.

C++ Source Code:

source 156985 nodes, optimized tree 5392 nodes

source 100835 leafs, optimized tree 3352 leafs

300 тысяч вертексов на этой карте

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 10-10-2020 в 12:34:

А вот вся эта замута с ConvexDecomposition и т.д. это случайно не та же самая компиляция моделей в браши с которой я бегал раньше?

Отправлено Дядя Миша 10-10-2020 в 12:58:

Я не слежу кто с чем бегает, и тем более что он имеет в виду на самом деле.
Convex Decomposition - это разложение произвольного тела на выпуклые.
Можно каждый треугольник превратить в браш, это самый тупой и неоптимальный метод. Но зато и самый надёжный. Именно так я поступил в p2st, он умеет из ase-моделей создавать брашы. И из патчей тоже.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 28-10-2020 в 21:03:

Нашёл немного времени, дай думаю распарсю level.cform.
Там коллизия. Взял Кордон для этого дела (ну я вообщем пока с ним экспериментирую). 20 мегабайт оно весит и там миллион триста тысяч индексированных вертексов. И это только коллизия.

Но если я правильно понял - там вообще вся коллизия. Т.е. для каждой ёлки-метёлки отдельная копия. Щас пытаюсь эту коллизию скомпилить в видимый уровень. Нормалей нет, текс-кордов нет (сделал автогенерацию), боюсь даже представить что из этого выйдет. Скорее всего out of memory.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 28-10-2020 в 21:32:

Цитата:

level.cform

Што эта?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 29-10-2020 в 08:11:

thambs сталкеровские уровни.

Физ. движки практически все работают в абсолютном пространстве, из-за чего исключают дубликаты. То есть, если я, наставил на карту 100500 ёлок, у каждой будет своя уникальная коллизия. Несмотря на то, что они статики.
Впрочем в ку3 такая же схема. Но я еще при работе над параноей придумал как это корректно обойти. Там основная сложность не просто в трансформации трассы в локальное пространство. Её еще надо повернуть корректно. И с этим есть некоторые сложности.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-10-2020 в 15:46:

Подгрузил так же уникальные модельки. Которые на карте присутствуют в единственном экземпляре. Overview кордона:

Вот эти квадратные дырки по моему разумению потом будут заполняться какими-то повторяющимися объектами. Ну то попозже.

Наконец-то можно полетать над кордоном. И оценить его размеры. В сталкере меня всегда бесило отсутствие ноклипа.

Обратите внимание, что внутренности домов видны, а наружная часть - нет. Это не баг отрисовки. Просто наружные коробки домов - это повторяющася модель, которая везде одинаковая, а вот внутри уже уникальная обстановка. Я эти модели просто еще не грузил. У них есть своё местоположение, угол ориентации.
Видеокарта на работе GT640, оптимизации здесь никакой нет, что вижу то рисую.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 29-10-2020 в 15:55:

Цитата:

Дядя Миша писал:
Обратите внимание, что внутренности домов видны, а наружная часть - нет. Это не баг отрисовки.

Выглядит как будто куллинг инвертирован.

__________________

Отправлено Дядя Миша 31-10-2020 в 08:55:

На кордоне - десять тысяч кусочков моделей. Я в этой карте собрал около трёх тысяч.

Вот еще какая мысль мне в голову пришла, кстати Ксер и тебе тоже советую поэкспериментировать. BSP при построении, проверяет размер ноды на максимально допустимый. И если он превышает 1024 юнита, то делает дополнительный разруб. Но как она его делает?! Просто берёт плоскость с этим отступом в 1024 юнита. А что если эту часть дерева строить по классическому AABB-разбиению? Тогда у нас уровень до определённых размеров будет делиться точно поровну. В моём понимании это хорошо способствует пространственной балансировке дерева и выравнивает время доступа к нему.

C++ Source Code:

1	int SelectPartition( tree_t tree, node_t node, bface_t *list )

3	if( tree->blocksize > 0 )

5	dvec3 halfSize = dvec3( node->bounds[1] - node->bounds[0] ) * 0.5;

6	dvec3 normal;

7	double dist;

#if 0

9	if( halfSize.x > tree->blocksize \|\| halfSize.y > tree->blocksize \|\| halfSize.z > tree->blocksize )

      int	axis;

13	if( halfSize.x >= halfSize.y && halfSize.x >= halfSize.z )

14	axis = PLANE_X;

15	else if( halfSize.y >= halfSize.x && halfSize.y >= halfSize.z )

16	axis = PLANE_Y;

17	else axis = PLANE_Z;

19	normal = dvec3( 0.0 );

20	normal[axis] = 1.0;

21	dist = ( node->bounds[1][axis] + node->bounds[0][axis] ) * 0.5;

23	return FindHashPlane( dplane( normal, dist ));

#else

26	// if it is crossing a 1k block boundary, force a split

27	for( int i = 0; i < tree->blockdimensions; i++ )

29	if( halfSize[i] > tree->blocksize )

30	dist = tree->blocksize * ( floor( ( node->bounds[0][i] + halfSize[i] ) / tree->blocksize ) + 1.0 );

31	else dist = tree->blocksize * ( floor( node->bounds[0][i] / tree->blocksize ) + 1.0 );

33	if( dist > ( node->bounds[0][i] + 1.0 ) && dist < ( node->bounds[1][i] - 1.0 ))

35	normal = dvec3( 0.0 );

36	normal[i] = 1.0;

37	return FindHashPlane( dplane( normal, dist ));

#endif

43	if( tree->optimized )

44	return SelectPartitionVL( node, list );

45	return SelectPartitionQ3( node, list );

У меня сейчас просто сурфейсы линейно тестируются на попадание во фрустум, но я верну дерево и сравню оба варианта на производительность.

Добавлено 31-10-2020 в 11:53:

Кстати в том же XRay есть "разбиение" пространства на отдельные куски. Разбиение фейковое, поскольку террайн и так уже тесселирован, оно просто группирует куски по пространственным квадратам, не делаю никаких дополнительных разрезов. Именно поэтому на скриншотах вы видите дыры с неровными краями.

Добавлено 31-10-2020 в 11:55:

А потом эти куски попадают в соответствующие ячейки octree. Т.е. octree ессно ничего не режет, его вообще нет в компиляторе. Но зато в этом дереве находится всё сразу - и статическая геометрия и динамическая. Дерево достраивается по мере заполнения уровня мобами. Мне лично этот момент не нравится, т.к. октри довольно жрущее по памяти и может во время игры давать вот те самые лаги и фризы. Но это пока что предположение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KorteZZ 03-11-2020 в 07:48:

А что насчет лимитов всяких? Не получится ли так, что если чел захочет сделать опенворлд, он уткнется тупо в лимиты чего-нибудь и у него получится в лучшем случае просто пустой мир?

__________________

Killing Floor: Horzine Outbreak

Отправлено Aynekko 03-11-2020 в 08:06:

У меня такой же вопрос. В ксаше я обратил внимание, что если поставить 30 солдат модельками как env_static, фпс не проседает, а если 30 реальных - то сильно падает. Это из-за их кода или бсп-дерева? Не совсем понимаю, как это работает.

__________________
Мой мод на Xash

Отправлено Дядя Миша 03-11-2020 в 10:41:

KorteZZ лимитов в новом ксаше особо нету. Лимиты только в аппаратном обеспечении.

Цитата:

Aynekko писал:
Это из-за их кода или бсп-дерева?

поиск по большому дереву, да. Писал об этом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 03-11-2020 в 10:53:

Дядя Миша
Есть планы по выносу AI в отдельный поток?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 03-11-2020 в 13:04:

Есть планы по оптимизации, а не по выносу.

Добавлено 03-11-2020 в 16:04:

Мне сейчас надо определиться с типом коллизии, вот оно что.
Представлять каждый треугольник в виде плоскости со скосами, довольно эффективно в плане скорости работы, но занимает чудовищно много места.
На какой-нибудь ЧАЭС легко может быть 10-15 миллионов плоскостей.
А ведь она по современным меркам довольно таки лоу-поли.

Впрочем там вылезает еще одна проблемка. У видеокарт оказывается, существует лимит на максимальный размер VBO - обычно миллион вертексов.
Самое поганое, что и на индексы точно такой же лимит - 1 миллион.
Это немного нелогично, к тому же превышение лимита далеко не всегда приводит к каким-то последствиям, на моих карточках.
Так что придётся еще и геометрию разбивать на небольшие батчи.
Наверное сделаю куски по 65 киловертексов с локальными оффсетами, чёб индексы хранить в 16-битном диапазоне.

Но повторюсь, главная задача, это определиться с коллизией. Коллизия будет по треугольникам, но надо решить с какими фигурами. Можно сделать просто triangle vs bbox. Можно как в третьем дууме - набирать произвольные простенькие фигуры из конечного числа вертексов - обычно 32-64. В том же физиксе лимит на активное тело - 256 вертексов, но как правило это даже избыточно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено kotar.sys 05-11-2020 в 06:48:

А в сталкере разве нет упрощенной модели геометрии для коллизии? Может строить/подгружать из 3д пакета её в компиляторе моделей, как это делает сорс?

__________________
Ржака

Отправлено Дядя Миша 05-11-2020 в 12:04:

Цитата:

kotar.sys писал:
А в сталкере разве нет упрощенной модели геометрии для коллизии?

Есть, да. Но там как. Вот допустим ёлки стоят на поляне. Понятное, дело, ёлка одна, просто рисуется много раз. А вот в коллизии, все эти ёлки продублированы, ну и не только они, конечно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено kotar.sys 05-11-2020 в 12:16:

Так почему бы не использовать сталкеровские методы обработки коллизии для сталкеровских моделей? Они тоже медленные?

__________________
Ржака

Отправлено Дядя Миша 05-11-2020 в 15:35:

Да нет никаких "сталкеровских" методов.

Загрузил недостающие части ландшафта. Обратите внимание на поликаунт.

На машинках почему-то текстуры съехали, на всех. Но я пока не разбирался.

Ну вот, прекрасная сцена для тестирования и оптимизации отрисовки и коллизии. Ну и для оптимального хранения данных тоже. Разумеется, я потом буду тестировать и другие сцены, вероятно и из эксодуса, надо получить вменяемую производительность.
Но тут конечно без вариантов - точного ответа нет. Только тестировать и сравнивать. Лоды проверю, размеры батчей, оптимальные размеры VBO, помощь дерева в отрисовке, и так далее.
Это вот как раз такой тип сцены, что нихрена не спрячешь и не укроешь, всё как на ладони.

Добавлено 05-11-2020 в 18:35:

По сути с этой сценой даже мой компилятор не справляется - ему не хватает памяти, выручает только ключ /3Gb в boot.ini
Предвидя советы "ну почему бы не сделать как в сталкере", напоминаю, что новый движок должен уметь как активно использовать полностью брашевые карты, так и полностью полигональные. Т.е. задачка несколько сложнее, чем представляется на первый взгляд.
Нет, не в оптимизации, конечно дело. А в выборе наилучших методов.
А чтобы что-то выбрать, надо многое протестить. Это время.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 05-11-2020 в 16:29:

Цитата:

Дядя Миша писал:
Обратите внимание на поликаунт.

Два-три миллиона, в зависимости от того, какая часть уровня в кадре. Вот пейсатели форков X-Ray кипятком обоссутся, если у тебя получится показать Кордон со всеми деталями на полной динамике с фпс выше, чем выдают их форки на твоей видекарте

Отправлено Cybermax 05-11-2020 в 18:08:

Мне уже больше нравится то что на скриншутах, чем в оригинале. Интересно что будет с эксодусом, учитывая что не играл в Метро.

Отправлено Дядя Миша 05-11-2020 в 20:50:

Цитата:

Ku2zoff писал:
Вот пейсатели форков X-Ray кипятком обоссутся, если у тебя получится показать Кордон со всеми деталями на полной динамике с фпс выше, чем выдают их форки на твоей видекарте

X-Ray очень хорошо оптимизирован. Но можно еще лучше, т.к. он точился под преведущее поколение карточек.

Цитата:

Cybermax писал:
Мне уже больше нравится то что на скриншутах, чем в оригинале

без лайтмап-то?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 06-11-2020 в 01:04:

Почему коллизия по треугольникам? Ты хочешь строить какую-то единую структуру для всей карты со всеми елками?

Отправлено Дядя Миша 06-11-2020 в 06:41:

Цитата:

ncuxonaT писал:
Почему коллизия по треугольникам?

Ну во первых, я пока что не пришёл к однозначному выводу. Просто такая коллизия должна переиспользовать уже существующие вертексы, что положительно скажется на финальном размере карты. А коллизия по плоскостям генерит слишком много этих самых плоскостей, несколько миллионов. Оно и в параное так было, посмотри размеры клипмапы для ЧАЭС.

Добавлено 06-11-2020 в 09:41:

Цитата:

ncuxonaT писал:
Ты хочешь строить какую-то единую структуру для всей карты со всеми елками?

Зависит от сложности симуляции. Для простой халфовской физики, можно хранить все объекты в локальном пространстве. Но для симуляции твёрдых тел, подобный подход уже не слишком удобен, хотя и тоже возможен.
Я вообще не хочу с физикой особенно заморачиваться, как выяснилось, она мало кому нужна. Единственное что народ котирует - это разрушение. Тотальная деструкция.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 06-11-2020 в 06:49:

Цитата:

Дядя Миша писал:
Единственное что народ котирует - это разрушение.

И рог нолл. Старый добрый олдскульный рог нолл.

__________________

Отправлено Дядя Миша 08-11-2020 в 07:23:

Еще одну забавную вещь обнаружил. Фрустум использует коллижен три для определения пересечений видимости и отсечения невидимых, нет не полигонов, скорее всего целых моделей, аппроксимированных до ббокса.
Вместо запроса OQ. Впрочем такой подход, предполагает геометрию, оптимизированную особым образом и не слишком вяжется с брашевыми уровнями. Тут скорее надо чтобы уровень был разбит на достаточно большие куски.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 13-11-2020 в 07:12:

Дома Noesis окончательно сломался, вылетает при запуске, ничо не помогает.
Но на работе воркает, я его запустил и проанализировал кусочки террайна от сталкеровской карты. И вот что выяснилось - сплиттер вообще не анализирует геометрию на предмет пространственной принадлежности.
Он скорее смотрит, чтобы у вертексов не было соседей. Т.е. эти куски, на которые разбит ландшафт могут проходить через всю карту.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 13-11-2020 в 15:48:

Решил опробывать BVH-деревья для трассировки. Я хронически путаюсь с терминологии, поэтому до сих пор забываю, AAAB это подмножество BVH или наоборот. Ну да ладно. Вообщем деревья строго аксиальные.

Сталкер не имеет собственной подсистемы коллизии и юзает стороннюю, точнее связку ODE + OPCODE. Вот здесь конечно нейминг вводит в лютое заблуждение. Потому что OPCODE воспринимается как целое слово - операционный код для процессора\виртуальной машины. Хотя на деле это аббревиатурко от OPtimized COllision DEtection. Была такая библиотека, в начале нулевых. А еще до нее была библиотека RAPID, которую OPCODE, со слов автора превосходила в большинстве случаев минимум в 2 раза.

Ну и вот значит сталкер её использует для коллизии. Точнее первоначально её использует сам ODE для симуляции твёрдых тел. А сталкер использует именно как коллизию, в двух кейсах, понятно - точечная трасса и трасса ббоксом для всяких игровых ситуаций. Точечная трасса, луч, так же используется для лайтмаппера. А я, напомню, заюзал вальвовское KD-tree, переписав его на FPU. И в целом был доволен до поры, так сказать. до времени. Но выяснилась неприятная вещь. Оно адски долго строится, если полигонов много. На сталкеровских картах это может занимать несколько минут. Второй момент, как вы уже наверное, догадались, был связан с тем, что я хотел уйти от коллизии по плоскостям и мне для этого понадобилась новая структура организации данных.
Ну в данном случае OPCODE был просто первый, кто под руку подвернулся. Там в принципе хорошая кастомизация по выбору секущей, можно поэкспериментировать. Сам OPCODE предлагает кроме построения дерева еще и саму коллизию, но сталкер использует собственные методы, ну впрочем как и я. Итак, я заимплементировал это дерево самостоятельно, чёб не тащить целую либу ради такой ерунды и провёл предварительные тесты. Для тестов использовал карту shaderlab_terrain, там гигантская моделька гор, хоть и довольно низкополигональная. Результаты:

Вальвовское KD-tree

C++ Source Code:

1	tree size: 1.12 Mb

2	KDTree::Build: 2.152100 secs

3	CullLights:

4	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (0.00 secs)

5	0 lights culled

6	DirectLighting:

7	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (1.98 secs)

8	269960 total traces casted, 16641 luxels illuminated

9	total lightmap pages 1

10	CreateLightmapPages: 0.014445 secs

11	writing maps\shaderlab_terrain.bsp

12	active memory 0 bytes, peak memory 10.08 Mb

13	active strings 52

14	4 seconds elapsed

AABB-tree из OPCODE

C++ Source Code:

1	tree size: 576.28 Kb

2	BVHTree::Build: 0.053519 secs

3	CullLights:

4	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (0.00 secs)

5	0 lights culled

6	DirectLighting:

7	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (1.89 secs)

8	269960 total traces casted, 16641 luxels illuminated

9	total lightmap pages 1

10	CreateLightmapPages: 0.014780 secs

11	writing maps\shaderlab_terrain.bsp

12	active memory 0 bytes, peak memory 10.08 Mb

13	active strings 52

14	2 seconds elapsed

Как минимум один плюс тут есть - AABB-tree строится в сотни раз быстрее, чем KD-tree. Это обстоятельство, кстати позволяет самому сталкеру не хранить дерево на диске, а строить его каждый раз при загрузке уровня, т.к. это очень быстро. Как видно из статистики - профит во всём.
AABB-tree меньше весит, чем KD-tree, в десятки раз быстрее строится и чуть-чуть быстрее работает. Ну это пока навскидку. Буду проводить серию тестов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 13-11-2020 в 16:01:

Цитата:

не хранить дерево на диске, а строить его каждый раз при загрузке уровня

Построение налету быстрее загрузки с диска?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 13-11-2020 в 20:03:

Цитата:

thambs писал:
Построение налету быстрее загрузки с диска?

Там не так. Скажем треугольники коллизии весят 20 мегабайт, и дерево примерно столько же. Но дерево строить 2-3 секунды. Вот и экономят место.

Добавлено 13-11-2020 в 20:54:

Ну чтож, как я и говорил - не всё так однозначно. Вот к примеру более тяжёлая карта для тестов.
Valve KD-tree

C++ Source Code:

1	KDTree::Build: 2.661017 secs

2	CullLights:

3	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (0.02 secs)

4	83840 lights culled

5	DirectLighting:

6	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (7.07 secs)

7	6015939 total traces casted, 107628 luxels illuminated

8	total lightmap pages 4

9	CreateLightmapPages: 0.131742 secs

10	writing maps\gwdm2_.bsp

11	active memory 0 bytes, peak memory 10.08 Mb

12	active strings 199

13	10 seconds elapsed

OPCODE AABB-tree

C++ Source Code:

1	tree size: 1.06 Mb

2	BVHTree::Build: 0.105040 secs

3	CullLights:

4	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (0.02 secs)

5	83758 lights culled

6	DirectLighting:

7	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (207.33 secs)

8	6080349 total traces casted, 108040 luxels illuminated

9	total lightmap pages 4

10	CreateLightmapPages: 0.130558 secs

11	writing maps\gwdm2_.bsp

12	active memory 0 bytes, peak memory 10.08 Mb

13	active strings 199

14	3 minutes, 27 seconds elapsed

OPCODE SSE AABB-tree

C++ Source Code:

1	tree size: 1.06 Mb

2	BVHTree::Build: 0.104811 secs

3	CullLights:

4	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (0.02 secs)

5	84818 lights culled

6	DirectLighting:

7	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (85.37 secs)

8	6077427 total traces casted, 108036 luxels illuminated

9	total lightmap pages 4

10	CreateLightmapPages: 0.135933 secs

11	writing maps\gwdm2_.bsp

12	active memory 0 bytes, peak memory 10.08 Mb

13	active strings 199

14	1 minute, 25 seconds elapsed

Здесь вальвовское дерево в десятки раз быстрее. Хотя строится по прежнему дольше.

Добавлено 13-11-2020 в 23:03:

проверил еще кучу карт. KD-tree быстрее всегда. Кроме исключений когда построка дерева сопоставима по времени с рассчётом освещения.
учитывая что разрыв реально до 30 раз + 2д хэширование крайне неудачное в сталкере (там наоборот aabb-tree идеально подходит), я поверю что свет в сталкере считался неделями.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 13-11-2020 в 20:27:

Так как ты дерево-то строишь?

Отправлено Дядя Миша 13-11-2020 в 20:34:

http://www.codercorner.com/Opcode.zip
там несколько вариантов построения. Но я не ощутил между ними особенной разницы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 13-11-2020 в 20:36:

Дядя Миша ну не надо код, расскажи алгоритм словами

Отправлено Дядя Миша 14-11-2020 в 07:26:

ncuxonaT ты не знаешь как строится AABB-tree?
Перебором всех треугольников, входящих в заданный объем, выбирается один из аксиальных углов. Нода разбивается на два узла. Каждая нода хранит ровно один примитив в конце разбиения. Поэтому можно заранее высчитать кол-во нод в дереве. Плохо то, что алгоритм просмотра рекурсивный и не поддается какой-либо оптимизации.

А у KD-tree вальвовского есть два важных момента. Во первых разбиение дерева оценивает даже не кол-во полигонов в узле, а кол-во операций, которые потребуются для трассировки этого узла. Т.е. стоимость сплита в опкодах. А во вторых сама трасса нерекурсивная, она просто перебирает в цикле ноды. Из-за этого производительность такая хорошая.
В любой трассе рекурсия это самое слабое место, самый главный удар по производительности.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 14-11-2020 в 12:51:

Стоит ли ждать эдакого на твой обычную дату в декабре?

Отправлено Дядя Миша 14-11-2020 в 14:04:

Пока особо хвастаться нечем. По крайней мере по моим меркам.

Добавлено 14-11-2020 в 16:47:

Ну вообщем полная жопа. Сталкеровский рейтрейсер критически не годится для рассчёта лайтмап по своему быстродействию. Неудивительно, что они неделями ждали результата.

Добавлено 14-11-2020 в 16:48:

Посчитал свет на testers_mp_pool. Вальвовский рейтрейсер управился за 19 секунд, а сталкеровский считал 5 минут 9 секунд.

Добавлено 14-11-2020 в 16:50:

Справедливости ради отмечу, что оба рейтрейсера используют идентичный алгоритм пересечения луча с треугольником, который дополнительно оптимизирован путём предрасчётов некоторых значений и которого, разумеется не было в самом сталкере. Так что там вероятно, это время рассчётов было бы еще больше.

Добавлено 14-11-2020 в 17:04:

Вот вы говорите, релиз к привычной дате.
Чем тут хвастаться? фпс ниже плинтуса, коллизию вообще страшно включать. Единственное достижение - лайтмапа всего 7 минут считается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 14-11-2020 в 14:06:

Дядя Миша знаю, но хотел узнать детали, например, по какому принципу выбирается, где разбивать ноду.

Цитата:

Дядя Миша писал:
кол-во операций, которые потребуются для трассировки этого узла. Т.е. стоимость сплита в опкодах.

Ничто не мешает делать так же в ААВВ дереве. Обычно это учитывают при расчете SAH.
Непонятно, почему а ААВВ траверс с рекурсией, а у кД нет. В чем разница?
Я знаю только бесстековый траверс, когда каждый узел хранит hit/miss линки, тут же нет рекурсии.

Отправлено Дядя Миша 14-11-2020 в 15:31:

Я потом вероятно опробую еще какие-нибудь деревья.
Но в данном случае мною двигало любопытство - узнать насколько в сталкере эффективная трассировка лучей.

Цитата:

ncuxonaT писал:
Непонятно, почему а ААВВ траверс с рекурсией

старый алгоритм на самом деле. Вероятно тогда над подобными вещами не заморачивались.

Ты-то сам откуда брал реализацию?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 14-11-2020 в 16:57:

Дядя Миша реализацию сам писал, а идеи алгоритма брал отсюда http://www.ray-tracing.ru/articles184.html и отсюда https://cs.uwaterloo.ca/~thachisu/tdf2015.pdf
В принципе, в первой ссылке всё есть. Единственное что, они почему-то в бесстековом траверсе не учитывают, что если найдено пересечение с треугольником, то можно пропускать узлы, которые дальше этого пересечения. А в варианте со стеком учитывают.

Отправлено Дядя Миша 14-11-2020 в 20:18:

Цитата:

ncuxonaT писал:
Единственное что, они почему-то в бесстековом траверсе не учитывают, что если найдено пересечение с треугольником, то можно пропускать узлы, которые дальше этого пересечения. А в варианте со стеком учитывают.

там же написано почему

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 14-11-2020 в 20:49:

Дядя Миша там написано, что нельзя остановить поиск после нахождения первого пересечения, и это верно.
А я говорю, что если нашел пересечение, то дальше имеет смысл проходить только те узлы, расстояние до которых меньше или равно расстоянию до найденного пересечения.

Отправлено Дядя Миша 17-11-2020 в 07:50:

Обнаружил вот какую любопытную вещь: те исходники X-Ray, что валяются в общем доступе и на гитхабе - фейковые. Нет, ну из них конечно можно собрать икс-рей и он наверное даже будет работать с оригинальными ресами сталкера, но это не те исходники, которые были изначально.

Я уже не помню где я их урвал, но там есть капитальное отличие - компиляторы не лежат в папке utils. Если бы на этом всё и заканчивалось, то какая разница. Но там есть такие файлы, которые в общеизвестных исходниках просто отсутствуют. Например там есть рассчёт PVS. И тесселяция. Всё это не было использовано на тот момент, но еще сохранялось в коде.

Добавлено 17-11-2020 в 10:50:

А впрочем нашёл. В саб-репозитории лежат тоже:

https://github.com/OpenXRay/xray/tree/master/trunk

Версия 1.0

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 19-11-2020 в 12:36:

Хвастаться пока еще рано, но уже что-то приличное начинает получаться.
И фпс высокий.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 19-11-2020 в 12:43:

Цитата:

Дядя Миша писал:
уже что-то приличное начинает получаться

Главное, чтобы картинка была не хуже второй порно-нойи.

Отправлено Дядя Миша 19-11-2020 в 16:14:

Я уже много раз объяснял, что в NT нет никакого рендерера по дефолту.
Пользоваель сам себе строит абсолютно любой рендерер. Хоть как в метре, хоть как в халфе. И довольно быстро, надо всего лишь написать шейдеры и придумать собственный язык описания материалов. Ну или использовать уже существующий, например как в ку3.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 19-11-2020 в 16:30:

Цитата:

Дядя Миша писал:
надо всего лишь написать шейдеры

Ты сделал Юнити?

__________________

Отправлено Дядя Миша 19-11-2020 в 17:14:

Я не знаю как в Юнити. Но помоему там масса ограничений на эти пользовательские шейдеры плюс обязательно идут встроенные, которые нельзя менять.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Cybermax 19-11-2020 в 17:55:

А этими вашими шейдерами можно разрушаемость сделать как в Frostbite?

__________________
ㅤ

Отправлено Дядя Миша 20-11-2020 в 06:52:

Не помню, говорил я или нет, в Англии есть такая поговорка:

чтобы всё осталось по прежнему, всё должно измениться.

Это как нельзя более отвечает концепции нового Ксаша. Тот же Элбер, помню сокрушался, что да, визуально новые движки выдают отличную картинку, но как же неудобно под них что-то делать. В отсутствие брашей и прочих мелких, досадных ограничений. То есть народу всегда нравилось делать карты таким подходом, который когда-то предложил Кармак.
Опять таки, многим принципиально нравится кубать. Современный движок предполагает, как правило что-то одно. Или кубать или моделить.
Теоретически там браши могут быть, как в Годоте или UE (даже в CE), но они не годятся для создания серъезных конструкций.
Я хочу попытаться найти баланс в таком подходе. Чтобы можно было и кубать как раньше, делая гигантские уровни брашами, и точно так же набивать уровни моделями, как в метро или сталкере.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 20-11-2020 в 07:00:

Цитата:

Дядя Миша писал:
Современный движок предполагает, как правило что-то одно. Или кубать или моделить.

В Волатиле можно и кубать, и моделить, и совмещать и то и другое.

__________________

Отправлено Дядя Миша 20-11-2020 в 07:06:

Цитата:

XaeroX писал:
В Волатиле можно и кубать, и моделить, и совмещать и то и другое.

Это понятно. Но я прекрасно помню, с каким трудом ты ЧЭАС туда затолкал и без лайтмапы.

Вот вам к слову наглядная иллюстрация того, как работают мип-мапы.
Кол-во полигонов не меняется, но при приближении используются старшие мипы, а значит фрагментный шейдер выполняется для большего кол-ва пикселей и фпс падает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 20-11-2020 в 09:50:

Дядя Миша
В каком формате на карту ставятся структурные модели?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 20-11-2020 в 15:34:

thambs та в любом текстовом. В smd например. Впрочем mdl тоже поддерживается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 22-11-2020 в 11:55:

Вообщем товарищи, имею сказать следующее. Нормалям, полученным из текстовой модельки доверять вообще нельзя. Там полное дерьмо порой бывает, а кто-то вообще не заморачивается и пишет туда мусор.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 22-11-2020 в 12:03:

О каких текстовых моделях речь?

Отправлено Дядя Миша 22-11-2020 в 13:26:

obj, ase, smd и всё в таком духе. Их конверторы очень часто пишут разные моделлеры на питоне и макс-скрипте и оно не всегда валидное.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 22-11-2020 в 14:16:

Дядя Миша текстовость не при чем. В 3дмаксе всратая система нормалей - есть группы сглаживания, а есть явные нормали. Сложно понять, какие из них используются в данный момент, и какие будут экспортированы. В одном из плагинов экспорта в smd можно выбрать экспорт явных нормалей, но тогда нужно перед экспортом кидать на меш модификатор Edit Normals, чтобы эти явные нормали у модели были и соответствовали тому, что видно во вьюпорте. В любом случае, всегда надо проверять, что вышло.
А плагин экспорта в obj в 3дмаксе сломан, начиная с 2017 версии, - вершины экспортируются в мировом пространстве, а нормали в локальном.

Отправлено Дядя Миша 22-11-2020 в 15:24:

Текстовость как раз даже очень причём. Бинарные форматы как правило записываются пограммистами, которые хоть что-то там проверяют. А текстовые парсят все кому не лень. Даже если накосячат - пофиг, парсер проглотит.

Добавлено 22-11-2020 в 18:24:

Короче нафиг эти нормали из исходников. Лучше я их сам посчитаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 22-11-2020 в 15:55:

Цитата:

Дядя Миша писал:
Короче нафиг эти нормали из исходников. Лучше я их сам посчитаю.

Ты же в курсе, что при использовании нормалмап нормали должны быть те же самые, что были при запекании с хайполи? Или, может быть, в курсе того, что нормали не завязаны на геометрию и могут быть произвольно отредактированы? Например, для волос или веток деревьев нормали часто проецируют со сферы.

Отправлено Дядя Миша 22-11-2020 в 16:38:

Цитата:

ncuxonaT писал:
нормали не завязаны на геометрию и могут быть произвольно отредактированы

так я и говорю что они всратые очень часто.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 22-11-2020 в 17:10:

Всратые нормали моделист может и в бинарный формат закинуть.

Отправлено KiQ 22-11-2020 в 20:09:

Цитата:

Дядя Миша писал:
Нормалям, полученным из текстовой модельки доверять вообще нельзя.

Ну вот как раз нормали в моем рендере smd всегда получались валидными, даже в анимации, после умножения на матрицу преобразования. В отличие от костей, которые до сих пор плющит и я фиг знает, что с этим делать, уже нервы извёл все

__________________
-Brain is dead-

Отправлено thambs 22-11-2020 в 20:23:

ncuxonaT
А можно их у деревца стрелочками визуализировать, как расположены на краях плэйна?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 22-11-2020 в 20:48:

Цитата:

nemyax писал:
Всратые нормали моделист может и в бинарный формат закинуть.

может. Но для текстовых это уже стало традицией.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 22-11-2020 в 20:51:

Цитата:

Дядя Миша писал:
Но для текстовых это уже стало традицией.

Почему ты думаешь, что виноват формат, если не видел оригиналов моделей? И сам ни разу модели не экспортировал.

thambs

http://www.arielchai.com/wip/q_bentnormals.jpg

http://wiki.polycount.com/w/images/2/23/Tree_shading_examples.jpg

http://wiki.polycount.com/w/images/b/b4/Maya_transferattributes.jpg

Вариант, когда нормали торчат в одной плоскости в разные стороны, обычно выглядит более всрато (слева):

https://us.v-cdn.net/5021068/uploads/editor/65/ca3di3ij07qq.png

К волосам тоже применимо

Отправлено Дядя Миша 23-11-2020 в 06:41:

Цитата:

ncuxonaT писал:
Почему ты думаешь, что виноват формат

Виноват не формат, а то, как с ним обращаются.

Добавлено 23-11-2020 в 09:39:

Да, насчёт деревьев. Я листве просто использовал half-lambert. И получал примерно тоже самое.

Добавлено 23-11-2020 в 09:41:

Надо традиционно сделать два переключателя: глобальный запрет на входящие нормали и локальный запрет по материалам, или персональный запрет для конкретной энтити. Что-то такое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 23-11-2020 в 15:27:

Вот товарищи, какая мерзкая штука получается.
Если сгруппировать сурфейсы по блокам, по которым на каждый блок приходится один ректангл лайтмапы, то этих блоков получается адское кол-во. Значит каждый блок - это один сурфейс. На маленьких всяких картах, типа кутришных еще трепимо. Но если взять к примеру сталкеровскую, там ужос-ужос. Под 200000 сурфейсов. Рендерить 20000 тысяч сурфейсов очень тяжко, даже если ничего не рисовать - всё время уйдет просто на их группировку и отправку на рендеринг. Оптимальное кол-во блоков - 3-4 тысячи на всю карту, в каждом блоке, от 100 до 6000 полигонов.
Ну примерно. В самом сталкере сделано как. Там сперва рассчитывается атлас для лайтмапы и занимаются места в этом атласе. Полученный атлас, очевидно назначается целому ряду сурфейсов. Потом эти сурфейсы мержатся обратно, поскольку больше нет причин держать их разделёнными.
Но есть проблема. При таком подходе плотность люкселей должна быть заранее посчитана на этапе компиляции BSP. То есть чтобы изменить разрешение лайтмапы придётся заново пересчитывать всю карту. Одним только светом не отделаешься.
В сталкере там еще хлеще, там свет всегда считается вместе с остальным, как я понял, свет можно пересчитать потом, но для первой компиляции он считается всегда.

Добавлено 23-11-2020 в 18:27:

Впрочем, я тут погуглил, всё еще интереснее. Компилер света считает освещение для детайлов. Для всякой там травы и мелких кустиков.
А основное освещение отключить вообще не вариант.
Т.е. каждая компиляция принудительно считает освещение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 23-11-2020 в 15:34:

>каждая компиляция принудительно считает освещение
Неделю?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 23-11-2020 в 15:40:

Ну я уже выше писал, что да, там довольно небыстрый рейтрейсер.
Раз в 40-50 медленней моего. Там где мой за 30 секунд управляется, оригинальный может считать минут 8.

Добавлено 23-11-2020 в 18:40:

И еще оригинальный код построения лайтгруп дико медленный, он рекурсивный. Надо его на стек переписать. Там блин он эти группы будет дольше искать, чем считать саму лайтмапу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 24-11-2020 в 18:31:

Цитата:

Дядя Миша писал:
При таком подходе плотность люкселей должна быть заранее посчитана на этапе компиляции BSP. То есть чтобы изменить разрешение лайтмапы придётся заново пересчитывать всю карту. Одним только светом не отделаешься.

А в Сорсе так же? Я ему выставляю другое разрешение но эффекта нет.

Отправлено Дядя Миша 24-11-2020 в 19:15:

Помоему да, там лайтматрица формируется в bsp.

Добавлено 24-11-2020 в 22:15:

Ну как-то так. Это testers_mp_factory. Проблема остаётся - здесь 76 тысяч сурфейсов - по кол-ву лайтмапгруп. Когда лайтмапа посчитана - они уже не нужны и можно эти группы объеденить обратно. Но компилятор света такими полномочиями не обладает. А даже если бы обладал - свет можно было бы посчитать только один раз, после чего требовалась бы полная перекомпиляция уровня. Не думаю что это кого-то обрадует.

Проблема конечно решаемая, но я пока думаю как лучше сделать.
Можно эти группы сохранить прямо в вертексы. Размер карты конечно вырастет. Можно попробовать сразу выделить место в атласе, но это проблемно - как потом считать плотность в юнитах, как реконструировать группы из атласа. Не факт что это вообще возможно. Буду думать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 24-11-2020 в 19:51:

что такое лайтмапгруппа?

Отправлено Дядя Миша 24-11-2020 в 20:26:

группа треугольников, которую можно спроецировать на плоскость.
К примеру террайн = 1 лайтмапгруппа.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 26-11-2020 в 16:06:

Вообщем без затиралки швов не обойтись.
Даже в идеальном случае, когда развертка полностью разматывается вокруг колонны, мы получаем минимум 1 шов.

Там по идее на границе шва надо просто сделать билинейку и всё.

Добавлено 26-11-2020 в 19:06:

Набросал простенькую удалялку швов, но не всё так просто.
На картинке видно, в первую очередь, ну там кое-где пропущенные пиксели, ошибка округления. Это мелочь.
А вот колонна, на которой эти швы и лезут в первую очередь, как видите здесь сами координаты плохо расположены. Надо отцентровать люксели.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 27-11-2020 в 15:36:

Сколько жы времени на бакэнд уходит, это очуметь можно.
Щас вот надо нормальный менеджер моделей написать, там до сих пор какие-то разроненные функции по типу кутришных. Оно мне досталось в наследство и я до последнего момента тянул, не хотел это говно трогать.
Но всё равно придется написать нормальную имплементацию.

Побочным эффектом можно будет создать всякие конветоры моделей из одного формата в другой. Т.е. такая же либа будет, как для изображений.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 28-11-2020 в 10:47:

Дядя Миша ждать SMD 2.0? Кстати, почему такое низкое разрешение у лайтмапы? Может быть сделать возможность его регулировать внутри порталов? Например в индоре - более мелкое, а для ландшафтов, соответственно мягкое крупное

__________________
-Brain is dead-

Отправлено Дядя Миша 28-11-2020 в 11:06:

Я сделаю бинарный промежуточный формат для хранения моделей.
И может быть я ему даже дам расширение .csm

Cached Static Mesh.

Добавлено 28-11-2020 в 14:00:

Цитата:

KiQ писал:
Например в индоре - более мелкое, а для ландшафтов, соответственно мягкое крупное

на ландшафтах тени от деревьев, нельзя там более крупное. Не слишком хорошая идея.

Добавлено 28-11-2020 в 14:06:

В загрузчике моделей я планирую сделать построитель развертки лайтмапы из исходных текстурных координат, с проверками на самопересечения и прочее. И вот еще какой важный момент - со встроенным анализатором плотности. Чтобы не получилось так, что моделька с лайтмапой будет иметь более низкочастотное освещение, нежели повертексное.
То есть, если люкселей меньше чем вертексов - оставляем повертексное.
Накрутили плотность лайтмапы - переключились на люксели.
Единственный недотстаток данного механизма - невозможно адекватно определить плотность, не посчитав лайтгруппы по настоящему.
Т.е. нередка ситуация, когда считали-считали и дропнули, т.к. вертексное ляжет лучше. Но на этот случай как раз и пригодится бинарный формат кэша. Туда меш сразу будет записываться уже с лайтмапными координатами и лайтгруппами. Чтобы потом не пришлось второй раз пересчитывать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 28-11-2020 в 17:29:

А вот кстати вопрос. В сталкере на статике тени меняются в зависимости от положения солнца? В лост альфе 1.4007 утром смешно видеть тени от деревьев в противоположную от солнца сторону.

Отправлено Дядя Миша 28-11-2020 в 18:16:

Дык можно же распаковать ресурсы и посмотреть на лайтмапы.
Лайтмапа там запечена только для одного направления солнца.
Кто-то говорил, что можно запечь для произвольного кол-ва направлений, но я насчёт этого пока не интерисовался.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 30-11-2020 в 09:42:

В сталкере, если вы изучали его лайтмапы, должны были отметить одну забавную особенность. Очень много кусков лайтмап повернуты под произвольным углом, отличным от 90 градусов. Это не касается механизма упаковки в атлас, это результат работы Orbitrary Ortho-Projection (оригинальный камент из кода XRay). Там в чём суть - полигоны группируются по нормали, следя, чтобы сумма этих нормалей не превысила некоторый угол, обычно 89 градусов. Результирующая нормаль частенько получается под произвольным углом, а вместе с нею и лайтмапа. Я отказался от этой схемы довольно быстро, использую своё изобретение, которое я назвал hashed lightmap axis. Идея в том, что для любого полигона можно найти максимально близкую аксиальную нормаль. Всего таких нормалей может быть шесть шутк - по сторонам куба. Это же автоматически повышает и плотность упаковки и исключает ситуации, с цилиндрической проекцией, например для колонны или цилиндра будет создано четыре лайтгруппы.
Правда между ними останутся швы, но при сталкеровском подходе они ведь тоже никуда не денутся. Еще и лайтмапу перекосит на какой-то угол.

Добавлено 30-11-2020 в 12:24:

ncuxonaT ты своим упаковщиком "уголком" когда-нибудь пробывал упаковать достаточно большие атласы? Ну скажем 1024х1024?
И не один, а штук 10. И сколько времени это у тебя заняло.
Потому что моя реализация какая-то адски медленная получилась.
Начиная с размера 512х512 она может маслать несколько минут.
До смешного доходит - освещение считается быстрее, чем упаковка в лайтмапу. Но если страница менее 512, то всё быстро.

Добавлено 30-11-2020 в 12:25:

Да вот пример

C++ Source Code:

1	DirectLighting:

2	0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% (833.86 secs)

3	173028152 total traces casted, 8122516 luxels illuminated

4	total lightmap pages 20

5	CreateLightmapPages: 817.050387 secs

6	writing maps\testers_mp_railroad.bsp

Упаковщик работал сопоставимо с рассчётом освещения. Кармаковский алгоритм таким не страдает, но и пакует ощутимо хуже.

Добавлено 30-11-2020 в 12:39:

Свежие скриншоты:

Фпс низкий, потому что в сурфейсы разбиты по лайтгруппам на 140 тысяч.
Такое кол-во даже просто отправить на рендеринг очень затратно.
Надо мержить обратно, по страницам лайтмапы, но тогда будут проблемы с множественным рассчётом освещения уже готовой карты. Иными словами, осветить карту можно будет только один раз, а потом заново пересобирать с нуля. Впрочем я этой проблемой пока еще не занимался вплотную.
Потом вместе решим как лучше сделать. В идеале тут должно быть 5-7 тысяч сурфейсов.

Добавлено 30-11-2020 в 12:41:

Кстати я реализовал эту схему, когда ландшафт использует лайтмапу более высокого разрешения, нежели остальные. Правда сама лайтмапа ландшафта идёт под таким же номером как и остальные и ничем не выделяется. Только размерами.

Добавлено 30-11-2020 в 12:42:

Деревья не освещены, т.к. подготовлены для повертексного, а его еще нет.
Впрочем это будет опционально, мне сперва надо сделать концепцию MU-моделей. Вот собсно, это и есть две самые главные задачи по компиляторам.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 30-11-2020 в 09:49:

Дядя Миша
На последнем шоте странные потемнения по краям полигонов, так и должно быть?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено ncuxonaT 30-11-2020 в 14:22:

Дядя Миша скорость наверное зависит от количества элементов, а не от разрешения. Проверил, мой изначальный алгоритм уголком уложил 25к элементов в атлас 4096х4096 за 6 секунд. Оптимизированная более уродская версия алгоритма справилась за 1 секунду.

У тебя точно упаковка медленная? В CreateLightmapPages помимо неё ничего не входит? Может, не атлас долго составляется, а освещение в него долго записывается?

Отправлено Дядя Миша 30-11-2020 в 14:52:

25 тысяч элементов и у меня быстро. А вот когда 130 тысяч - уже долго.

Добавлено 30-11-2020 в 17:52:

Цитата:

thambs писал:
На последнем шоте странные потемнения по краям полигонов, так и должно быть?

абведи.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 30-11-2020 в 15:19:

130 тысяч на страницу атласа 1024х1024? 3х3 пикселя куски? Из которых 8 пикселей - это бордюр? Такая себя развертка.
150к в атлас 8к у меня упаковались за 5 минут обычным и 45 секунд оптимизированным.

Отправлено Дядя Миша 30-11-2020 в 15:42:

Цитата:

ncuxonaT писал:
130 тысяч на страницу атласа 1024х1024?

Я наверное неточно выразился. Куски могут быть какого угодно размера, равно как и кол-во страниц. Там какой алгоритм.
Сперва все куски сортируются по размеру
Потом выделяется страница, в которую я пытаюсь запихать вообще все куски, которые у меня есть.
Если кусок прошёл по размеру - помечаем его.
Если кусок не прошёл - ну пофик, переходим к следующему.
И так - пока не проверим абсолютно все куски.
Когда куски закончились лайтмапа считается построенной полностью.
Потому что не может быть ситуации, чтобы она не заполнилась на 100%.
Во всяком случае по разумению упаковщика.
Дальше мы переходим к следующей странице и проделываем тоже самое.
Ну и считаем, если ни один кусок не добавился - значит лайтмапы закончились, процесс завершён.
Конечно этот прогон сам по себе занимает достаточно времени, но на Кармаковском алгоритме он проходит довольно быстро.

Цитата:

ncuxonaT писал:
150к в атлас 8к у меня упаковались за 5 минут обычным и 45 секунд оптимизированным.

А что ты там оптимизировал? Я подозреваю больше всего времени отнимает выделение памяти.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 30-11-2020 в 15:52:

Дядя Миша

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 30-11-2020 в 16:06:

Я рёбра не рендерю, чёб быстрее было. Так-то оно уберётся.

Ну вот пожалуйста. 200 тысяч кусочков на пять лайтмап 1024х1024 добавлялось полчиса, этожы ачуметь можно! Точнее даже в четыре лайтмапы, т.к. в пятой ландшафт.

Добавлено 30-11-2020 в 19:04:

Спровидливозти ради, это на работе, тут комп древний, кора дуба.

Добавлено 30-11-2020 в 19:06:

Ландшафт. Даже от провадов тени есть

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 30-11-2020 в 17:29:

Дядя Миша в одну большую страницу будет собираться быстрее или медленнее, чем в несколько маленьких?

Цитата:

Дядя Миша писал:
А что ты там оптимизировал? Я подозреваю больше всего времени отнимает выделение памяти.

Памяти сразу много выделяю. Оптимизировал вставку нового куска. В оригинальном алгоритме идет рекурсивный поиск свободного лифа по дереву, а я завел список свободных лифов и просто по нему прохожу.

Отправлено Дядя Миша 30-11-2020 в 17:51:

Цитата:

ncuxonaT писал:
в одну большую страницу будет собираться быстрее или медленнее, чем в несколько маленьких?

в одну большую дольше.

Цитата:

ncuxonaT писал:
В оригинальном алгоритме идет рекурсивный поиск свободного лифа по дереву, а я завел список свободных лифов и просто по нему прохожу.

ну это вечный баланс между производительностью бинарного поиска и тупого перебора. Часто хрен угадаешь что окажется быстрее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 02-12-2020 в 07:53:

Нравится это кому-нибудь или нет, но я таки запилил простейший промежуточный бинарный формат для хранения вертексов-треугольников и назвал его CSM, что можно расшифровать как Computed Static Mesh, Compiled Static Mesh или Cached Static Mesh. Но любители конспирологии должны увидеть здесь отслыку к cs-mapping. Не будем им мешать.

И сегодня я наконец-то понял, как же мне смержить сурфейсы обратно в большие куски, не растеряв связи с группами. Причём информации придётся сохранить минимально. Нам не надо хранить информацию для каждого вертекса, нам не надо хранить информацию для каждого треугольника, нам не надо хранить информацию для каждой рендер-группы. Всё что надо сделать - это просто сохранить информацию о ректангле в специальный файлик описания шрифтов, формат которого я разработал этой весной.
Я предполагал, что мне это пригодится, поэтому формат заранее включает в себя разные типы данных: шрифты (описание букв), спрайты (центровка кадра) именованные кадры (для худ-картинок) и наконец лайтмапы.
Там можно сохранить ректангл и размер в world-units. Сами ректанглы записываются в особый файлик сопровождения шрифтов - по одному файлу на каждую лайтмапу. Каждый ректангл - это лайтгруппа. То есть когда мы грузим треугольники геометрии - мы просто напросто ищем в какой из ректанглов попал этот треугольник. Пересечение bbox и tri. В двухмерном пространстве. Задачка решается простым перебором, но здорово ускоряется при помощи AABB дерева. Или двухмерного хэша, но по памяти дерево тут быстрее. И вот таким вот образом нам не надо хранить эту информацию больше нигде. Треугольники обратно собираются в группы, используя минимум информации. Записывать координаты в лайтмапу обратно не нужно - это делается уже в BSP.
Единственный минус подхода - плотность лайтмапы можно будет отрегулировать только в BSP. Впрочем оно почти везде так. И в кутри и в сорсе. А для террейна плотность автоматически считается.
К тому же, пользователь всегда может удалить эти описания шрифтов, сделав перекомпиляцию света невозможной.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 02-12-2020 в 10:01:

Цитата:

Дядя Миша писал:
я таки запилил простейший промежуточный бинарный формат для хранения вертексов-треугольников и назвал его CSM

Дашь нам криворуким моделистам заголовочник, чёб мы нормали портили?

Отправлено Дядя Миша 02-12-2020 в 14:03:

Да их бесполезно портить, компилятор их всё равно игнорит.
Дам конечно. Там оч. простой формат, вертексы, фейсы и всё.

Добавлено 02-12-2020 в 14:13:

Лиманск из Чистого Неба

И конечно машина времени, в оригинале я её так и не нашёл.

4 часа освещение считалось. Наверное из-за того, что домов слишком много. У луча много препятствий.

Добавлено 02-12-2020 в 14:16:

Следует особо отметить, что в данный момент компилятор работает по максимально негативному сценарию - каждое деревце, каждый пропс копируется и вставляется в карту заново. Из-за чего Лост-Альфовские карты, например, могут занимать до полугигабайта по размерам. Но для меня главное, что сам компилятор это выдерживает и прекрасно укладывается в 32-х битные лимиты по памяти. Уж если он такое издевательство выносит, то без дубликатов - тем более. Но это всё потом. У меня итеративная разработка.

Добавлено 02-12-2020 в 16:56:

Остались у меня две самые сложные задачи.

1. переделать механизм лайтгрупп на новую систему, о которой я написал выше. Наполовину уже сделано, т.е. bsp переписал, остался рад.

2. сделать мульти-референс модели, чтобы не дублировать геометрию. Очень много мелочей придётся учесть, это утомляет.

Опять же с коллизией вопрос в воздухе подвешен, я ею так и не занимался.
Но к счастью коллизия не затрагивает визуальную часть. Там надо будет изучить варианты. Я просто предполагаю, что если строить прямо по-хорошему конвексные хуллы, это и вправду займёт около недели. Очень тяжёлая операция.

Добавлено 02-12-2020 в 17:03:

Во, я вспомнил в чём цымес. В BSP будет введён ключ -onlylights, чтобы можно было обновлять только лампочки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 02-12-2020 в 16:03:

Тебе не кажется, что ты переусложняешь?

Отправлено Дядя Миша 02-12-2020 в 16:22:

ncuxonaT переусложняю что именно?

Добавлено 02-12-2020 в 19:22:

Всё что я перечислил - обязательные вещи. Без мержинга лайтмап, фпс ниже плинтуса. Без мульти-референса моделей чудовищный размер уровня, без коллизии игрок постоянно проваливается в скайбокс.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 02-12-2020 в 17:33:

То, что про мержинг лайтмап. Я не очень понял, что с чем объединяется. Вся геометрия разбивается на лайтгруппы, которым соответствуют отдельные куски на лайтмапе, так? Потом эти лайтгруппы объединяются в большие куски, чтобы рендерить их одним дипом?
Почему нельзя хранить эти куски как субмеши с указанием номера страницы лайтмапы? И текстурные координаты для обычных текстур и для лайтмапы.

Отправлено Дядя Миша 02-12-2020 в 18:07:

Цитата:

ncuxonaT писал:
Я не очень понял, что с чем объединяется

Вот есть страница лайтмапы. На ней - множество мелких кусочков.
Каждый кусочек - это лайтгруппа. Это то, что удалось развернуть в единый кусок. Наверное в такой группе все треугольники соприкасаются.

Далее, большие секвенции делятся вот на такие вот маленькие. И каждая маленькая секвенция содержит набор треугольников, точно соответствующий одной лайтгруппе. Это не нужно для рендеринга. Это нужно чтобы компилятор света мог найти эти группы и посчитать свет для каждой.

Цитата:

ncuxonaT писал:
Вся геометрия разбивается на лайтгруппы, которым соответствуют отдельные куски на лайтмапе, так?

да.

Цитата:

ncuxonaT писал:
Потом эти лайтгруппы объединяются в большие куски, чтобы рендерить их одним дипом?

Потом нельзя - вопрос концепции. Рад не имеет права этого делать, поскольку рад по замыслу можно запускать много раз подряд. А если рад объединит сурфейсы, то второй раз его запустить будет уже нельзя.

Цитата:

ncuxonaT писал:
Почему нельзя хранить эти куски как субмеши с указанием номера страницы лайтмапы?

Ну во первых оно жы там как-то разбивается на куски, чтобы в одном сабмеше было не более 65 киловертексов. А уж сколько лайтгрупп в этот меш попадёт не учитывается. При таком подходе найти какие там вертексы какой лайтгруппе соответствуют и тем более выделить эти сабмешы - достаточно ресурсоёмкая задача. Т.е. сортировка и группировка в первую очередь должны полагаться на максимально дружелюбную дату для рендинга. А не искать компромиссы, чтобы их лайтмаппер хорошо видел. Это ничем хорошим не закончится. Да и там слишком много мест, где всё это перетасовывается, я не смогу их все отследить. Можно сделать тупо - для каждого треугольника завести структурку

C++ Source Code:

1	// 16 bytes here

2	struct ref_lightgroup

4	uint32_t container; // gcontainer index

5	uint32_t firstelem; // gcontainer->firstelem + firstelem

6	uint32_t numelems; // for( uint32_t i = gcontainer[container].firstelem + firstelem; i < numelems; i++ )

7	int32_t lightGroup;

};

10	// 4 bytes here

11	struct ref_group_bounds

13	hvec2 bounds; // изначальные баундсы для каждой лайтгруппы, чтобы можно было восстановить истинный

14	// размер. Места в атласе выделяются в makebsp

};

Это то, что мне в голову пришло в первую очередь. Но когда в сцене 4-5 миллионов сурфейсов подобные сервисные структуры могут весить до 50 мегабайт. Zhopa. Вторая мысль была озвучена выше - сохраняем для каждой страницы атласа информацию о ректанглах. А затем просто пропускаем каждый треугольник сквозь этот ректангл и находим, где он попал внутрь. Если попал - этот треугольник принадлежит этой лайтгруппе. Для ускорения процесса я построю двухмерное AABB-tree.
Полагаю это будет самый оптимальный вариант.
Есть у такого подхода и минус - невозможно сжимать в 1 пиксель совсем чёрные лайтмапы, например. Но это в целом некритично. А для лайтстилей - даже вредно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Raid 03-12-2020 в 15:23:

Цитата:

ncuxonaT писал:
Ты же в курсе, что при использовании нормалмап нормали должны быть те же самые, что были при запекании с хайполи? Или, может быть, в курсе того, что нормали не завязаны на геометрию и могут быть произвольно отредактированы? Например, для волос или веток деревьев нормали часто проецируют со сферы.

А можно для дебилов как сделать так же красиво? А то у меня пока как слева деревья выходят.

Отправлено ncuxonaT 03-12-2020 в 16:57:

Дядя Миша лайтгруппы нужны только раду? Но развертку под лайтмапу создает бсп?

Raid скрипты slide normal thief или noors normal thief для 3дмакса проецируют и переносят нормали с одного объекта на другой. Создаешь вокруг дерева сферу или полусферу, выбираешь её как источник нормалей, крону дерева выбираешь как таргет и переносишь.
https://gamebanana.com/tuts/12231

Отправлено Дядя Миша 03-12-2020 в 17:16:

Цитата:

ncuxonaT писал:
лайтгруппы нужны только раду? Но развертку под лайтмапу создает бсп?

всё верно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 03-12-2020 в 18:12:

Дядя Миша как сложно с вашим радом. Тогда да, наверное, способ со хранением прямоугольников проще. Еще можно было бы искать по соприкасающимся ребрам на развертке. В таком случае лайтгруппы могли бы быть невыпуклыми. В смысле не надо было бы под лайтгруппу отдавать целый прямоугольник.

Отправлено Дядя Миша 03-12-2020 в 20:09:

Цитата:

ncuxonaT писал:
Еще можно было бы искать по соприкасающимся ребрам на развертке.

можно, да, но это хреновый критерий для привязки. Неоднозначный.

Цитата:

ncuxonaT писал:
как сложно с вашим радом.

пока игрушечные сцены компилишь - пофигу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-12-2020 в 11:25:

Переделал концепцию, как описано выше. Стало на порядок удобнее.
Во первых, реконструкция групп - очень быстрая, пару секунд буквально.
Во вторых, с учётом сделанных изменений, лайтмаппер вообще не модифицирует BSP, ему это просто не нужно. Только сами лайтмапы.
Правда остаётся еще вопрос с повертексным освещением, но прежде чем его решить, надо придумать что делать с дубликатами. Как им накладывать лайтмапу, как повертексное. Причём этот момент вообще самый сложный, надо очень многое продумать. Как это всё рисовать, как выполнять коллизию.

Добавлено 05-12-2020 в 13:37:

Единственное, с чем я лажанулся в своей концепции - исходил из того, что в атласе не может быть более 65к кусочков. А тут лайтмапы.
Не, ну для шрифтов и картинок худа это условие полностью выполнялось.
Хидер менять - это заново все шрифты и худ пересобирать. Ох, блин.

Добавлено 05-12-2020 в 13:37:

Ну да ладно, пособираю статистику, как часто происходит это превышение.

Добавлено 05-12-2020 в 14:25:

Что еще любопытно - я полагал что уменьшение размера вертекса хорошо уменьшит конечный размер BSP-файла. Но по факту снижение произошло всего на 1/6. Все эти дубликаты дают такой чудовищный размер.

Впрочем я неплохо оптимизировал компилятор по потреблению памяти и даже с таким негативным сценарием он отлично справляется, среднее потребление всего 700 мегабайт на сталкеровских картах.
Так я уже и лост-альфовские пробую.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 05-12-2020 в 11:37:

Цитата:

Дядя Миша писал:
Так я уже и лост-альфовские пробую.

А они сильно более детализированные, или только из-за размера сложнее? Я вот сейчас всё-таки прохожу 1.4007, и порой возникает желание дать по морде тому, кто некоторые из них так удлиннил. Кордон на севере, Свалка и Металлургическая Фабрика на юге имеют просто бесполезные кишки по 200-300 метров, где ничего нет. Локации в целом классные, если их поурезать и выбросить незанятое место, будет отлично.

Добавлено 05-12-2020 в 18:37:

Ах да, ещё Тёмная Лошина. Именно лошина (по состоянию души автора), потому что нормальному человеку не придёт в голову делать локацию-кишку, на которой всего несколько мест для посещения и дебильный километровый жд тоннель.

Отправлено Дядя Миша 05-12-2020 в 13:19:

Цитата:

Ku2zoff писал:
А они сильно более детализированные, или только из-за размера сложнее?

да там вроде бы и то и это.
Была какая-то локация - 98 килоюнитов в поперечнике.
Болота из CS - 59 килоюнитов квадрат. Очень хорошая локация.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 06-12-2020 в 08:16:

ncuxonaT кстати ты был частично прав, действительно запись кусков в лайтмапу занимает часть времени от построения атласа. 56 страниц 1024х1024 писались почти 2 минуты.

Добавлено 06-12-2020 в 11:16:

И да, я ради интереса перекроил этот механизм, выделил память под ноды одним большим куском. Сразу под все ноды. Кусок лайтмапы с бордюром занимает 3х3 пикселя, страница 1024х1024, значит выделяем (width / 3)* (height / 3) + 1 (корневая нода), около 17 мегабайт. Ну не фатально.
И время построения вообще не поменялось. Как было пару минут так и осталось. Значит рекурсия всё убивает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-12-2020 в 06:35:

Разобрался как в сталкере устроено освещение. Вообщем для солнца лайтмапа в явном виде не хранится. Оно и понятно, нужна смена времени суток. Хранится hemisperical lighting и теневая карта. Hemispherical годится для любого времени суток, а вот теневая карта, увы только для одного направления. Впрочем, я думаю, можно рассчитать тени для всех положений солнца. Освещение по полусфере получается от виртуальных hemi-источников. В q3map2 была настройка q3map_skyLight, вот это оно и есть.
Просто генерятся лайты с равномерным распределением в несколько сторон, по окружности, симулируя непрямой свет. Если на ландшафте, допустим стоял какой-нибудь столб, то на лайтмапе прямо видно эти нечёткие тени от разных направлений и их можно посчитать. Чем больше равномерно распределённых таких источников, тем более качественной получается hemi-лайтмапа. Ну и в шейдере всё это смешивается - цвет от солнца (деномический), умножить на теневую карт плюс индирект + амбиент.
Для точечных лайтов хранится просто RGB-мапа с запечённым индиректом.
Этот же подход объясняет как при такой угробищной схеме построения атласа практически не видно швов. Индирект равномерный и его переходы не видны. Прямой свет накладывается попиксельно. А тени редко попадают в стрёмные места. Остаётся еще свет в помещениях, но там во первых VPLS для радиосити, а во вторых, в большинстве помещений - пусто. Голые стены и немного предметов. Так что заметить швы нереально. Но мне конечно такой способ построения атласа не годится. У Микрософта есть UVAtlas какой-то, он раньше был частью DXSDK, но они апублековали сорцы. И вот все кто юзал DX с незапамятных времен его использовали для генерации. Помоему это одна из первых имплементаций LSCM (статья от 2002-го года). Конечно это занимает порядочно времени, но с другой стороны - это всё равно сохранится в статик-мешах моего формата. Так что пофиг. Один раз посчитать и всё.
А для брашей можно и мои hashed LM axis юзать, они хорошо спровляются.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-12-2020 в 14:24:

ncuxonaT напомни как твоя затиралка швов работает.
Всю тему пересмотрел - не могу найти упоминания.
Единственное что нашёл, это про какой-то уровень качества, по дефолту равный 100.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 07-12-2020 в 14:34:

Дядя Миша https://www.sebastiansylvan.com/pos...esTextureSeams/

Отправлено ncuxonaT 07-12-2020 в 20:32:

Единственное что, направление градиента нужно сбрасывать периодически. Я в ConjugateGradientOptimize на каждой 10 итерации ставлю beta = 0.0;

Отправлено thambs 07-12-2020 в 21:02:

Дядя Миша
Эти сталкеровские карты как-то делятся (на сектора?) или это всё один огромный кусок геометрии?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 08-12-2020 в 09:39:

ncuxonaT я делал немного по другому. Просто находил соседние эджы и биинтерполировал их люксели. А эджы находил вообще перебором, но поскольку меш индексированный, это было достаточно быстро. Но есть большая проблема. Для брашей это работает плохо из-за T-Junc.
А градиенты вообще можно применять изолировано.

Но использовать Conjugate Gradient Solver мне как-то в голову не пришло.
Да дело вообще не в солверах, я уверен. Дело в том, что я вероятно не понимаю истинной природы швов этих. К тому жы там как минимум два варианта может быть - несовпадение цветов люкселей и несовпадение их оригинов. И вторая проблема куда серъезнее. Вот у нас допустим пятно света. Переходит на два полигона. И на втором люксели сдвинуты относительно первых на половинку. Ну и всё - пятно со швом. И это уже никакими градиентами не поправишь.

Кстати, непомню кто, но кто-то авторитетный говорил - пофиг на повороты лайтмапы, главное чтобы не было швов. То есть, если у нас лайтмапа повернута даже на 45 градусов, то это ок. Но я не согласен. Повернутые люксели тоже выглядят как говно.

Цитата:

thambs писал:
Эти сталкеровские карты как-то делятся (на сектора?) или это всё один огромный кусок геометрии?

Делятся, но без фанатизма. В отличие от BSP, который явно стремится нарезать геометрию по секущей плоскости, здесь просто идёт пространственная группировка для того чтобы отрисовать сразу побольше полигонов, если они оказались в одном месте. Ничего не режется, просто делится на группы. В группе от 64 до 4096 треугольников обычно. Потом, когда лайтмапа построена, их можно дополнительно смержить.

Добавлено 08-12-2020 в 09:18:

Цитата:

Дядя Миша писал:
Для брашей это работает плохо из-за T-Junc.

Кстати первоначальный вариант нахождения групп искал не смежные рёбра, а просто коллинеарные. Надо наверное вернуть это повидение для брашей. Ну или второй вариант - построить T-Junc и они свяжут эти сурфейсы через себя. Заодно по швам на лайтмапе можно будет проверять качество их удаления.

Добавлено 08-12-2020 в 09:22:

А, да. Я жы всё-таки вчера опробовал LSCM. Линейный солверов в сети до чёрта, но они обычно идут в составе какой-то гигантской библиотеки, типа Eigen или OpenNL, и достать оттуда только то что надо, проблематично.
Но я нашёл старенькую OpenNL еще с реализацией солверов на шаблонах и подключил их. Ну что сказать? Наверное лыжы не едут.

Механихм рабочий, но качество разбивки отвратительное. Причём исходные значения текскордов солвер вообще мало волнуют. Я довольно много разных параметров там крутил и получал стабильно отвратительный результат.
Обычно вполне хорошую поверхность разрывает на 2-3 по случайному принципу. Не знаю, что ему надо. Надо будет еще попробовать нвидиевскую релизацию из Thekla_Atlas.

Добавлено 08-12-2020 в 09:29:

А, насчёт градиентов. В сталкере используется эффективный метод их применения и в тоже время очень простой. Там каждый люксель помечен маркером - было ли в него попадание. Даже не света или трассы, а просто - попал ли этот люксель в треугольник или хотя бы на его ребро. Ну а дальше Average Occluded Samples, по типу как в ку3 у Кармака, но хитрее.
Там задаётся уровень значений этого маркера. Если люксель строго попадает внутри геометрии, то у маркера значение 255. А у остальных градиентов - 254 и так далее по убывающей. То есть по сути это тоже СЛАУ, но весьма быстрое. Оно каждый раз ищет сумму люкселей с маркером выше чем у текущего, заглядывая в 8 соседей.
Этот эффект можно увидеть на лайтмапах в сталкере. Некоторые места этих лайтмап выглядят как нисходящий градиент в прямой угол. Я правда хз, надо ли было так заморачиваться, ведь достаточно одного сторожевого люкселя.

Добавлено 08-12-2020 в 11:22:

Вот к примеру львиная голова из кутри. Ну что это такое?
Технически это мало чем отличается от исходных текстурных координат.

Добавлено 08-12-2020 в 12:39:

У LSCM есть одна очень мерзкая особенность. Он на вход принимает уже готовую параметризацию и растягивает квадраты. Но если параметризация была выполнена с разбивкой на раздельные фейсы то адекватного результата дождаться не получится.

Вот с примером этого льва. Там на половинки текстура отзеркалена.
Результат соответствующий. Я могу конечно нагенерить абстрактные координаты, но вертексы от этого не станут смежными, поскольку текскорды не дают им это сделать.
Есть вариант с другой разбивкой, хранить текскорды в фейсе, а точки - отдельно, но это опять гонять объемы данных.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 08-12-2020 в 10:46:

Хех, ну чтож я оказался прав. Солверу критически важны входные данные.
Иными словами, если подать ему на вход уже существующую параметризацию в виду текстурных координат, то и на выходе мы получим ну примерно такие же текстурные координаты, только в профиль.
То есть впустую потратим время. Решение заключается в том, чтобы убрать из вертексов текстурные и лайтмапные координаты и перенести их в структуру фейса. Тогда мы сможем абсолютно точно подсчитать кол-во уникальных вертексов, сгенерить абстрактную проекцию в качестве начальной параметризации (просто выберем какой-нибудь произвольный угол или короткую сторону ббокс, это вообще плевать, солвер сам растянет квадраты правильно), и подать это на вход. И вот тогда у нас получится что-то нормальное. Вот такой симпатичный лёва у меня тепреь получился.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 08-12-2020 в 13:25:

Цитата:

Дядя Миша писал:
И на втором люксели сдвинуты относительно первых на половинку. Ну и всё - пятно со швом. И это уже никакими градиентами не поправишь.

Поправишь. Градиенты замажут так, что видно не будет.

Цитата:

Дядя Миша писал:
Кстати первоначальный вариант нахождения групп искал не смежные рёбра, а просто коллинеарные.

Я именно так и делаю. Тжунки не учитываю вообще.

Цитата:

Дядя Миша писал:
А, насчёт градиентов. В сталкере используется эффективный метод их применения и в тоже время очень простой. Там каждый люксель помечен маркером - было ли в него попадание. Даже не света или трассы, а просто - попал ли этот люксель в треугольник или хотя бы на его ребро.

В методе с сопряженными градиентами это тоже учитывается. Люксели внутри треугольника имеют больший вес, чем наружние.

Цитата:

Дядя Миша писал:
Вот такой симпатичный лёва у меня тепреь получился.

А что у симпатичного лёвы с искажениями и равномерностью?

Отправлено Дядя Миша 08-12-2020 в 15:35:

Корочи хрень полная этот LSCM. Я на какой-то демке на гитхабе находил в качестве примера картинку, где LSCM ловко наложил текстуру на лицо.
Так вот подтверждаю - для морд раскладку он генерирует действительно просто идеально, лучше не придумаешь. В остальном у него ровно те же самые проблемы. Если будет цилиндрический объект - тут же настанет жопа.
Пример - та же самая морда с рогами. Морда отлично, рога вытянулись в острые треугольники. Его конечно можно и дальше ограничивать, например по углу от базовой нормали или по реальным текскордам, но тут мы столкнёмся с той же самой траблой - если так ограничивать, то LSCM и вовсе не нужен, я обычной трипланаркой управлюсь. Но в том-то и смысл, что вот у нас к примеру раковина и хочется для нее иметь нормальную развертку.
Так ладно раковина, а если к примеру унитаз? Это ж вообще капец!

Есть еще геодезическая проекция, она используется, например для проекции нашей и так уже плоской земли на другую плоскость.
Вот вероятно мне надо копать в эту сторону. Тем более, как я понял, что его мелкософт юзает для своего UVAtlas из D3DTools. Я конечно позавчера ковырнул его сорцы, но там тихий ужас. Надо найти какое-то чистое решение - примерчег.

Добавлено 08-12-2020 в 18:35:

Я чёт совсем забыл, что в комплекте с OpenNL идт демонстрационные модельки для теста LSCM. А щас глянул - все модельки, это чьи-то морды.
пять моделей разных морд. Зашибись вообщем. И разумеется ни у одной морды нету рогов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 08-12-2020 в 17:17:

Рога взрезают вдоль и обводят у основания, и только тогда лскмизируют.

Отправлено Дядя Миша 08-12-2020 в 18:59:

Изучал этот микрософтовский UVAtlas. Углубился. Во первых там тоже нет серебряной пули. Он пытается сперва сделать тривиальную параметризацию. Потом планарную. Потом строит геодезическую изомапу.
Потом внимание! проверяет, не является ли тело цилиндром или бараньим рогом. И тут внимание! вызывает для параметризации цилиндра чертову функцию, которая просто делит его на два куска. Я это как увидел, у меня уж руки опустились... А бараний рог сверху проецируется, в круг.
Полное дерьмо. Из этого следует нехитрый вывод - изомапа с замкнутыми объектами тоже не дружит. И второй вывод - надо к каждому типу объекта свой подход. Иначе просто никак.
То есть вот я нашёл тут гитхаб чувачка который занимался параметризацией. Дипломная работа у него штоле:
https://github.com/alecjacobson/geo...arameterization
так вот там просто до чёрта вариантов. Спрашивается, если бы было ультимативное решение, ктобы всё это тестировал и изобретал?

Добавлено 08-12-2020 в 21:58:

Мало этого. Там еще и общий метод состоит из:

Landmark Merging by geodesic distance

если не прокатит, то

LSCM

далее

Barycentric parametrization

spectral clustering

и наконец если не прокатит - разбить по фейсово.

Добавлено 08-12-2020 в 21:59:

А я ещ думал, да чтож либа такая громадная, да чому там столько кода.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 08-12-2020 в 19:16:

Дядя Миша а ты думал, почему люди руками до сих пор развертку делают?

Отправлено Дядя Миша 08-12-2020 в 19:27:

ncuxonaT я думал они щас нейросеть обучают

Вообщем еще немного покопаюсь с этим и чувствую что вернусь к исходному варианту - строить из текстурной развёртки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 09-12-2020 в 08:32:

Так, кажется я кое-что понял. Мне необходимо посчитать халф-эджы и boundaries. Может и LSCM нормально заработает.
Вобще складывается ощущение, что это тема нормально нигде не разобрана, есть только отдельные статьи, а общего обзора, сравнения и принципов нету.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 11-12-2020 в 05:35:

Вышел новый Unigine и в него добавили лайтмаппер. Я помню, как Запрягаев в своё время орал - никаких лайтмап, только динамика. А как его ушли, так сразу и добавили. Интересное кино.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 11-12-2020 в 19:14:

Дядя Миша
Поясни один момент. Если карта собрана из smd, то она обязательно должна лежать внутри брашевого скайбокса, или же замкнутый smd сам по себе может сформировать уровень без ликов?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 11-12-2020 в 19:44:

внутри скайбокса да.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 12-12-2020 в 20:01:

Цитата:

Дядя Миша писал:
Спрашивается, если бы было ультимативное решение, ктобы всё это тестировал и изобретал?

Как говорил Постников, само разнообразие решений означает что ни одно из них не является приемлемым.

Отправлено Дядя Миша 13-12-2020 в 07:20:

Я тут на геймдеве спросил, можно ли нейронку приспособить для редукции одного измерения, но народ скатил тему во флейм.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 14-12-2020 в 10:01:

Чем дальше я лезу в дебри этого микрософтовского параметризатора, тем больше укрепляется впечатление, что это какое-то адовое дерьмо.
Ну вот судите сами. Первое, что он пытается сделать - это надежда на то, что поверхность - один сурфейс и её можно параметризовать абстрактным треугольником или что-то вроде этого. Следующая проверка - что это нечто вроде плоскости. Идеальный кейс на самом-то деле. Тут не надо никакого СЛАУ, тривиальная проекция всегда даёт отличный результат.
Собственно единственный кейс, который всегда даёт что-то валидное с минимальными усилиями. Ну и дальше он, прямо как в сталкере пытается вычесть нормаль из первого случайно выбранного фейса с остальными нормалями (собсно единственное отличие как раз таки в том, что он вычитает, а не складывает). Если по результатам такого вычитания длина нормали опасно приблизилась к нулю (т.е. меш завернулся сам на себя, по типу цилиндра), то ой-ой, нам это не годится, стоп работа. Однако прикол в том, что планарная параметризация особенно с учётом выполненной подготовительной работы, по разделению на субмешы, раздельные потом по границам, вероятность того, что такое наложение окончится фейлом, ну процентов может быть 10-15. Как раз вот для всяких там цилиндров или лонгхорнов. Проще говоря - для меша, который совсем на себя завернулся.
Ну есть конечно еще одно условие - чтобы не было нулевой площади у треугольников, но это ведь вырожденный случай.

То есть меня не покидает ощущение, что все эти eigen И решение слау там чисто для галочки и охватывают какие-то совсем уж узкоспециальные мешы, которые к тому же еще и детектируются особым образом. А на большинство ложиться обычная планарка. Просто я до последнего в это не хотел верить. Но сейчас ради интереса всё же проверю. И посмотрим.

Добавлено 14-12-2020 в 13:01:

PS. для тех кто в танке поясню - параметризация цилиндра это наипростейшая операция, вообще без матана, единственная сложность - это убедиться, что перед нами реально цилиндр.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 14-12-2020 в 14:49:

"eigen"?

Отправлено Дядя Миша 14-12-2020 в 14:56:

https://ru.wikipedia.org/wiki/Eigen

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 14-12-2020 в 17:58:

Дядя Миша
Ещё вопрос. Скажи, возможно ли в рамках одной карты иметь несколько 3d-скаев, которые рендрятся в зависимости от локации в зависимости от локации?

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 15-12-2020 в 10:31:

В новом ксаше нету 3д-скаев. Я пока не трогал этот вопрос. Но технически сложностей нету.

Добавлено 15-12-2020 в 10:35:

Вообщем я дропнул эти эксперименты с микрософтовским параметризатором. Ужасно мутный и тошнотворный код, никогда еще такого не видел. Обычно я в любом незнакомом коде спустя час изучения уже могу выделить ключевые моменты и понять принцип работы. Здесь это сделать невозможно, потому что на каждой стадии алгоритм проваливается дальше и дальше и даже когда он завершил работу нельзя сказать, что там на выходе уже какой-то корректный результат, потом еще идут пост-процессы, мержинг и замазывание, то есть понять, что даёт наибольший вклад решительно невозможно. Это видимо современный стиль программирования. Может быть оно там на всех этапах выглядит как дерьмо, но в конце эти кусочки объединяются, сглаживаются и конечный результат уже на что-то похож. Но там нет главного алгоритма. Там нельзя сказать, что 90% параметризации осуществляется через какую-то функцию, а некоторые специальные случаи - отдельно. Нихрена подобного. Там минимум пять или шесть вариантов и на каждом этапе оценивается качество построения. Плюс для геодезической изомапы надо рассчитать vertex importance и они не придумали ничего умнее, как сделать это через построение progessive mesh, что само по себе довольно тяжелая операция, но самое интересное - это учесть, что чаще всего в атлас попадают вообще какие-то незамкнутые конструкции с одной границей, для которой считать PM на мой взгляд вообще бессмысленно. Но предполагается что для таких кусочков параметризация будет выполнена типа раньше - на этапе планарной параметризации. Самое смешное, что изомапа тоже может сфейлить и следующий этап - барицентрическая параметризация, но перед этим будет проверка на цилиндр. Я опробовал барицентрическую отдельно - ну это просто несеръезно. Не зря её в Thekla Atlas дропнули.
Кстати LSCM они там сразу выключили по умолчанию. Видимо он не оправдал надежд даже по их меркам.

Я всё больше склоняюсь к тому, что надо просто создавать атлас из текстурных координат. Это самый простой и надёжный путь. Причём с тем подходом, который использую я, не имеет даже значения тот факт, что текстура может быть наложена с повторами. Потому что тексели конвертируются в мировые юниты, а потом ремапятся к реальному размеру атласа. Этот же механизм позволяет заранее кэшировать меши без реальной привязки к сэмпл-сайзу. То есть, когда в материале он меняется, меш не надо пересчитывать заново. Ну и самый важный момент - юзер контролирует качество лайтмапы при таком подходе. Очевидно, если шов на текстуре, то шов на лайтмапе заметить уже невозможно.

Добавлено 15-12-2020 в 10:38:

И кстати. Я в своё время был очень удивлён насколько пользователи готовы самостоятельно всё исправлять и улучшать, не полагаясь на движок. Они просили лишь вменяемые инструменты контроля, чтобы не пришлось это делать через хитрозакрученную задницу.

Добавлено 15-12-2020 в 13:16:

Ну да ладно. Пора возвращаться к основной задаче, из-за которой я не могу двигаться дальше - сделать поддержку MU-моделей. В Волатиле её кстати нет, из-за чего невозможно сделать ТЛез32. В Сталкере, как мы пару дней назад выяснили в соответствующей теме MU-модели могут освещаться только повертексно. Шареная геометрия + массивы цвета. Я понятия не имею как они при рендеринге объединяются, никогда с подобной задачей просто не сталкивался. И если честно, не хочу и пробывать. Я хочу сохранить цвета вертексов в лайтмапу, а брать их через VTF. Надеюсь, что он у всех потдерживается, начиная с GF6600. Потому что я точно помню, что смотрел его демки именно на этой карточке. Плюсов много - структура повертексного располагает теми же данными, что и попиксельное (т.к. на вертекс обычно приходится меньше данных, чтобы он сам не распух), здесь это неактуально. Не надо городить какие-то дополнительные массивы опять же. Из минусов боюсь только, что VTF будет недостаточно быстрым. Ну это я проверю. Так же предстоит понять, как именно модельки должны превращаться в MU. Не то по запросу юзера, не то автоматически.
Но тут вот какое соображение. В сталкере это автоматически провоцировало повертексное освещение, т.е. экономя на переиспользовании мы лишались лайтмапы. У меня этого не будет, поэтому я думаю, можно сделать автоматически, подсчётом референсов. Если референсов больше одного - это MU.
В лайтмаппере трассу придётся перестроить с учётом новых реалий. Это уже будет сложносоставная трасса из AABB и локальных Kd-tree. Но кстати она должна напорядок быстрее строиться и занимать гораздо меньшы места. А вот удержится ли её производительность на уровне чистого KD-tree тут уж хз. Будем надеяться, что да.
Ну и в шейдер придётся пропустить параметр смещения в лайтмапе от референса (для всей модели или для визгруппы). Опять жы интересный вопрос, как набивать цвета вертексов в лайтмапу. Если линией, то явно не хватит её длины. Значит где-то надо будет сделать перенос. Ну или скажем извлечь корень из числа вертексов и это будет стороной квадрата с люкселями для вертексов. Что-то такое. Впрочем повертексного у меня пока что нету.

Добавлено 15-12-2020 в 13:31:

Любая реализация начинается с концепции. Я бы мог принять за концепцию, что любая MU-модель доступна только для мира, а для саб-моделей они дублируются, но это не слишком прозрачно.
Эти модельки по идее должны глобально шариться между любыми энтитями.
Это будет более разумный подход. К тому же их можно отпроцессить заранее, еще до того, как будет построено дерево для мира.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 15-12-2020 в 11:58:

Цитата:

Дядя Миша писал:
Ужасно мутный и тошнотворный код, никогда еще такого не видел. Обычно я в любом незнакомом коде спустя час изучения уже могу выделить ключевые моменты и понять принцип работы. Здесь это сделать невозможно, потому что на каждой стадии алгоритм проваливается дальше и дальше и даже когда он завершил работу нельзя сказать, что там на выходе уже какой-то корректный результат, потом еще идут пост-процессы, мержинг и замазывание, то есть понять, что даёт наибольший вклад решительно невозможно. Это видимо современный стиль программирования. Может быть оно там на всех этапах выглядит как дерьмо, но в конце эти кусочки объединяются, сглаживаются и конечный результат уже на что-то похож. Но там нет главного алгоритма. Там нельзя сказать, что 90% параметризации осуществляется через какую-то функцию, а некоторые специальные случаи - отдельно. Нихрена подобного. Там минимум пять или шесть вариантов и на каждом этапе оценивается качество построения.

Современный стиль? Но ты же говоришь это в 2002-2003 году писалось? Какая же это современность?
А вот на что похоже-так это на то как работают нейросети.

Цитата:

Дядя Миша писал:
Я в своё время был очень удивлён насколько пользователи готовы самостоятельно всё исправлять и улучшать, не полагаясь на движок. Они просили лишь вменяемые инструменты контроля, чтобы не пришлось это делать через хитрозакрученную задницу.

Ты только смотри, что это были за пользователи. Если это было то поколение которое потом первую Паранойю сделало, то данное наблюдение уже устарело.

Отправлено Дядя Миша 15-12-2020 в 13:23:

Цитата:

Crystallize писал:
Но ты же говоришь это в 2002-2003 году писалось? Какая же это современность?

Начали в 2003-м, да. И сопровождали все 18 лет, там уже номер версии 180 или около того.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 16-12-2020 в 18:53:

Я тут озаботился важнейшим вопросом - решил узнать сколько же деревьев в настоящем лесу. И вот данные колеблются от 600 до 4000 на гектар.
А минимальный - полгектара, т.е. 50х50 метров, но это несеръезно конечно.
Возмьмем нормальный лес, ну скажем 100 квадратных километров, это десять тысяч гектар. Таким образом в подобном лесу может расти 40 миллионов деревьев. Вот это настоящий ТЛез32.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 17-12-2020 в 07:29:

Внедрил поддержку MU-моделей на две трети. А почему на две - в компилятор, в движок, осталось в лайтмаппер сделать. Вес карт очень резко упал. Теперь он не превышает 90 мегабайт даже на картах из LostAlpha.
Причём судя по всему он даже меньше чем оригинальная геометрия (но правда у меня пока еще нет лодов). Скажем la23_oldroad с копированием геометрии весила 550 мегабайт , а с MU-моделями - всего 78 мегабайт.
Удивительно как маленькие модельки, вставленные на карту много раз так сильно раздувают конечный размер. Бонусом упало потребление памяти для компиляции. Раньше оно могло достигать почти двух гигабайт, т.е. впритык, теперь - непревышает 400-500 мегабайт, что даже меньше чем у p2st.
Правда FPS всё же сильно падает, если смотреть из одного края карты на другой. Так что нужны лоды. А потом - писать конвертор уровней из метро эксодус. И вот ежели новый ксаш прожует тамошние карты, можно сказать, что всё удалось.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 18-12-2020 в 01:53:

Дядя Миша слушай, ты проверь сам, конечно, но похоже, что считать TBN в шейдере - это дохлый номер. Тангенты получаются граненые, и ничего с этим не сделать. Ортогонализация помогает не сильно.

Отправлено Дядя Миша 18-12-2020 в 05:59:

Цитата:

ncuxonaT писал:
Тангенты получаются граненые

Как стакан? На геймдеве народ тожы жаловался, но там интереснее. Говорили, что пространство плывёт, если подойти к модели черезчур близко.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 19-12-2020 в 11:39:

Очень непростая это штука - лайтмапы для инстанс-моделей.
Во первых рассчитать динмически размер страницы - почти нерешаемая задача, поскольку размер блока для инстанса может превысить размер подсчитаной страницы для статичной геометрии. Обычно это вылезает на картах-коробках, но теоретически может везде вылезти.
Второй момент - лайтмапа не скейлится в зависимости от размеров объекта, она всегда единичного размера. Это можно поправить введя индивидуальный скейл для координат лайтмапы, но я чот слабо себе представляю, можно ли эти координаты прямо вот так вот скейлить, как бы они просто не уехали нахрен. К тому же как спроецировать трёхмерный скейл на двухмерный тоже непонятно. Ну можно взять какое-то среднее число конечно.

Добавлено 19-12-2020 в 14:39:

А и да, самое мерзопакостное. Разбиение KD-tree на локальные суб-деревья роняет производительность трассы как минимум вдвое.
То есть я эти дерева сую в AABB-три и уже по нему передвигаюсь.
на первый взгляд это могло бы наоборот ускорить дело, но не всё так просто.
Мы должны проверить каждое такое локальное субдерево на предмет того, что трасса в него упёрлась. Мы не можем попасть в первое и остановиться. Да и если честно, это не сильно влияет на производительность.

К тому же результаты освещения для единой модели и для инстансов у меня отличаются. Не сильно, но кое-где вылезают косячки. У меня есть одна идея, как обратно эти инстансы налету построить в единое дерево, получится компромисс между потреблением памяти и скоростью работы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 20-12-2020 в 06:16:

Ну чтож, сработал мой хитрый план, построил единое дерево для всех инстансов, потребление памяти всё равно меньше, чем при старом подходе, поскольку вертексы не дублируются. Правда в фейс пришлось сохранить их позиции, чтобы не трансформировать при каждом обращении, без этого построение дерева по времени вырастало вдвое. Размер фейса был 64 байта + 36 байт на позиции = 100. Но изначально, неоптимизированный размер фейса в предидущей итерации был вообще 114 байт, так что можно сказать - да, действительно удалось сэкономить. Ну а размер вертексного буффера так и остался маленьким за счёт инстансов. У некоторых карт к примеру из-за дубликатов вес достигал 550 мегабайт, в оптимизированной версии 70-90 мегабайт. Т.е. как минимум здесь потребление упало в несколько раз. Из плюсов - удалось сохранить время постройки дерева на прежнем уровне, а время рассчёта освещения, помоему даже сократилось процентов на 15, но я хз почему, подозреваю, что там что-то неправильно считается. Ну это потом уже разберусь. Главное что оптимальный подход найден. Второй любопытный момент относится к скейлу лайтмапы в зависимости от скейла конечного меша. Если координаты были построены текстурных, то они естественно сохранены в .CSM-модельку и для таких кэшированных мешей скейл геометрии на карте не влияет на разрешение лайтмапы. Ни для дублирования, ни для инстансов. Так что можно сказать, в этом плане отличий не будет.

Скачал сорцы UE4 на предмет изучения. Там lightmass тоже юзает KD-tree. Видимо это самый оптимальный вариант, другие деревья заведомо медленее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 20-12-2020 в 16:35:

Опробывал переупаковщик атласов из UE4. Полное разочарование.
В документации зато как красиво. Вообщем первое что становится понятно из кода - эта штука не дружит с отраженными развертками. Она их видит, но сделать не может ничего. Объединяет обратно тоже из рук вон плохо, поскольку разъединение как раз и происходит на зеркальной развертке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 21-12-2020 в 06:28:

Ну нет худа без добра, из уешной реализации я вынес для себя две очень важных вещи. Во первых - механизм трансляции мирового скейла в текстурный, что нужно для придания правильной пропорции. На самом деле, где бы я еще нашёл эту формулу, подобные вещи не валяются на каждом углу. Сама формула довольно несложная, но я лично хрен бы догадался.

Оставлю здесь, может кому-то понадобится

C++ Source Code:

UVLength.x = length(  edgeUV2.y * edge1 - edgeUV1.y * edge2 );

UVLength.y = length( -edgeUV2.x * edge1 + edgeUV1.x * edge2 );

edge1, edge2 - это рёбра в трёхмерном пространстве, а edgeUV - в текстурном. UVLength - это worldScale. Потом еще надо поделить сумму worldScale на UvScale, которая сумма текстурного пространства.
Ну а второй момент - как правильно задетектировать отраженную развертку, причём идея настолько тривиальная, что я очень удивился почему мне эта мысль в голову не пришла. Мы просто умножаем signed UV area на аналогичную у соседнего треугольника и смотрим знак. Если обе негативные - будет положительный, если обе позитивные тоже. А если встретилась позитивная и негативная площади, ну значит здесь шов от зеркалки. Элементарно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 21-12-2020 в 14:15:

Цитата:

Дядя Миша писал:
Оставлю здесь, может кому-то понадобится

C++ Source Code:

UVLength.x = length(  edgeUV2.y * edge1 - edgeUV1.y * edge2 );

UVLength.y = length( -edgeUV2.x * edge1 + edgeUV1.x * edge2 );

Оптимизировали умножение матричек?

Отправлено Дядя Миша 22-12-2020 в 08:19:

Я почти управился с развертками, буду использовать комбинированный подход. В большинстве случаев это будет подготовленная развертка из текстурных координат как в UE. А для планарных поверхностей - трипланарная проекция. Надо только определиться какие треугольники лучше параметризовать через текстурные координаты, а какие через проекцию. Трипланарка сфейлить не может, но надо оценить оптимальность результатов, завязанную на множество параметров, на качество освещения, наличия швов и общий размер атласа.
К тому жы у меня на освещении лезут какие-то подозрительные белые точки в некоторых местах, главное раньше их не было вроде.
Когда с этим управлюсь, останется только прикрутить прогрессивные мешы и радиосити. Ну и полностью всё отладить и взапроверить.

Добавлено 22-12-2020 в 11:19:

Слева направо:
1. без рендеринга ребёр
2. ребра рендрятся, используя нормаль треугольника ( как в сталкере )
3. ребра пытаются получить сглаженную нормаль, а если нет, то используют нормаль треугольника

4. ребра используют только сглаженную нормаль, полученную через барицентрические координаты UV-лайтмапы
5. ребра используют только сглаженную нормаль, полученную через барицентрические координаты мировой позиции (в P2 аналогично)

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Chyvachok 22-12-2020 в 09:35:

На последних скриншотах балка на потолке лучше всего выглядит. Только вот шов посреди арки видно на всех скриншотах, на первом его меньше всего видно.

Отправлено Дядя Миша 22-12-2020 в 09:46:

Различия в освещении между полной геометрией (когда каждая моделька вставляется по месту) и инстансами (когда хранится один эталонный набор).

Как видите есть небольшая разница. Черт его знает почему так. Ну тени еще ладно, а вот то, что мелкие кусты немного по разному осветились, это я вообще хз. Я не могу это забороть. Наверное потеря точности при трансформации. Может быть этих различий не будет если увеличить разрешение лайтмапы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 23-12-2020 в 12:15:

Неудивительно отчего в халфе такое освещение всратое.
Оно там сначала клипается, а уже потом умножается на гамму.
Чёрт его знает как оно после этого выходит за границы Byte.
Главное и у меня в P2St точно так же. Я этот момент вообще не трогал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 23-12-2020 в 13:47:

Но на гамму нужно не умножать, а возводить в степень

Отправлено Дядя Миша 23-12-2020 в 17:50:

ncuxonaT ну я выразился немного некорректно. Я про последовательность действий.

Опробовал VTF для симуляции повертексного освещения. Ну как я и предполагал - всё сработало отлично. На ландшафте, понятное дело, всё превратилось в пятна, на ёлках-соснах в целом без особых изменений.
Но есть два момента. Во первых фпс упал почти на 1/8. Т.е. было 800 фпс, стало 700. Может быть это GT640 не слишком любит VTF.
Второй важный момент - повертексное тут не решит ничего, потому что для лайтмапы и для вертекса, во всяком случае на граничных точках, считаются те же самые позиции, те же самые нормали и та же самая окклюзия.
То есть повертексное само по себе тут разве что уберёт швы на лайтмапе, а больше от него толку не будет. А на деревьях нам надо рассчитать нормали по полусфере или взять какой-то зазор у источника света, ну халф-ламберт или что-то такое. Но с нормалями вообще тяжко. Они как правило невалидные все, мусор. Редко-редко когда попадется модель с исправными.
Я полагаю, чем генерить для листвы эти хитрые нормали, проще в материал дать подсказку. Ну то потом.

Добавлено 23-12-2020 в 19:15:

Набрался хабразде и решил повторить подвиг Элбера - собрать объединённую ЧАЭС из двух карт. Но, т.к. редакторами я не владею, решил пообъединять их в блокноте, посмотрел и понял, что это довольно-таки просто сделать. Пропсы на двух картах не пересекаются, а значит можно смело добавлять их в одну. Террайн взял тот, что поподробнее, проблема только в статик меше, то что есть в одном - отсутствует в другом.
Добавил сразу оба, а в компилятор ввёл проверку на дублирующуюся геометрию. Чтобы он мне просто повыкидывал лишние полигоны с этого же места. И это таки сработало! Собралась такая карта, весит 132 мегабайта.
Причём потребление компилятора во время работы не превысило даже 1 гигабайт, а ведь это пожалуй самая гигантская карта из всех, даже в лост-альфе нет такого ужоса. Всё прекрасно скомпилилось, правда свет я не считал еще.

Добавлено 23-12-2020 в 20:48:

Кстати, к вопросу о швах. Вот пример шва:

Кажется что всё ужасно. Но давайте включим диффузку.

А если посмотреть с другого ракурса, становится понятна и причина:

Там не просто шов, там еще и выступ. Конечно в идеале даже этого быть не должно, но уже вполне юзабельно.

Добавлено 23-12-2020 в 20:50:

Основная причина этих швов - неравномерность и сдвиги люксельной сетки.
Если мне удасться решить эту задачку, швов вообще не будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 24-12-2020 в 06:57:

Ну вот, если кому-то интересно, как выглядит повертексное через VTF

Добавлено 24-12-2020 в 09:57:

Способ хорош тем, что имея лайтмапу мы всегда сможем превратить её в повертексное освещение, например для маскировки швов на маленьких моделях. А вот наоборот уже хрена. Поэтому предпочтительнее считать и хранить лайтмапу вообще для всего, а повертексное не считать вовсе.
Тем более что, я вообще не планирую хранить значения освещённости в самих вертексах, я не представляю как это грамотно сделать для инстанс-моделей. В параное, как вы помните, при загрузке из оригинальной модели и массива повертексного освещения, налиту создавался дубликат, отчего потребление видеопамяти зашкаливало. Вероятно есть какие-то средства, чтобы объединять налету два массива. Скорее всего если массивы сгруппированы по атрибутам. Массив вертексов, массив текстурных координат, массив цветов. Вот в таком раскладе это работает. Но я не планирую так делать, это устаревший подход.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 24-12-2020 в 08:31:

Цитата:

Дядя Миша писал:
Неудивительно отчего в халфе такое освещение всратое.

И ты ещё говорил что там индирект ядовитый. Хотя я лично ни того ни другого не замечал.

Отправлено Дядя Миша 24-12-2020 в 14:39:

Подшаманил мержинг сурфейсов, теперь ЧАЭС собирается 20 минут вместо часа. Причём 16 минут - это построение атласа. Очень уж этот уголок тормозной даже удивительно. Надо бы с этим что-то сделать.
Но тут двояко. Любой модный прогрессивный алгоритм с эвристикой чую будет работать еще дольше, сталкеровское попиксельное построение атласа вообще дико медленное, вот и фиг знает что его делать.

Добавлено 24-12-2020 в 13:58:

Кстати у меня тут есть одна любопытная идейка насчёт Кармаковского алгоритма, надо будет проверить.

Добавлено 24-12-2020 в 14:00:

Цитата:

Crystallize писал:
И ты ещё говорил что там индирект ядовитый. Хотя я лично ни того ни другого не замечал.

дело еще и в том, что менять местами клиппинг и гамму нельзя, тогда у теней появляется белая окантовка.

Добавлено 24-12-2020 в 15:52:

Запустил ради интереса свет на объединённой ЧАЭС (это походу будет устоявшийся термин, ну навроде как объединённая Каста), думал он весь день считать будет, однако за час управился. Ну теперь чаэс настоящая, а не то что там Элбер клеил вручную, 4 миллиона полигонов! Только травы нехватает для полного щастья, ну это потом уже.

Тут еще вот какое дело. Во первых одна лайтмапа под террейн 2048х2048 явно недостаточна. Тут размер карты 60 х 90 килоюнитов. Но это предел для самого иксрея, он не генерит лайтмапы большего разрешения. Не потому что не может, скорее сознательное ограничение для совсем древних карточек. Сталкер-то по современным меркам способен на лютом хламе запускаться.
Второй важный момент - если лайтгруппа не влезает в атлас, я её рескейлю вниз, а икс-рей делит на две части. Это принципиальная разница в подходе. Так что кое-где у меня тень может размыться внезапно. Может потом переделаю. Для меня сейчас самое главное - это стресс-тесты. Компилятор должен сожрать все карты из лост-альфы и уложиться в 32-х битные лимиты по потреблению памяти. Пока ему это очень хорошо удаётся, к примеру создание карты отняло всего-навсего 700 мегабайт, а лайтмаппер зохавал 1.5 гигабайта, а ведь это одна из самых гигантских карт.

Добавлено 24-12-2020 в 17:39:

Ну чтож. MU-модели успешно внедрены и помогли здорово уменьшить финальный размер карты, да и вроде как рассчеты света немного ускорили.
Опять же моя реализация позволяет запекать на таких моделях лайтмапу, а в сталкере - только повертексное. Самое смешное, что мне лайтмапу было на них запечь даже проще, чтобы держать всё в юниформе.

Следующий этап - автоматические прогрессивные мешы. Возьму из сталкера тоже реализацию, а там она, как я понял от Tom Forsyth.
Собственно, чем прогрессивные мешы отличаются от обычных лодов?
Лоды требуют собственные вертексы, для них нужна собственная развертка, для них поидее требуется новая развертка лайтмапы, это тихий ужос.
Прогрессив-мешы наоборот, коллапсят исходный меш таким образом, чтобы всегда используя уже имеющиеся вертексы образовывать новые валидные треугольники, то есть в таком вот меше поменяется только набор индексов, а вертекс-дата останется неизменной. И в этом громадный плюс такого подхода. К тому же их можно и нужно использовать и для персонажей тоже.
Единственное с чем я пока не определился - нужны ли импосторы. С одной стороны, если у тебя ТЛез32 это единственный способ удержать производительность, с другой, они не в юниформе, то есть были мешы-мешы и вдруг - вот такая хрень. В самом сталкере, как я понял их чуть ли не вручную расставляют в местах нахождения деревьев и прочих пропсов. Плюс им нужна эта текстура - вид с восьми углов. Плюс с высоты они понятно как будут выглядеть (по этой же причине, к слову в дууме и прыгать не дают игроку). Так что пока введу прогрессивные мешы и будем дальше думать. Скажу, к примеру, что ЧАЭС с угла максимального обзора, когда в кадре все четыре миллиона полигонов на GT640 у меня выдаёт 49 фпс. Так что в целом не всё так уж и плохо даже совсем без лодов. Но с ними должно стать совсем хорошо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 24-12-2020 в 14:40:

Цитата:

Дядя Миша писал:
дело еще и в том, что менять местами клиппинг и гамму нельзя, тогда у теней появляется белая окантовка.

Это интересный способ найти люксели которые лежат на границе теней.

Можно как-то использовать для их сглаживания.

Отправлено Дядя Миша 24-12-2020 в 14:41:

Crystallize ты про edge-detection совсем ничего не слышал?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 24-12-2020 в 16:14:

Цитата:

Дядя Миша писал:

дело еще и в том, что менять местами клиппинг и гамму нельзя, тогда у теней появляется белая окантовка.

Но почему? Как это работает?

Какое суммарное разрешение лайтмапы получилось?

Отправлено Дядя Миша 24-12-2020 в 18:09:

Цитата:

ncuxonaT писал:
Но почему? Как это работает?

Я сам вот удивился, но у меня и без того хлопот полон кот, некогда разбираться, потом.

Цитата:

ncuxonaT писал:
Какое суммарное разрешение лайтмапы получилось?

на чаэс? да фиг его знает. 40 страниц 1024х1024 + ландшафт 2048х2048.
На болотах из чистого неба, получилось 82 страницы, но там пропсов аж 5 тысяч, а на чаэс - всего 500. И болота 2.5 часа считались.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KorteZZ 25-12-2020 в 11:34:

А чего это скрины такие мелкие? Даешь FHD!

__________________

Killing Floor: Horzine Outbreak

Отправлено Дядя Миша 25-12-2020 в 14:18:

Внедрил прогрессив-мешы. Спорная штука. Во первых она почти не поддаётся контролю. На параметры реагирует слабо. Во вторых, она сама решает насколько меш может быть симплифицирован, вот на одних прямо втрое получается, а на других - дай бог чтобы на 20%.
Не угадаешь. От топологии вероятно зависит. В некоторых случаях вообще полный фейл, т.е. работа проделана, а симплификации - нет.
Но результат в целом очень деликатный. Одно скользящее окно удаляет из исходного меша 1 вертекс, поэтому заметить деградацию с расстоянием игроку невозможно в принципе, как бы он не присматривался. Другое дело, что в среднем такие лоды снижают поликаунт ну максимум на треть, даже не вдвое. Ну я еще потыкаю, может сделаю алгоритм более агрессивным.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 26-12-2020 в 10:34:

Кстати, вот какая еще мысль мне пришла в голову. Для MU-моделей можно использовать ковариантную проекцию лайтмапы, она пытается из облака точек вычленить уникальную нормаль проекции, даже если объект замкнут сам на себя. Т.е. сфейлить она не может никогда. Но такая проекция обычно бывает очень растянута. Но для MU-моделей, которые в большинстве своём ёлки-метёлки, это даже лучше, т.к. будет чем-то напоминать повертексное освещение, только с большим разрешением. Ну и естественно - никаких швов. Впрочем. наверное там лучше завести переключатели всякие в материале.

Добавлено 26-12-2020 в 13:34:

Опробовал. Ну да, ковариантная проекция на MU-моделях выглядит очень растянуто, освещение перезатекает аж назад на дерево, но зато нету швов.
И очень-очень похоже на повертексное.
Я думаю надо сделать вот как. По дефолту - пусть остается ковариантная.
А если юзер прямо создал крутую текстурную развертку, из которой не стыдно строить лайтмапу, то можно переключиться на нее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 26-12-2020 в 13:35:

Цитата:

Дядя Миша писал:
если юзер прямо создал крутую текстурную развертку

Крутую это какую?

Отправлено Дядя Миша 26-12-2020 в 19:52:

nemyax без самопересечений, без дегенеративных UV-островков.

Добавлено 26-12-2020 в 19:34:

ну чтож, финальный штрих - радиосити.
В данном случае надо просто наспавнить вторичных аналитических источников света от поинтлайтов. Ну можно и от лайтспотов тоже.
А потом эти лайты будут участвовать в общем процессе освещения.
Т.е. свет посчитается сразу как прямой, так и отражённый, не надо будет ничего там вымучивать в несколько проходов.

Добавлено 26-12-2020 в 21:26:

Кстати, насчёт завершения истории с прогрессив-мешами.
У меня тут, собственно, было два варианта. Bunnylod от Stan Melax, ну вы его все видели. И jmspmesh от Jeff Somers. второй - это вьювер с четырьмя самыми известными методами - QEM, QEM weighted by area, реализация от Stan Melax и shortest path (не знаю кто автор).
QEM и QEM weighted by area представлены так же библиотекой qSlim.

Пока я совал этому вьюверу модельки, идущие с ним в комплекте - всё было хорошо. Даже отлично. Но как только я переконвертил сталкеровские модельки и начал совать их - тут же начался тихий ужос. Оно вообще не в состоянии их адекватно обработать. Так что SWPM от Tom Forsyth, которую юзает сталкер - наименьшее зло. Да, оно симлифицирует до определённого порога. Но модель хотя бы не превращается в кашу на произвольном уровне симплификации.

Добавлено 26-12-2020 в 22:40:

Кстати. Shortest Edge, это нечто навроде метода от Stan Melax, только еще проще - без учёта курватуры. Как говорится, уже тупее некуда - выкидывается самое короткое ребро. Там вообще математики нет, если не считать VectorLength. Я этот метод опробывал тоже, слегка доработав реализации BunnyLod. И знаете - мне понравилось. И даже очень.

Добавлено 26-12-2020 в 22:52:

Минималка, 30% от исходного меша. Если ниже, то там уже полная дигродацыя начинается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 27-12-2020 в 12:57:

Цитата:

Дядя Миша писал:
ну чтож, финальный штрих - радиосити.
В данном случае надо просто наспавнить вторичных аналитических источников света от поинтлайтов. Ну можно и от лайтспотов тоже.
А потом эти лайты будут участвовать в общем процессе освещения.
Т.е. свет посчитается сразу как прямой, так и отражённый, не надо будет ничего там вымучивать в несколько проходов.

Напоминает тысячи солнц на небосводе в TyrUtils. Может это можно всё-таки как-то параметрически реализовать? Я просто боюсь что будут видны пятна от отдельных лайтов.

Отправлено Дядя Миша 27-12-2020 в 15:53:

Цитата:

Crystallize писал:
Напоминает тысячи солнц на небосводе в TyrUtils.

оно и в ку3 так.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 28-12-2020 в 12:56:

Ну вот, сляпал на скорую руку некоторое подобие радиосити.
Пусть пока хоть такое будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-12-2020 в 07:53:

Честно говоря, толку от этих лодов примерно никакого, увы. Максимум, на который они способны без видимой деградации, это примерно половина от оригинального поликаунта, но часть секторов вообще нет смысла упрощать, они и так довольно простые, хотя их и много. То есть складывается идиотская ситуация, допустим взгляд с крайней точки карты, в кадре 4.5 миллиона треугольников. Включаем лоды, поликаунт падает до 3.6 миллионов. Ну и что? Фпс подымается максимум на 1-2. Он же экспоненциально падает. Импосторы могли бы поправить дело, но пока не хочется с ними связываться.

Добавлено 29-12-2020 в 10:53:

И вообще, я по прежнему придерживаюсь мнения, что основная нагрузка идёт на фрагментный шейдер, т.е. если его подменить, ну скажем заливкой одним цветом, то фпс сразу вырастет прилично. Надо будет чистый тест устроить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 29-12-2020 в 10:00:

Цитата:

Дядя Миша писал:
Фпс подымается максимум на 1-2.

Кстати, спрошу, раз уж тема лодов затронута. Насколько мне известно, относительно современные видеокарты (не старше 10 лет) отлично справляются с большим количеством полигонов в кадре. Упор идёт в возможность загрузки в память жЫрных текстур неоправданно высокого разрешения. Ну и всякие вычисления для красивостей. Насколько это справедливо в случаях для каких-то конкретных движков? И почему, например, относительно гладкий и лысый Control имеет системные требования выше, чем высокополигональный и рельефный UT3 и его производные?

Отправлено Дядя Миша 29-12-2020 в 12:04:

Я про Control вообще впервые слышу. Но повторюсь, щас основная нагрузка идёт на фрагментный шейдер и это мало чем можно оптимизировать на самом деле. Только упрощать вычисления.

Если бы прогрессивные лоды снижали поликаунт прогрессивно, от них бы действительно был толк. Но чудес не бывает. Нельзя из модели в 10000 полигонов сделать модель в 300 полигонов, чтобы она при этом не превратилась в полное дерьмо. То есть можно, конечно, но ручками.
А это значит, что под эти модели будет идти свой набор вертексов, значит под лоды придётся заново перерасчитывать лайтмапу, плюс даже при таком подходе, вовсе не факт, что они прямо здорово выровняют фпс. Наилучший подход, мне представляется, это хитрый программный растеризатор для окклюжена, но эта штука сама по себе может быть довольно тормозной на самом-то деле. Тут конечно двояко. Отрендерить один канал глубины в текстуру 320х200 - это мегабыстро. Рендерить можно прямо через рейтрейсинг, чтобы не заморачиваться матрицами проекции. Проблема в том, что перекрытие будет посчитано при таком подходе очень и очень приблизительно. И будут нужны еще доп. условия, чтобы не отсечь лишнего. А это значит, что часть работы была проделана впустую. И вот где-то есть оптимальная точка балансировки, когда от всего этого механизма есть польза, причём не факт, что это константа.

Добавлено 29-12-2020 в 15:04:

Давайте напишу немного про очевидные трудности, связанные с внедрением лайтстилей и о том, почему их (трудностей) не было в старых кваках.

Итак. Лайтмапу можно хранить двумя способами:
1. одномерный массив точек, и отсылки к каждому геометрическому примитиву, обычно простой поверхности.
2. предрассчитанный 2D атлас, отсылка через UV-координаты.

Первый способ позволяет строить лайтмапу какой угодно размерности, контролируя сколько лайтстилей получит каждый сурфейс (от четырёх, до нуля), второй, очевидно этого не позволяет. Как минимум потому, что построение атласа вообще не учитывает сколько там будет лампочек и какой вклад они внесут в освещение. Частично этому мешает тот факт, что атлас строится задолго до рассчёта освещения, но главным образом - что в атласе освещение считается не для отдельно взятого полигона, а для целой их группы. Причём объединение в сурфейсов в группу для наложения на нее единого куска лайтмапы имеет вполне конкретный смысл - отсутствие швов. Есть и второе соображение - сейчас вся геометрия в треугольниках. Если для каждого треугольника выделять свой кусок лайтмапы, получим двойной перерасход люкселей. Впрочем, если кто-то полагает, что этот способ всё же имеет право на жизнь - во второй параное именно этот подход и реализован. Каждый треугольничек освещается отдельно, занимает отдельный кусочек лайтмапы и освещение радует дикой грязью, где уже невозможно отличить шов от ошибки взятия нормали по фонгу. Корректных способов это разрулить попросту не существует. Только объединять в группу. В кваке, где всё было параллельно и попендикулярно, а сурфейсы квадратными, это не имело никакого значения, вообщем-то И то, как вы помните китаец приложил немало усилий, чтобы сгладить эти чёртовы швы между смежными поверхностями. Но если вы думаете, что его алгоритм - панацея, то спешу вас разочаровать. Я конвертил некоторые модели в брашы и пытался их компилить в p2st. Террайны, колонны (не витые, просто круглые). Результат был еще хуже, чем работал просто мой лайтмаппер по треугольникам. Там вообще дикий ужос. Китайский сглаживатель хорошо себя чувствует только с аксиальными рёбрами, судя по всему. Но даже если каким-то чудом допустить, что мы эти лайтмапы просчитали для каждой квад-пары (которой может вообще не быть в большинстве случаев) и получили такие симпатичные одномерные лайтмапы, прилинкованные к сейфейсам, это всего лишь означает, что эти сурфейсов получилось несколько сотен тысяч на более-менее приличной карте. Если рисовать их так - фпс умрёт, просто по факту перебора поверхностей, даже не отрисовки. Если их мержить при загрузке налету, неизвестно сколько это займет времени. Причём, как вы понимаете, чем больше карта, тем больше времени. Сделать это после рассчёта света тоже нельзя - тогда свет второй раз уже не посчитаешь.
Но даже, повторюсь, если на всё это наплевать и всё таки сделать именно так, то есть пример второй паранои перед глазами. Там есть лайтмапы на моделях и там есть лайтстили. Качество освещения вы видели. А если нет, то всегда можете заценить. Сорцы открыты, можете брать и пытаться это дело улучшить. Навряд ли это вообще возможно. К тому же, повторюсь, при таком подходе почти всегда дикий перерасход лайтмапы получается.
Я бы мог и другие причины назвать, но и этих достаточно. Особо подчеркну, что по отдельности они не кажутся какими-то фатальными, но когда всё это собирается вместе и сталкивается с практикой, начинается тихий ужос. Но конечно, если у кого-то есть достаточно свободного времени, он вполне может доказать, что и это подход имеет право на жизнь. Второй вариант - атласы предрассчитаны заранее. Мы не можем выделять здесь какие-то группы. Но зато мы можем выделять слои-каналы.
Ведь у нас в текстуре целых четыре канала RGBA. Можно отвести каждый канал под монохромный цвет. Таким образом убивается сразу джва зайца.
И лайтстили как бы сохранены и в то же время размер лайтмапы не вырос.
Но с цветным освещением придётся уже попрощаться. Нечто подобное используется в UE4 насколько я знаю. Но что делать, если цветное освещение хочется? Можно попробовать использовать технику, которую Humus назвал Modern Lightmapping. Когда в каналы сохраняется только тень, а свет считается динамически. Частично этот подход использовался и в сталкере, для смены времени суток, например. Минус в том, что всё равно придется заводить лайтмапу под индирект-освещение, если оно у нас есть. Правда и тут есть варианты - использовать индирект только для солнца, а обычным лайтам его не давать. В конце-концов в ку3 индиректа не было и ничего, не фатально. Причём по большому счёту его не было даже в q3map2 - по дефолту он выключен. Вы можете попробовать его включить, но тогда рассчёт света из 2 минут превратиться в пару часов или около того. Поэтому его всё равно никто не юзал.
Варианты с сохранением различной информации в лайтмапу, я естественно опробую, плюс тут еще и в том, что на одной и той же странице, но в разных участках могут быть сохранены совершенно разные лайтстили. Наконец можно цвет лампочки передавать в шейдер, а в канале держать только карту интенсивности. Такой подход тоже вполне себе имеет право на жизнь.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-12-2020 в 20:19:

Сделал лайтмаппер прогрессивным. Как только страница посчитана, она тут же сохраняется на диск. Т.е. даже если лайтмаппер вылетел с нехваткой памяти, то всё равно часть света посчиталась и будет доступна.
Теоретически можно будет еще замутить досчёт, если допустим страницы по дате новее чем карта, ну то потом как-нибудь.

Добавлено 29-12-2020 в 21:20:

И еще раз оптимизировал потребление памяти. Лес из Лост Альфы не тянет даже на ТЭЛез16, там всего-навсего 22 тысячи деревьев. Но в целом довольно солидно смотрится. Я там даже заблудился однажды.
Но даже для освещения всех этих ёлок-метёлок надо около 2 гигабайт памяти. Можно попробовать сделать GPU-лайтмаппер, благо его архитектура идеально для этого подходит, но пока не знаю.
В будущем году можно будет попробовать.

Добавлено 29-12-2020 в 21:25:

Я себе к слову довольно смутно представляю, как работает GPU-солвер.
Тому шо, если у нас к примеру индирект от солнца - ну скажем 200 источников, это чтож, надо 200 шадов-мап нагенерить? А потом разом их применить? Нет, ну можно конечно итеративно, я видел, они в основном именно так и работают, но этот комбинаторный взрыв ИМХО сводит на нет все преимущества от использования GPU.

ncuxonaT напомни как ты действуешь. И сколько видеопамяти это потребляет.

Добавлено 29-12-2020 в 21:27:

Продолжая рассуждать - я бы мог к примеру KD-Tree засунуть в текстуру и тогда бы на GPU вместо шадовмап так бы всё считал в сингл-проходе, красотищща, но беда в том, что на больших картах Kd-tree само по себе строится до 15 минут.

Добавлено 29-12-2020 в 23:18:

Внимание на поликаунт. Вот это лоды в идеальном случае. Было 8 миллионов, стало пять. ну и что? Фпс не поменялся. Для GTX650 одинаково тяжело.

Добавлено 29-12-2020 в 23:19:

А экспоненциально снижать поликаунт не в состоянии ни одна лод-система.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 30-12-2020 в 04:09:

Дядя Миша под индиректом от солнца подразумевается свет от неба? Ну да, много шадовмап. Так старый лайтбейкер работал, только от неба шадовмап было не 200, а 1000 по умолчанию. А для какого-нибудь арканоса, где через маленькие окошки освещается большая карта, шадовмап нужно было не меньше 10000. И да, рендерилось оно итеративно с накоплением.
Но шадовмапы дают лики и акне, поэтому новый лайтбейкер перешел на рейтресинг. Он медленнее, но надежнее.

Сколько оно занимает места, давай посчитаем.
На каждый треугольник 3 вершины, вершины лежат в двух RGBA32F текстурах в виде (pos.x, pos.y, pos.z, uv.x) (norm.x, norm.y, norm.z, uv.y). Итого 32 байта на вершину и 96 байтов на треугольник.
В дереве 2N - 1 узлов, каждый узел это ббокс (RGB32F x2) и ссылки на двух детей (RGBA16 x6). X6, потому что сейчас я использую метод Хачисуки (https://cs.uwaterloo.ca/~thachisu/) с 6 деревьями. Значит, на узел 72 байта.

В сумме на треугольник 240 байт.

Если стоит задача экономии памяти, то можно выкинуть 5 деревьев, использовать индексы, а нормали хранить в RGB16. И, если допустить, что количество вершин в среднем равно количеству треугольников, то выйдет порядка 70 байтов не треугольник.

Добавлено 30-12-2020 в 07:09:

Ты деревья по-одному рисуешь? Инстансинг нельзя использовать?

Отправлено Дядя Миша 30-12-2020 в 07:28:

Цитата:

ncuxonaT писал:
только от неба шадовмап было не 200, а 1000 по умолчанию

погоди-погоди-погоди, 1000 шадовмап и каждая 4096х4096?
Так никакой видеопамяти нехватит. Тысяча это много, ста штук достаточно.

Цитата:

ncuxonaT писал:
В сумме на треугольник 240 байт.

У меня сейчас face_t занимает 96 байт. На этой карте с лесом общая память под уникальные фейсы - 800 мегабайт. А у тебя значит займёт больше двух гигабайт видеопамяти. Здесь звучит музыка из ералаша. Пара-пара-пам.

Цитата:

ncuxonaT писал:
Ты деревья по-одному рисуешь? Инстансинг нельзя использовать?

деревья и так в инстансе. Т.е. моделька дерева одна, а рисуется с разными матрицами скейла и ориентации. В OpenGL нет настоящего инстансинга, только фейки. Ну то есть если я средствами драйвера сделаю то, что они называют инстансингом, это всё равно будет на CPU, только на стороне драйвера.

Добавлено 30-12-2020 в 10:28:

Строго говоря, если уж GPU-лайтмаппер перешёл на использование рейтрейсинга, какой тогда смысл пытаться имитировать растеризацию?
Надо делать на CUDA, разве нет?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 30-12-2020 в 14:45:

Цитата:

Дядя Миша писал:

погоди-погоди-погоди, 1000 шадовмап и каждая 4096х4096?
Так никакой видеопамяти нехватит. Тысяча это много, ста штук достаточно.

Говорю же, рендерится итеративно, то есть по одной шадовмапе за раз. Отрендерил шадовмапу, посчитал с ней освещение, отрендерил другую, посчитал с ней освещение, добавил к предыдущему и так далее. Ста штук недостаточно, будет видно 100 теней от какого-нибудь столба или дерева.

Цитата:

Дядя Миша писал:
У меня сейчас face_t занимает 96 байт. На этой карте с лесом общая память под уникальные фейсы - 800 мегабайт. А у тебя значит займёт больше двух гигабайт видеопамяти. Здесь звучит музыка из ералаша. Пара-пара-пам.

96 байт на фейс, а дерево сколько еще будет занимать? Я могу ужаться до 70 байтов на треугольник с учетом дерева. Ну это в лучшем случае, конечно.

Цитата:

Дядя Миша писал:
В OpenGL нет настоящего инстансинга, только фейки.

https://learnopengl.com/Advanced-OpenGL/Instancing вот это не настоящий инстансинг? Они там 100к астероидов рисуют.

Цитата:

Дядя Миша писал:

Строго говоря, если уж GPU-лайтмаппер перешёл на использование рейтрейсинга, какой тогда смысл пытаться имитировать растеризацию?
Надо делать на CUDA, разве нет?

КУДА это вендор лок, а у нас тут кроссплатформа. Да и по тесту Хачисуки рейтрейсер на GLSL сопоставим по производительности с вариантом на КУДЕ.
Почему имитация растеризации? Лучи не летят параллельно на манер шадовмапы, от каждого текселя лучи летят рандомно.

Отправлено Дядя Миша 30-12-2020 в 19:46:

Цитата:

ncuxonaT писал:
а дерево сколько еще будет занимать?

дерево у меня максимум было 150 мегабайт.

Цитата:

ncuxonaT писал:
Они там 100к астероидов рисуют.

ну ты покликай режимы, там довольно занятно.

Цитата:

ncuxonaT писал:
Почему имитация растеризации?

я говорю, раз уже всё равно рейтрейсер используем.

Цитата:

ncuxonaT писал:
будет видно 100 теней от какого-нибудь столба или дерева.

А ты с какой яркостью рендеришь?

Добавлено 30-12-2020 в 22:46:

Гм. продолжение обсчёта лайтмап пришлось прикрутить экстренно, после того как лайтмаппер внезапно вылетел с нехваткой памяти. Я конечно не знаю, почему он вылетел, но вариантов там немного. Один, если быть точным. Благо прогрессивный механизм сохранения лайтмап - это уже половина дела. Добавил пару условий и всё заработало.
Надо еще будет анализатор сделать, чтобы понять чего хочет юзер - полный новый обсчёт или досчёт.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 30-12-2020 в 21:03:

Цитата:

Дядя Миша писал:
ну ты покликай режимы, там довольно занятно.

А как ~~какать~~ кликать? Не вижу там готового демо. Ты из исходников собирал?

Что ты подразумеваешь под имитацией растеризации?

Цитата:

Дядя Миша писал:
А ты с какой яркостью рендеришь?

Пусть будет с яркостью 1. Я не понимаю, при чем здесь яркость. Давай посмотрим, сколько нужно шагов/шадовмап, чтобы свет на арканосе сошелся до чего-то более-менее приемлемого:

Отправлено Дядя Миша 31-12-2020 в 10:20:

Цитата:

ncuxonaT писал:
А как какать кликать? Не вижу там готового демо. Ты из исходников собирал?

Странно. Я видел какую-то готовую демку инстансинга с астероидами.

Цитата:

ncuxonaT писал:
Что ты подразумеваешь под имитацией растеризации?

ну то что видеокарта работает в режиме рендеринга.

Цитата:

ncuxonaT писал:
Я не понимаю, при чем здесь яркость.

Один главный источник направления + лайты по полусфере. Ну это для солнца.

Добавлено 31-12-2020 в 13:20:

Сделал разбиение лайтмапы для больших поверхностей типа террейна на куски, при условии, что какой-то кусок превышает максимальный размер страницы (1024 х 1024 пикселя). В сталкере, напомню, макс размер атласа для террейна 2048х2048. Для той же ЧЭАС это адски мало, там тени размытые их толком не видно. Впрочем такое разбиение провоцирует швы, но поскольку раньше это была одна целая лайтгруппа, то они малозаметны на самом деле. Причина появления этих швов тривиальна - люксели сдвигаются относительно друг друга при конвертации в локальное пространство страницы лайтмапы. Но победить это не так-то просто.
Кстати, вот в самом сталкере координаты лайтмапы хранятся в fixed point.
Я вот и думаю, может быть это как поможет отцентровать люксели.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 02-01-2021 в 11:59:

Добил полное сохранение стейта лайтмаппера и сделал его умным.
Теперь он сам определяет, что от него хотят - продолжить освещение с текущей страницы или заново всё переосветить. KD-три тоже сохранил, очень уж долго оно рассчитывается на некоторых картах.
Но вообще я вот что заметил - то что считает мой лайтмаппер обычно не считает никто. Я уже молчу про то, что на той же лост-альфе большинство объектов отправлено на повертексное освещение. Но там и скейл подкручен. И естественно MU-модели имеют только повертексное. В результате, там где у меня 150 страниц 1024х1024, в лостальфе - всего-навсего шесть. Конечно это не значит, что надо непременно идти таким долгим путём. Но в рамках тестирования предельной нагрузки на компиляторы - это вполне себе ок. Уж если он такое выдерживает, то и ваши эксперименты тоже выдержит. А я не думаю, что у кого-то хватит терпения делать такие гигантские карты, как в лост-альфе.
Еще бы метрошные карты проверить, но я чёт так и не нашёл конвертора.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 13-01-2021 в 09:45:

Ну штож, пора бы уже сделать колоизацию для триангловых моделей.
Без колоизации можно только летать ноклипом или бродить по скайбоксу.
Какие варианты тут есть?

Ну например, можно подключить физикс. Правда его в некоторых местах неудобно сопрягать с игровым кодом. Аналогично с Ньютоном.
С физ.движками вообще расклад такой - придётся выбросить оригинальную трассу. С одной стороны - не могу сказать, чтобы я был особенно против, но меня пугает один момент, с которым обычно сталкиваешься, пытаясь использовать сторонние библиотеки - на определённом наборе данных это начинает или дико тормозить или глючить или вообще вылетает. Вы вероятно не в курсе, но в ксаш-моде есть парочка хаков на этот счёт. Я уже не помню, то ли новодекс, то ли уже физикс вылетали при попытке запечь геометрию одной из халфовских карт. А сорцев на тот момент и не было.
Но вылет-то ладно, если есть сорцы, поправимо. А если тупить начнёт?

Сперва, как и говорил уже когда-то, попробую нагенерить брашей из каждого полигончика, предварительно их симплифицировав. Метод тупой, не особо оптимальный, но можно будет построить им дополнительное дерево. У такого подхода есть один плюс - пересечение AABB, с таким вот брашем из треугольника, считать в десятки раз быстрее, нежели честную коллизию Tri vs AABB. Но за это придётся заплатить увеличенным кол-вом данных. Там у нас, строго говоря, пусть даже неиндексированный треугольник - это три вертекса, 36 байт.
Если из него генерить браш - это минимум шесть сторон, если нам повизёт и он окажется лежать на одной из аксиальных осей. Шесть сторон - это шесть плоскостей. Одна плоскость - 16 байт. 96 минимально. Но. Нам еще нужны бевелы. Без них толку не будет. А вот бевелов может быть довольно-таки много. До 30 штук, в среднем - те же шесть. Правда есть один лайфхак. Если треугольник неаксиальный, нам вовсе необязательно непременно добивать его полноценного браша - достаточно одних бевелов. Так что в теории их может быть не шесть, а меньше. К тому же, учитывая, что мы имеем дело именно с брашами, нам вовсе необязательно превращать в них треугольники. Можно сперва бъеднить все треугольники в конвексные фигуры, по максимуму. Сколько бы их там ни было - это всё равно будет одна плоскость. Так что в некоторых случаях выигрыш просто очевиден. Для ландшафта, например. Другой конечно вопрос - насколько всё это будет оптимально. Ну вот и проверим.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 13-01-2021 в 16:05:

Так, брашевые извращения, походу отпадают. Оно работает и коллизия гладкая, но занимает чертовски много места, просто охренеть сколько.
Вес плоскостей может в 2-3 раза превышать вес видимой геометрии.
Конечно для коллизии геометрию можно и нужно симплифицировать, но всё равно это не выход. Для кордона эти плоскости уже весят сопоставимо со всем остальным. И это только для террайна и статик-моделей.
Причём скомпилить карту, при использовании полноценных брашей (не односторонних) я уже не могу - памяти не хватает. А если бы хватило, вес бы увеличился еще на столько же. Это просто нерационально.
Смысл любой оптимизации, в том и заключается, что и без нее всё хорошо, а с ней - вообще отлично. Но надеяться на симплификацию, как на разрешение проблемы нельзя. Это её просто слегка отодвинет в сторону.
Только время тратить. Ну хорошо, посмотрим какие у нас есть варианты в трассировке треугольников при помощи ббокса.
Вообще надо заметить, что проверка bbox vs triangle очень тяжёлая. Особенно class III test.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 13-01-2021 в 17:25:

Почему ббокс?

Отправлено Дядя Миша 13-01-2021 в 18:19:

ncuxonaT ну а как игрока представить? Капсулой? Это пока не существенно. Вот кстати, хотел бы с вами посоветоваться насчёт одной коллизии. Описание компиляторных энтить в скриптах - это почти полноценный исполняемый язык, хоть и с некоторыми оговорками.
И в этом языке возникла небольшая коллизия, сейчас поясню на примере.

C++ Source Code:

1	"env_static"

3	addCompileFlags( C_DETAIL );

4	includeModel( "model" );

6	if( spawnflags & 1 )

7	forceClipModel();

8	if( spawnflags & 2 )

9	dropToFloor();

11	transformModel( "self" );

12	movePrimitives( "classname", "worldspawn" );

14	removeEntity();

Это описание компиляторной энтити env_static. Надеюсь тут и человеку далёкому от программирования понятно, как это устроено и как работает.
Это именно выполняемый код, который исполняется так же как и любой другой. Но здесь есть ошибка, привязанная к некоторым особенностям языка. Совершенно неочевидная, к слову, поскольку присуща именно моему язык. Сейчас поясню.
Дело в том что условия

C++ Source Code:

if( spawnflags & 1 )

  if( spawnflags & 2 )

будут выполняться не так, как того ожидает пользователь (это касается именно битовых операций, но теоретически возможны и другие коллизии). Почему так происходит?
Всё дело в том, что в этом языке нет средств, позволяющих указать явным образом с каким типом данных мы имеем дело. Интерпретатор скрипта пытается догадаться об этом самостоятельно, следуя нехитрой логике, а именно: каждая константная строка сперва интерпретируется как имя ключа в текущей энтите. Если таковая действительно будет найдена, то на её место будет подставлено значение для этого ключа. Это вполне логично и соответствует ожиданиям пользователя. Далее, если окажется что, значение цифровое, оно будет переведено в цифры. А если нет - то для него будет посчитан хэш, для последующего сравнения строк. Теперь представим ситуацию, что в описании энтити этого поля нет вообще.
Строка spawnflags будет естественно распознана, именно как строка, для нее посчитается хэш (CRC32 если быть точным) и... битовая операция произойдет применительно к этому хэшу. Следовательно результат проверки окажется вообще бессмысленным. Потому что повторюсь, язык не различает, где просто константная строка, а где значение из настроек энтити. Нет такого средства в языке. Правильный вариант условия выглядит следующим образом

C++ Source Code:

1	if( spawnflags )

3	if( spawnflags & 1 )

4	forceClipModel();

5	if( spawnflags & 2 )

6	dropToFloor();

Здесь мы уже проверяем что такое поле вообще существует. Причём в данном случае компилятор уже не трактует строчку как константную, он уверен, что это именно ключ в настройках энтити. С другой стороны - я не могу сделать подобного исключения для битовых операций, потому что регистры грузятся вообще без оглядки на сами команды.
Но можно придумать какой-нибудь модификатор подсказку, чтобы скрипт точно знал, что это ключ, а не константное слово. Но с другой стороны - это может испохабить синтаксис. Вы бы как поступили на моём месте?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 13-01-2021 в 18:35:

Цитата:

Дядя Миша писал:
Вы бы как поступили на моём месте?

Странная идея с хэшами, ну ладно.
Я бы поступил так:
1) Если поле отсутствует - то оно "", цифровое значение для битовых операций 0.
2) Если поле есть - преобразуем в число. Если число не является целым, или вообще не число - тогда считаем что оно 0. Можно ещё варнинг кинуть.

__________________

Отправлено nemyax 13-01-2021 в 18:38:

Цитата:

Дядя Миша писал:
Строка spawnflags будет естественно распознана, именно как строка

Но там нет строки "spawnflags". Или у тебя любой незнакомый токен в блоке интерпретируется как поле?

Отправлено Дядя Миша 13-01-2021 в 19:04:

Цитата:

XaeroX писал:
Странная идея с хэшами, ну ладно.

Там CRC32 checksum, про хэш это я так. Буков меньше писать.

Цитата:

nemyax писал:
Но там нет строки "spawnflags"

ну это же всё-таки скрипт. Толерантность. Здесь нельзя объявлять какие-то локальные переменные, и нет никаких типов. Любая строка так или иначе приводится к чексумме, любое число передаётся неизменным.

Вот пример условия

C++ Source Code:

if( targetname == t1 )

Оба операнда можно взять в кавычки, это ни на что не повлияет.
Для обоих выполняется одна и та же раписанная выше операция - сперва каждая строка интерпретируется как ключ. Для targetname это удаётся, и тогда она подменяется содержимым ключа. Для t1 это не удается и она остается первоначальной строкой. Дальше обе строки превращаются в чексуммы (виртуальная машинка работает только с целыми числами). И дальше над двумя регистрами выполняется запрошенная операция, в данном случае сравнение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-01-2021 в 19:07:

Мне было бы комфортнее самому объявить то, что я хочу считать полем. Например так:

C++ Source Code:

field spawnflags;

field model;

field targetname;

Или так:

C++ Source Code:

field spawnflags, model, targetname;

Отправлено Дядя Миша 13-01-2021 в 21:39:

Так я же об этом и толкую. Объявлять ничего нельзя. Здесь нет переменных, только обращение. И данные бывают двух типов - либо это содержимое ключа, либо константа. Над ними нельзя производить операции кроме как сравнения или сохранять куда-то полученные результаты. Хотя модифицировать имена ключей и их содержимое - можно. Но - только такими же константами. Или на худой конец - содержимым соседних ключей в пределах одной энтити.

Добавлено 14-01-2021 в 00:39:

Ну да ладно, вернёмся к колоизации. Вообще я думаю, дело даже не только и не столько в методах, сколько в выборе дерева. Здесь по идее мне нужно аксиальное нерегулярное BSP. Которое будет искать оптимальный сплиттер по двум критериям - минимальному размеру ноды и максимальному кол-ву полигонов, которые лежат на ноде. Т.е. отбалансировать это дерево именно для коллизии. Стоковое кутришное дерево для этих задач абсолютно негодится. Возможно я его тоже потом отбалансирую, но это не так критично. Смысл в том, что дерево ничего не должно разрезать, в этом плане уподобляясь AABB-tree, но при этом быть иррегулярным. AABB это как правило регулярная сетка, где каждый узел содержит ровно один полигон (хотя это и необязательно конечно). Из-за чего такое дерево может быть просто гигантских размеров. Ну нам это очевидно не надо.
А подход с несколькими деревьями неплохо себя зарекомендовал еще со времён первой кваки. Для видимости одно дерево, для коллизии другое.
Надо только придумать как потуже сжать клипсурфейсы, у них будет раздельный набор данных - точки и рёбра. Причём рёбра в некотором смысле будут выполнять роль индексов для точек, поскольку каждое ребро содержит индексы двух точек. Ну собсно, как и в халфе.
Так же у каждого ребра есть нормаль, но я думаю хранить их в карте слишком расточительно, лучше заново рассчитать при загрузке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 14-01-2021 в 12:19:

С этой коллизией, немаловажная задача стоит, определиться какую именно геометрию мы будем использовать. С одной стороны - нам непременно нужна видимая, для точечной трассы, которая способна трассировать тексели, например для пропуска пуль сквозь решётки, ну и не только.
С другой стороны, нам нужна упрощённая геометрия для тестирования примитивов. И вот здесь конечно затык у меня. Хранить оба вида геометрии в карте? Строить точную геометрию при загрузке, а упрощённую считать при компиляции? Оба типа геометрии рассчитать при компиляции?
Всё это так или иначе угрожает переизбытком данных. Конечно не столь масштабным, как если бы вознамерился сконвертить каждый треугольник в браш, но всё равно.
Для начала я решил всё же опробывать аксиальное дерево из третьего дуума. Хорошая штука, но о том, чтобы строить его при загрузке, речи конечно не идёт, на картах типа кордона это может занять десятки минут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 14-01-2021 в 12:39:

Цитата:

Дядя Миша писал:
Хранить оба вида геометрии в карте? Строить точную геометрию при загрузке, а упрощённую считать при компиляции? Оба типа геометрии рассчитать при компиляции?

А если пошарить куски, которые годятся туда и сюда?

Отправлено Дядя Миша 14-01-2021 в 16:33:

Совсем пашарить не получится, потому что видимая геометрия натурально хранится в RAW-контейнере, куда доступ только по шаблонам. Для коллизии обращаться с такой датой дико неудобно, поэтому для нее создается локальная копия. Ну она не сильно много места занимает.
А вот с симплифицированной версией визуальной геометрии, тут уже посложнее, её придется хранить в явном виде. Но меня больше занимает вопрос, насколько эта геометрия вообще актуальна.

Добавлено 14-01-2021 в 19:33:

Построил я дерево и даже его визуализировал на всякий случай. Долго строится зараза и полигоны к узлам как-то странновато примыкают. Наверное налажал где-то. У этого дерева есть существенный плюс - его очень легко хранить на диске. Потому что нам посути надо сохранить только axial type (если -1 это лиф), дистанцию до плоскости и два указателя на детей. 16 байт на ноду максимум. Лифов вообще нет, как легко догадаться.
А при загрузке просто отфильтровать геометрию в это дерево, это легко и просто делается, там даже ничего резать не надо. То есть в такое дерево можно профильтровать вообще любую геометрию, ну там брашы, полигоны, наконец полигоны из симплифицированой версии. А в карте таскать только само дерево. В этом несомненный плюс конечно.
Но я его еще не тестил на производительность. Хотя с виду - ну дерево как дерево, наверняка быстрее классического в силу аксиальности. И как я понимаю, обладает некоторыми достоинства R-Tree, KD-Tree и BVH вместе взятых. Впрочем BSP это самый общий случай, поэтому оно и способно приобретать черты узкоспециализированных деревьев и в его построении допускаются абсолютно любые приёмы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 15-01-2021 в 09:02:

Собственно почему придётся завести два дерева. Потому что для двух задач - коллизии и рендеринга нужны совершенно противоположные требования.
То что идёт на отрисовку сгруппировано большими кусками, там дерево нужно достаточно редкое, отдельные узлы могут быть даже размером 1024х1024. Для физики напротив - скопление мелких полигонов в одном месте провоцируют появление дополнительных узлов там. Это противоречие никак не разрешить в одном дереве. Да вообщем-то и не нужно. К слову сказать, те кто делал OverDose этот момент вообще не поняли. Неудивительно что он такой тормозной получился.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 15-01-2021 в 13:46:

Цитата:

Дядя Миша писал:
Собственно почему придётся завести два дерева.

На севере диком стоит одиноко
На голой вершине сосна,
И дремлет, качаясь, и снегом сыпучим
Одета, как ризой, она.

И снится ей все, что в пустыне далекой,
В том крае, где солнца восход,
Одна и грустна на утесе горючем
Прекрасная пальма растёт.

Отправлено Дядя Миша 15-01-2021 в 19:05:

Ввёл в компилятор понятие уровень оптимизации.
Там довольно много такого, что могло бы помочь, но каждый раз ждать пока оно сработает, брр. А для финального компила можно и потерпеть.
В основном влияет на уменьшение размера карты и на увеличение фпс.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 16-01-2021 в 16:19:

Всё забываю устроить опрос. У меня есть очень древний вьювер моделек, совмещённый с дециматором. Но главное его преимущество в том, что там аж четыре наиболее известных метода симплификации встроено и можно пощёлкать и оценить качество работы того или иного алгоритма.
В комплекте, разумеется, идёт набор рафинированных моделек, на которых всё гладко. Я недолго думая, при помощи Noesis переконвертил пару моделек из сталкера, в частности, вот камаз и сунул этому вьюверу.
И оставил от первоначального поликаунта примерно 20% (было 9697 трианглов, стало 2288). И сделал пять картинок. Оригинал, чтобы была референсная точка. И четыре различных метода симплификации. И вот мне любопытно, какой из четырёх методов вам покажется наиболее качественным. Оставить 20% от первоначального меша, это довольно непростая задача, если бы я убрал скажем половину полигонов, скорее всего разница была бы малозаметна. Программка называется jmspmesh, если кому-то интересно. Поехали:

Это оригинал:

Quadric Error Metrics (QEM) weighted by triangle area

Quadric Error Metrics unweighted

Original Algorithm by Stan Melax (Стэн Мелакс, это дядька такой известный)

Shortest Edge (не знаю кто автор, но принцип работы можно уместить в одно предложение: выбрасывается самое короткое ребро)

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Cybermax 16-01-2021 в 16:35:

В Shortest Edge наиболее угадывается камазюка, разве что немного покрышки побиты.
На втором месте Quadric Error Metrics unweighted, кроме покоцанных колес угадывается оригинал.
Quadric Error Metrics (QEM) weighted by triangle area
- такое себе, лонжероны пропали.
Original Algorithm by Stan Melax - ужас.

Отправлено Chyvachok 16-01-2021 в 17:37:

Судя по скриншотам автоматическая генерация лодов еще долго не заменит ручную работу модельщика.

Вообще мне кажется что в принципе вряд ли возможен алгоритм который мог бы нормально уменьшать полигонаж, т.к. надо понимать геометрию модели, и упрощать ее сохраняя ее форму.

Добавлено 16-01-2021 в 19:37:

Если выбирать из перечисленных то однозначно Shortest Edge, у него модель меньше всего убита. Stan Melax однозначно самое дно, модель полностью анигилирована.

Отправлено Дядя Миша 16-01-2021 в 17:38:

Цитата:

Chyvachok писал:
Судя по скриншотам автоматическая генерация лодов еще долго не заменит ручную работу модельщика.

скорее всего - никогда. Потому что сейчас делают наоборот. Берут заранее симплифицированную модельку и добавляют к ней детали при помощи тесселяции. А тесселяция, это не просто увеличение полигонов. Она ориентируется на хейтмапу, снятую с оригинальной хай-поли модели.
Крупные детали так конечно не сделать, но вся мелочь в играх именно так и проступает. Игрок далеко - тесселяция на минимум. Правда у нее есть существенный минус, она не ускоряет работу, как лоды, а наоборот замедляет её.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 16-01-2021 в 18:07:

Цитата:

Дядя Миша писал:
Потому что сейчас делают наоборот.

В одном Метре увидел и экстраполируешь.
А скинь модель, я посмотрю, как 3дмаксовский упрощатель упростит.

Отправлено Дядя Миша 16-01-2021 в 22:13:

Цитата:

ncuxonaT писал:
В одном Метре увидел и экстраполируешь.

Есть вполне официальная тенденция. Зря что ли тесселяцию внедрили.
Вообще-то первые демки были уже в 2009-м году.

Добавлено 17-01-2021 в 01:13:

Цитата:

ncuxonaT писал:
как 3дмаксовский упрощатель упростит.

все дециматоры худо-бедно дают неплохие результаты до 50%.
Проблемы начинаются где-то от 30%. И там уже фирменные косяки алгоритма лезут наружу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 17-01-2021 в 09:49:

Цитата:

Дядя Миша писал:

Есть вполне официальная тенденция. Зря что ли тесселяцию внедрили.
Вообще-то первые демки были уже в 2009-м году.

Официальная тенденция среди украинских разработчиков разве что. Не очень-то много современных игор вспоминается с тесселяцией. Даже если посмотреть статьи "что такое тесселяция" за последние пять лет, то там в примерах будут сталкер, метро и крузис 2.

Цитата:

Дядя Миша писал:

все дециматоры худо-бедно дают неплохие результаты до 50%.
Проблемы начинаются где-то от 30%. И там уже фирменные косяки алгоритма лезут наружу.

3дмакс сработал не очень, а блендер родил вот такое. Модель кривая, она на части разбита, где не надо. Например, покрышки разбиты на 4 отдельных куска. Если предварительно объединить совпадающие вершины, то не будет дыр хотя бы (левый камаз)

Отправлено Дядя Миша 17-01-2021 в 12:36:

Цитата:

ncuxonaT писал:
Модель кривая, она на части разбита, где не надо

так ведь приходится иметь дело с какими угодно моделями.
Кому нужен движок, который работает только с идеальными, сферическими.

Добавлено 17-01-2021 в 15:29:

Нам в идеале даже из самой похабной модели неплохо бы получить что-то не совсем ужасное. Ну а если моделлёр постарается, так вообще отлично будет.

Добавлено 17-01-2021 в 15:36:

В Максе наверняка QEM,а он чувствителен к топологии очень сильно.

Добавлено 17-01-2021 в 15:36:

Цитата:

ncuxonaT писал:
Официальная тенденция среди украинских разработчиков разве что

ты что-то имеешь против украинских разработчиков?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 17-01-2021 в 13:39:

Цитата:

ncuxonaT писал:
блендер родил вот такое

У блендера три упрощатора.

Добавлено 17-01-2021 в 16:39:

Цитата:

Дядя Миша писал:
все дециматоры худо-бедно дают неплохие результаты до 50%.

Я б сказал, что ниже этого порога тебе уже нужен не дециматор, а реконструктор. Неко кои дециматор ты не обучишь тому, что камаз должен в итоге выродиться в нечто вроде этого:

Отправлено Дядя Миша 17-01-2021 в 13:49:

Цитата:

nemyax писал:
Я б сказал, что ниже этого порога тебе уже нужен не дециматор, а реконструктор

Дай-ко угадаю, он сперва бьёт модель на группу конвексных хуллов а потом считает разницу между реальностью и финальной точкой?

Цитата:

nemyax писал:
камаз должен в итоге выродиться в нечто вроде этого:

финальная стадия это импостор

Добавлено 17-01-2021 в 16:49:

Вообще, не забывайте, что у лодов, сконструированных автоматически, есть одно серъезное преимущество - они обсалютно не затрагивают исходную геометрию, меняют только индексы. Такой подход здорово экономит видеопамять. Причём если бы там были настоящие лоды, для них пришлось бы и лайтмапу считать, а для прогрессивных мешей лайтмапа сама "адаптируется". Хотя декали могут действительно утопать внутри модели на низших уровнях лодов. Кстати может в сталкере наблюдать этот эффект, чиркнуть ножом по дереву и отойти. Зарубка исчезнет. Я долгое время думал, что это какой-то глюк и только недавно до меня дошло что это такое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 19-01-2021 в 11:00:

Цитата:

Дядя Миша писал:
ты что-то имеешь против украинских разработчиков?

Только то, что они не создают тенденций.

Цитата:

nemyax писал:
У блендера три упрощатора.

Ты про три режима Decimate, или там еще что-то есть? Я показал то, что выдает Collapse. Unsubdivide, очевидно, не подходит, а Planar не дает выставить в процентах, сколько должно выйти треугольников.

Цитата:

Дядя Миша писал:
Причём если бы там были настоящие лоды, для них пришлось бы и лайтмапу считать

Необязательно, если делать у лодов развертку под лайтмапу более-менее совпадающей. И запекать можно было бы на лодах, а не на хайполи.
В любом случае, использовать для коллизий генерированную автоматом мешанину из треугольников вряд ли стоит.

Отправлено Дядя Миша 19-01-2021 в 11:45:

Цитата:

ncuxonaT писал:
Только то, что они не создают тенденций.

А кто создаёт? Крайтек?

Цитата:

ncuxonaT писал:
Необязательно, если делать у лодов развертку под лайтмапу более-менее совпадающей

Это неконтролируемый процесс. Для старших лодов наверное еще возможно, а вот для предельного варианта - очень навряд ли.
В любом случае придётся предусмотреть отдельные развертки для каждого лода, на случай, если что-то пойдет не так.

Цитата:

ncuxonaT писал:
В любом случае, использовать для коллизий генерированную автоматом мешанину из треугольников вряд ли стоит.

Сталкер именно такую мешанину и использует. Просто дециматору заданы особые параметры и дополнительные штрафы на несмежных рёбрах.
Но есть важное отличие - мы имеем дело с геометрией у которой нет материалов и все точки шареные. И дециматору работать на порядок легче. Вы же обратили внимание, что все демки симплификации намеренно не используют текстурирование. Ну вот в том числе и поэтому.

Добавлено 19-01-2021 в 14:45:

Совсем забыл. Есть такой хитрый режим децимации, я не вникал как это работает, но он упрощает модель не в процентном соотношении, заданном юзером, а до тех пор, пока не начнётся определённая деградация.
Причём степень этой деградации вычислятся индивидуально для каждой модели. Где-то можно и впятеро симплифицировать, а где-то всего на 30%.

В сталкере SWPM именно так и работает, он сам выбирает до каких пределов модель поддаётся упрощение. Из-за чего увидеть деградацию модели в принципе невозможно. Что в свою очередь привело к мнению, будто бы в сталкере нет никаких лодов. Причём это порой утверждают даже люди, которые делали под XRay уровни.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 22-01-2021 в 11:00:

Имплементировал колоизацию из дуум3, в целом неплохо, мне нравится.
Но есть конечно и досадные моменты. Во первых, больше всего места в заняли сурфэджы - индексы ребёр. На лост-альфовском кордоне почти 17 мегабайт. И ведь ничего не сделаешь. Сами рёбра и вертексы весят достаточно скромно, дерево я ужал, плюс это всё происходит на оригинальной геометрии где порядка миллион двести тысяч полигонов (не треугольников, а именно полигонов). Думаю, если геометрию симплифицировать, будет не так жутко. К тому же у аксиального BSP есть один важный плюс - сурфейсы в него можно фильтровать на лету, это очень быстро, а значит не надо их хранить в карте. К тому же фильтровать их можно, читая контентсы из материала, если к примеру несолидный, то вообще не помещать в дерево. Ну то есть, для того чтобы поменять контентсы, вовсе необязательно перекомпиливать карту.
Минус в проверке на пересечение модель\полигон. Т.е. движение модели сквозь полигон работает отлично, а вот тест на застревание внутри полигона - не очень. Это не баг кода, это такой подход. Помните выражение "застрял в текстурах"? Вот это как раз оно. Т.е. проверка на пересечение делается в самом начале, когда плоскости модели и плоскость полигона рядом. Но чистой проверки на всю модель - не выполняется.
Иными словами полигоны односторонне проходимы, т.е. сзади сквозь него можно пройти, но назад он уже не пропустит.
Такой подход не позволяет конечно некоторые вещи, которые раньше решались легко и просто, ну например - проверка на вставание игрока внутри узкого тоннеля скорее всего сфейлит. Это не значит что подобные вещи нереализуемые теперь, логика немного поменяется. Но я вот думаю что классический тест на застревание тоже нужен. Потому что трассировочную модель можно представить в виде конвексного браша.

Добавлено 22-01-2021 в 14:00:

К слову, весь этот механизм колоизации предполагает любопытный выверт геометрии. Вся геометрия вывернута наизнанку, но плоскости смотрят правильно. При этом и модель для трассировки тоже вывернута, но уже в другую сторону, т.е. полигоны смотрят внутрь, а плоскости наружу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 23-01-2021 в 14:54:

Вообщем главная претензия к колоизации - это её размер.
Хрен его знает что с этим делать. Всего по чуть-чуть, а в сумме много.
Примерно половина от визуальной части. Ну скажем, если визуальная геометрия весит 100, то колоизация - 50. Многовато.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 23-01-2021 в 15:13:

А сколько ты хотел?

Отправлено Дядя Миша 23-01-2021 в 16:10:

Мегабайт 30 к примеру.
Кстати, ЧАЭС с коллизией собралась и коллизия там весит удивительно немного. Было 175 стало 214.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 26-01-2021 в 09:15:

Кстати, вот такой вопрос к сообществу.
Как сейчас делают внутриигровые редакторы движков?
Там все элементы GUI кастомные или на стандартных виндовых контролах?
Ну или скажем блендер или 3дМакс? Я просто смотрю на некоторые скриншоты и понимаю, что виндой там и не пахло.

В принципе если делать кастомные контролы, которые рисуются через GL, то будет настоящая кроссплатформенность, правда я не гарантирую что все шрифты будут чёткие на любом разрешении, со шрифтами конечно придётся повозиться тогда.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Camblu_Buildovich 26-01-2021 в 09:27:

Цитата:

ncuxonaT писал:
Модель кривая, она на части разбита, где не надо

Точно не надо?

Я не знаю, откуда ДМ выдирал модель, но оригинальный камаз из зп (а туда он перешел из тч) при компиляции уровня будет разбит по материалам.
В аттаче скрин, как мы видим, есть 3 материала с одной текстурой, но разные шейдеры и тип материала. Например, кабина камаза имеет материал metal_plate, чтоб звучало как железо.

__________________

Цитата:

MR wild Alex писал:
Многоувожаймый XaeroX , очень интересно почиму вы со своими друзьями не можите создать движок для HL на основе всех предыдущих проэктов (Xash,SoHL,HLFX) это ведь для
вашей команды не так сложно.

КСМ это форум украинских нацистов и в администрации нет адекватов.

Отправлено nemyax 26-01-2021 в 09:30:

Цитата:

Дядя Миша писал:
скажем блендер или 3дМакс?

Могу сказать за блендер — у него самописный оконный менеджер со своими контролами и системой ивентов. Про макс врать не буду, но похоже на допиленные контролы винапи. Кроссплатформы в нём никакой нету. В майе и гудини, насколько знаю, по нынешним временам Qt.

Отправлено ncuxonaT 26-01-2021 в 11:06:

Camblu_Buildovich этим можно объяснить разбиение покрышки на части?

Вроде бы и УЕ, и юнити, и даже годот используют собственный GUI. А по поводу шрифтов - фотошоп, например, использует собственные контролы, но текст на них рисует средствами системы.

Отправлено Camblu_Buildovich 26-01-2021 в 11:23:

Цитата:

ncuxonaT писал:
этим можно объяснить разбиение покрышки на части?

Тогда извиняюсь, ждем коментарии ДМ.

__________________

Цитата:

КСМ это форум украинских нацистов и в администрации нет адекватов.

Отправлено Дядя Миша 26-01-2021 в 12:28:

Цитата:

Camblu_Buildovich писала:
Я не знаю, откуда ДМ выдирал модель

Из Сталкера.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Camblu_Buildovich 26-01-2021 в 16:38:

Из уровня, из огф-версии, где-то нарыл исходный .object

__________________

Цитата:

КСМ это форум украинских нацистов и в администрации нет адекватов.

Отправлено Дядя Миша 26-01-2021 в 17:17:

Мне проще написать декомпилятор уровней, чем искать оригинальные модели.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 01-02-2021 в 15:14:

Добавил механизм анимации текстур, разделённый по группам.
Изначально анимация базировалась на единственной группе, но это не позволяло, скажем, иммитировать кушные\халфовские кнопки.
Теперь 32 группы по 32 кадра. Каждая группа может иметь как автоматическую анимацию, так и контроль за кадрами с сервера.

Описание кушной кнопки ( два кадра мигает в отжатом состоянии, один светится в нажатом), в простейшем случае выглядит, ну например так:

C++ Source Code:

1	"+0runered"

3	image u_ColorMap = "globals->$WhiteTexture";

5	// pev->frame == 0

6	addUnitFrame( u_ColorMap, "textures/<wadname>/+0runered", 0, 0 );

7	addUnitFrame( u_ColorMap, "textures/<wadname>/+1runered", 1, 0 );

8	setUnitFramerate( u_ColorMap, 10.0f, 0 );

10	// pev->frame == 1

11	addUnitFrame( u_ColorMap, "textures/<wadname>/+Arunered", 0, 1 );

12	setUnitFramerate( u_ColorMap, 10.0f, 1 );

Я их не заворачивал ни в какие макросы, сразу напрямую прописал. Предпоследний аргумент - порядковый номер кадра, последний - номер группы. Аналогичным образом на моделях будет реализована и смена скинов. И что особенно важно - скины тоже смогут быть анимированные, если это понадобится. Для остальных текстурных юнитов точно так же можно сменять нормалмапу, глосску и луму, если это вдруг понадобится, но повторюсь, это уже какой шейдер напишут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 01-02-2021 в 16:03:

анимации дискретные что ли

Отправлено Дядя Миша 01-02-2021 в 16:55:

На одном юните сидят, так что без лерпинга, если ты конечно это имел в виду.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ncuxonaT 01-02-2021 в 17:04:

Можно в 3д текстуру засунуть и анимировать сдвигом по z координате. Я так анимированные спрайты делал.

Отправлено Дядя Миша 01-02-2021 в 17:08:

Вообще лерпинг легко замутить даже имеющимися средствами.
Надо просто объявить два текстурных юнита и сдвинуть в них один и тот же набор кадров на один шаг.
Но это для скайбоксов разве что. Обычно оно не нужно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 06-02-2021 в 08:08:

Да с коллизей конечно очень непросто. Слишком много взаимоисключающих параметров. С одной стороны - инстанс-модели нельзя хранить с локальными деревьями. Потому что tree of trees это такой тормоз перестройки, что его даже рассматривать не хочется. Ну естественно, всё упирается в стек.
Может пока там две-три, пять моделей это незаметно. Но когда их несколько тысяч - не вариант вообще. Значит надо колоизацию для каждой копии из локального пространства разворачивать в общую кучу треугольников. Это естественно влечёт за собой резкий рост конечного BSP-файла. Эджи и сурфэджи при таком раскладе хранить в карте вообще не вариант - и те и другие весят, ну например для Кордона, суммарно столько же, сколько весят сами вертексы и индексы. Т.е. грубо говоря, вертексы 18 мегабайт (только точки, позиции в пространстве), 20 мегабайт - описание самих сурфейсов, ну и эджы с сурфэджами - еще 60.
Но для индексированной геометрии, рёбра весьма легко восстановить при загрузке. это занимает совсем немного времени, если использовать хэш.
Пару секунд примерно. Собсно, я так и делаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 06-02-2021 в 13:09:

Визуализировал колоизацию. Цвета рандомные. Но кстати берутся из халфовской палитры

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 08-02-2021 в 18:25:

Не могу сказать, чтобы компилятор уровней был готов прямо на 100%, но я над форматом уровней работаю уже год и у меня попросту замылился глаз.
К тому же есть и другие важные задачи. Собственно, задач еще две:
1. разработка формата моделей с общим банком анимаций. Это не должно занять много времени, благо основные части механизма уже разработаны.
В частности форматы хранения вертексов-индексов, контейнеры для моделей и прочее. Думаю за месяц управлюсь.
2. Собственно, то, что делает движок пригодным для использования продуктом - самостоятельный редактор для всего. Движок без редактора точно никому не нужен, в этом я уже убедился. Джек не годится - он не сможет отрисовать ЧАЭС из Сталкера, не заточен он под такое.
К слову сказать, я подсознательно предполагаю что отсутствие собственного редактора во многом ограничивало полёт моей мысли в некоторых аспектах.
Надеюсь преодолеть это противоречие.
Промежуточный билд будет доступен когда я разработаю новый формат моделей.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено xrcore_cpu 12-02-2021 в 12:23:

Дядя Миша 3д пакет за редактор сойдет?)

Отправлено Дядя Миша 12-02-2021 в 12:49:

Я не планирую делать привязку к конкретному типу редактора.
Будет свой собственный редактор, в котором можно будет сделать большинство операций, исключая полноценное моделирование и анимацию, но подвигать вертексы-треугольники будет можно, а так же редактировать развертки. Можно будет написать какой-нибудь плагин к блендеру и наконец кубать в Джеке, если планируется по старинке использовать браши по большей части. Любая привязка к собственному редактору обычно только отталкивает пользователей.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено xrcore_cpu 13-02-2021 в 06:51:

Дядя Миша, я скорее имел ввиду плагин на какой-нибудь 3д редактор, с экспортом всего уровня для последующей компиляции.

Отправлено Дядя Миша 13-02-2021 в 08:07:

Ну да, я это и имел в виду. Геометрия и точечные объекты.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Cybermax 13-02-2021 в 09:19:

А в GtkRadiant можно будет?

Отправлено Дядя Миша 13-02-2021 в 10:44:

Почему нет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 13-02-2021 в 15:34:

https://hlfx.ru/forum/showthread.php?s=&threadid=5620

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 20-04-2022 в 15:46:

Открыл тему обратно. Буду тут по прежнему бухтеть бесплатно и без смс

Добавлено 20-04-2022 в 18:46:

Сразу же дам ответы на вопросы, которые должно быть интересуют общественность.

1. Блог на Boosty - всё. Вестись более не будет. Дико неудобная площадка как по своей природе, так и для моего формата.
2. Телеграм-канал. Будет вестись, но к сожалению на данный момент идёт работа над низкоуровневыми вещами, которые подписчикам там попросту не будут интересны. Как только начнётся работа над вещами, понятными юзерам, он будет активно вестись. В этом году.
3. В этой теме продолжится классический формат ведения блога в стиле "заметки на полях". С вашими вопросами и предложениями, и моими ответами. Полагаю этот формат наиболее всех устраивает.
4. Доступ к бета-тестированию по прежнему платный, цены не поменялись.
5. В данный момент идёт разработка виртуальной машины и универсального редактора. Редактор будет использовать виртуальную машину для создания оформления. Таким образом ядро будет единым, а внешний вид - на усмотрение пользователя. Собсно, я об этом уже писал.
6. Как только будет что показать вы это сразу узнаете, по активности в телеграм-канале.
7. Какой-то прототип редактора (не уровней, а вообще всего), будет готов уже в этом году, по крайней мере я на это надеюсь.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 20-04-2022 в 16:58:

Дядя Миша
Расскажи по форматам ресурсов.
Можно ли будет драг дропом закинуть модельку и чтобы движок сразу собрал её под нужный формат?
Тоже самое с текстурами?
Будут ли генерироваться дефолтные материалы при импорте модели?
Будет ли движок пытаться запарсить параметры этих материалов? Хотя бы дефолтный PBR.
Будет ли возможность в материале подключить свой шейдер, и указать глубину его отрисовки?
Будут ли модели наконец поддерживать морфинг?
Можно ли объектам назначать вместо параметров, скрипты которые будут задавать правила этим объектам? И можно ли в реальном времени их включать/выключать? А так же перемещать в иерархию друг друга?
Будет возможность загрузить пустую сцену без бсп и накидать на ней объекты?

Отправлено Дядя Миша 20-04-2022 в 20:29:

Цитата:

FiEctro писал:
Расскажи по форматам ресурсов.

Что конкретно рассказать?

Цитата:

FiEctro писал:
Можно ли будет драг дропом закинуть модельку и чтобы движок сразу собрал её под нужный формат?

Я не понимаю, что значит "собрать под нужный формат". Это среда для разработки, а не конвертор одних типов ресурсов в другие.
Хотя у меня конечно была мысль такое сделать, но по здравом размышлении я решил остановиться только на импорте. Т.е. на входе - ресурсы любых форматов, а на выходе - понятные XashNT. Различные форматы ресурсов будут поддерживаться при помощи двух слагаемых:
1. системы плагинов для импорта, которые будут читать различные типы ресурсов.
2. абстрактный формат ресурсов самого XashNT, который позволяет сконвертировать в него, практически любые существующие форматы, ну может кроме Nanite-меша. Если формат чего-то не умеет - это туда добавляется, никак не влияя на совместимость.

Цитата:

FiEctro писал:
Тоже самое с текстурами?

А что с текстурами? Каких-то хитрых форматов в XashNT нет, только самые распространённые. bmp, jpeg, tga, dds.

Цитата:

FiEctro писал:
Будут ли генерироваться дефолтные материалы при импорте модели?

Моя система материалов позволяет генерировать не дефолтные материалы, а полностью воспроизводить рендеринг из того движка, откуда модель была скопирована. По крайней мере, если речь идёт о достаточно старых движках, до первого срузиса, включительно.
В теории можно будет из унреалов-юнитей тоже всё это иметь, сам механизм позволяет, но я пока что не тестировал.

Цитата:

FiEctro писал:
Будет ли движок пытаться запарсить параметры этих материалов? Хотя бы дефолтный PBR

В подавлюящем большинстве движков используются убогие системы материалов, настройки к которым можно описать совсем небольшим набором параметров, а генератор этого набора, соответственно, встроить прямо в плагин импорта. Я внимательно изучал возможности систем материалов разных движков, по сравнению с тем что может XashNT, там никто даже и близко не подобрался. Спустя 15 лет, всё так же занимаются пробросом юниформов из скрипта в видеодрайвер.

Цитата:

FiEctro писал:
Будет ли возможность в материале подключить свой шейдер, и указать глубину его отрисовки?

Некорректный вопрос. Система материалов XashNT вообще не предусматривает никаких встроенных материалов и шейдеров. Только пользовательские. Фактически рендерер создаётся в скриптовых файлах с нуля под любую задачу. Соответственно меняется уровень графики, в зависимости от использованных шейдеров. Можно получить картинку уровня Doom\Quake, можно картинку уровня HL2, уровня Stalker\Crysis или Unreal4. Я над этой концепцией шесть лет думал.

Цитата:

FiEctro писал:
Будут ли модели наконец поддерживать морфинг?

Что имеется в виду под морфингом? Если лицевая анимация, то на данный момент её нет, но формат позволяет её добавить в любой момент, не нарушая совместимость. Если же имеются в виду модели с вертексной анимацией (без костей), то этого на данный момент тоже нет, но такой формат будет. И тоже без нарушения совместимости.

Цитата:

FiEctro писал:
Можно ли объектам назначать вместо параметров, скрипты которые будут задавать правила этим объектам? И можно ли в реальном времени их включать/выключать? А так же перемещать в иерархию друг друга?

ECS - это недо-реляционная система, которая жрёт память и набивает карманы ловким мошенникам. Я принял решение остановится на скриптовом языке, который визуально очень похож на С++ и классических объектах-энтитях, как в кваках и халфах. Благодаря тому, что их описание хранится в виртуальной машине, дизайнер избавляется от необходимости думать за массу низкоуровневых вещей, с которыми он неизбежно сталкивался в том же HL_SDK или SourceSDK. В последний даже я лезть не рискую, это тихий ужос. Т.е. набросать прототип объекта на С++-подобном языке даже через копипасту, будет легко и приятно.
Так что изначально ориентируйтесь именно на эту концепцию. Она самая удобная.

Цитата:

FiEctro писал:
Будет возможность загрузить пустую сцену без бсп и накидать на ней объекты?

На данный момент совсем без брашей обойтись не удасться - нужен как минимум брашевый скайбокс. Это не является каким-то ограничением формата движка, в дальнейшем я добавлю возможность делать этот скайбокс обычными полигонами, т.е. можно будет строить карты без единого браша. Но сам скайбокс обязательно нужен, по двум причинам:
1. На него проецируется небо. XashNT не умеет рисовать небо в пустоте, только проецировать на реальные полигоны.
2. От небесных полигонов излучается солнечный свет для лайтмаппера. Если нет небесных полигонов, то и света от солнца тоже не будет.
Наконец в незамкнутой карте не будет работать VIS, хотя это и не повлияет на производительность, если мы имеем дело с огромными открытыми пространствами.

Добавлено 20-04-2022 в 23:15:

Перечитаю-ка я всю тему сначала. Вспомню что планировал, что сделал, от чего отказался и к чему пришёл в итоге.

Добавлено 20-04-2022 в 23:29:

А вот, кстати: https://hlfx.ru/forum/showthread.ph...3960#post183960

Та фундаментальная проблема более чем успешно разрешена, но теперь на очереди другие. Уже не такие фундаментальные, но всё же.
К тому же я принял решение полностью отказаться от пользовательских библиотек и остановиться на виртуальной машине.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 21-04-2022 в 03:40:

Дядя Миша Сколько символов в минуту читаешь?

Отправлено (_-=ZhekA=-_) 21-04-2022 в 05:21:

Дядя Миша
А какой скриптовой язык будет?
Насколько сложно будет сделать визуальное програмирование типа, как в уе4 - блюпринты?

Отправлено Дядя Миша 21-04-2022 в 05:53:

Цитата:

(_-=ZhekA=-_) писал:
А какой скриптовой язык будет?

По синтаксису максимально близкий к С++. Но без низкоуровневых заморочек, которые подстерегают пользователя при работе с реальным кодом.

Цитата:

(_-=ZhekA=-_) писал:
Насколько сложно будет сделать визуальное програмирование типа, как в уе4 - блюпринты?

Я не смотрю в эту сторону. В какой-то степени объекты, расставленные на карте и связанные между собой стрелочками имен и целей - это тоже визуальное программирование. Вот в этом направлении можно попробовать его развивать. Еще Laurie в спирите думал в этом направлении, т.е. основы закладывались именно тогда.
Не удивлюсь, что концепцию блу-принтов предложил именно человек, который в начале нулевых что-то делал под спирит на халфе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-04-2022 в 05:57:

>> Что конкретно рассказать?

Вообще с какими форматами файлов работает движок.

>> 1. системы плагинов для импорта, которые будут читать различные типы ресурсов.

Что подразумевается под плагинами для импорта? Это обычные компиляторы? Я к тому нужно ли писать какие то плагины экспорта для 3д пакетов? Как в случае с .smd ГС и Сорса? Либо же твой конвертер будет питаться обычными моделями типа .obj, .fbx, .blend и т.п.? Насколько это всё сложно в настройках?

>> Т.е. на входе - ресурсы любых форматов, а на выходе - понятные XashNT.

Под нужным форматом это я и имел ввиду. Стоковый формат движка.

>> А что с текстурами? Каких-то хитрых форматов в XashNT нет, только самые распространённые. bmp, jpeg, tga, dds.

О, это уже неплохо. Добавь ещё PNG

>> Моя система материалов позволяет генерировать не дефолтные материалы, а полностью воспроизводить рендеринг из того движка, откуда модель была скопирована. По крайней мере, если речь идёт о достаточно старых движках, до первого срузиса, включительно.
В теории можно будет из унреалов-юнитей тоже всё это иметь, сам механизм позволяет, но я пока что не тестировал.

Ну вот загрузил ты в движок модельку, она грузится у тебя голой без материалов, или же у неё уже есть какой то стоковый набор созданный при импорте где можно просто дописать пути к текстурам?

>> Некорректный вопрос. Система материалов XashNT вообще не предусматривает никаких встроенных материалов и шейдеров. Только пользовательские. Фактически рендерер создаётся в скриптовых файлах с нуля под любую задачу. Соответственно меняется уровень графики, в зависимости от использованных шейдеров. Можно получить картинку уровня Doom\Quake, можно картинку уровня HL2, уровня Stalker\Crysis или Unreal4. Я над этой концепцией шесть лет думал.

Ты наверное неправильно понял. Вот допустим я захочу сделать материал которого тупо нет в движке. Например туже кубамапу поделенную на сектора, которые можно заливать разным цветом. Или там зеркало с альфаканалом какое нибудь. Зачем для этого лезть в рендер? Когда можно просто загрузить простой шейдер, и сделать ему публичные переменные как настройки материала?

>> Что имеется в виду под морфингом? Если лицевая анимация, то на данный момент её нет, но формат позволяет её добавить в любой момент, не нарушая совместимость. Если же имеются в виду модели с вертексной анимацией (без костей), то этого на данный момент тоже нет, но такой формат будет. И тоже без нарушения совместимости.

https://www.youtube.com/watch?v=e675Ulc7QL4

Отправлено Дядя Миша 21-04-2022 в 06:00:

Тут еще вот какое соображение. В халфе нормально логические энтить такого рода сделать было невозможно - для них физика считалась, движок пытался их передать по сети, к тому же они занимали очень много памяти, каждый логический блок - как целый монстр. Только что без модельки.
В ксаше с этим не будет проблем, там объектам необязательно наследоваться от CBaseEntity, их кол-во не будет ограничено тысячей штук, т.е. их может быть и 10000 тысяч. Вполне естественно какую-то часть отдать вот под такие логические условия. А в редакторе сделать вкладку, которая будет их показывать отдельно, на манер блу-принтов.
Да, в дальнейшем надо будет поразмыслить над этой темой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 21-04-2022 в 06:04:

Цитата:

Дядя Миша писал:
Я не смотрю в эту сторону.

Жаль, очень прикольная штука с низким порогом вхождения и для этого не нужно знать С++. С одной стороны блюпринты это С++ а с другой оформлен в виде нод и все намного понятнее и нагляднее. Но опять же это уже на свой вкус, кому-то удобно в студии код писать, а кому-то создавать ноды и с ними работать

__________________
Kiss my ass if you don't like my Ford!
------------------------------------------
Game Area51 Update 1
First Person Shooter Released Jul 24, 2017
The game is a 3d shooter with the elements of the quest.

http://button.moddb.com/download/medium/125531.png

Отправлено Дядя Миша 21-04-2022 в 06:11:

Цитата:

FiEctro писал:
Вообще с какими форматами файлов работает движок.

Звуки, видео и изображения - общепринятые. Уровни, модели, спрайты, шрифты - собственные форматы.

Цитата:

FiEctro писал:
Что подразумевается под плагинами для импорта? Это обычные компиляторы?

Импортёры не компилируют а импортируют.

Цитата:

FiEctro писал:
Я к тому нужно ли писать какие то плагины экспорта для 3д пакетов?

Не, я сам их напишу.

Цитата:

FiEctro писал:
Добавь ещё PNG

Ни в коем случае. Нет формата хуже PNG и лучше BMP.

Цитата:

FiEctro писал:
или же у неё уже есть какой то стоковый набор созданный при импорте где можно просто дописать пути к текстурам?

Ты не поймешь мой ответ, поскольку не знаком с концепцией моей системы материалов. Моделька будет выглядеть именно так, как она выглядела в родном движке. Естественно, что дефолтный материал для этого дела и шейдер придётся написать ручками, но это надо сделать один раз для конкретного движка. Один раз для голдсорса, один раз для Сорса, итд. А импортёр просто проставит в материалах некоторые настройки, соответствующие написанным материалам и внутренним настройкам самой модели. Так же есть возможность загружать нативные материалы от сторонних движков, при соблюдении двух условий:
1. описание материалов текстовое
2. описание материалов - поименованный блок фигурных скобок.
В принципе второе требование необязательное, но на данный момент это то, что я точно могу гарантировать. Впрочем в большинстве форков, так ихи иначе основанных на кодобазе Кармака именно этот подход и используется. И есть еще три альтернативы:
1. запись материала в одну строчку - Сталкер, Метро(?)
2. Материал в XML-файле (Unigine, Unity), пока что не поддерживается (я не тестировал, если честно)
3. Материал в бинарном файлике (Unreal) - вот это точно не будет поддерживаться. Но их можно налету сконвертить в текстовые.

Цитата:

FiEctro писал:
Вот допустим я захочу сделать материал которого тупо нет в движке

В движке вообще нет никаких материалов и шейдеров тоже нет. Всё что там есть - создано пользователем.

У меня к тебе огромная просьба - цитируй общепринятым способом.
Выделяешь мышкой текст и жмёшь на кнопку Цитата. Не надо вот этой вот заморочки с ручным цитированием, я не могу понять где кончается мой ответ и начинается твой вопрос.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-04-2022 в 10:58:

Цитата:

Дядя Миша писал:
Тут еще вот какое соображение. В халфе нормально логические энтить такого рода сделать было невозможно - для них физика считалась, движок пытался их передать по сети, к тому же они занимали очень много памяти, каждый логический блок - как целый монстр. Только что без модельки.
В ксаше с этим не будет проблем, там объектам необязательно наследоваться от CBaseEntity, их кол-во не будет ограничено тысячей штук, т.е. их может быть и 10000 тысяч. Вполне естественно какую-то часть отдать вот под такие логические условия. А в редакторе сделать вкладку, которая будет их показывать отдельно, на манер блу-принтов.
Да, в дальнейшем надо будет поразмыслить над этой темой.

Так вот как раз для таких случаев ECS и нужен.

Цитата:

Дядя Миша писал:
спрайты

Зачем спрайтам свой собственный формат? Почему для них нельзя использовать обычные материалы с уже имеющимися форматами текстур?

Цитата:

FiEctro писал:
Ни в коем случае. Нет формата хуже PNG и лучше BMP.

Нормальный формат. Везде используется. Уж почаще чем TGA или Jpeg. Юнити вроде как всё при первичном импорте в dds пересобирает, в независимости что ты ему скормишь, хотя я на 100 процентов не уверен.

Цитата:

FiEctro писал:
Ты не поймешь мой ответ, поскольку не знаком с концепцией моей системы материалов.

Так вот объясни пошагово. Вот у меня в блендере есть моделька с ригом, анимациями и разверткой, а так же текстуры в формате допустим tga. Что я должен сделать чтоба эта модель запустилась под ксашем? Прямо по пунктикам.

Цитата:

Дядя Миша писал:
В движке вообще нет никаких материалов и шейдеров тоже нет. Всё что там есть - создано пользователем.

Тоесть можно использовать только стоковые материалы? Своих уникальных не создать, либо только комбинировать параметры из имеющихся как в третьей кваке или сорсе? А хочешь своё, пересобирай рендер?

Цитата:

Дядя Миша писал:
1. описание материалов текстовое
2. описание материалов - поименованный блок фигурных скобок.
В принципе второе требование необязательное, но на данный момент это то, что я точно могу гарантировать. Впрочем в большинстве форков, так ихи иначе основанных на кодобазе Кармака именно этот подход и используется. И есть еще три альтернативы:
1. запись материала в одну строчку - Сталкер, Метро(?)
2. Материал в XML-файле (Unigine, Unity), пока что не поддерживается (я не тестировал, если честно)
3. Материал в бинарном файлике (Unreal) - вот это точно не будет поддерживаться. Но их можно налету сконвертить в текстовые.

Да что текстовые оно понятно. Меня беспокоит другое, как пакетную обработку всего этого производить? И сколько времени нужно на это будет потратить? Например если кому то взбредит вставить c1a0 моделькой со всей её сворой текстур. Тут вот Раид недавно выкладывал инструкцию как это делать при помощи ПоверШелл и я офигел, надеюсь такого трешака в релизах не будет.

Цитата:

Дядя Миша писал:
Не, я сам их напишу.

Для блендера и 3д макса? Или своя внешняя утилита?

Цитата:

Дядя Миша писал:
У меня к тебе огромная просьба - цитируй общепринятым способом.
Выделяешь мышкой текст и жмёшь на кнопку Цитата. Не надо вот этой вот заморочки с ручным цитированием, я не могу понять где кончается мой ответ и начинается твой вопрос.

Хорошо, просто теги вечно забываю правильно раставить, разметку рвёт.

Отправлено Дядя Миша 21-04-2022 в 12:08:

Цитата:

FiEctro писал:
Так вот как раз для таких случаев ECS и нужен.

Ты эту систему знаешь только со стороны пользователя.

Цитата:

FiEctro писал:
Зачем спрайтам свой собственный формат?

Спрайт - это разновидность шрифта. Там информация о глифах. К тому же у моих спрайтов хранится реальная геометрия. Т.е. можно делать сразу спрайты крест-накрест ну или импосторы из восьми сторон.
А те спрайты, которые ты имеешь в виду - им действительно никакой формат не нужен.

Цитата:

FiEctro писал:
Нормальный формат.

Я уже лет десять твержу что они дико медленный. Там где BMP будут загружаться полсекунды, у PNG на это уйдет до 40 секунд. Эти идиоты додумались каждую скан-линию в рисунке превратить в отдельный zip-архив.
А народ как почуял что формат откровенно дерьмовый, так сразу же стал его дико котировать.

Цитата:

FiEctro писал:
Что я должен сделать чтоба эта модель запустилась под ксашем?

Пока ничего. Вышесказанное относится к готовым моделям из других игр.
С моделями из Макса\Майи\Блендера еще только предстоит разобраться.

Цитата:

FiEctro писал:
Тоесть можно использовать только стоковые материалы?

Да нету никаких стоковых материалов и самого понятия "стоковый материал" нету.

Цитата:

FiEctro писал:
Своих уникальных не создать

Только уникальные материалы и поддерживаются. Которые создал пользователь. Если их нет - движок нарисует мусор вместо картинки.

Цитата:

FiEctro писал:
либо только комбинировать параметры из имеющихся как в третьей кваке или сорсе?

Сорс и ку3 я привёл просто для примера. Какие шейдеры напишешь - такая графика и будет.

Цитата:

FiEctro писал:
А хочешь своё, пересобирай рендер?

Наборот. Только своё и поддерживается, а в рендере нет ничего.

Цитата:

FiEctro писал:
Меня беспокоит другое, как пакетную обработку всего этого производить?

Эти тулзы будут идти в комплекте в качестве плагинов к редактору.
На каждый тип импортируемой игры - свой плагин. Можно и в один конечно засунуть, но думаю так удобнее.

Цитата:

FiEctro писал:
Раид недавно выкладывал инструкцию как это делать при помощи ПоверШелл и я офигел

Я тоже. Я тогда отдыхал и он решил справиться сам.

Цитата:

FiEctro писал:
Для блендера и 3д макса? Или своя внешняя утилита?

Я не полез в Макс\Блендер, лучше будут конверторы из понятных им форматов во внутренний ксашевский и наоборот. А плагины я писать не буду, они слишком быстро устаревают. А на петоне дико медленно всё.

Цитата:

FiEctro писал:
просто теги вечно забываю правильно раставить

Да не надо вручную тэги расставлять,я же говорю - выделил строк мышкой и нажал кнопку Цитата. И оно само всё скопирует с тэгами.

Добавлено 21-04-2022 в 15:08:

Проще говоря, модели спрайтов в XashNT - это такие примитивы без костей и дополнительной инфы. Кустики там всякие, трава ну или классические спрайты. Корочи для тех случаев когда модели со скелетной анимацией использовать неоправдано. В принципе у них нет ограничения на размер меша, так можно ими гильзы делать от оружия и всякую такую хрень.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-04-2022 в 12:13:

Дядя Миша
Уже более понятно что из себя представляет движок. Чтож, скажу что мне пока твоя концепция нравится. Главное чтобы с ресурсами можно было работать очень быстро, не теряя уймы часов на подготовку их к конвертациям, это меня прямо сильно в ГС/Сорсе раздражало.

Ну и вообще имей ввиду что твой движок будут использовать по большей части художники которые хорошо знают 3д макс и фотошоп, но при этом ничего не смыслят в архитектурах движков. Очень надеюсь что ксаш освободит от написания юзверя лишних скриптов, и предоставит пользователю заниматься конкретно игрой (игровой логикой и шейдерами). Ибо даже если взять Юнити, всеравно от этой инженирии никуда не деться, но там авторы конечно прямо постарались.

Из пожеланий наверное классно бы было сделать в движке встроенный файловый менеджер, который бы мог просматривать и перемещать, конвертировать все нужные ресурсы.

Хотелось бы конечно пощупать это вживую, но наверное лучше подожду, пока ты всё причешешь и уже сам выложишь
Что кстати по кроссплатформенности, насколько реально собрать проект под тот же андроид? Вроде как виртуальная машина должна упростить портирование? Или без разницы?

И ещё такой вопрос, что с физикой? Вернее какой физический движок используешь, и планируется поддержка ригидбоди и регдоллов?

Отправлено (_-=ZhekA=-_) 21-04-2022 в 12:18:

Дядя Миша
А как будет хоть примерно выглядеть редактор, скрины есть? Ну, или на что будет примерно похож?

Отправлено Дядя Миша 21-04-2022 в 13:28:

Цитата:

FiEctro писал:
Главное чтобы с ресурсами можно было работать очень быстро, не теряя уймы часов на подготовку их к конвертациям, это меня прямо сильно в ГС/Сорсе раздражало.

Да, я этому уделю особое внимание. Меня это это тоже бесило.

Цитата:

FiEctro писал:
Очень надеюсь что ксаш освободит от написания юзверя лишних скриптов, и предоставит пользователю заниматься конкретно игрой (игровой логикой и шейдерами)

В комплекте будут идти готовые, даже не примеры, а целые рендереры для конкретных игр. Написанных на скриптовом языке. Да собственно они уже идут и доступны в приватной бете, ты же не хочешь её смотреть. Там и документация есть. Но редактора пока нет, пишу вот.

Цитата:

(_-=ZhekA=-_) писал:
А как будет хоть примерно выглядеть редактор, скрины есть? Ну, или на что будет примерно похож?

А ни на что не будет похож. Редактор будет использовать такую же скрипт-машину, как для энтитей, но для описания интерфейса. То есть редактор будет выглядеть как угодно. Я напишу оболочку для кварка, возможно для хаммера. Пользователи смогут рисовать свои оболочки тоже.
Можно будет и в стиле UE сделать. Единственно, что на это время понадобится и возможно помощь коммунити.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 21-04-2022 в 13:48:

Цитата:

Дядя Миша писал:
Редактор будет использовать такую же скрипт-машину, как для энтитей, но для описания интерфейса.

Пока не особо понятно, как все это будет выглядеть (

Цитата:

Дядя Миша писал:
Пользователи смогут рисовать свои оболочки тоже.
Можно будет и в стиле UE сделать.

Вот это уже интересно ) Скрины бы еще глянуть )

Добавлено 21-04-2022 в 16:48:

Цитата:

FiEctro писал:
Из пожеланий наверное классно бы было сделать в движке встроенный файловый менеджер, который бы мог просматривать и перемещать, конвертировать все нужные ресурсы.

+1 в ue4 очень удобно )

Отправлено Дядя Миша 21-04-2022 в 14:09:

Цитата:

(_-=ZhekA=-_) писал:
Вот это уже интересно ) Скрины бы еще глянуть )

Да не на что пока еще глядеть. Как раз над этим сейчас и работаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 22-04-2022 в 07:28:

Читаю тему с самого начала, неспешно. Очень хорошо что я это сделал, например освежил в памяти, сколько же на самом деле было итераций у системы материалов. Спустя 2 года, мне уже кажется, будто я её выдумал и реализовал буквально за месяц. Но нет, она менялась очень много раз.
Что хотелось бы отметить.

- XashNT разрабатывается итеративным методом. Это чем-то напоминает работу виндового дефргаментатора. Содержимое диска изменилось - повторный запуск и опять всё сначала. Поэтому если в теме встречаются упоминания "движок готов на 50\60%" это число могло откатиться обратно к более скромным значениям. Я в принципе не готов оставлять те решения, которые кажутся мне спорными. Готов с ними какое-то время мириться, но потом они всё равно будут переписаны.

- Основная задача, как и декларировалось изначально - максимальная целостность концепции. Это даёт пользователю возможность безо всякой документации, просто по аналогии и предидущему опыту предполагать у движка наличие тех или иных возможностей и движок не обманет его в этих ожиданиях. На мой взгляд это самое главное качество. Продираться через документацию - это почти всегда заставлять себя принимать чужую точку зрения и пытаться её осмыслить. Конечно это не значит, что документации вообще не будет. Будет и она уже есть, но гораздо удобнее, если человек прочитав вводную и уловив общие принципы сможет действовать интуитивно, а не спотыкаться на каждом шаге.

- Всё что я делаю сейчас - это продолжение разработки того самого ксаша из 2007-го года. Да, Ксер мне сказал - сделай его совместимым с халфой и я сделал. Появился Xash3D, XashXT, P2:Savior. Но об истинной цели я не забывал никогда. Просто теперь у меня появился несравнимый с 2007-м опыт.

Глобальные задачи, которые предстоит решить:
- Написание редактора
- Использование виртуальной машины в качестве игровой библиотеки

Самое сложное в разработке, это фундаментальные задачи, когда еще неизвестно чем дело закончится. Ну вы помните, когда я разрабатывал новый формат уровней и точно так же не знал. А что если у меня не получится? А что если он будет слишком тормозной? Или лайтмапу не сумею нормально наложить? Тут те же вопросы встают, по виртуальной машине. Точнее часть очень острых вопросов стояла буквально месяц назад, но я их успешно решил. Впрочем, вопрос о производительности пока остаётся.

Добавлено 22-04-2022 в 09:51:

Кстати. Я там в середине темы топил за сохраняемые модели. К этой концепции можно будет всеръез вернуться, когда пользовательская часть станет виртуальной машиной. Ну потому что сейчас сериализация именно в юзерской части дллки находится и это совсем другой расклад.

Добавлено 22-04-2022 в 10:26:

Пока не забыл, оставлю здесь на будущее концепцию моделей.
Идея в том, чтобы абсолютно все видимые и осязаемые сущности были моделями. В старых движках модель - это только то, что было загружено с диска. Уровень, монстр или спрайт. Я хочу пойти дальше и сделать моделями абсолютно всё. Эти модели смогут конструироваться на лету и сохраняться в сейв. Что с одной стороны разрешит вопрос, например с сериализацией разрушаемых моделей. Т.е. если модель в сейве - грузим именно её, а не с диска. Примеры:

Модель декалей: mod_decal. Имеет родителя - реальную модель, неважно мир или монстра. Внутри массив вертексов, который загружается в VBO и точно так же рисуется через стандартную систему материалов. При добавлении новой декали обновляется и массив. С точки зрения конвейера - это точно такая же модель. С точки зрения физического движка - коллизии нет.

Модель лучей: mod_beam - рисуем лучи по синусоиде или как там еще, скроллим текстурку. Ну их наверное нет смысла сохранять в сейв.

Модель партиклей: mod_particle - рисуем партикл-систему. Можем сохранить в сейв состояние частиц по аналогии с декалями. Thambs помню агитировал за это. Разницы никакой, что характерно - те же самые позиции в пространстве. Ну наверное можно оптимизировать, сохранять позиции как char и глобальный оффсет к ним или скейл. Это всё детали.

Модель деформируемая: mod_softbody. Коровы эти проминающиеся или просто разрушаемый ящик. С точки зрения рендеринга - те же самые частицы, аналог декалей или партиклей. С точки зрения физики да, посложнее, но тоже решаемо.

В этой концепции самое главное - рендерер по прежнему остаётся абстрактным конвейером. Ничего кроме списка моделей он не рисует.
А список бьётся на непрозрачные и прозрачные сущности. Конечно проблема отрисовки полупрозрачных поверхностей внутри такой модели никуда не исчезает к сожалению. Т.е. скажем партиклы внутри системы как-то сортировать. Но вам прекрасно известно, что эта проблема в принципе нерешаемая стандартными средствами, а OIT по прежнему слишком дорог для большинства пользовательских видеокарт.

Впрочем моя скриптовая рендер-система позволяет реализовать OIT пользовательскими средствами, чтобы каждый сам для себя так сказать решил, надо ли оно лично ему.

У этой системы есть только один условный минус. Она по дизайну куда больше подходит для persistent-объектов. А не для короткоживущих, типа спыжки от выстрела или wallpuff. Особенно, если этих последних довольно много. Но это наверное можно решить, определив время жизни для переиспользуемых слотов в массиве моделей. По тому же принципу, по которому энтити переиспользуются.

Такая концепция разом снимает все потенциальные проблемы и здорово упрощает разработку. Можете высказываться по поводу

Добавлено 22-04-2022 в 10:28:

ЗЫ, Чтобы было понятнее - это в противовес тесселятору из ку3, который программно обрабатывал каждый полигончик. Но сейчас для производительности весьма вреден такой подход. Поэтому вот такие модели - группы полигонов в VBO, а обработка в шейдере.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 22-04-2022 в 07:31:

Цитата:

Дядя Миша писал:
Это даёт пользователю возможность безо всякой документации, просто по аналогии и предидущему опыту предполагать у движка наличие тех или иных возможностей и движок не обманет его в этих ожиданиях. На мой взгляд это самое главное качество. Продираться через документацию - это почти всегда заставлять себя принимать чужую точку зрения и пытаться её осмыслить

Этот как? Например просмотрел какой нибудь условный Вася на ютубе курсы по крестам. Освоился более менее в IDE и синтаксисе. Скачал твой движок, какой у него опыт? Ладно это мы с тобой уже ковыряли разные движки и хоть немного представляем как это работает. Но вот для примера сам попробуй взять и без подглядывания в гугл и документацию написать прямо с набегу какой нибудь тетрис на юнити.

Цитата:

Дядя Миша писал:
Идея в том, чтобы абсолютно все видимые и осязаемые сущности были моделями.

Это скорее просто объекты. Идея здравая, мне нравится. Но не забывай что кости моделей тоже могут быть отдельными объектами. Это очень крутая особенность позволяет очень гибко комбинировать физику и анимацию.

Отправлено Дядя Миша 22-04-2022 в 07:55:

Цитата:

FiEctro писал:
Но не забывай что кости моделей тоже могут быть отдельными объектами

Надо еще учитывать, что видеокарта не любит рисовать маленькими порциями. Это налагает определённые ограничения.

Цитата:

FiEctro писал:
Ладно это мы с тобой уже ковыряли разные движки и хоть немного представляем как это работает

Да, нас таких всего два человека на планету, а остальные только ролики на ютубе смотрели.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 22-04-2022 в 08:49:

Цитата:

Дядя Миша писал:
Да, нас таких всего два человека на планету, а остальные только ролики на ютубе смотрели.

Так надо уменьшать порог вхождения

Чтобы на начальном уровне пользование движком было не сложнее просмотров роликов на ютубе. Может быть даже заведем ютуб канал где будем объяснять особенности работы с движком, естественно при твоей консультации.

Цитата:

Дядя Миша писал:
Надо еще учитывать, что видеокарта не любит рисовать маленькими порциями. Это налагает определённые ограничения.

Да ладно, мобилы тянут, а десткоп не потянет

Отправлено Дядя Миша 22-04-2022 в 11:10:

Цитата:

FiEctro писал:
Да ладно, мобилы тянут, а десткоп не потянет ?

В Юнитехе примерно так и думают.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 22-04-2022 в 12:11:

Я очень не понимаю причем тут вообще отрисовка. Что, теже регдоллы рисуются как то по другому? Там же посути тоже каждая кость как отдельный объект с
ригидбоди.

Отправлено Ku2zoff 22-04-2022 в 12:20:

Цитата:

FiEctro писал:
мобилы тянут, а десткоп не потянет

Графические процессоры немного по-разному устроены, вроде бы? На десктопе разрешения на порядок выше: де-факто, стандартом уже стали 2k-4k (не в нищей России, конечно, дай б-г, чтобы у четверти владельцев ПК было FullHD). Да и в целом, требования к скорости работы и отзывчивости управления на десктопе сильно выше.

Отправлено Дядя Миша 22-04-2022 в 12:36:

Цитата:

FiEctro писал:
Что, теже регдоллы рисуются как то по другому?

регдоллы нет, а вот расчлёнёнку уже сложнее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 22-04-2022 в 13:40:

Цитата:

Ku2zoff писал:
Графические процессоры немного по-разному устроены, вроде бы? На десктопе разрешения на порядок выше: де-факто, стандартом уже стали 2k-4k (не в нищей России, конечно, дай б-г, чтобы у четверти владельцев ПК было FullHD). Да и в целом, требования к скорости работы и отзывчивости управления на десктопе сильно выше.

На мобилах не меньше, есть как и 2к и 4к.

Цитата:

Дядя Миша писал:
регдоллы нет, а вот расчлёнёнку уже сложнее.

Я имею ввиду возможность задавать отдельно каждой косточке правила движения скриптом. Например тот же джоинт сиськам или волосам назначить, или переместить саму кость по иерархии, или даже самую простую ИКшку. Разрезание это уже отдельная тема.

Отправлено Дядя Миша 22-04-2022 в 13:57:

Кости с сервера контролируются, так что да, будет такое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 23-04-2022 в 06:24:

Осилил 70 страниц темы. Моё личное когнитивное искажение заключается в том, что я некоторые вещи я уже не помнил и искренне считал, что с самого начала придерживался подобной линии, но вот как оказалось, отношение к ним поменялось непосредственно в процессе разработки, по итогам проведённых опытов. Давайте же вспомним все ключевые моменты.

1. Игровую часть планировалось оставить в С++ библиотеке и вынести туда как можно больше связанных вещей, чтобы у юзера было как можно больше свободы действий. Это действительно было сделано, но движение в данном направлении превращает пользовательские библиотеки в подобие сорсовских. Куда обычному дизайнеру просто страшно залезать. Это явно не то, чего бы мне хотелось.
Смена концепции: игровая часть должна быть в скрипт-машине, которую легко отредактировать, не устанавливая громоздких IDE.
Статус: еще не реализовано

2. Система материалов. Концепция, если внимательно ознакомиться с темой, менялась раз пять-шесть, в процессе имплементации. Получившийся язык позволяет гибко описать абсолютно любой материал, однако он слишком громоздкий для обычно пользователя. Решение было найдено при помощи системы макросов, которые позволяют притвориться одним из стандартных языков описания материалов. Таким образом пользователю даже не придётся переучиваться. Или наоборот - он сможет создать свой язык описания системы материалов.
Статус. завершено наполовину, поскольку нет динамического освещения и теней, что вероятно потребует некоторых нововведений в уже существующую систему.

3. Формат уровней. Изначально предполагалось использовать Q1-like формат, слегка доработанный. Во многом в рамках этого эксперимента и создавались p2st-компиляторы. Затем был использован Q3-like формат,
который тоже меня не устроил по ряду показателей и наконец в процессе была выработана концепция Uniform Mesh. Это очень хороший механизм, позволяющий расширять любой формат без потери совместимости.
Статус: формат завершен, однако текущие реализации на его базе еще будут изменяться (без потери совместимости) и расширяться.

4. Статическое освещение. Как вы помните, изначально я не планировал его внедрять, однако под давлением общественности и собственных соображений всё же сделал это. Смена концепции: первоначальный лайтмаппер не умел считать отражённое освещение, но в итоге там появился полноценный радиосити.
Статус: лайтмаппер закончен, но я не исключаю его дальнейших оптимизаций.

5. Редактор ресурсов. До сентября прошлого года не хотелось связываться с этой темой вообще. Были надежды, что его заменит Jack или Blender.
Натурные эксперименты показали, что об этом нечего даже и думать.
Смена концепции: я не хотел делать редактор, поскольку он ожидаемо был бы похож на QuArK, но теперь я создаю редактор, у которого внешний вид заложен в скриптовых файлах, а следовательно может быть адаптирован под внешний вид любого редактора, будь то Jack или даже Unity.
Статус: в процессе разработки (именно над ним я сейчас и работаю).

Всё это конечно удлиняет путь, но меня покрайней мере не мучают мысли, что я собственноручно заложил в фундамент своего движка какое-то гамно или дохлую крысу. Уж если для себя строить тяп-ляп, зачем тогда вообще строить?
Есть и другие соображения. Когда мне кто-то говорит "Да сделай всё как в XXX", я спрашиваю - а зачем? Копия не будет лучше оригинала. Это их концепция и их путь. Если кто-то его разделяет, то пусть и пользуется этим продуктом.
На данный момент я придерживаюсь такого мнения, что ситуация на рынке движков, абсолютно не устраивает их пользователей, но альтернативы у них всё равно нет. Вот и приходится терпеть и успокаивать себя тем, что всё что они видели - еще хуже.

Добавлено 23-04-2022 в 09:24:

Теперь к вопросу, могут ли поставленные задачи быть реализованы одним человеком? Если на другой стороны - корпорации с миллиардными бюджетами. Ну я напоминаю, что изначально Кармак и Суини писали свои движки в одно жало. Сила таких продуктов - в сложившемся коммунити, и накопленных обучающих материалах, ресурсах, а так же в общественном мнении. А вовсе не в том, что исходники движка весят 20 гигабайт.

Если народу понравится предложенный мной путь, это будет куда важнее многомиллиардных бюджетов. Сила в идеях, а не в нарисованных ноликах на банковском счёте. Ну да ладно, не буду углублять эту тему, а то уже политота начнётся.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 24-04-2022 в 08:32:

Цитата:

Дядя Миша писал:
5. Редактор ресурсов. До сентября прошлого года не хотелось связываться с этой темой вообще. Были надежды, что его заменит Jack или Blender.
Натурные эксперименты показали, что об этом нечего даже и думать.
Смена концепции: я не хотел делать редактор, поскольку он ожидаемо был бы похож на QuArK, но теперь я создаю редактор, у которого внешний вид заложен в скриптовых файлах, а следовательно может быть адаптирован под внешний вид любого редактора, будь то Jack или даже Unity.
Статус: в процессе разработки (именно над ним я сейчас и работаю).

Вот у меня давно висел этот вопрос. Я помню что ты изначально писал что можно будет обойтись любым редактором, но потом сказал что разрабатываешь собственный, что меня ввело в недоумение.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 24-04-2022 в 11:34:

Цитата:

SNMetamorph писал:
Я помню что ты изначально писал что можно будет обойтись любым редактором

Мы прикрутили Блендер. Неудобно. Опытным товарищам может и зайдет, но для начинающих это сразу "нет".

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 24-04-2022 в 11:45:

Цитата:

Дядя Миша писал:
Мы прикрутили Блендер. Неудобно.

Геометрию в нём делать может и удобно, но редактор уровней должен уметь делать не только геометрию, но ещё показывать карту в максимально готовом виде и позволять удобно работать с энтитями: расставлять их, делать из них связки, менять свойства. Желательно это всё делать в одном редакторе, чтобы не прыгать из 3D пакета в скриптер и обратно.

Отправлено FiEctro 24-04-2022 в 11:48:

Цитата:

Ku2zoff писал:
Геометрию в нём делать может и удобно, но редактор уровней должен уметь делать не только геометрию, но ещё показывать карту в максимально готовом виде и позволять удобно работать с энтитями: расставлять их, делать из них связки, менять свойства. Желательно это всё делать в одном редакторе, чтобы не прыгать из 3D пакета в скриптер и обратно.

По мне хорошее сочетание брашей и моделей реализовано в UDK. В теории всё это в блендере можно сделать, но нужно написать соответствующие плагины. А уж про предварительный просмотр освещения на карте в реальном времени, равных Блендеру просто нет. Ни Джек, ни Кварк, ни Хаммер такую фичу не поддерживают.

Отправлено Ku2zoff 24-04-2022 в 11:53:

Цитата:

FiEctro писал:
В теории всё это в блендере можно сделать, но нужно написать соответствующие плагины.

Блендер избыточен на мой взгляд. Ещё тяжко переучиваться после хаммера/радианта/кварка на работу в проге для 3D моделирования.

Отправлено FiEctro 24-04-2022 в 11:55:

Цитата:

Ku2zoff писал:
Блендер избыточен на мой взгляд. Ещё тяжко переучиваться после хаммера/радианта/кварка на работу в проге для 3D моделирования.

Если ты хочешь делать что то сложнее мода Бумера тебе всеравно придётся изучать моделирование. Или воровать чужие модели..
На деле, моделировать куда проще чем кубать в хаммере, потому что во-первых у тебя есть нормальный инструментарий для работы с геометрией и разверткой (в брашевых редакторах он можно сказать практически отсуствтует), во-вторых тебе не надо заморачиваться с тем чтобы все 4 вершины лежали в одной плоскости, что координаты будут плавать после экспорта и давать leak там где его не должно быть, в третьих нормальная топология, а не то мессево из полигонов что режет CSG. Т.е. карту модель всегда в готовом виде можно отредактировать. Редактирование брашевого декомпила это всегда боль. Что проще сделать с нуля, нежели с этим возиться.

Из минусов да, не очень удобная работа с игровыми объектами, поскольку блендер просто о них ничего не знает. Но они там есть, просто нужно писать к ним плагин. Я к сожалению в питоне не шарю, а то так бы давно написал.

Отправлено Дядя Миша 24-04-2022 в 12:19:

Ну я планирую написать простенький редактор моделей тоже.
В первую очередь для себя, потому что я написал компиляторы уровней вслепую, а некоторые эвристические вещи лучше визуализировать.
В частности это касается склеивания зеркальной развертки обратно в обычную для лайтмапы, ну и не только это, конечно.

Т.е. персов в нём навряд ли можно будет делать, а вот всякие домики, на манер брашевых - вполне, так думаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 24-04-2022 в 12:24:

Дядя Миша
Можно будет в редакторе запустить сцену и побегать на ней?

Отправлено Дядя Миша 24-04-2022 в 15:35:

Цитата:

FiEctro писал:
Можно будет в редакторе запустить сцену и побегать на ней?

Да, в паре с виртуальной машинкой это отлично получится.
Если бы там была С++ игровая библиотека, возникло бы множество проблем, вплоть до того, чтобы разработчику пришлось бы особо настраивать поведение в редакторе и в игре, для объектов.
А с виртуалкой таких проблем не будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 24-04-2022 в 20:35:

Дядя Миша
Круто, ждём ждём ждём

Отправлено Ku2zoff 24-04-2022 в 21:14:

Цитата:

Дядя Миша писал:
я планирую написать простенький редактор моделей тоже

Что-то уровня kHED? В принципе, нормально, лишь бы было удобно работать с анимациями. Блендер в этом плане я пока не осилил, милка - тихий ужос, фрагмоушен - слабоват.

Цитата:

Дядя Миша писал:
Т.е. персов в нём навряд ли можно будет делать

Ну это смотря каких персов. Что-то лоуполи уровня первой халфы наверное можно будет. Хотя оно особо и не требуется, т.к. можно импортировать из того же блендера, и в движковом редакторе подкручивать по мелочи.

Цитата:

Дядя Миша писал:
в паре с виртуальной машинкой это отлично получится

То есть, без компиляции, предварительный тест на манер кваковского CSG+BSP? Этого очень не хватает порой, чтобы всякую фигню править налету.

Отправлено FiEctro 24-04-2022 в 21:19:

Цитата:

Ku2zoff писал:
то-то уровня kHED? В принципе, нормально, лишь бы было удобно работать с анимациями.

Ты ещё из брашей персонажей делать предложи

Отправлено Дядя Миша 25-04-2022 в 06:27:

Цитата:

Ku2zoff писал:
Что-то уровня kHED? В принципе, нормально, лишь бы было удобно работать с анимациями

Ой нет, насчёт анимаций ничего обещать точно не могу. Только статичные модельки.

Цитата:

Ku2zoff писал:
предварительный тест на манер кваковского CSG+BSP

Можно запускать вообще без компиляции. Хотя хз, посмотрим.

Добавлено 25-04-2022 в 09:27:

Цитата:

FiEctro писал:
Ты ещё из брашей персонажей делать предложи

Робатов! Они как раз квадратные.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 25-04-2022 в 06:53:

Цитата:

Дядя Миша писал:
насчёт анимаций ничего обещать точно не могу. Только статичные модельки.

А зачем тогда такой редактор? kHED уже есть для статичных моделек. Экспорт-импорт и готово.

Отправлено Дядя Миша 25-04-2022 в 07:29:

Затем что, он позволит редактировать модели, не выходя из редактора уровней.
Насколько я знаю, с этим всё очень хреново.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 25-04-2022 в 07:41:

Цитата:

Дядя Миша писал:
Затем что, он позволит редактировать модели, не выходя из редактора уровней.

Если в нем нельзя будет делать сложные статичные модели с разверткой, то в нем нет смысла. Для этого есть макс, блендер и другие. + Для создания моделей должно быть тонна разных инструментов и удобная навигация ( опять же удобная навигация для каждого своя, так как люди работают в разных пакетах для моделирования, я работаю в максе и для меня это удобно и привычно )

Отправлено FiEctro 25-04-2022 в 07:54:

(_-=ZhekA=-_) Ku2zoff
Я так понимаю ДМ имеет ввиду инструментарий для создания брашевой геометрии или просто базового блокинга. В целом норм идея. А для создания сложных мешей действительно лучше нормальные 3д пакеты юзать.

Отправлено (_-=ZhekA=-_) 25-04-2022 в 08:01:

Цитата:

FiEctro писал:
Я так понимаю ДМ имеет ввиду инструментарий для создания брашевой геометрии или просто базового блокинга.

Типа как в джеке? Если так, то да, это логично и все для этого должно быть в одном редакторе. А вообще я не понимаю зачем писать велосипед, ведь можно же договориться с Ксером написать плагин для джека в котором будут учтены все особенности движка и спокойно юзать

Отправлено Дядя Миша 25-04-2022 в 09:21:

Цитата:

(_-=ZhekA=-_) писал:
Если в нем нельзя будет делать сложные статичные модели с разверткой, то в нем нет смысла

Как раз развертке будет уделено особое внимание. Потому что мне для лайтмап надо еще развертку генерить и в редакторе этот процесс гораздо легче сделать, нежели потом компилятор будет с этим разбираться.

Цитата:

(_-=ZhekA=-_) писал:
можно же договориться с Ксером написать плагин для джека в котором будут учтены все особенности движка

Джек не сможет учесть всех особенностей, к сожалению.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 25-04-2022 в 09:34:

Цитата:

Дядя Миша писал:
Джек не сможет учесть всех особенностей, к сожалению.

А о каких особенностей идет речь, если не секрет?

Отправлено Ku2zoff 25-04-2022 в 09:39:

Цитата:

FiEctro писал:
инструментарий для создания брашевой геометрии или просто базового блокинга. В целом норм идея.

Мы это оценим в боевых условиях. Если прокатит - останется. Не прокатит - будет брошено. Как было со многими вещами при разработке Ксаша. Просто я пока что не слишком понимаю разницу между брашевым домом и точно таким же домом-моделькой. Если

Цитата:

Дядя Миша писал:
Как раз развертке будет уделено особое внимание.

отсюда можно сделать вывод, что текстуры можно будет накладывать одинаково как на браши, так и на модели внутри редактора. Зачем тогда редактировать дом в отдельном окошке?

Отправлено (_-=ZhekA=-_) 25-04-2022 в 10:02:

Цитата:

Дядя Миша писал:
но теперь я создаю редактор, у которого внешний вид заложен в скриптовых файлах, а следовательно может быть адаптирован под внешний вид любого редактора, будь то Jack или даже Unity.

А что нужно будет сделать, чтобы сменить тему\вид редактора? Писать код\скрипт в блокноте\студии или в самом редакторе будет все для этого необходимое и не нужно будет ничего писать?

Отправлено FiEctro 25-04-2022 в 10:16:

Цитата:

(_-=ZhekA=-_) писал:
А вообще я не понимаю зачем писать велосипед, ведь можно же договориться с Ксером написать плагин для джека в котором будут учтены все особенности движка и спокойно юзать

Потому что у Ксерокса свой движок, и подстраивать Джек под чужой движок у него нет ни времени, ни желания.

Цитата:

Ku2zoff писал:
Просто я пока что не слишком понимаю разницу между брашевым домом и точно таким же домом-моделькой. Если

Я так понимаю это просто базовый инструмент для того чтобы как то на коленке набросать прототип уровня, чтобы сразу побегать, не скачивая и не изучая других 3д пакетов.

Цитата:

Ku2zoff писал:
отсюда можно сделать вывод, что текстуры можно будет накладывать одинаково как на браши, так и на модели внутри редактора. Зачем тогда редактировать дом в отдельном окошке?

Накладываются материалы. А развертка просто редактируется.

Отправлено (_-=ZhekA=-_) 25-04-2022 в 10:29:

Цитата:

FiEctro писал:
Потому что у Ксерокса свой движок, и подстраивать Джек под чужой движок у него нет ни времени, ни желания.

Это само-собой, что Ксеру не до ксаша - это понятно, но есть система плагинов и сам плагин ДМ может написать сам при желании. Но видимо там проблема намного глубже, возможно, что-то личное, хз.

Отправлено Ku2zoff 25-04-2022 в 10:49:

Цитата:

(_-=ZhekA=-_) писал:
там проблема намного глубже, возможно, что-то личное, хз.

Я думаю, что проблема в архитектуре редактора. Некоторые вещи просто невозможно реализовать через плагин, не затрагивая ядро. Да и как вообще возможно будет

Цитата:

FiEctro писал:
в редакторе запустить сцену и побегать на ней

Тут нужен такой движок, который, грубо говоря, имеет два уровня работы: первый - уровень редактора, где всё попроще, но можно вносить изменения налету. Второй - релизный уровень, где всё скомпилено и оптимизировано. Эдакий CUBE-Like вариант. Сама идея редактирования налету в Кубе мне всегда нравилась, но вот реализация там очень неудобная: нет 2D видов и привычных инструментов.

Отправлено Дядя Миша 25-04-2022 в 10:57:

Цитата:

(_-=ZhekA=-_) писал:
А о каких особенностей идет речь, если не секрет?

Ну например авто-формирование списка игровых объектов, прямо из виртуальной машинки. Не надо будет больше никаких FGD.
Или создание и редактирование ландшафтов. Наконец я не представляю как его подружить с моей системой материалов. Это только то, что навскидку.

Цитата:

Ku2zoff писал:
Не прокатит - будет брошено. Как было со многими вещами при разработке Ксаша.

Оно не исчезло вникуда, я может потом поделюсь этими наработками. Там еще на один движок хватит.

Цитата:

Ku2zoff писал:
Просто я пока что не слишком понимаю разницу между брашевым домом и точно таким же домом-моделькой

Брашевый дом с непривычки сделать куда как проще. Вот это главная разница. Да и щелей там уж точно не будет.

Цитата:

(_-=ZhekA=-_) писал:
А что нужно будет сделать, чтобы сменить тему\вид редактора?

Написать новый вид редактора на скриптовом языке, близком к С++.
Но там довольно просто всё будет. К тому же скриптовая машинка будет подгружать скриптовой файл где будут в текстовом формате находиться эти самые окошки, т.е. их вид можно будет попдравить просто в блокноте.
Но вот чтобы привязать к окошку какое-то действие - скорее всего придётся кодить. Хотя хз, это за горизонтом моего планирования на текущий момент. Не могу предвидеть.

Цитата:

(_-=ZhekA=-_) писал:
Но видимо там проблема намного глубже

Он просто знает, что я могу написать свой редактор

Добавлено 25-04-2022 в 13:57:

Консольку сделал новую, для среды.

Добавлено 25-04-2022 в 13:57:

WinAPI это конечно нечто. Когда нибудь я вам поведаю о своих приключениях.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 25-04-2022 в 11:09:

Цитата:

Дядя Миша писал:
Консольку сделал новую, для среды.

Похоже на хэш от майнинга

Цитата:

Дядя Миша писал:
Он просто знает, что я могу написать свой редактор

Я думаю, что никто не сомнивается, что ты его напишешь, просто все упирается во-время его явно за пару месяцем не напишешь, могут уйти годы...

Цитата:

Дядя Миша писал:
Но там довольно просто всё будет.

Это просто для тебя, но не факт, что это будет просто для юзера. Я думаю нужно будет сделать несколько готовых вариантов самых известных типа UE4, юнити, макс, блендер и оставить возможность эти темы редактировать, если кому-то это понадобится

Отправлено Дядя Миша 25-04-2022 в 11:17:

Цитата:

(_-=ZhekA=-_) писал:
могут уйти годы...

Первый рабочий прототип уже в этом году будет, а потом только добавление функционала.

Цитата:

(_-=ZhekA=-_) писал:
но не факт, что это будет просто для юзера

Вот пусть юзеры и сообщают, просто им или нет. Они же тестировать всё это будут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 25-04-2022 в 11:32:

Цитата:

Дядя Миша писал:
Написать новый вид редактора на скриптовом языке, близком к С++.

Можно сделать простенький UI редактор который будет генерировать эти скрипты. По образу диалоговых окон в MFC, там вроде не так сложно. Да и тебе это ускорит разработку редактора.

Отправлено (_-=ZhekA=-_) 25-04-2022 в 11:32:

Цитата:

Дядя Миша писал:
Первый рабочий прототип уже в этом году будет, а потом только добавление функционала.

Это хорошо

Для всех или для избранных?

Отправлено Ku2zoff 25-04-2022 в 11:34:

Цитата:

(_-=ZhekA=-_) писал:
Я думаю нужно будет сделать несколько готовых вариантов самых известных типа UE4, юнити, макс, блендер и оставить возможность эти темы редактировать

Самые известные в нашем комьюнити - Хаммер и Кварк. Хаммером пользуются или пользовались почти все, Кварком - Дядя Миша. Какой-нибудь третий вариант типа 3ds max или Blender может быть полезен тем, кто работает в 3d пакетах. Остальное сделают сами пользователи других редакторов. Скорее всего, в процессе разработки будут учитываться отзывы тестеров и результаты голосований. Я подозреваю, что управление и раскладка по-умолчанию будут хаммеровские с возможностью тонкой настройки.

Отправлено nemyax 25-04-2022 в 11:42:

Цитата:

(_-=ZhekA=-_) писал:
Для создания моделей должно быть тонна разных инструментов

Чтобы моделилка начала приносить практическую пользу, инструментов надо не так уж и много. А базовых операций, на которых основываются инструменты конкретно изменения геометрии, я бы лично выделил не больше шестнадцати. Плюс операции для трансформаций и выделения, которые нужны и для геометрии, и для ювишек.

Отправлено FiEctro 25-04-2022 в 12:01:

Цитата:

Ku2zoff писал:
Самые известные в нашем комьюнити - Хаммер и Кварк. Хаммером пользуются или пользовались почти все, Кварком - Дядя Миша. Какой-нибудь третий вариант типа 3ds max или Blender может быть полезен тем, кто работает в 3d пакетах. Остальное сделают сами пользователи других редакторов. Скорее всего, в процессе разработки будут учитываться отзывы тестеров и результаты голосований. Я подозреваю, что управление и раскладка по-умолчанию будут хаммеровские с возможностью тонкой настройки.

Хаммером и кварком сейчас пользуются 2 с половиной человека. Эти инструменты уже устарели, и тащат за собой больше проблем чем достоинств. Например та же настройка Entity там реализована максимально идиотским способом.

Наверное придётся снимать интенсив по блендеру, дабы разоблачить этот брашевой культ.

Отправлено (_-=ZhekA=-_) 25-04-2022 в 12:23:

Цитата:

FiEctro писал:
Хаммером и кварком сейчас пользуются 2 с половиной человека. Эти инструменты уже устарели, и тащат за собой больше проблем чем достоинств.

Ну, тут как посмотреть, если, например, ксаш использовать только для хобби, то джек самое то. Если планы зарабатывать деньги и использовать движок для архитектурной визуализации, то тут нужно смотреть вообще в другую сторону и на другие проги и движки

Отправлено FiEctro 25-04-2022 в 12:24:

Цитата:

nemyax писал:
Чтобы моделилка начала приносить практическую пользу, инструментов надо не так уж и много. А базовых операций, на которых основываются инструменты конкретно изменения геометрии, я бы лично выделил не больше шестнадцати. Плюс операции для трансформаций и выделения, которые нужны и для геометрии, и для ювишек.

Смотря опять же какие модельки ты хочешь получить по итогу. Если кубы вроде даста 2 то да, совсем не много. Но если какой нибудь автобус из Сталкера, или персонажа, то тут извиняй, хоть 16, хоть 30, но нужен нормальный 3д пакет, иначе создание твоих моделей затянется на несколько месяцев.

Цитата:

Дядя Миша писал:
WinAPI это конечно нечто. Когда нибудь я вам поведаю о своих приключениях.

Посмотри кстати эту штуку. Для интерфейсов.
https://github.com/ocornut/imgui

Отправлено nemyax 25-04-2022 в 12:54:

Цитата:

FiEctro писал:
нужен нормальный 3д пакет, иначе создание твоих моделей затянется на несколько месяцев

Если в моделилке реализованы extrude, connect, dissolve, collapse, bridge и bevel, то ты готов хоть к неанимированному хряку, хоть к кабине вертолёта в кратчайшие сроки.

Цитата:

FiEctro писал:
хоть 16, хоть 30

Число неделимых операций зависит главным образом от структуры данных редактируемого меша, на которой остановится дядя Миша. Если там не будет поддержки проволочных рёбер без полигонов, то и того меньше.

Отправлено Дядя Миша 25-04-2022 в 13:36:

Цитата:

(_-=ZhekA=-_) писал:
Для всех или для избранных?

Для бета-тестеров.

Цитата:

(_-=ZhekA=-_) писал:
и использовать движок для архитектурной визуализации

Ксаш и позиционируется для тех, в ком жив дух старой школы.
Архитектурная визуализация в мои задачи не входит.

Цитата:

FiEctro писал:
Посмотри кстати эту штуку. Для интерфейсов.

Видел уже.

Цитата:

nemyax писал:
Если там не будет поддержки проволочных рёбер без полигонов

А на кой эти рёбра нужны?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 25-04-2022 в 13:39:

Цитата:

Дядя Миша писал:
А на кой эти рёбра нужны?

Для твоих задач совершенно ни на кой. А в том же блендере например есть смысл их иметь для разных приёмчиков.

Отправлено FiEctro 25-04-2022 в 13:59:

Цитата:

nemyax писал:
Если в моделилке реализованы extrude, connect, dissolve, collapse, bridge и bevel, то ты готов хоть к неанимированному хряку, хоть к кабине вертолёта в кратчайшие сроки.

Как правило "ограниченный инструмент" и "кратчайшие сроки" понятия взаимоисключающие. Вот только неанимированных хряков и делать.

Цитата:

Дядя Миша писал:
А на кой эти рёбра нужны?

Можно например путь сделать и по индексам вертексов пустить вагончик.

Отправлено nemyax 26-04-2022 в 05:14:

Цитата:

FiEctro писал:
Можно например путь сделать и по индексам вертексов пустить вагончик.

Тут логичнее реализовать сплайны, чтобы оно гарантированно не ветвилось.

Отправлено FiEctro 26-04-2022 в 05:53:

Цитата:

nemyax писал:
Тут логичнее реализовать сплайны, чтобы оно гарантированно не ветвилось.

Дык сплайны можно конвертить в геометрию

Отправлено Дядя Миша 26-04-2022 в 05:55:

Использовать реальную геометрию для путей, это какой-то гнилой способ.
Это же и навмешей касается. Вон в Метро Эксодус бандюки по воздуху бегали. Потому что в этом воздухе висел навмеш.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 26-04-2022 в 09:02:

Цитата:

Дядя Миша писал:
Использовать реальную геометрию для путей, это какой-то гнилой способ.

Зато гибкий, не спамит объектами, работает намного шустрее обычных кривых и в реалтайме, а так же ты всегда уверен что он не отвалится в нужный момент. Звучит как костыль, но приемущество перед другими методами налицо. Самое сложное это понять как собрать индексы в нужном порядке. Делается это очень легко, но сам метод не очень очевидный.

Цитата:

Дядя Миша писал:
Это же и навмешей касается. Вон в Метро Эксодус бандюки по воздуху бегали. Потому что в этом воздухе висел навмеш.

Это косяк маппера, который забыл пересобрать навмеш для новой геометрии.

Отправлено Дядя Миша 26-04-2022 в 09:27:

FiEctro то что ты описал вполне могут быть недостатки конкретных реализаций. Но я пока не составил по этому поводу своего мнения, так что спорить не буду.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 26-04-2022 в 09:33:

В уе хорошо, там волюмы, поставил один на всю карту и вася кот )))

Отправлено Дикс 26-04-2022 в 12:05:

Многие иностранцы пилят карты для ку1-ку2 в тренчбрум. В его сторону тоже стоит смотреть. Хотя бы потому, что там подход как в УЕ - все можно делать не покидая 3д-окна.

__________________
igroprom.d3.ru

Отправлено Дядя Миша 26-04-2022 в 12:15:

Ну я надеюсь вы понимаете, что в 3д окне очень важны всякие прилипалки геометрии друг к другу, поскольку там целиться неудобно.
Но я это тоже планирую сделать. Это очень удобная фишка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 26-04-2022 в 12:51:

Цитата:

Дядя Миша писал:
Ну я надеюсь вы понимаете, что в 3д окне очень важны всякие прилипалки геометрии друг к другу, поскольку там целиться неудобно.

Кстати их же ни в одном редакторе нет, так? Я не видел по крайней мере. А вот в видеоредакторах они везде.

Отправлено nemyax 26-04-2022 в 12:59:

Цитата:

Crystallize писал:
Кстати их же ни в одном редакторе нет, так?

Везде есть.

Отправлено FiEctro 26-04-2022 в 13:51:

Цитата:

Дядя Миша писал:
Ну я надеюсь вы понимаете, что в 3д окне очень важны всякие прилипалки геометрии друг к другу, поскольку там целиться неудобно.
Но я это тоже планирую сделать. Это очень удобная фишка.

Еще если можно, возможность прилипания по нормали к поверхности.

Цитата:

Дикс писал:
Многие иностранцы пилят карты для ку1-ку2 в тренчбрум. В его сторону тоже стоит смотреть. Хотя бы потому, что там подход как в УЕ - все можно делать не покидая 3д-окна.

Никогда не слышал, но по трейлеру мне понравилось.

Дядя Миша
Твой редактор не будет привередлив к тому что вертексы брашей лежат не в 1 плоскости и сможет добавлять недостающие ребра сам?

Отправлено Crystallize 26-04-2022 в 17:37:

Цитата:

nemyax писал:
Везде есть.

Я видел только прилипание к сетке. Прилипание браша к браша не видел нигде. Все хотел попросить у Ксерокс фича в джек но не был уверен что надо.

Отправлено nemyax 26-04-2022 в 18:09:

Crystallize
Ну я про триде-редакторы.

Отправлено Дикс 26-04-2022 в 22:01:

К слову о прилипании, в УЕ даже хоткей есть, который позволяет "уронить" какой-нибудь условный ящик на условный пол.

__________________
igroprom.d3.ru

Отправлено XaeroX 27-04-2022 в 00:15:

Цитата:

Crystallize писал:
Все хотел попросить у Ксерокс фича в джек но не был уверен что надо.

Вполне возможно, что через несколько лет (ну на пенсии, надеюсь, точно) я смогу вернуться и к разработке волатилы, и игры (OI), и джека. И вполне может быть, что реализую наконец какое-то подобие редактирования в 3д, с прилипаниями и прочим.
Если честно - до сих пор удивляюсь, сколько же всего мне удалось наворотить, пока жил в относительно "тепличных" условиях Новосибирска, с вагоном свободного времени. Но ещё больше так и осталось на уровне задумок и планов.

__________________

Отправлено FiEctro 27-04-2022 в 07:18:

Цитата:

XaeroX писал:
Если честно - до сих пор удивляюсь, сколько же всего мне удалось наворотить, пока жил в относительно "тепличных" условиях Новосибирска, с вагоном свободного времени. Но ещё больше так и осталось на уровне задумок и планов.

Стареем

Отправлено Дядя Миша 27-04-2022 в 07:37:

Пришлось пока что остановить работу над редактором и заняться бакэндом.
А точнее - платформозависимым слоем абстракции. Поскольку движок изначально базировался на коде от Кармака, вы знаете, как там с этим обстоят дела - мультиплатформенность гарантируется только для самого движка, а вот утилиты и особенно редактор - ну как повезёт.
К тому же утилиты использовали собственную файловую систему, упрощённую. Пока я долгое время тешил себя надеждой, что можно будет обойтись сторонним редактором, это всё худо-бедно работало.
Но с учётом новой концепции, это будет единая среда, в которой каждый компонент может запускать другой. Движок из редактора, редактор из движка, утилиты. Неплохо бы предусмотреть гибкий механизм, который позволяет это сделать. Какие-то зачатки были еще в старом ксаше, там как вы помните, движок умел перезапускать сам себя, через хитрозакрученную систему каллбэков, но это не слишком надёжно.
Сейчас я выработал новый принцип для этого дела. Есть некая структурка, которая содержит в себе:
1. путь до загружаемой библиотеки
2. название инстанции (движок, редактор, дедикатед-сервер, компилятор)
3. строку командных параметров

Эта структурка заполняется внутри .exe файла. И передаётся внутрь дллки, которая будет вызвана. Дальше дллка может по собственному усмотрению записать туда новый путь к дллке, новую инстанцию и изменить командную строку. И при выходе из экспортной функции, соответственно, вернуть 0 - завершение работы. Или 1 - рестарт.
А сам вызов этой экспортной функции из дллки оформлен в цикле.
Точнее говоря, не просто функции, а загрузки библиотеки, вызова функции и выгрузки библиотеки. Т.е. мы можем подключать любые части движка по необходимости, минуя классический вызов экзешников с командной строкой, поскольку возникают сложности, с выводом в консоль, например при таком подходе. Там какие-то трубы надо городить.
Опять же смену игровой директории через этот механизм можно делать.

Вторая задача - абстракция платформозависимого кода, вынос его в отдельный класс, не только для движка, а для всей среды. Это будет нечто вроде SDL (для понимания), но для более широкого спектра задач и заточенное именно под XashNT.

Например в любом приложении будет доступна консоль с виндовым окошком, а не только системная.

Отдельно скажу по DLL Hell. В новом ксаше я принял за правило, что ни одно из приложений входящих в среду не может вызвать более одной дллки. Иначе получится натуральный DLL Hell. Т.е. всегда будет работать схема: exe->dll. А дллка будет содержать в себе абсолютно всё необходимое для работы. Конечно она может вызывать еще какие-то дллки, но только системные из папки windows. То есть в такой дллке будет целиком оформлена подсистема движка, но на уровне понятном пользователю. Библиотека - редактор, библиотека - движок, библиотека - компилятор уровней. То что, с точки зрения пользователя делает какое-то завершенное действие. А вот подход, когда у нас в этой библиотеке tier0, tier1, FileSystem, ParticleMan и прочее - такого не будет. Потому что неизбежно получится каша из разных версией с несовпадающими интерфейсами и работать ничего не будет.
Мое допущение заключается в том, что абсолютно у всех библиотек будет единая точка входа, с интерфейсом, описанным в начале этого поста.
И этот интерфейс никогда меняться не будет.

Из любопытного: теперь настройки для конкретного экзешника будут задаваться в командной строке, в которую экзешник будет автоматически добавлять параметры - вот в ту самую структурку. Таким образом пользователи смогут тоже вручную это контролировать в некоторых ситуациях. Довольно гибкий подход получится, я думаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 27-04-2022 в 07:52:

XaeroX
У тебя уже есть полностью рабочий двиг для него рабочий редактор, что еще для жизни надо?!

Дядя Миша
Если не секрет, то сколько часов в день ты тратишь на свой двиг и все необходимое для него?

Отправлено FiEctro 27-04-2022 в 08:06:

>> Отдельно скажу по DLL Hell. В новом ксаше я принял за правило, что ни одно из приложений входящих в среду не может вызвать более одной дллки.

Ну можно процесс иницилизации вынести в GameInfo.txt А сами дллки хранить в папках игры или мода, с подписью версии движка. Ну и создать папку base с базовыми библиотеками, на случай если в папке мода вообще ничего нет. В общем всё уже валва придумала за нас.

Отправлено Дядя Миша 27-04-2022 в 08:12:

Цитата:

(_-=ZhekA=-_) писал:
Если не секрет, то сколько часов в день ты тратишь на свой двиг и все необходимое для него?

По-разному. Иногда по 6-8 часов в день, иногда вообще нет на это времени.
Еще бывают творческие отпуска, когда я целый месяц к коду не притрагиваюсь.

Цитата:

FiEctro писал:
Ну и создать папку base с базовыми библиотеками

Папка base есть, для 32-х битной версии называется bin_x86, ну ты видел.
Но дллок в игровой папке скорее всего не будет, там теперь будут файлы виртуальной машины. А дллки - только в базовой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 27-04-2022 в 08:19:

Цитата:

Дядя Миша писал:
По-разному. Иногда по 6-8 часов в день, иногда вообще нет на это времени.

А как же работа, если ты тратишь почти целый день на это? Если я правильно понимаю, то двиг для тебя сейчас, как хобби, который пока доход не приносит, так?

Цитата:

Дядя Миша писал:
Еще бывают творческие отпуска, когда я целый месяц к коду не притрагиваюсь.

Такое кстати у меня тоже бывает...

Отправлено Дядя Миша 27-04-2022 в 10:09:

Цитата:

(_-=ZhekA=-_) писал:
А как же работа, если ты тратишь почти целый день на это?

Ну так я прямо на работе его и пишу, если её нет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 27-04-2022 в 13:55:

Цитата:

Дядя Миша писал:
По-разному. Иногда по 6-8 часов в день, иногда вообще нет на это времени.
Еще бывают творческие отпуска, когда я целый месяц к коду не притрагиваюсь.

Это похвально, я бы за такой период уже бы давно выгорел. Интересно как ты боришься с выгоранием?

Отправлено XaeroX 27-04-2022 в 15:18:

Цитата:

(_-=ZhekA=-_) писал:
А как же работа, если ты тратишь почти целый день на это?

Работа разная бывает. Сравнивая Россию с Канадой, мне кажется, что в России можно получать относительно неплохие деньги, не особо напрягаясь. У меня даже в Яндексе оставалась куча времени на волатилу.

Тем временем, в Северной Америке в ходу вот такие грустные шутки:

Перевод:
"Отлучился с работы в Европе: я уехал путешествовать на всё лето, напишите емейл в сентябре.
Отлучился с работы в Америке: я покинул офис на два часа ради операции на почке, но вы всегда можете связаться со мной по мобильному телефону."

Так и живём!

А вы говорите - "где апдейты, где сдк волатилы, где джек"...

__________________

Отправлено Дядя Миша 27-04-2022 в 15:27:

Цитата:

FiEctro писал:
Интересно как ты боришься с выгоранием?

Сменой деятельности же. Занимаюсь основной работой.

Цитата:

XaeroX писал:
я покинул офис на два часа ради операции на почке

Это чертовски долго, целых два часа на почку. Тут на две почки хватит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 27-04-2022 в 15:31:

Цитата:

Дядя Миша писал:
Это чертовски долго, целых два часа на почку. Тут на две почки хватит.

Да. Я думаю, у менеджера к этому товарищу будут серьёзные вопросы во время перфоманс-ревью.

__________________

Отправлено Дядя Миша 27-04-2022 в 15:53:

Да, если бы я только за компьютером сидел и код писал, уже давно бы выгорел. Но у меня тут ручная работа, кофемашины жы.
Так что нормально получается в целом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 28-04-2022 в 05:50:

Предидущий пост на эту тему: https://hlfx.ru/forum/showthread.ph...&pagenumber=116

Из того что тогда предстояло финализировать, отпишусь по готовности.

1. единый формат хранения геометрии успешно финализирован. Возможно я к нему так же приведу шрифты, для пущей консистентности. DONE

2. компилятор освещения успешно финализирован и радиосити прикручен. DONE

3. Код рендерера с момента того поста практически не менялся. UNDONE

4. Колоизация сделана. Симуляция твёрдых тел еще нет. Partially DONE

5. Момент продуман, сама виртуальная машина уже написана, но пользовательская часть еще не создана. Partially DONE

6. Код сети с момента того поста практически не менялся. UNDONE

7. Просмотровщик в планах, он поделит код вместе с редактором, так что по сути оба появтся одновременно. UNDONE

8. Как раз над редактором я сейчас и работаю. Но я только начал, по сути. UNDONE.

Интересно, как теперь подсчитать процент готовности движка?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 28-04-2022 в 06:12:

Цитата:

Дядя Миша писал:
Интересно, как теперь подсчитать процент готовности движка?

Собрать все-все хотелки\фичи в один пост и сделать подсчет, что в итоге готово, а что еще нет или чего вообще не будет, как-то так )

Отправлено XaeroX 28-04-2022 в 06:13:

Цитата:

Дядя Миша писал:
UNDONE

Кстати, мне всегда казалось, что UNDONE - это когда ты что-то сделал, потом понял, что получилась ерунда, удалил весь написанный код и написал комментарий - "UNDONE: xxx".

__________________

Отправлено nemyax 28-04-2022 в 08:00:

Да, undone - разломато, загублено.

Отправлено Дядя Миша 28-04-2022 в 12:00:

UNDONE - недоделато, я так всегда понимал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 28-04-2022 в 12:13:

Недоделато — incomplete, unfinished.

Отправлено Дядя Миша 28-04-2022 в 12:24:

Вобще я всегда нелюбил это слово, поэтому в каментах к коду использую только
TODO и FIXME. Ну еще иногда HACKHACK и TESTTEST

Кстати товарищи, вот вам от меня небольшой лайфхак. Ни для кого не секрет что очень многие начинающие программисты бояться работать с памятью, с указателями, поскольку программа вылетает. Но дело не в том, что она программа вылетает. Дело в том, какой звук она при этом издаёт!
Стандартный виндовый звук ошибки даже подготовленного человека заставляет наложить фштаны, или спровоцировать энурез, понятно.
Поэтому мой вам совет - идёте в звуковые схемы и там на звук ошибки ставите что-то более нейтральное, например "Звездочка.wav". И Вася-кот!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дикс 28-04-2022 в 22:49:

Цитата:

Дядя Миша писал:
Предидущий пост на эту тему: https://hlfx.ru/forum/showthread.ph...&pagenumber=116

Интересно, как теперь подсчитать процент готовности движка?

1. 12.5%
2. 12.5%
3. 0%
4. 6.25%
5. 6.25%
6. 0%
7. 0%
8. 0%

12.5+12.5+6.25+6.25 = 37.5%

__________________
igroprom.d3.ru

Отправлено Дядя Миша 29-04-2022 в 18:07:

Вопросы про авто-нумерацию билда вынес в отдельную тему:
https://hlfx.ru/forum/showthread.php?s=&threadid=5834

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 05-05-2022 в 16:36:

Цитата:

Дядя Миша писал:
я не хотел делать редактор, поскольку он ожидаемо был бы похож на QuArK

Тебе задонатить надо или что? Иметь такой же Кварк но без кучи детских болезней сводящих половину фич на нет, было бы довольно круто.
Например дупликатор путей крут но не поддерживает симлесс-текстурирование, не поддерживает развилки, и не дружит с негативными брашами (на поворотах тоннеля возникают сверхтонкие стенки ), не умеет резать внутренней поверхностью текущего сегмента предыдущий и последующий, из-за чего на резких поворотах в тоннеле возникает этакая "слоновья нога".
При широком использовании путей и негативных брашей простое выделение браша занимает 30 секунд на той же карте с тоннелями.

Отправлено Дядя Миша 05-05-2022 в 17:00:

Crystallize ты как-то тему невнимательно читал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 06-05-2022 в 07:02:

Знаете, пожалуй, что самое сложное при написании компилятора программ?
Неважно настояшего или виртуальной машинки, потому что между ними разница только в том, какие опкоды этот компилятор генерирует - для процессора или виртуальные. Так вот самое сложное в том - чтобы отследить все пользовательские ошибки и выдать сообщение.
В отличие от всех остальных типов компиляторов, ну например уровней или моделей, да чего угодно, где наоборот приветствуется выдача предупреждения и нормальное продолжение работы, здесь надо ругаться на каждую мелочь. Потому что потом программа запустится и вы уже не поймете что получилось. А компилятору в целом пофигу, пока ему не сделаешь явный вызов ошибки, он будет собирать любую дичь абсолютно.
Можно например в структуре сделать кучу переменных с одинаковыми именами, компилятор будет просто каждый раз обращаться к первой.
Технически здесь нет никакой ошибки. Но для юзера - есть.

Добавлено 06-05-2022 в 10:02:

Я вам характерный примерчег приведу.
Я уже упоминал, что при инициализации членов класса можно через двоеточие задавать кол-во бит, которые будут использоваться не для выравнивания структуры, как в настоящем языке, а как подсказка для сейв-рестора и передачи по сети. Выглядит это вот так, ну вы знаете:

C++ Source Code:

1	class CBaseEntity

3	string m_targetname : 16;

4	float m_health : 10;

5	unsigned int m_skin : 8;

};

Имена тут просто для примера, для наглядности.
А вот как выглядит код, который это парсит:

C++ Source Code:

1	if( CheckToken( ":" ))

3	if( m_immediateType != type_integer )

4	m_lexer.Error( LEX_CONSTANT_EXP_NOT_INTEGRAL, "constant expression is not integral" );

5	else bits = m_immediate.integer;

7	if( bits == 0 ) m_lexer.Error( BIT_FIELD_ZERO_COUNT, "'%s' : named bit field cannot have zero width", name );

8	else if( bits < 0 \|\| bits > 32 )

9	m_lexer.Error( BIT_FIELD_INVALID_COUNT, "'%s' : type of bit field too small for number of bits", name );

10	if( type->Type() != ev_integer && type->Type() != ev_float && type->Type() != ev_string )

11	m_lexer.Error( BIT_FIELD_INVALID_TYPE, "'%s' : bit field must have type 'int', 'float', or 'string'", name );

12	def->bits = bound( 1, bits, 32 );

13	NextToken();

Тут вызовов с ошибками больше, чем кода, который сохраняет значение в def. К тому же, например, если компилятор уровней даже на что-то ругается, он может это делать скрытно. Пока не пропишешь в командной строке параметр -dev или -debug, все эти сообщения не будут видны.
В компиляторе исходных текстов ошибки отключать нельзя в принципе.
Но как вы знаете можно сделать наоборот - превратить предупреждения в ошибки. Абсолютно разные концепции.
Ну оно и понятно. Карта соберётся с косяками и вы на них полюбуетесь в реальном времени. А если с программой начнёт происходить какая-то чертовщина, вы очень долго будете разбираться что сделали не так.
Если компилятор вам в этом не поможет. К слову сказать, в 60-е, 70-е годы, компиляторы почти ничего не находили. Иногда это приводило к срыву космических программ, например.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-05-2022 в 07:09:

Дядя Миша
А разве нет уже готовых решений? Зачем изобретать велосипеды?

Отправлено Дядя Миша 06-05-2022 в 07:34:

Готовые решения, в лучшем случае code-driven к тому же внутренние методы спрятаны от пользователя и находятся только в документации.
Для того чтобы вызвать какой-нибудь косинус в яве ты не можешь заглянуть в хидер. Либо лезть в документацию, либо помнить наезусть, либо надеяться, что тебе студия вывалит подсказку. Всё это очень неудобно.
Я пишу data-driven машинку, т.к. это общая концепция XashNT.

Добавлено 06-05-2022 в 10:30:

Поясню на примере. Когда у тебя в коде виртуальной машины есть хидеры со списком всех доступных системных, функций, ты уже можешь прикидывать что тебе понадобится для реализации. А не листать многостраничную документацию или вообще с размаху налететь на стену, узнав что такого метода просто нет, но в следующей версии появится обязательно.

Добавлено 06-05-2022 в 10:34:

Для мапперов очень хороший пример приведу. Энтити, которые есть в игре вам не видны. Вы можете только прописать их в FGD, причём FGD и реальные энтити никак не связаны. Вы можете прописать туда несуществующую энтить или наоборот - забыть прописать то, что есть.
Вот с этими виртуалками, у которых системные методы нигде не задекларированы точно такая же ситуация. Очень неудобно это.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-05-2022 в 07:43:

Цитата:

Дядя Миша писал:
Когда у тебя в коде виртуальной машины есть хидеры со списком всех доступных системных, функций, ты уже можешь прикидывать что тебе понадобится для реализации.

И как юзер будет в этом разбираться? В той же студии есть подсказки с кратким описанием методов, и что куда им скармливать.

Отправлено Дядя Миша 06-05-2022 в 09:17:

Сегодня товарищи, знаментальный день. Я набиваю для виртуального языка системные функции, ну что-то вроде CRT. И дело дошло до функции Q_timestamp. И тут я вспомнил! Эта функция была мною написана в апреле 2007-го года (первые опыты с написанием движка начались в феравле 2007-го). Так вот я её написал, чтобы в лог сохранять дату когда движок был запущен и соответственно остановлен.
Эта функция пережила старый ксаш (ну который несовместимый ни с чем), переехала в Xash3D и оттуда разумеется попала в FWGS, затем она так же без изменений попала в XashNT и вот я делаю её частью стандарта будущего скриптового языка. И теперь миллионы людей по всему миру её увидят и будут ей пользоваться. А-ФИ-ГЕТЬ. Знал бы я какая судьба будет у этой функции, когда я её писал в апреле 2007-го года, я бы удивился и неповерил.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 12-05-2022 в 23:12:

Пишу конвертор Delphi -> C++. Для того чтобы изучать исходники QuArK, естественно. Мне проще написать конвертор, чем забивать голову этим ублюдошным синтаксисом.
Интересно, будет ли такой конвертор нужен кому-то еще кроме меня?

Добавлено 13-05-2022 в 02:12:

Делфи изумительный язык. Мало того что его компилятор по сути стейт-машина, так в язык намеренно введены конструкции чтобы программист выполнял половину работы за компилятор.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 14-05-2022 в 00:38:

Цитата:

Дядя Миша писал:
Делфи изумительный язык. Мало того что его компилятор по сути стейт-машина, так в язык намеренно введены конструкции чтобы программист выполнял половину работы за компилятор.

я когда на нём писал плагины под CS 1.6 на сервак, который мы с другом держали на взломанном компе из Малайзии, помню всё время мне казалось, что это скриптовый язык какой-то, а ещё там была какая-то дурацкая фича, что сначала нужно было создать основную форму, а потом уже код писать, причём эта форма нигде даже не использовалась. Delphi7 кажись был Ж)

Добавлено 14-05-2022 в 03:38:

Цитата:

Дядя Миша писал:
Мне проще написать конвертор, чем забивать голову этим ублюдошным синтаксисом.

А конвертор пардон из чего конвертирует?

__________________
-Brain is dead-

Отправлено Дядя Миша 14-05-2022 в 07:55:

Из Delphi в С++.

Добавлено 14-05-2022 в 10:55:

Больше всего я боюсь, что пока буду писать конвертор - выучу сам Delphi.
Нахрен бы мне он нужен.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено AntiPlayer 14-05-2022 в 20:45:

Дядя Миша
Помнится, когда я активно использовал C++ Builder, то сидел на каком-то программистском форума в разделе посвящённому вышеназванной ide. Так вот добрая треть тредов там была с просьбами перевести код из дельфи в C++.

Как вообще такой конвертер будет работать? Он выдаст рабочий код или просто сделает код более читабельным (для знающих С) ?

__________________
I tell you to enjoy life

Отправлено Дядя Миша 14-05-2022 в 22:00:

Утром я наивно полагал, что можно сконвертить 1 в 1 и прям будет работать
Сейчас я уже в этом так не уверен, да и лично для меня это неприоритетная задача, чтобы прям доводить конвертор до идеала.
Скорее всего он будет работать лучше всех существующих аналогов, но и только. Да я его вам выложу, потестируете.

Добавлено 15-05-2022 в 00:59:

Цитата:

AntiPlayer писал:
Он выдаст рабочий код

В идеале он должен выдавать рабочий код, да.
Через пару дней станет понятно что получится из этой затеи.
Тут еще вот какая штука - если это скажем какой-то хардкор, переведённый на Делфи, ну типа ZIP-архиватора, скорее всего там будет чёто мусорное.
А если классы самих пользователей, то думаю получится вполне рабочий код, т.к. на делфях обычно ничо сложнова не пишут.

Добавлено 15-05-2022 в 01:00:

Впрочем, если я не могу гарантировать стопроцентную конвертацию, мне же никто не мешает вписать туда камент, типа // verify this!
чтобы пограммист был внимательнее. Думаю это оптимальный подход.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено AntiPlayer 16-05-2022 в 09:02:

Цитата:

Дядя Миша писал:
В идеале он должен выдавать рабочий код, да.
Через пару дней станет понятно что получится из этой затеи.

Очень интересно, что выйдет из этого. На сколько я помню код в делфи очень сильно связан с их IDE и библиотеками

__________________
I tell you to enjoy life

Отправлено FiEctro 16-05-2022 в 10:51:

Цитата:

Дядя Миша писал:
Больше всего я боюсь, что пока буду писать конвертор - выучу сам Delphi.
Нахрен бы мне он нужен.

Глубина вопроса куда больше, зачем вообще изучать сорцы Кварка? Это же давным давно устаревшее гамно мамонта. Что в нём такого особенного? И насколько будет стабилен такой сконвертированный код?

Отправлено Дикс 16-05-2022 в 11:06:

Цитата:

FiEctro писал:
Глубина вопроса куда больше, зачем вообще изучать сорцы Кварка? Это же давным давно устаревшее гамно мамонта. Что в нём такого особенного? И насколько будет стабилен такой сконвертированный код?

Речь не об изучении, а о переносе интерфейса с минимальными усилиями. С тем, чтобы получить базовую версию редактора как можно быстрее.

__________________
igroprom.d3.ru

Отправлено FiEctro 16-05-2022 в 11:24:

Цитата:

Дикс писал:
Речь не об изучении, а о переносе интерфейса с минимальными усилиями.

Уж чего чего, а интерфейс в кварке это одна сплошная большая ошибка, ничего кроме рвотных позывов он не вызывает, хотя конечно там и есть некоторые элементы реализованные лучше чем в хаммере, но в целом это не эноргомичный шлак. Лучше бы из КаФу какого нить взяли, там он и на крестах вроде как.

https://a.fsdn.com/con/app/proj/quark/screenshots/21870.jpg/max/max/1

https://www.heise.de/download/media/cafu-engine-ca3d-engine-52207/cafu-engine-ca3d-engine-1_1-1-9.jpg

Отправлено Дядя Миша 16-05-2022 в 11:50:

FiEctro в кварке самое ценное - инспектор объектов и компас.
А кол-во окон может быть любым.

Добавлено 16-05-2022 в 14:48:

И да, начиная с версии 6.4 интерфейс основательно испортили, но к счастью он находится на прилипающих панелях, которые можно выдернуть и закрыть. Правда народ настолько привык что поменять ничего нельзя, что даже не подозревает об етом

Добавлено 16-05-2022 в 14:50:

Цитата:

FiEctro писал:
Лучше бы из КаФу какого нить взяли, там он и на крестах вроде как.

Ты видел как делаются окна на крестах? Причём неважно используется ли там Qt\wxWidgets\MFC? Это тихий ужос, миллион однотипных строчек на создание окошек и ловлю каллбэков. Оно не поддерживаемое по сути.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 16-05-2022 в 14:27:

Цитата:

FiEctro писал:
Это же давным давно устаревшее гамно мамонта.

Ок побуду Ксероксом: устаревшее в каком плане? Коммиты идут до сих пор.

Цитата:

FiEctro писал:
Уж чего чего, а интерфейс в кварке это одна сплошная большая ошибка, ничего кроме рвотных позывов он не вызывает

Ну допустим на твоих скриншотах именно в Кварке легче понять что происходит. А на россыпь иконок не смотри, они отключаются. И то, может я просто их не раскушал ещё. А когда раскушаю, наверняка снова поймаю несколько багов и побегу писать репорты.
Я вот так работаю:
https://alxgk.ru/uploader/img/27630...905b8407cc3.png
Но да, я бы текстурирование и создание шаров-цилиндров сделал как в Хаммере и ещё разобрал бы свалку в меню Command.

Цитата:

Дядя Миша писал:
FiEctro в кварке самое ценное - инспектор объектов и компас.

Мне компас пока не пригождался, я как-то не понял вообще его. В кварке в 3д-окне браши можно тягать по нормали к поверхности, с этим компас как бы уже и не нужен.

Цитата:

Дядя Миша писал:
И да, начиная с версии 6.4 интерфейс основательно испортили

Я юзал и 6.3 тоже, у меня не было ощущения что классная версия на которой мне хочется остаться. Если тебе кажется что она была более работоспособной то возможно это потому что ты не юзал модификаторы, там багов хватало. При чём в этой версии ошибка не вызывает эррора, просто допустим нажатие на кнопку не даёт эффекта. Поэтому может казаться что багов меньше.

Отправлено XaeroX 16-05-2022 в 14:43:

В Кварке меня в своё время поразило, что для того, чтобы что-то сделать с брашем, надо непременно найти его в иерархическом списке, с именем East Wall 1643, ну или скажем South Wall 998. Если не знаешь названия браша - то извините, надо было за-пони-нать!
А что касается компаса, он меня тоже поразил. Думаю, надо же, такой уродский интерфейс и в нём такой красивый компас. Поэтому я на всякий случай решил его не трогать.

Добавлено 16-05-2022 в 10:43:

Цитата:

Дядя Миша писал:
И да, начиная с версии 6.4 интерфейс основательно испортили

Не помню, какая именно версия была у меня - помню лишь, что она была в 2001 году на диске Игромании, и поддерживала Hired Team: Trial (тут Дядя Миша по традиции должен спросить, что это такое). А ещё для установки редактора надо было сначала поставить питон. В дистрибутив редактора он не входил, но к счастью, его тоже положили на диск журнала.

__________________

Отправлено Crystallize 16-05-2022 в 16:00:

XaeroX пятерка наверное, совсем древняя. 4 была в 1998, 6 в 2003

Добавлено 16-05-2022 в 23:00:

Цитата:

XaeroX писал:
В Кварке меня в своё время поразило, что для того, чтобы что-то сделать с брашем, надо непременно найти его в иерархическом списке, с именем East Wall 1643, ну или скажем South Wall 998. Если не знаешь названия браша - то извините, надо было за-пони-нать!

в 6 и далее браши выбираются в проекциях и 3д окне как в хаммере. а если надрачивать в 2д клик в одном месте то будет цикл брашей по глубине.

Отправлено FiEctro 16-05-2022 в 17:02:

Цитата:

Crystallize писал:
Я вот так работаю:
https://alxgk.ru/uploader/img/27630...905b8407cc3.png

Тебе самому этот треш нравится?

Цитата:

Crystallize писал:
Ок побуду Ксероксом: устаревшее в каком плане? Коммиты идут до сих пор.

В плане вкуса и юзабилити. Он выглядит как какая то программа времен 95 винды, хотя по сути ей и является. Впрочем в чате ксаша как оказалось даже есть люди которые до сих пор моделят в милкшейпе. Так что не отрицаю что есть любители сладкого хлеба, которым может такое зайти.

Отправлено Crystallize 16-05-2022 в 17:44:

Цитата:

FiEctro писал:
Тебе самому этот треш нравится?

В целом да, разве что я путаюсь где какая ось.

Цитата:

FiEctro писал:
В плане вкуса и юзабилити. Он выглядит как какая то программа времен 95 винды, хотя по сути ей и является.

Он выглядит стильно, особенно та старая версия где окошко было в оттенках бурого. Мне не нравятся интерфейсы типа блендера где всё мелкое, круглое, и ярко раскрашенные элементы на темном фоне. Лгбт какое-то.

По юзабилити есть проблемы, я ведь так и не делал в Кварке чего-то похожего на нормальную карту. Неудобно летать, неудобно искать лики, неудобно серчить текстуры, неудобно текстурить и неудобно сделать даже цилиндр. Но я и не пытаюсь делать уровни по типу шутерных, больше какие-то заготовки.

Отправлено XaeroX 16-05-2022 в 18:26:

Цитата:

Crystallize писал:
Неудобно летать, неудобно искать лики, неудобно серчить текстуры, неудобно текстурить и неудобно сделать даже цилиндр.

Вот! "Неудобно" это слово, которое лучше всего характеризует кварк.
При этом я честно признаюсь: кварк это был первый редактор, который я пощупал. То есть меня нельзя упрекнуть в косности и потакании привычкам. После кварка я перешёл на UnrealEd - и это уже был просто праздник какой-то (не считая Ctrl+S, разумеется). Ну а потом - Worldcraft, это был вообще идеал редактора на тот момент. Собственно, он для меня таковым и оставался вплоть до появления Джека.

__________________

Отправлено FiEctro 16-05-2022 в 18:51:

Цитата:

Crystallize писал:
Неудобно летать, неудобно искать лики, неудобно серчить текстуры, неудобно текстурить и неудобно сделать даже цилиндр. Но я и не пытаюсь делать уровни по типу шутерных, больше какие-то заготовки.

Мыши плакали, кололись, но продолжали жрать кактус

Отправлено Ku2zoff 16-05-2022 в 19:16:

Цитата:

XaeroX писал:
"Неудобно" это слово, которое лучше всего характеризует кварк.

Я пробовал его пару раз. Почему-то хаммер я освоил с нуля (вообще с нуля, ни разу не работав ни в одном редакторе уровней или 3D редакторе) буквально за несколько часов, и уже смог кое-что кубать, подглядывая в декомпил. Правда, правильно строить карту без ликов и с освещением я научился где-то дня через три. А в кварке в первый раз не разобрался за два дня. Особенно выморозил иерархический список со всеми объектами: по-умолчанию ничего нормально выделить невозможно. Второй раз так же потратил два дня, так и не смог настроить редактор до вменяемого состояния, чтобы было удобно, и бросил. Были мысли к нему всё-таки вернуться, когда я поднабрался опыта, но к тому времени появился джек.

Отправлено Crystallize 16-05-2022 в 19:33:

FiEctro в маппинге есть остальные аспекты и их реализация мне нравится. Например когда я вижу вершину браша я не должен думать о том что по факту их там две на разной глубине и их нужно таскать отдельно.

Отправлено Дядя Миша 17-05-2022 в 07:10:

Цитата:

FiEctro писал:
Впрочем в чате ксаша как оказалось даже есть люди которые до сих пор моделят в милкшейпе.

Это где такой чат?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 17-05-2022 в 07:13:

Дядя Миша
В Дискорде и Вк, вроде как наш Метаморф держит

Цитата:

Crystallize писал:
FiEctro в маппинге есть остальные аспекты и их реализация мне нравится. Например когда я вижу вершину браша я не должен думать о том что по факту их там две на разной глубине и их нужно таскать отдельно.

В маппинге ты должен думать куда больше чем в моделинге.
1. Все вертексы грани браша должны лежать в одной плоскости
2. Все вертексы должны быть по сетке (желательно без плавающих точек), иначе это может привести к неочевидным ликам и корежению геометрии.
3. Думать о плоскостях внутри геометрии (по возможности покрывать их нуллом там где это имеет смысл).
4. Перемещать текстуры так чтобы они не ломали геометрию
5. Превращать часть геометрии в детайлы или фанк валлы чтобы они не били друг друга.

Короче одно сплошное задрачивание bsp/csg вместо творчества.

Единственное в хаммере что удобнее это покрывать браши текстурами, поскольку у каждого полигона там своя развертка. Но это в то же время и минус, приводит к швам на всяких полузакругленных и кривых поверхностях.

Отправлено Crystallize 17-05-2022 в 07:39:

FiEctro
У тебя какие-то совсем дремучие представления о маппинге
1. Кварк делает за меня
2. устарело лет на 10 и даже тогда для Кварка не было важно
3. устарело примерно так же
4. чисто эстетика
5. согласен

Отправлено FiEctro 17-05-2022 в 08:09:

Crystallize
Ну фиг знает. Я до сих пор вижу что народ спотыкается об эти грабли, даже на Джеке, хотя казалось...

Отправлено Дядя Миша 17-05-2022 в 08:48:

Во первых, боюсь вы невнимательно читали. Я не собираюсь реконструировать интерфейс кварка 1 в 1. Более того, я вообще не собираюсь, чтобы мой редактор был похож на Кварк.

Вот ссылка на итоги тестирования: https://hlfx.ru/forum/showthread.php?s=&threadid=5733

Чтобы не повторяться.

Добавлено 17-05-2022 в 11:34:

А во-вторых, все авторы редакторов упорно копируют друг за другом, из-за чего и складывается впечатление, что по другому не бывает.
Бывает. Просто этого еще никто не делал.

Добавлено 17-05-2022 в 11:48:

Чтобы не быть голословным - напомню про свой опыт создания модель-вьювера. Который по факту своего выхода разом заткнул за пояс всё, чтобы было сделано за 20 лет ранее. Безальтернативно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 17-05-2022 в 10:47:

Цитата:

FiEctro писал:
Ну фиг знает. Я до сих пор вижу что народ спотыкается об эти грабли, даже на Джеке, хотя казалось...

Ну так мы же видели что авторы того же Field Intensity признались что до сих пор компилят тулзами от китайца. Оттуда и глюки. Хотя да, результат тамошнего рада тулзы ДМ воссоздать не в состоянии.

Отправлено FiEctro 17-05-2022 в 11:01:

Цитата:

Дядя Миша писал:
Чтобы не быть голословным - напомню про свой опыт создания модель-вьювера. Который по факту своего выхода разом заткнул за пояс всё, чтобы было сделано за 20 лет ранее. Безальтернативно.

Да по сути это просто отреверснутая прога палеозойского периода, с некоторыми исправлениями и нововведениями. Но ничем координально она от Джедса не отличается. Всё тот же интерфейс, всё тот же функционал + немного доведена до ума. Даже до уровня вьюпорта 3д макса не дотягивает.

Отправлено Дядя Миша 17-05-2022 в 11:53:

Цитата:

Crystallize писал:
Хотя да, результат тамошнего рада тулзы ДМ воссоздать не в состоянии.

Я и не хотел, чтобы мои результаты были похожи на китайские, мне не нравится.

Цитата:

FiEctro писал:
Да по сути это просто отреверснутая прога палеозойского периода

Сорцы модельвьювера всегда были доступны. Какой еще реверс, что ты несёшь?

Цитата:

FiEctro писал:
Но ничем координально она от Джедса не отличается

Стесняюсь спросить, ты его вообще скачивал?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 17-05-2022 в 12:06:

Цитата:

Дядя Миша писал:
Сорцы модельвьювера всегда были доступны. Какой еще реверс, что ты несёшь?

Сорцы Джедс вроде как не открывал.

Цитата:

Дядя Миша писал:
Стесняюсь спросить, ты его вообще скачивал?

Да

Отправлено Дядя Миша 17-05-2022 в 12:11:

Цитата:

FiEctro писал:
Сорцы Джедс вроде как не открывал.

Так в Jeds нет ничего такого, что бы требовало реверса. Достаточно покликать в самой программе как пользователь, запомнить функционал и просто написать его заново.

Цитата:

FiEctro писал:
Да

Ну значит ты или чего-то не понимаешь, или намеренно передёргиваешь.
Может быть в твоём представлении, модельвьювер от меня должен был весить 100 мегабайт и иметь интерфейс как у Unreal Editor, тогда бы ты согласился, что он "лучше" всех остальных. Но поскольку ты с ним не работал, т.к. к тому момент уже перешёл на Unity\Unreal, то и сделал такие странные выводы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 18-05-2022 в 12:37:

Цитата:

Дядя Миша писал:
модельвьювер от меня должен был весить 100 мегабайт и иметь интерфейс как у Unreal Editor

Есть моделвьювер от Солокиллера, он весит 13 мегабайт. Выдаёт нестабильные 50-60 fps и имеет почти такой же функционал. Он привычнее пользователям джедса - в нём все элементы управления расположены во вкладках, нет никаких тайных хоткеев. Лично я сделал выбор в пользу быстродействия. Но на всякий случай храню у себя все вьюверы: Дядьмишин, Дядьмишин для кваки, HLMV 1.25, Jed's HLMV, Solokiller's HLMV, MD2 Viewer.

Отправлено Дядя Миша 18-05-2022 в 14:01:

Цитата:

Ku2zoff писал:
и имеет почти такой же функционал

Умеет грузить модели с развесовкой?
Умеет показывать цвета ремапа и менять цвет прямо во вьювере?
Поддерживает pose-params из Source?
Поддерживает инверсную кинематику из Source?
Есть встроенный редактор для аттачментов, хитбоксов и положения модели?
Умеет редактировать флаги спецэффектов (типа вращения, коллизии)?
Умеет переключаться на следующую модель стрелками влево\вправо?
Автоматически подгоняет увеличение и скорость навигации под размер модели?
Наконец умеет переваривать модели с сотнями тысяч полигонов?

Это так, навскидку.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 18-05-2022 в 15:17:

Цитата:

Дядя Миша писал:
Умеет грузить модели с развесовкой?

Мимо, голдсорс не поддерживает.

Цитата:

Дядя Миша писал:
Умеет показывать цвета ремапа и менять цвет прямо во вьювере?

Да.

Цитата:

Дядя Миша писал:
Поддерживает pose-params из Source?
Поддерживает инверсную кинематику из Source?

Мимо, голдсорс не поддерживает.

Цитата:

Дядя Миша писал:
Есть встроенный редактор для аттачментов, хитбоксов и положения модели?

Да. Огромным плюсом идёт редактор эвентов, которого в твоём вьювере нет.

Цитата:

Дядя Миша писал:
Умеет редактировать флаги спецэффектов (типа вращения, коллизии)?

Да.

Цитата:

Дядя Миша писал:
Умеет переключаться на следующую модель стрелками влево\вправо?

Да.

Цитата:

Дядя Миша писал:
Автоматически подгоняет увеличение и скорость навигации под размер модели?

Нет.

Цитата:

Дядя Миша писал:
Наконец умеет переваривать модели с сотнями тысяч полигонов?

Не знаю, лимиты не описаны. Возможно.

Если выкинуть ксаш-специфичные фичи, вьюверы равноценны. Разве что буржуйский умеет играть звуки и позволяет редактировать эвенты. Последнее - люто полезная штука, не знаю, почему ты её не сделал. Но я не использую буржуйский, у меня он подтормаживает.

В буржуйском не пропадает фокус с контролсов, если повертеть модель мышью. Маленький, но плюс.
Вообще, этот буржуйский вьювер уже неактуален. Автор выпустил новую утилиту: HLAM. Не то, что многие подумали, а Half-Life Asset Manager. Вроде бы функционал тот же самый. Одна странность: позволяет даже переименовывать кости, а вот менять активности у анимаций не позволяет - только пишет их название и номер.

Отправлено Дядя Миша 18-05-2022 в 18:25:

Цитата:

Ku2zoff писал:
Если выкинуть ксаш-специфичные фичи, вьюверы равноценны

На момент выхода моего вьювера тот ничего этого не умел даже и близко.
Ну раз научился - хорошо.

Цитата:

Ku2zoff писал:
Если выкинуть ксаш-специфичные фичи, вьюверы равноценны

Тянет на ложные слухи. Повторюсь, я написал только то, что первым в голову пришло. И уж конечно не тебе судить поддерживает голдсорс что-то там или не поддерживает. Вообще-то развесовку можно в клиентке подключить и в оригинальной халфе, используя мои форматы. Ты уж прямо скажи, тебе это не pozubam, вот и приходится говорить "мимо".

Добавлено 18-05-2022 в 21:25:

Цитата:

Ku2zoff писал:
вьюверы равноценны

Цитата:

Ku2zoff писал:
Но я не использую буржуйский, у меня он подтормаживает.

Вот с какой целью ты пытаешься мне что-то доказать и тут же сам себя опровергаешь?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 18-05-2022 в 19:00:

Цитата:

Дядя Миша писал:
Ты уж прямо скажи, тебе это не pozubam

А зачем мне развесовка? Это модели переделывать, настраивать веса, геморно и долго. В ксаше поддерживается, и хорошо. Может быть кто-то намоделит в своём проекте персов, у которых локти будут сгибаться не резко на 90 градусов, а сглаженно.

Цитата:

Дядя Миша писал:
не тебе судить поддерживает голдсорс что-то там или не поддерживает

Искаропки не поддерживает, ты сам написал, что надо кодить.

Цитата:

Дядя Миша писал:
с какой целью ты пытаешься мне что-то доказать

На ксаше сделана одна полноценная игра и пара интересных модов. Прочее в разработке или сдохло. Крутые моды выходят до сих пор именно на голдсорсе: Delta, Field Intensity, Echoes, Uplinked, Crowbar deep in the dead, Hunt the C-nt - это за последние 5 лет и самое запомнившееся. Я сравниваю вьюверы не как пользователь ксаша, а как пользователь голдсорса. Ксаш-специфичные фичи не аргумент в данном случае. Скорее всего, наши товарищи, делающие сейчас на ксаше свои работы не используют ничего, что требует переделывать модели.
Вот выйдет XashNT - ситуация будет другая, потому что форматы будут несовместимые, и просто так модельку из условного Сру от Страха в свою игру не своруешь.

Отправлено XaeroX 18-05-2022 в 19:23:

Цитата:

Ku2zoff писал:
А зачем мне развесовка? Это модели переделывать, настраивать веса

Чтобы выдирать модельки из игр на сорсе.

Цитата:

Ku2zoff писал:
Hunt the C-nt

Страшно представить, какой сюжет у мода с таким названием.

__________________

Отправлено Ku2zoff 18-05-2022 в 19:30:

Цитата:

XaeroX писал:
Страшно представить, какой сюжет у мода с таким названием.

Нормальный сюжет. Название неприличное, да. Я бы на месте автора такое слово не использовал. Что с буржуев взять? Я решил как-то поиграть в Крэк-Лайф, так бросил через двадцать минут из-за обилия ругательств, которыми даже заменены некоторые звуки, типа лазанья по лестницам. По сравнению с этим модом, наш Испытатель-4 очень культурный мод, несмотря на налогичную наркоманию.

Отправлено Дядя Миша 18-05-2022 в 19:38:

Цитата:

Ku2zoff писал:
Искаропки не поддерживает, ты сам написал, что надо кодить

На уровне SDK поддерживает, этого достаточно.

Цитата:

Ku2zoff писал:
Я сравниваю вьюверы не как пользователь ксаша, а как пользователь голдсорса

Т.е. для тебя наличие фичей, которые ты мог бы использовать - это минус?

Добавлено 18-05-2022 в 22:38:

Цитата:

Ku2zoff писал:
На ксаше сделана одна полноценная игра и пара интересных модов. Прочее в разработке или сдохло

А давай сравним сколько лет голдсорсу и сколько ксашу.
Особенно интересно слышать такие предъявы от человека, который сам не сделал вообще ничего. Вон даже шрифты допилить и то не может.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 18-05-2022 в 19:53:

Цитата:

Дядя Миша писал:
А давай сравним сколько лет голдсорсу и сколько ксашу.

Дык ксашу уже 10 лет. Это не показатель.

Цитата:

Дядя Миша писал:
Т.е. для тебя наличие фичей, которые ты мог бы использовать - это минус?

Я не говорил, что эти фичи минус. Кто-то сможет их использовать. Мне они без надобности, потому что я убедился на примере многих работ, что хороший мод можно сделать без них.
Я ксашем уже давно не пользуюсь по нескольким причинам. Одна из них то, что оригинал несовместим с модами на новом SDK, совместим только FWGS. А FWGS я ни в коем случае не хочу использовать как основной движок.

Цитата:

Дядя Миша писал:
от человека, который сам не сделал вообще ничего. Вон даже шрифты допилить и то не может

А что особенного я должен сделать? Не буду никого называть, но есть товарищи, которые сделали намного меньше моего. Пусть мои туторы мало кому нужны, но лично для меня это хороший опыт. Что касается завершённой работы в виде мода, всё продвигается очень лениво. А со шрифтами что-нибудь придумаю. У них с масштабированием под разрешения не всё так просто. Собсно, как и у спрайтов худа. Я давеча наткнулся на одну нехорошую вещь, которую упустил. Нужно тщательнее тестировать.

Отправлено Дядя Миша 19-05-2022 в 05:55:

Цитата:

Ku2zoff писал:
Дык ксашу уже 10 лет. Это не показатель.

Народ не может что-то делать, если всё меняется. Даже при обновлении XashXT с версии 0.6 до версии 0.81 было много жалоб.

Цитата:

Ku2zoff писал:
я убедился на примере многих работ, что хороший мод можно сделать без них.

Так ты уже мод 10 лет делаешь, это не показатель.

Где можно скачать этот обновлённый модельвьювер?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-05-2022 в 07:51:

Цитата:

Дядя Миша писал:
Ну значит ты или чего-то не понимаешь, или намеренно передёргиваешь.

У вас с Ксером какая то бинарная логика. Чуть что какая критика, сразу записываете меня во враги, будто я какие то козни строю. Отличный у тебя вьювер, спору нет. Но ничего радикально нового в нём нет, просто доведенный до ума классический вьювер и это тоже здорово. Я к тому что сам интерфейс этой проги немножечко застрял где то в начале 2000х, и функционал не дотягивает даже до браузерных вьюверов. Да чего говорить, вот твой параноя вьювер разве поддерживает "параноевский PBR"? Т.е. он как бы даже с самой параноей не до конца совместим. Или я просто не нашел где?

Отправлено Дядя Миша 19-05-2022 в 08:43:

Цитата:

FiEctro писал:
Чуть что какая критика, сразу записываете меня во враги

Между прочим, у нас страна все 30-е годы искала врагов народа, изрядно понаторела в этом и теперь абсолютно у всех пролетарское чутьё на такие вещи. И бдительность конечно тоже. Может ты конечно хочешь помочь, а может ты шпиён какой и хочешь нас наоборот отбросить назад в развитии?

Цитата:

FiEctro писал:
Но ничего радикально нового в нём нет, просто доведенный до ума классический вьювер и это тоже здорово

Мой вьювер отвечает на вопрос "чего хотел пользователь?". Пользователю не надо ничего "радикально нового", просто потому что на календаре 2022-й год. Ему надо чтобы было удобно и те возможности, которые он хотел (во вьювере в основном то, что у меня просили пользователи, а не моя отсебятина). Т.е. это не просто "возьму, да и сделаю". Он составлялся именно по многочисленным просьбам телезрителей. Но конечно не зная этого, понять невозможно. Вот и приходится рассуждать про "радикально новое".

Цитата:

FiEctro писал:
вот твой параноя вьювер разве поддерживает "параноевский PBR"?

Мне бы очевидно пришлось тащить во вьювер-полдвижка для этого дела, чего бы мне в данном случае совсем не хотелось, поскольку это всё же такой универсальный вьювер и для халфы тоже. Мне народ жаловался, что на интел-встройках тормозит MSAA. А теперь представь, если бы я туда еще и шейдеры встроил. Он бы у половины вообще не запустился.
Разумеется в NT вьювер будет устроен иначе. Но в данном случае мне пришлось выбирать оптимальный вариант исходя из условий и требований.

Добавлено 19-05-2022 в 11:34:

Запилил обзор на поделие СолоКиллера: https://hlfx.ru/forum/showthread.php?s=&postid=209279

Добавлено 19-05-2022 в 11:43:

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-05-2022 в 08:56:

Цитата:

Дядя Миша писал:
Этак мы договоримся, что и С++ устарел, он 83-го года выпуска, да и мы сами тоже устарели - нам ведь тут всем больше 20 лет, по меркам компьютерного мира, нас всех пора уже выбрасывать за борт корабля истории и объявлять deprecated.

Так давайте все тогда на Паскаль пересядем

Отправлено Дядя Миша 19-05-2022 в 09:09:

FiEctro А вот ты напрасно смеешься. Объект Паскаль - 86-го года, т.е. он новее чем С++

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 19-05-2022 в 09:30:

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

Отправлено Дядя Миша 19-05-2022 в 10:53:

Crystallize

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-05-2022 в 10:56:

Дядя Миша
Так ООП это новомодная и ненужная приблуда навязанная маркетингом. Люди всегда без ООП писали, а теперь видите ли.

Отправлено Дядя Миша 19-05-2022 в 10:58:

По смыслу ООП действительно нужен далеко не везде. Но там где нужен - там с ним действительно удобнее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 19-05-2022 в 11:52:

Цитата:

Дядя Миша писал:
Народ не может что-то делать, если всё меняется.

Ну вот то-то и оно. Народ ничего не делает на ксаше, народу не нужны ксаш специфичные фичи. Для пользователей халфы, кс и всех модов вьюверы равноценны.

Цитата:

Дядя Миша писал:
Так ты уже мод 10 лет делаешь, это не показатель.

Я никуда не тороплюсь. Это же хобби.

Отправлено Дядя Миша 19-05-2022 в 12:08:

Цитата:

Ku2zoff писал:
Народ ничего не делает на ксаше, народу не нужны ксаш специфичные фичи

Ты этому радуешься или очень хочешь чтоб так оно и было?
Когда ты понял, что сам никакой ксаш написать не сможешь, даже мод сделать, ты начал доказывать себя и почему-то мне, что всё это говно и не нужно, прямо как Мастер. Такой путь для само-успокоения.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-05-2022 в 12:43:

Цитата:

Ku2zoff писал:
Народ ничего не делает на ксаше, народу не нужны ксаш специфичные фичи.

Нужны, но инструментов для них не сделали. Думаю в NT с этим дело будет обстоять лучше.

Отправлено Дядя Миша 19-05-2022 в 12:48:

Цитата:

FiEctro писал:
Нужны, но инструментов для них не сделали

Сегодня какой-то волшебный день. То человек, который занят разработкой под халфу уверяет, что ксаш не нужен. То человек, который занят разработкой под Юнити, уверяет что ксаш нужен.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-05-2022 в 13:11:

Цитата:

Дядя Миша писал:
Сегодня какой-то волшебный день. То человек, который занят разработкой под халфу уверяет, что ксаш не нужен. То человек, который занят разработкой под Юнити, уверяет что ксаш нужен.

Народу нужен ксаш, но шоб он был комбайн как юнити.

Отправлено Ku2zoff 19-05-2022 в 13:18:

Цитата:

Дядя Миша писал:
Ты этому радуешься или очень хочешь чтоб так оно и было?

Ни то ни другое. Меня это немного печалит. Стабильный ксаш и более-менее стабильный ксашмод есть уже давно, но использует их мало народу. А те, кто используют, всё равно вставляют костыли. Signal Lost, например. Что мешало использовать ксаш-мод и 3d sky? Ничего. Дык там 3d небо по-старинке моделями сделано.

Цитата:

FiEctro писал:
инструментов для них не сделали

Инструменты, документация, а самое главное - пиар. Вон, тулзы солокиллера активно пиарятся (или пиарились) на форуме свенкоопа. И всякие разные studiomdl на геймбанане выложены. У многих до сих пор проблемы с установкой модов под оригинал ксаша, потому что копируют папку valve, а архив с графикой для меню вон-версии не распаковывают.

Цитата:

Дядя Миша писал:
ты начал доказывать себя и почему-то мне, что всё это говно и не нужно

Очевидно, что мало кому нужно, если до сих пор крупные моды выходят на голдсорсе. Скорее это ты доказываешь, что оно нужно, упоминая ксаш-специфичные фичи там, где о них речь не идёт:

Цитата:

FiEctro писал:
Да по сути это просто отреверснутая прога палеозойского периода, с некоторыми исправлениями и нововведениями. Но ничем координально она от Джедса не отличается. Всё тот же интерфейс, всё тот же функционал + немного доведена до ума.

С этого ведь всё началось, не так ли? С позиции простого пользователя отличий и правда мало. А что там оно внутри поддерживает (не нужное простому пользователю) - дело второе.
Может быть и правда со временем народ плотно пересядет на ксаш, как получилось с форками кваки. Боюсь, что нет, потому что голдсорс будут поддерживать в состоянии совместимости с новыми версиями винды ради сраной каэсочки. Если бы не баги с рендерером, я бы до сих пор гамал в ку1 и ку2 на оригинальных движках. У голдсорса таких багов нет.

Отправлено Дядя Миша 19-05-2022 в 13:27:

Цитата:

Ku2zoff писал:
Стабильный ксаш и более-менее стабильный ксашмод есть уже давно, но использует их мало народу.

А как ты определяешь сколько народу их использует?
И почему бы например не допустить, что это саморазвивающийся процесс.
Выходит игра, привлекает чье-то внимание и новых разработчиков, соответственно. На халфе ведь поначалу так же было. Сначала модов мало, а потом всё больше и больше.

Цитата:

Ku2zoff писал:
Очевидно, что мало кому нужно, если до сих пор крупные моды выходят на голдсорсе

И на параное будут моды делать. Там уже будет 100% отвязка от голдсорса.
Вопрос времени. Причём эти моддеры будут называть ксаш "движком паранои", как любители дедаста называют голдсорс движком CS.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 19-05-2022 в 13:32:

Цитата:

Дядя Миша писал:
Когда ты понял, что сам никакой ксаш написать не сможешь, даже мод сделать

Я ещё раз повторяю: я никуда не тороплюсь. А свой ксаш писать нет смысла по одной простой причине: году в 2007-2008 я думал, что будь открыты сорцы голдсорса, можно было бы надобавлять новых фич, поднять лимиты, прикрутить графон и физику и вообще всякое, чтоб мод получился крутым. Крутой мод можно сделать и без этого, и даже на WON-версии.

Добавлено 19-05-2022 в 20:32:

Цитата:

Дядя Миша писал:
И на параное будут моды делать. Там уже будет 100% отвязка от голдсорса.

Надеюсь на это. Не зря же столько времени и сил потрачено на разработку.
Сначала я для себя решил, что мне не нужна возня с графонием, деланье дополнительных текстур и проч. А потом вообще решил делать просто делать на чистом голдсорсе, ведь так даже интереснее.

Отправлено Дядя Миша 19-05-2022 в 14:26:

Цитата:

Ku2zoff писал:
году в 2007-2008 я думал, что будь открыты сорцы голдсорса, можно было бы надобавлять новых фич, поднять лимиты, прикрутить графон и физику и вообще всякое, чтоб мод получился крутым

Ну ты примерно правильно думал. Ведь если фича есть - у тебя есть выбор, использовать её или нет. А если нет выбора, то сначала ты себя успокаиваешь тем, что не больно-то и нужно, а потом уже жалко бросать проделанную работу, например. К тому же я отчего-то уверен, ты себя тешишь мыслью, что если всё же тебе не хватит лимитов голдсорса, ты потихому на ксаш перескочишь и сделаешь вид, что таков и был план с самого начала

Цитата:

Ku2zoff писал:
Крутой мод можно сделать и без этого, и даже на WON-версии.

Угу, а потом тебе на этот крутой мод будут оставлять отзывы - убогая графика.
Если делать в стиле халф-квейков, то там конечно без разницы какой движок.

Цитата:

Ku2zoff писал:
Не зря же столько времени и сил потрачено на разработку.

P2 - это так, тренировка перед действительно важными вещами.
Поэтому в ней так много маленьких косяков, у меня уже не было ни времени ни желания их полировать, к тому же я предполагал, что коммунити с удовольствием этим займется. Так и оказалось.

Добавлено 19-05-2022 в 17:24:

Ku2zoff я корочи понял твою фишку. Это примерно тоже самое, чем мы с Ксером маялись в своё время. Смотрите - шейдеры на халфе, смотрите физика на халфе, ну итд. А у тебя немного другой посыл - смотрите всё тоже самое, но только без ксаша

Добавлено 19-05-2022 в 17:26:

Цитата:

Ku2zoff писал:
Сначала я для себя решил, что мне не нужна возня с графонием, деланье дополнительных текстур и проч

Ксаш-мод, он не про графоний, в первую очередь. И никаких дополнительных движений от моддера не требует. Декали на моделях, например, парент-система, телевизоры-порталы, 3д небо. Всё на тех же самых ресурсах, с той же картинкой, но чуточку красивее. Так что насчёт графона тут как бы странное возражение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 19-05-2022 в 15:30:

Цитата:

Дядя Миша писал:
если всё же тебе не хватит лимитов голдсорса, ты потихому на ксаш перескочишь и сделаешь вид, что таков и был план с самого начала

Лимитов так и так не хватит, слишком уж сильное ограничение на модели и элементы уровней. Если первое решаемо методом Гуля в ХЛВЕ, то второе уже никак не обойти. Я нашёл на что перескочить: Sven Engine. Прошёл под ним пару модов - полёт нормальный. Совместимость с синглом не изломана. Xash FWGS тоже будет поддерживаться, а вот оригинал, увы, нет. Неохота компилить две версии клиентки с SDL и без.

Цитата:

Дядя Миша писал:
у тебя немного другой посыл - смотрите всё тоже самое, но только без ксаша

Может быть и так. Ксаш бы избавил меня от многих моментов, например проблем с размерами уровня и лимитами. Размеры я увеличил, свен избавит от лимитов. Хороший мовевитч и физ. движок были бы в плюс, но первое для сингла решено ещё в старом ксашмоде под голдсорс, я копипастил и оно работало лучше, чем в спирите 1.7. А второе ненадо, потому что я сделал носимые пушабли.

Отправлено XaeroX 19-05-2022 в 15:38:

Цитата:

Ku2zoff писал:
Я нашёл на что перескочить: Sven Engine

С одного иностранного проприетарного движка перейти на другой иностранный проприетарный движок, ну или форк, которым занимается непонятно кто? Что же может пойти не так.

Всё-таки правы наши власти: в России существует какое-то необъяснимое преклонение перед Западом...

__________________

Отправлено Дядя Миша 19-05-2022 в 15:46:

Цитата:

XaeroX писал:
в России существует какое-то необъяснимое преклонение перед Западом...

Родина им Ксаш дала, носи - не хочу!

Добавлено 19-05-2022 в 18:46:

А где этот Sven Engine посмотреть можно? Хотя бы фичелист.
Для меня свен-коп, это такая сборная солянка из копипасты чего угодно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 19-05-2022 в 15:46:

Цитата:

XaeroX писал:
С одного иностранного проприетарного движка перейти на другой иностранный проприетарный движок

А что в этом плохого, когда делаешь мод для халфы?

Цитата:

XaeroX писал:
Что же может пойти не так.

У свена огроменное комьюнити. Если что-то изламывается, авторам массово репортят. Касательно сингла, да, в него под свеном не играют что репортить никто не будет. Но сингл никто и не трогал, раз в него не играют, шанс изломать именно его невысок. Разве что случайно.

Цитата:

XaeroX писал:
в России существует какое-то необъяснимое преклонение перед Западом...

Сказал человек, который переехал из России на ПМЖ в Канаду

Отправлено XaeroX 19-05-2022 в 15:53:

Цитата:

Ku2zoff писал:
Сказал человек, который переехал из России на ПМЖ в Канаду

Можно переехать на ПМЖ на Запад - но не преклоняться перед Западом.
А можно всю жизнь прожить в России - и преклоняться с утра до вечера.
Эти понятия вообще перпендикулярны.
Вот если бы я бросил Волатилу и перешёл на какой-нибудь UE4 - тогда другой разговор. Хотя и здесь всё может точно так же определяться экономической целесообразностью.
А вот

Цитата:

Ku2zoff писал:
когда делаешь мод для халфы

экономическая целесообразность уже роли не играет. Тут уже вопросы принципов. Ну или как говорил наш тхамбс (кстати где он) - базовых ценностей.

__________________

Отправлено Ku2zoff 19-05-2022 в 15:58:

Цитата:

Дядя Миша писал:
А где этот Sven Engine посмотреть можно? Хотя бы фичелист.

Например вот здесь.
Свен доступен в стиме, причём абсолютно бесплатно. Не надо указывать игрокам где и что качать. Скачал свен, кинул мод в папку, запустил батником.

Добавлено 19-05-2022 в 22:58:

Цитата:

XaeroX писал:
Тут уже вопросы принципов.

То есть, Field Intensity из принципа выпущен под голдсорс, не поддерживает ванильный ксаш, и его авторы преклоняются перед западом?

Отправлено XaeroX 19-05-2022 в 16:05:

Цитата:

Ku2zoff писал:
Field Intensity из принципа выпущен под голдсорс, не поддерживает ванильный ксаш, и его авторы преклоняются перед западом?

Во-первых, это готовый мод и у него есть определённая маркетинговая стратегия. Выпускать под оригинальную игру - это удобно, например в том же Стиме выкладывать можно без проблем. Во-вторых, вероятно им и не нужны были все эти ксаш-специфичные фичи, либо они были не критичны. То есть у авторов не стоял выбор между кастомными движками, они просто взяли оригинальную игру и сделали к ней мод, то есть пользовательскую модификацию, аддон. Добавили что-то к игре, то бишь. А мы говорим про ситуацию, когда проект уже перерастает рамки мода, разве нет?

Цитата:

Ku2zoff писал:
Скачал свен, кинул мод в папку, запустил батником.

Если у тебя мод не содержит ресурсов халфы - да, ок, это сработает (наверное). Хотя не уверен, что фраза "Sven Co-op now uses a customized GoldSrc engine under licence from Valve" означает, что движок доступен всем желающим при любых условиях. У него наверняка тоже есть правила использования. И моддерское EULA.

Но главное веселье начнётся, когда авторы Свена официально запретят выходцам из России использовать их движок. А у тебя к тому времени уже почти готова будет игра. Ведь ещё полгода назад над таким предположением все бы смеялись, а некоторые и сейчас продолжают смеятся, играя в свою любимую игру "верю-не верю".

__________________

Отправлено Дядя Миша 19-05-2022 в 16:28:

Цитата:

Ku2zoff писал:
Скачал свен, кинул мод в папку, запустил батником.

Ставить стим для того, чтобы запускать моды батником? Оригинально.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 19-05-2022 в 16:52:

Ku2zoff кстати форумы свен-коопа закрылись вот уже примерно пару лет назад.

Добавлено 19-05-2022 в 23:52:

Цитата:

XaeroX писал:
Но главное веселье начнётся, когда авторы Свена официально запретят выходцам из России использовать их движок.

А как они определят кто выходец а кто нет?

Отправлено FiEctro 19-05-2022 в 17:00:

Цитата:

А то че они нам сделают?

https://i.kym-cdn.com/photos/images/original/001/460/969/bcc.png

Отправлено Ku2zoff 19-05-2022 в 17:01:

Crystallize да эт я по старой памяти упомянул форумы. Сейчас свен обсуждается в стим-комьюнити.

Отправлено Дядя Миша 19-05-2022 в 17:28:

Цитата:

FiEctro писал:
А то че они нам сделают?

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

Добавлено 19-05-2022 в 20:28:

Посмотрел фичелист Свен Энджын, в основном - мелкие исправления и накрутка лимитов. Получить сорцы движка != понимать как он работает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 19-05-2022 в 17:41:

Цитата:

FiEctro писал:
А то че они нам сделают?

Пожалуются в Стим, те распубликуют мод.

Отправлено XaeroX 19-05-2022 в 17:45:

Цитата:

Crystallize писал:
А как они определят кто выходец а кто нет?

Они - никак, а вот комьюнити вполне может проявить пролетарское чутъё и сообщить куда следует.

Цитата:

FiEctro писал:
А то че они нам сделают?

Вопрос из серии "вот возьму я и выложу мод на ворованных ресурсах, и что они мне сделают".
~~Арестуют и выдадут в США при первом же выезде из РФ~~. Понятно, что ничего особенного они не сделают, но будут всячески осуждать, удалять и блокировать в своих интернетах. Ты будешь ждать, что народ оценит в твоём моде работающий барнакль, а народ будет всячески поносить тебя за нарушение санкционного режима. Между прочим, когда я выложил HLFX:Single, думаешь, что первым делом отметили буржуи? Думаешь, бамп, тени, или может быть, мини-игру с подключением электричества в щитке? Нет, они отметили модельки датакуба и кодового замка из Deus Ex!
Вообще говоря, cancel culture кажется безобидной ровно до того момента, когда отменяют лично тебя.

__________________

Отправлено FiEctro 19-05-2022 в 17:58:

Цитата:

XaeroX писал:
Думаешь, бамп, тени, или может быть, мини-игру с подключением электричества в щитке? Нет, они отметили модельки датакуба и кодового замка из Deus Ex!

Ну вот ты и сам ответил на свой вопрос. Они всю жизнь такой фигнёй занимались, и текущая "cancel culture" это всего лишь временное обострение. Как говорится Pozubam yourselves, guys! В любом случае не запретят движок, запретят пользоваться стимом.

Отправлено SNMetamorph 20-05-2022 в 10:58:

Цитата:

Ku2zoff писал:
FiEctro писал:
инструментов для них не сделали

Инструменты, документация, а самое главное - пиар. Вон, тулзы солокиллера активно пиарятся (или пиарились) на форуме свенкоопа. И всякие разные studiomdl на геймбанане выложены. У многих до сих пор проблемы с установкой модов под оригинал ксаша, потому что копируют папку valve, а архив с графикой для меню вон-версии не распаковывают.

Ты немножко отстал от жизни, видимо. За последний год народ начал больше обычного интересоваться ксашем, что последовало из ряда действий, по большей части моих. При содействии других людей, конечно.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 23-05-2022 в 13:26:

Если кто-то из вас надумает писать свой компилятор или виртуальную машину - очень рекомендую ознакомиться с исходниками TinyC, там хороший кодостиль, приятно почитать. ~~К тому же, оно вроде как научилось собирать С++.~~ А если вам нужен пример жуткого кодостиля - посмотрите cfront от Страуструпа.

Добавлено 23-05-2022 в 16:26:

Цитата:

SNMetamorph писал:
За последний год народ начал больше обычного интересоваться ксашем, что последовало из ряда действий, по большей части моих.

*мечтательно*
Буржуев бы перетянуть. СвенКоповцев, Кофовцев там, я не знаю.
Квейк-коммунити опять же.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 23-05-2022 в 18:39:

Цитата:

Дядя Миша писал:
Буржуев бы перетянуть. СвенКоповцев, Кофовцев там, я не знаю.
Квейк-коммунити опять же.

Для этого надо сделать релиз и хорошую презентацию к нему.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Crystallize 24-05-2022 в 10:03:

Цитата:

Дядя Миша писал:
очень рекомендую ознакомиться с исходниками TinyC, там хороший кодостиль, приятно почитать

демки на TinyC от автора генератора рандомных карт для хл

Отправлено FiEctro 24-05-2022 в 10:52:

Цитата:

Дядя Миша писал:
Буржуев бы перетянуть. СвенКоповцев, Кофовцев там, я не знаю.

А как Свен работает под ксашем? Мне кажется не станут они переходить, ведь у них уже куча фанатских серваков поднято.

Отправлено Дядя Миша 24-05-2022 в 12:59:

Цитата:

FiEctro писал:
А как Свен работает под ксашем?

Если дело только в лимитах, то должен работать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дикс 24-05-2022 в 19:24:

Цитата:

Дядя Миша писал:
Если дело только в лимитах, то должен работать.

Так ведь разрабам свен-коопа Вальв дала сорцы голдсорс, как и команде БМС

Вики:

Цитата:

Engine GoldSrc (heavily modified), Svengine (v 5.0+)

__________________
igroprom.d3.ru

Отправлено Дядя Миша 24-05-2022 в 19:39:

Фичелист из свена выкладывали, в основном - лимиты.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено [CFR] B@N@N 25-05-2022 в 16:42:

Так запустите да посмотрите будет последний свин работать на Краше или нет

Отправлено Ku2zoff 25-05-2022 в 18:52:

[CFR] B@N@N как минимум, версии SDL2 и VGUI несовместимы с ксашевскими. Ещё сервер завязан на стимовских интерфейсах. На FWGS не заводится, на ванилле - тем более.

Отправлено Дядя Миша 25-05-2022 в 19:24:

Вальва с этим внезапным обновлением голдсорса подложила всем Геганцкую Свенью™
Напоминаю, что это делалось ради стим-бокса, который в итоге так и не вышел, портирование игр на линукс закончилось пшиком - линуксоиды не захотели за это платить. Зато мы получили изумительный несовместимый голдсорс, который для своей работы требует теперь FBO, т.е. минимум GeForce 8xxx. Так мало было виндовых функций проброшенных в клиентку.
Теперь туда еще и SDL примотали. И все носятся с этим обновлением и причитают - о боже, нам срочно нужна такая халфа.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 28-05-2022 в 14:23:

Для понимания того, что собой представляют, ну как минимум старые компиляторы (да и новые зачастую тоже) С\С++, приведу вам вот какой факт: эти компиляторы по сути - продвинутая версия интерпретаторов ассемблера. Только ассемлеровские листинги просто конвертятся в опкоды процессора, а смысл этой замуты в то, что опкоды для разных архитектур отличаются, а во вторых приятнее всё же читать команды push, mov нежели просто номера опкодов - глазу удобнее.
Так вот Си в большей степени, а С++ в меньшей степени являются точно такими же интерпретаторами, которые помнят объявленные переменные.
Генерация опкодов происходит прямо по факту чтения очередного операнда, ну в некоторых случаях компилятор сам втыкает условия и goto, например в циклах или свитчах. С парсингом классов чуть похитрее - там двухпроходной цикл, сначала парсим члены класса, пропуская тела функций, объявленных внутри декларации класса, потом парсим только тела функций.
Функции класса, объявленные вне его тела парсятся в обычном режиме.
Самая сложная замута с шаблонами, их вообще нельзя парсить на момент их объявления, поэтому компилятор сохраняет их исходный текст в укромное место и начинает парсить только когда предвидится реальный шаблонный вызов, из-за чего ошибки шаблонов сыплются чуть ли на этапе линковки и немало удивляют юзера. Вообще я так понимаю этот костыль с шаблонами, Страуструп прикрутил по многочисленным просьбам телезрителей чуть ли не в самом конце разработки. Вот они и получились такие неудалые. Впрочем более современные компиляторы, вроде как со стандартная С++11, уже так не делают, они все опкоды сохраняются в какие-то локальные массивы, отчего там и ошибки информативнее и возможны некоторые конструкции, которые не работали на стандарте С99. Ну об этом можно в Вики почитать.

Добавлено 28-05-2022 в 17:23:

Кстати эти современные компиляторы далеко не факт что спровляются лучше старых, но вот памяти жрут однозачно больше, и при этом компилируют дольше. Ну это так, к слову. Направление эволюции вполне естественное.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 28-05-2022 в 19:47:

https://ru.wikipedia.org/wiki/CISC
https://ru.wikipedia.org/wiki/RISC

Теперь уже с полным пониманием дела можно освежить эту информацию и с уверенностью сказать, что моя VM использует RISC архитектуру

Добавлено 28-05-2022 в 22:47:

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 29-05-2022 в 14:17:

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

Отправлено Дядя Миша 29-05-2022 в 14:20:

Crystallize CISC-команды предназначались для людей, пишущих на ассемблере, а RISC-команды - для компилятора. Это основная разница.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-06-2022 в 14:10:

Вообщем вот какая у меня нехорошая вещь получилась. Поскольку это всё же виртуальная машина, а не настоящий С++, у меня не получилось сделать из компилятора нормальный вызов виртуального деструктора. Потому что опирается не на участок памяти, по которому идёт переход на виртуальную таблицу, а на тот тип, который сунули в указатель delete. И соответственно если вызов деструктора делает компилятор, то без разницы виртуальный он или нет - правильность его вызова напрямую зависит от типа указателя, а ведь смысл виртуальных деструкторов в том и заключается чтобы правильно работать независимо от типа входных данных. Хорошо, я выбросил этот вызов из компилятора и конструктивно объединил вызов деструктора в рантайме с высвобождением памяти. Это прекрасно работает абсолютно в любом случае, т.к. VM располагает всей необходимой информацией.
Но вылезла другая проблема, блин! Теперь оно ВСЕГДА работает правильно, независимо от того, виртуальный деструктор или нет. Само по себе это проблемы не представляет, поскольку вызов идёт именно правильный.
Проблема в другом. Если кто-то напишет код на моей VM без виртуальных деструкторов, а потом решить его перенести на С++, оно перестанет правильно работать. Хотя в сущности поправить дело будет несложно, достаточно будет прописать virtual у деструктора базового класса.
Помнится мне, что когда я меню разрабатывал у меня там тоже кошмар начался, а прописал virtual и помогло. Т.е. технически проблемы нет, просто будет вот такая особенность языка. Деструкторы всё равно не могут быть перегружены, скорее виртуальный деструктор - это костыль для самого С++, нежели реальная необходимость.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 05-06-2022 в 17:12:

Цитата:

Дядя Миша писал:
виртуальный деструктор - это костыль для самого С++, нежели реальная необходимость.

Виртуальный деструктор предназначен не для переопеределения, а для того, чтобы правильно удалять класс через указатель на базовый класс. Почему не все деструкторы по дефолту виртуальные? Чтобы не создавать vtbl там, где она не особо нужна. Главный принцип С++ "ты платишь только за то, что используешь", и это один из примеров его применения.

__________________

Отправлено Дядя Миша 05-06-2022 в 19:28:

Цитата:

XaeroX писал:
Виртуальный деструктор предназначен не для переопеределения, а для того, чтобы правильно удалять класс через указатель на базовый класс

Я понимаю. В моей реализации эта штука оказалась лишней. Она будет работать, её можно использовать, но ничего кроме выполнения лишних инструкций она не повлечёт.

Цитата:

XaeroX писал:
Чтобы не создавать vtbl там, где она не особо нужна.

Ну у меня чуть хитрее сделано. Вместо vtable выделяется хэндл с номером метаинформации, который заполняется в рантайме при вызове конструктора.
А vtable находится уже в самой метаинформации и не дублируется в экземпляре класса, как в С++. Т.е. экземпляр класса имеющий непосредственный доступ к метаинформации увеличивается в размерах всегда на 4 байта. Множественное наследование я делать не буду, ну его на.
Опять таки, динамически созданные экземпляры класса всегда имеют доступ к метаинформации, т.е. это скорее актуально для экземпляров, созданных на стеке и в глобальной куче.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-06-2022 в 16:31:

Ну что же, теперь, когда я достаточно понаторел в разработке С++ совместимого языка, я могу вам наконец-то рассказать, за что же его все так ругают и почему это с ним произошло в отличие от того же Си.
Всё дело в том, по-видимому, что Страуструп писал его в молодости и был увлекающейся натурой. То есть он придумывал какую-то фичу, которую можно было реализовать в рамках препроцессора Си и тут же её внедрял.
Как правило это давало какие-то новые возможности и открывало для программиста новые удобства. Но порождало комбинаторный взрыв, который в свою очередь разрушал целостность поведения, порождая UB.
Как когда-то написал Боресков в своей статье - откройте любую книгу по С++, о чём там будет написано в первую очередь? "Как не надо делать!".
То есть довольно много таких проблематичных мест на самом деле, из-за чего невозможно догадываться о поведении языка в целом, а желательно уточнять в справочнике, если вдруг что-то не заработало. Опытный программист просто их все знает наизусть и в ногу себе не стреляет.
Новичок же пытается экстрполировать полученный опыт но весь язык и очень часто получает граблями по носу. Это основная претензия, так сказать. В какой-нибудь Яве или СиШарпе перетянули в обратную сторону - постарались исключить вообще всё, что могло вызывать малейшие проблемы, из-за чего эти языки обновляются с пугающей периодичностью - туда постоянно добавляют то, чего не хватает юзерам. И то и другое - очевидно крайности. Я попытаюсь сделать свой язык максимально близким по синтаксису и парадигме к С++, но при этом лишив его пугающих неоднозначностей и UB, насколько это в моих силах. Чтобы никто не смог выстрелить себе в ногу.

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 08-06-2022 в 07:28:

Хочу вам на наглядном примере показать, почему в перегрузке функций, к сожалению нельзя опираться на то что функция возвращает. Иными словами нельзя иметь перегруженные функции, у которых меняется только тип возврата

C++ Source Code:

int get( void );

float get( void );

Собственно, почему это не работает. Всё дело в поддержке вызова аргументов в виде других функций. Ну то есть чтобы не писать

C++ Source Code:

int a = foo();

bar( a );

Мы можем просто написать

C++ Source Code:

bar( foo() );

Это удобно, но мы попадаем в логическую ловушку. Для того чтобы определить перегруженную только по возвратному типу функцию foo, мы сперва должны узнать какой тип аргумента принимает bar, а если bat перегружен тоже, то мы никаким чудом не сможем узнать какую функцию выбрать из foo - ведь мы же еще не выбрали bar, а bar мы не выберем, поскольку не можем выбрать foo. Замкнутый круг.
Собственно почти все ограничения С++ относятся именно вот к таким логическим ловушкам. Именно поэтому они и не исправляются в новых редакциях языка. Потому что это невозможно в принципе.
Запрещать такую форму записи тоже не вариант - ведь это очень удобно.
Приходится выбирать чем пожертвовать.

Добавлено 08-06-2022 в 10:28:

Опять же, несмотря на строгую типизацию, С++ унаследовал от Си довольно много неявных преобразований. Например, преобразование к void * всегда неявное. Точно так же конверсия базовых типов выполняется неявно, хотя компилятор и сыплет предупреждениями, типа 4244, но их затыкают в первую же очередь. А в новых версиях С++ они возможно на четвертом уровне и отключены по умолчанию.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 08-06-2022 в 15:14:

Ну чтож, замутил я перегрузку функций, прямо как в С++. Самым поганым оказалось необходимость написания функции с тысячами if-else, прямо как ФиЭктра любит. Вот к сожалению никак это в табличку не свести.

Но я смотрю вам неинтересно всё что я пишу по С++? То ли вы так хорошо язык знаете, то ли вам просто неинтересны эти подробности.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 08-06-2022 в 18:01:

Дядя Миша скорее я знаю плюсы плохо, в рамках HLSDK, но вот например с перегрузкой методов в яве такие же дела. Хотя мне всегда казалось, что сигнатура функции при компиляции в байткод может иметь отдельный байт или маску на возрвращаемый тип, что позволит делать рекурсивную перегрузку

__________________
-Brain is dead-

Отправлено XaeroX 08-06-2022 в 18:37:

Цитата:

Дядя Миша писал:
То ли вы так хорошо язык знаете, то ли вам просто неинтересны эти подробности.

Народу нужна нормальная мув-семантика, асинхронность, std::filesystem и ranges. А ты пишешь про перегрузку функций. Здравствуй, мой 1996 год, как говорится.

Добавлено 08-06-2022 в 14:35:

А, поддержка coroutines ещё.
У тебя, надеюсь, будет нативная поддержка ключевого слова yield?

Добавлено 08-06-2022 в 14:37:

До появления С++20 приходилось извращаться кто как умеет.

__________________

Отправлено Дядя Миша 08-06-2022 в 19:07:

Цитата:

XaeroX писал:
yield

Это принудительная остановка потока и передача управления в другой?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 08-06-2022 в 19:08:

Дядя Миша
Это как пауза в выполнении функции. Вызвал функцию снова - продолжил выполнение с этого места, а не с начала.

__________________

Отправлено Дядя Миша 08-06-2022 в 19:15:

Цитата:

XaeroX писал:
А ты пишешь про перегрузку функций

Ну наверное глупо начинать с фичей 2020-го года, пока не реализованы фичи 1983-го?

Добавлено 08-06-2022 в 22:12:

Цитата:

XaeroX писал:
Это как пауза в выполнении функции.

Сам по себе пауза не нужна. Я почему и спрашиваю - чтобы передать управление другому потоку?

Добавлено 08-06-2022 в 22:15:

Цитата:

XaeroX писал:
А, поддержка coroutines ещё.

Пока я не вдуплю зачем это вообще нужно - не будет.
Я хотел сделать возможность объявить функцию внутри функции.
Не понимаю чем это от лямбды отличается.

Да и потом, в вашем этом хвалёном С20 сериализация изкаропки появилась?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 08-06-2022 в 20:26:

Цитата:

Дядя Миша писал:
Сам по себе пауза не нужна

в мобильной яве особо упоротые делали через него прерывания логики для передачи управления основному потоку

__________________
-Brain is dead-

Отправлено Дядя Миша 08-06-2022 в 20:32:

KiQ почему в яве фреймворк с рантаймом весят один гигабайт?
Что туда напихали?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 08-06-2022 в 20:40:

Дядя Миша думаю разрослись засчёт сторонних либ и обратной совместимости. На мобилках как-то впихивали, вот прошивки на мои SonyEricsson весили в пределах 50Мб

__________________
-Brain is dead-

Отправлено AntiPlayer 09-06-2022 в 05:54:

Цитата:

Дядя Миша писал:
Но я смотрю вам неинтересно всё что я пишу по С++? То ли вы так хорошо язык знаете, то ли вам просто неинтересны эти подробности.

Интересно, но хотелось бы побольше примеров, например про неявное преобразование типов. Откуда оно вообще в C

Цитата:

XaeroX писал:
А, поддержка coroutines ещё.

Это какая-то помесь async/await из C# и генераторов из python/JavaScript?

__________________
I tell you to enjoy life

Отправлено Дядя Миша 09-06-2022 в 06:18:

Цитата:

AntiPlayer писал:
например про неявное преобразование типов

Неявное преобразование выполняется там, где результат однозначен для программиста и не влечёт UB. В некоторых случаях преобразование возможно с потерей точности, тогда выдаётся предупреждение.
Скажем int->double вопросов не вызывает, а вот double->int уже да.
Для указателей эти требования еще строже. Нельзя объявить указатель на double и положить туда int без явного преобразования, у них как минимум разные размеры.
Как оно в Яве я не знаю. Там кажется любая переменная имеет на самом деле тип variant, поэтому можно даже bool преобразовать в строку "false" ну или "true".

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено AntiPlayer 09-06-2022 в 06:49:

Цитата:

Дядя Миша писал:
Неявное преобразование выполняется там, где результат однозначен для программиста и не влечёт UB.

Да и я искренне считал, что неявное преобразование запрещено в C.

__________________
I tell you to enjoy life

Отправлено Дядя Миша 09-06-2022 в 09:39:

В Си наоборот слишком дохрена неявных преобразований, там где С++ уже ругается и нехочит.
Пример

C++ Source Code:

unsigned char *foo = malloc( 123 );

Для си это валидная конструкция, он позволяет кастовать из void* к любому типу, а С++ позволяет только обратное неявное преобразование - любой тип к void*.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 10-06-2022 в 17:53:

Важное событие! Сегодня написал имплементацию динамического массива прямо на скриптовом языке. Насколько я знаю, ни на шарпе ни на яве это сделать невозможно в принципе. То есть можно унаследовать динамический массив от намертво встроенного в язык, а вот так чтобы с нуля - невозможно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 10-06-2022 в 18:12:

Дядя Миша
А пример можно? Как это выглядит?

Отправлено AntiPlayer 10-06-2022 в 18:41:

Цитата:

Дядя Миша писал:
Важное событие! Сегодня написал имплементацию динамического массива прямо на скриптовом языке.

У тебя JavaScript не получится на выходе?

Согласен, хотелось бы примеров.

__________________
I tell you to enjoy life

Отправлено Дядя Миша 10-06-2022 в 19:02:

Цитата:

FiEctro писал:
А пример можно? Как это выглядит?

Представь себе типичную реализацию контейнера на С++, только без шаблонов. Вот так же и выглядит. Шаблоны я пока не прикрутил и не знаю точно, нужны ли они.

Цитата:

AntiPlayer писал:
У тебя JavaScript не получится на выходе?

Нет, у меня получится язык максимально близкий к С++ по синтаксису концепции и парадигме, но лишенный недостатков самого С++.
Цена за это - низкое быстродействие скриптовой машины.
Впрочем в дальнейшем можно будет прикрутить JIT, но это когда-нибудь потом.
По моим замерам быстродействие ниже С++ примерно в 9.5 раз.
Впрочем у Java без JIT оно наверное ниже раз в 100.

Добавлено 10-06-2022 в 22:02:

А то что я по языку мало новостей пишу - уж не обессудьте. На нашем форуме С++ знает только Xaerox, остальным навряд ли будет всё это интересно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 10-06-2022 в 19:14:

Цитата:

Дядя Миша писал:
А то что я по языку мало новостей пишу - уж не обессудьте. На нашем форуме С++ знает только Xaerox, остальным навряд ли будет всё это интересно.

Так расжуй массам популярно, ты это умеешь, я знаю.

Отправлено Дядя Миша 10-06-2022 в 19:41:

Ну я вон выше про логические ловушки написал - никто даже не откомментил.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 10-06-2022 в 20:31:

Дядя Миша я писал контейнеры на Яве, но там это выглядело так - заводим массив элементов на 10, при его заполнении создаём новый [n+10], делаем Arrays.copyOf и обнуляем старый массив

__________________
-Brain is dead-

Отправлено Дядя Миша 11-06-2022 в 05:51:

В сущности принцип тот же. Но realloc всяко быстрее будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 11-06-2022 в 10:57:

Цитата:

Дядя Миша писал:
мы сперва должны узнать какой тип аргумента принимает bar

Кому была реально нужна эта фича, перегрузка? Это же зародыш современных Intellisense которые пытаются быть умнее пользователя и писать код за него.

Добавлено 11-06-2022 в 17:56:

Цитата:

Дядя Миша писал:
Ну я вон выше про логические ловушки написал - никто даже не откомментил.

Ну я допустим прочитал. Наверное единственное что я не читал-это не простыни где ты описывал историю всех своих проектов.
Можно конечно ввести кнопку "я прочитал" но принципиально важно чтобы счетчик был виден только автору поста, иначе стадный эффект убьёт форум.

Добавлено 11-06-2022 в 17:57:

Цитата:

Дядя Миша писал:
Цена за это - низкое быстродействие скриптовой машины.

Меня терзают смутные сомнения.

Отправлено Дядя Миша 11-06-2022 в 14:00:

Цитата:

Crystallize писал:
Кому была реально нужна эта фича, перегрузка?

Вообще-то на перегрузке весь полиморфизм основан.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 12-06-2022 в 07:50:

Вообщем два миллиарда команд выполняется примерно за 21-секунду.
Цикл с условием INT_MAX. Для сравнения чистый С++ справляется за 4 секунды.
60 миллионов команд отнимает 0.7 секунды. Среднее кол-во инструкций для игрового кадра - ну может тысяч 20-30. Хотя это я так, навскидку.
Потом замерю, скажу точно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-06-2022 в 10:09:

Самое прожорливое как правило это поиск и перебор игровых объектов, а так же их параметров.

Отправлено Дядя Миша 15-06-2022 в 15:09:

Поиск можно в движке будет сделать. Ну посмотрим.

Добавлено сегодня в 18:09:

Образчик кода на делфи, низкий уровень, где-то в раёне базы для всех классов

C++ Source Code:

1	procedure TComponent.ReadLeft(Reader: TReader);

begin

3	LongRec(FDesignInfo).Lo := Reader.ReadInteger;

end;

6	procedure TComponent.ReadTop(Reader: TReader);

begin

8	LongRec(FDesignInfo).Hi := Reader.ReadInteger;

end;

Помоему тут прекрасно вообще всё. FDesignInfo - это целочисленная 32-битная переменная. Очевидно ReadLeft читает младшие 16 бит, а ReadTop - старшие 16 бит. Встаёт сразу вопрос - а почему такая странная пара left-top? Почему не right-bottom например? Опять же из названия функции ReadLeft никоим образом не следует, что мы совершаем операции с FDesignInfo. Интересно какая была мотивация у того, кто это писал?
Может я чего-то не догоняю?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 15-06-2022 в 19:27:

Upd. На GD.ru подсказали, что top-left - это верхний левый угол окна, т.е. его позиция, почему-то упакованая в int с названием FDesignInfo.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено PRoSToTeM@ 15-06-2022 в 20:30:

Дядя Миша, насчёт виртуальной машины, а почему бы не взять wasm с уже готовым JIT и биндингами, в который к тому же умеют компилироваться всякие разные языки (C, C++, C# и т.д.). Или этот вариант уже рассматривался и был отвергнут?

Отправлено Дядя Миша 16-06-2022 в 06:57:

PRoSToTeM@ я вообще стараюсь как можно меньше использовать чужой код. По крайней мере - в виде готовых библиотек. Потому что он всегда не годится под мои задачи, которые выходят за рамки стандартных применений в силу того, что у меня есть своё виденье, как всё это должно быть устроено. Есть конечно вещи, которые меня устраивают - например форматы OGG и Theora. Писать свои собственные форматы для сжатого аудио и видео я точно не планирую.

Добавлено 16-06-2022 в 09:51:

И вообще любая привязка к чужим библиотекам это очень порочная практика.
1. ты привязываешься и поначалу тебе всё нравится
2. потом ты что-то изменяешь под себя\исправляешь ошибки
3. потом выходит новая версия оригинальной либы с исправленными ошибками, о которых ты вообще ничего не знал
4. вместо того чтобы писать код дальше - начинаешь мержить либо вносить в новую либу уже сделанные изменения
5. если чужих либ много - то периодически в каждую
6. следишь чтобы после всех этих изменений у тебя самого ничего не испортилось
7. в конце-концов плюешь и перестаёшь вносить эти изменения
8. к моменту релиза твой софт использует устаревшие версии с критичными дырками (к примеру)
9. обновлять их нельзя, так уже создан пользовательский контент, неизвестно что сломается после обновления
10. Плюешь на пользователей пилишь новую версию, несовместимую, заставляешь всех перелезть туда.
11. За это время куча либ получает очередные обновления...
Вот в итоге чем занимается современный разработчик который просто хотел "сэкономить немного времени".

Добавлено 16-06-2022 в 09:57:

Для себя я выработал два чётких критерия, когда можно использовать сторонние библиотеки и один опциональный:
1. функционал библиотеки отвечает абсолютно всем моим требованиям, а если какие-то мелочи и не отвечают, то альтернативы нет всё равно.
2. библиотека не обновлялась в течении очень долгого времени - 10-15 лет и скорее всего не будет обновляться уже никогда, но при этом достаточно активно используется программистами. Или пусть не так активно, но была задействована в продакшене, что тоже показатель.
3. (опционально) библиотека берётся на время, в качестве заглушки, потом вместо нее будет написана собственная реализация.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено AntiPlayer 16-06-2022 в 07:06:

Цитата:

Дядя Миша писал:
1. функционал библиотеки отвечает абсолютно всем моим требованиям, а если какие-то мелочи и не отвечают, то альтернативы нет всё равно.

Про функционал понятно, а что с кодом? Ты его полностью вычитываешь и разбираешь?

__________________
I tell you to enjoy life

Отправлено Дядя Миша 16-06-2022 в 07:47:

Цитата:

AntiPlayer писал:
Ты его полностью вычитываешь и разбираешь?

Нет. Я просто стараюсь использовать только библиотеки, которые реализуют функционал чёрного ящика - подали данные на вход, получили данные на выходе. Этим требованиям отвечают тот же OGG, Theora, Zlib, Squish, Jpglib, т.е. просто какие-то распаковщики сжатого формата данных. Или наоборот упаковщики. Когда результат работы очень легко проконтролировать.
Если же библиотека начинает своими импортами экспортами расползаться во все части движка, подобно раковой опухоли, я просто такое не использую в принципе.
Т.е. стороняя реализация виртуальной машины или физики или рендерера моим требованиям отвечать не может, поэтому там всё самописное.
Если вам нужен обратный пример, где всё заимстованное - то вот Unity есть.
До пятой версии там почти всё было со стороны.

Добавлено 16-06-2022 в 10:42:

Если вам интересно, приведу список third_party на текущий момент в XashNT

1. ogg.lib (будет использоваться)
2. theora.lib (будет использоваться)
3. vorbis.lib (будет использоваться)
4. squish.lib (возможно будет переписана в дальнейшем)
5. NvTriStrip.lib (возможно будет удалена, на настоящий момент от нее мало толку)
6. Qslim.lib (скорее всего будет написана собственная реализация Progressive Mesh)

Чужие реализации в исходниках
1. bunnylod от Stan Melax (еще одна реализация Progressive Mesh, уже доработанная мной для ипользования режима Shortes Edge и преодтвращения деградации на швах)
2. Реализация progessive mesh от Tom Forsyth (оригинальная версия)
3. ZLib (без изменений, но отрезано всё ненужное, исходник весит всего 38 килобайт, меньше чем скомпиленная zlib1.dll)

Т.е. легко заметить что добрая треть библиотек - это различные вариации на тему Progressive Mesh, но своей реализации я еще не написал, потому что вслепую это очень неудобно делать, а вот когда у меня будет свой редактор, я этим конечно займусь. Можно было бы заморочиться и просто написать визуализатор для опытов, но это нерациональная трата времени. TriStrip как пятое колесо в телеге, ну нет от него толку на современных GPU. И на GD.ru это тоже подтвердили. Хотя я всё по феншую делал, с ремапом. ZLib я выброшу, просто потому что в игровых контейнерах сжатие вообще не нужно, оно только вредит. Но опять же, это не раньше чем будет написан игровой редактор и разработан собственный формат контейнеров хранения файлов.

Как-то так.

Добавлено 16-06-2022 в 10:47:

Ну и пару слов за форматы audio\video. Ни vorbis ни theora меняться уже не будут, они хорошо задокументированы и вполне предсказуемы.
К примеру, в то же римейке Quake от Night Dive идут видео в OGV, которые ксаш прекрасно воспроизводит, а у меня там стоят либы, скачанные с официального сайта, датируемые 2006-м кажется годом. Это полностью устаканившийся формат, от которого не ждёшь никаких неожиданностей.
А вот то, что делала Google для своих ютубов, это просто формат видео, который может идти в паре с форматом аудио (любым) и практически любым типом контейнера. То есть там полный зоопарк, с которым нет никакого желания связываться.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено PRoSToTeM@ 22-06-2022 в 19:09:

Дядя Миша, я конечно во многом согласен, но есть и security аспект. Для singleplayer он разумеется не сильно актуален, но для multiplayer очень даже. Да и в случае с singleplayer пользователь может скачать ресурсы со стороннего сайта, а там окажется эксплойт в модельке/звуке.

Отправлено Дядя Миша 22-06-2022 в 20:26:

PRoSToTeM@ приведи пример такого эксплойта.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 22-06-2022 в 21:17:

Цитата:

Дядя Миша писал:
приведи пример такого эксплойта.

Например, скачиваешь модельку - а там моделька Путина.
А вместо привычного "Go! Go! Go!" звучит "Нам не оставили выбора".
В отдельных случаях, как ты понимаешь, это может тяжело травмировать психику. Админ психанёт и выключит сервер. А хакеру того и надо было.

__________________

Отправлено Дядя Миша 23-06-2022 в 06:09:

Ничего себе! Нам надо срочно нейросеть, которая будет анализировать контент и подменять женские соски на мужские! А модельку Путина на модельку Брежнева.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 28-06-2022 в 07:17:

Новостей никаких не пишу, к сожалению, ну тут как обычно. Чем фундаментальнее и масштабнее работа - тем меньше чего-то осмысленного можно сказать аудитории по этому поводу. Фундаментальные вещи, они или есть или нет. А как продвигается над ними работа никого не интересует.
Чаще всего в таких случаях просто берут готовую библиотеку и не парятся.
Ну вот как в Юнити однажды взяли C# который для игр абсолютно не годится и уже 15 лет с ним вооют. Я так не хочу, поэтому создаю собственный скриптовой язык, ну об этом вы знаете. Так же будет собственная библиотека оконного менеджера, написанная прямо на этом языке.
Фишка в том, что она сможет подгружать оконные формы из текстовых описаний, а значит визуальное оформление можно будет менять на лету без перекомпиляции. Это относится к будущему редактору. Сам же язык будет использоваться и для описания игровых объектов тоже. Ну и не только для них, для игрового меню, для клиентской библиотеки. Вобщем для всего того, для чего вам раньше требовался С++ и необходимость устанавливать студию. В идеале получится среда, которой не требуются никакие внешние инструменты для работы. Самое главное в данном случае - возможность гибкого расширения, т.к. изначально всё предусмотреть невозможно.

Написание фундаментальных вещей занимает больше всего времени к сожалению, поэтому работа идёт небыстро. Но зато это последние две фундаментальные вещи, которых не хватало движке - свой собственный язык программирования и библиотека окошек. А потом наконец-то будет первая юзабальная версия и регулярные обновления.

Добавлено 28-06-2022 в 10:10:

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

Добавлено 28-06-2022 в 10:17:

Ну и если хотите какого-то оживления в этой теме, пока нет официальных новостей - задавайте вопросы сами.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-06-2022 в 08:29:

Цитата:

Дядя Миша писал:
В идеале получится среда, которой не требуются никакие внешние инструменты для работы

Какие будут инструменты для отладки?

Цитата:

Дядя Миша писал:
Ну вот как в Юнити однажды взяли C# который для игр абсолютно не годится и уже 15 лет с ним вооют. Я так не хочу, поэтому создаю собственный скриптовой язык, ну об этом вы знаете. Так же будет собственная библиотека оконного менеджера, написанная прямо на этом языке.

А чем он не годится? Куда проще и удобнее чем обычные кресты. Плюс собирается под все возможные платформы. Раньше вообще Жаба шкрипт был. А сейчас вроде как ещё обещают Питон завезти, правда я не знаю зачем такое обилие языков для одного движка. Но с другой стороны, а какая разница чем вызывать движковые функции?

Отправлено Дядя Миша 28-06-2022 в 08:44:

Цитата:

FiEctro писал:
Какие будут инструменты для отладки?

Для отладки чего именно?

Цитата:

FiEctro писал:
Куда проще и удобнее чем обычные кресты

Скорее наоборот - очень запутанный и негибкий язык. Если бы он полностью удовлетворял всем условиям - его бы не обновляли каждый год.
В тех же крестах, например, можно спокойно писать на редакции языка 98-го года и вообще не испытывать никаких неудобств. Всё необходимое там есть. В Шарпе наоборот - до какой-то версии им было очень проблематично пользоваться.

Цитата:

FiEctro писал:
Но с другой стороны, а какая разница чем вызывать движковые функции?

Ну вот если разницы бы не было - к чему такая суета вокруг языков и их версий? Не всё так просто.

На мой взгляд кресты пугают новичков не своим синтаксисом, который как раз удобный и логичный, а скорее близостью к железу, на этом языке невозможно писать, не зная что у тебя в итоге там получится.
На шарпе наоборот - чтобы ты ни написал, оно будет работать, а то что медленно и памяти много жрёт - ну просто купите себе компьютер побольше.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-06-2022 в 08:46:

Цитата:

Дядя Миша писал:
Для отладки чего именно?

Написанных скриптов. Ну вот накосячил юзверь в коде, и не знает где ошибка, что ему делать? В юнити можно даже посмотреть какой объект или скрипт сколько жрёт памяти и тактов процессора.

Отправлено Дядя Миша 28-06-2022 в 08:49:

За Шарп вот какая любопытная вещь прослеживается. Его версию в Unity периодически обновляют, но на самом деле это довольно небыстрый процесс. Может и год пройти, пока обновят. То есть просто нельзя взять и скачать новый рантайм, надо что-то менять в коде самого Юнити. А почему так происходит? Ну очевидно потому что в самом шарпе опять вообще всё переделали, чтобы он стал только лучше от этого. Значит старые версии говном были? И так - из года в год.

Добавлено 28-06-2022 в 11:48:

Цитата:

FiEctro писал:
Написанных скриптов. Ну вот накосячил юзверь в коде, и не знает где ошибка, что ему делать?

Отладчик встроенн прямо в язык, показывает всё, как студия. С номером строчки и именем исходного файла.

Добавлено 28-06-2022 в 11:49:

Цитата:

FiEctro писал:
В юнити можно даже посмотреть какой объект или скрипт сколько жрёт памяти и тактов процессора.

Это разумеется тоже будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-06-2022 в 08:51:

Цитата:

Дядя Миша писал:
За Шарп вот какая любопытная вещь прослеживается. Его версию в Unity периодически обновляют, но на самом деле это довольно небыстрый процесс. Может и год пройти, пока обновят. То есть просто нельзя взять и скачать новый рантайм, надо что-то менять в коде самого Юнити. А почему так происходит?

Сам задаюсь этим вопросом, обычно старый апи они объявляют как deprecated, но по сути он там так и остаётся навсегда. Сейчас у юнити новая заморочка - выносить части движка в отдельные модули, которые уже не будут предустановлены изкаропки, и их можно будет отдельно бесплатно скачать и установить через менеджер пакетов.

Отправлено Дядя Миша 28-06-2022 в 08:59:

Есть поучительный пример с Valve. Которая очень долго использовала Havok, но в итоге для Source3 написали свой собственный физический движок.
Хотя я лично про Havok ничего плохого сказать не могу, да и вообще не помню, чтобы на него кто-то ругался. Но вот, рассудили, что свой всё равно лучше будет. И это совершенно правильная тенденция. Никогда не возможно чужие либы друг с другом совместить идеальным образом.

Добавлено 28-06-2022 в 11:59:

Кстати, с JavaScript точно такая же шляпа прослеживается. Как-то KIQ давал свой движок потестить, так я скачал наверное штук 15 рантаймов, прежде чем нашёл тот, с которым он заработал. Ну и что в этом хорошего?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-06-2022 в 09:07:

Цитата:

Дядя Миша писал:
Кстати, с JavaScript точно такая же шляпа прослеживается. Как-то KIQ давал свой движок потестить, так я скачал наверное штук 15 рантаймов, прежде чем нашёл тот, с которым он заработал. Ну и что в этом хорошего?

Это мне напомнило как я собирал одну прогу на Делфях, там такая же беда. Причем оно работало только если установить в папку рабочего стола, а в остальных других местах кукиш.

Цитата:

Дядя Миша писал:
Отладчик встроенн прямо в язык, показывает всё, как студия. С номером строчки и именем исходного файла.

И что в нужный такт находится в памяти тоже?

Отправлено Дядя Миша 28-06-2022 в 11:05:

Цитата:

FiEctro писал:
И что в нужный такт находится в памяти тоже?

Можно включить отладку вот такого рода

C++ Source Code:

1	CALL: main( locals 52, args 0 );

2	TAKE_ADDR: stack[16]( <RESULT> '4445748' ) = &stack[8]( foo '4445748' );

3	PUSH_P: stack[52] = stack[16]( <RESULT> '4445748' );

4	OBJECT_CALL: PropTest::ctor( locals 12, args 1, size 4 );

5	ADD_P: stack[56]( <RESULT> '4445748' ) = stack[52]( this '4445748' ) + heap[240]( m_customText '0' );

6	STOREP_S: memory[4445748]->string( '' ) = heap[292]( <IMMEDIATE> '' );

7	ADD_P: stack[60]( <RESULT> '4445752' ) = stack[52]( this '4445748' ) + heap[244]( m_text '4' );

8	STOREP_S: memory[4445752]->string( '' ) = heap[292]( <IMMEDIATE> '' );

9	RETURN: void;

10	TAKE_ADDR: stack[16]( <RESULT> '4445748' ) = &stack[8]( foo '4445748' );

11	PUSH_P: stack[52] = stack[16]( <RESULT> '4445748' );

12	PUSH_S: stack[56] = heap[580]( <IMMEDIATE> 'Test' );

13	PUSH_I: stack[60] = heap[28]( true '1' );

14	OBJECT_CALL: PropTest::SetText( locals 16, args 3, size 12 );

15	IFNOT: stack[60]( useCustom '1' ) != 0, continue from 21;

16	ADD_P: stack[64]( <RESULT> '4445748' ) = stack[52]( this '4445748' ) + heap[240]( m_customText '0' );

17	STOREP_S: memory[4445748]->string( 'Test' ) = stack[56]( text 'Test' );

18	GOTO: jump from 24 to 27;

19	RETURN: void;

Уж не знаю, насколько это будет для вас информативно.

Добавлено 28-06-2022 в 12:29:

Оно тут показывает совершаемые операции, названия переменных, содержимое переменных, их адреса и какая память используется - стек, глобальная, объекты. Ну подробнее с опкодами навряд ли возможно.

Добавлено 28-06-2022 в 13:59:

Для конкретных объектов так же можно будет полностью вывести их содержимое, в соответствии с типами членов. Ну то есть для оригина вывести позицию, для таргета - имя, итогдалие.
Но это умела еще машинка первой кваки и ничего особенного тут нет.
Виртуальные машины именно за этим и заводят.

Добавлено 28-06-2022 в 14:05:

Кстати. Не помню уж где, то ли на хабре, но вычитал что в Юнити нет никаких стандартных методов поиска объектов в трёхмерном пространстве в заданном радиусе. Вот просто нету и всё. Причём там же в каментах приводили в пример Сорс, вот мол посмотрите - там и то есть такой поиск, а в Юнити - нету. Хотя этот поиск наличествовал еще в первом Квейке.
Мне как-то странно такое читать. Действительно его нет в Юнити?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-06-2022 в 11:18:

Цитата:

Дядя Миша писал:
Кстати. Не помню уж где, то ли на хабре, но вычитал что в Юнити нет никаких стандартных методов поиска объектов в трёхмерном пространстве в заданном радиусе.

В юнити такие вещи предполагается делать через колайдер - триггер, либо через сферкаст. Я подобным образом например для игрока нормали на поверхности перебираю. Может ещё какие нибудь методы есть, не знаю, не углублялся так далеко. Но вообще в Юнити перебор объектов и их компонентов в реальном времени довольно тяжелая операция по ЦПУ таймингу, и для ПК она в целом ок, но вот мобильные процы просаживаются по фпс.

Отправлено Дядя Миша 28-06-2022 в 11:34:

Цитата:

FiEctro писал:
В юнити такие вещи предполагается делать через колайдер - триггер, либо через сферкаст

Но ведь этот коллайдер не увидит точечные логические энтити, например, хотя в Юнити помоему такого и так нету. Там любой объект непременно должен иметь какую-то модель.
Да и само обращение к физическому движку ради простого перечисления объектов довольно тяжелая операция, особенно если за кадр надо это делать много раз. В кваке проще - там регулярная сетка AABB-дерева, в которой пространственный поиск весьма быстр. Я подобную сетку даже для рассчётов радиосити использую и она справляется лучше, чем например BSP-дерево в аналогичной ситуации.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-06-2022 в 12:03:

Цитата:

Дядя Миша писал:
Но ведь этот коллайдер не увидит точечные логические энтити, например, хотя в Юнити помоему такого и так нету. Там любой объект непременно должен иметь какую-то модель.
Да и само обращение к физическому движку ради простого перечисления объектов довольно тяжелая операция, особенно если за кадр надо это делать много раз.

В Юнити нет понятия Энтитии, в Юнити у тебя есть абстрактные объекты пустышки с компонентом Трансформ (позиция, вращение и скейл), а так же иерархию, имя, слои для физики (в т.ч. подразделение на статику и динамику) и тег. Сами компоненты выступают в роли отдельных скриптов (энтитей), и ты к ним можешь обращаться из своих скриптов которые навешиваются как кастомные компоненты. Т.е. если тебе например чтобы сделать какой то сложный объект, не нужно писать много кода, ты просто задаешь ему компоненты с нужными параметрами и управляешь ими через скрипт или эвенты. В кармаковских же движках пришлось бы либо хардкодить, либо заниматься доктортрессизмом городя конструкции из кучи объектов (вспоминаем тему про брашевой салют). Про модель это вообще враньё, Меш рендер это отдельный компонент, которого по дефолту может и не быть у объекта.

Цитата:

Дядя Миша писал:
В кваке проще - там регулярная сетка AABB-дерева, в которой пространственный поиск весьма быстр. Я подобную сетку даже для рассчётов радиосити использую и она справляется лучше, чем например BSP-дерево в аналогичной ситуации.

Ну то что я перечислил это стандартные рекомендации которые можно найти на форумах и справке. AABB дерево в Юнити тоже есть, но я хз что это и как с ним работать.

Отправлено Дядя Миша 28-06-2022 в 12:07:

Цитата:

FiEctro писал:
В Юнити нет понятия Энтитии, в Юнити у тебя есть объекты

Без разницы как называть. В кваке тоже логические энтити содержали в себе трансформацию, хотя, понятно, она им была не нужна.

Цитата:

FiEctro писал:
Т.е. если тебе например чтобы сделать какой то сложный объект, не нужно писать много кода

Как правило достаточно некоторого набора заготовок, который можно переиспользовать в большинстве ситуаций, так сказать.
Но опять же - в Юнити нет ни сейв-рестора ни переноса объектов на следующий уровень, это целиком лежит на совести разработчика.
А как оно это реализует - вопрос спорный. Может конечно в пятом Юнити сейв-рестор появился, не знаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-06-2022 в 12:09:

Цитата:

Дядя Миша писал:
Но опять же - в Юнити нет ни сейв-рестора ни переноса объектов на следующий уровень, это целиком лежит на совести разработчика.

Всё есть, можно записывать как в реестр, так и в жсоны в пару строк кода, причем работает это невероятно быстро, практически так же как и бинарные файлы. Просто там логика работы сцен немного отличная от Кармаковской. Мобильные игры это активно используют. Тоже самое касается и сети, хотя в последнее время её вынесли в отдельный ассет.

Отправлено SNMetamorph 28-06-2022 в 12:13:

Цитата:

FiEctro писал:
Какие будут инструменты для отладки?

Меня больше интересует, будут ли какие-то удобные инструменты для разработки на этом скриптовом языке: подсветка синтаксиса, иерархия вызовов функций, поиск ссылок, и т.д. Или же юзиру предлагается писать код в блокноте?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 28-06-2022 в 12:15:

Цитата:

FiEctro писал:
Всё есть, можно записывать как в реестр, так и в жсоны в пару строк

Кого в реестр записывать? Сейв в игре?

Цитата:

SNMetamorph писал:
будут ли какие-то удобные инструменты для разработки на этом скриптовом языке: подсветка синтаксиса, иерархия вызовов функций, поиск ссылок, и т.д. Или же юзиру предлагается писать код в блокноте?

Со временем появится и своя студия, вероятно. Но всегда можно будет использовать какой-то редактор для С++, я думаю он справится.
Т.к. там многое совпадает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-06-2022 в 12:16:

Цитата:

Дядя Миша писал:
Кого в реестр записывать? Сейв в игре?

Да можно и сейв, в целом вообще всё что угодно можешь записать, например стринг "Здесь был Дядя Миша", но ничего не мешает записать просто жсон на диск, или бинарник. С реестром просто работать проще, там даже заморачиваться не нужно, он сам всё за тебя сделает для каждой платформы.

https://www.red-gate.com/simple-tal...ata-with-unity/

К тому же поскольку у тебя обычный Шарп ты можешь работать и с обычной файловой системой в обход Юнити. Я такие финты прочесывал, когда нужно было прочесать все свободные открытые порты в винде, сама Юнити ничего об этом не знает, а Шарп вполне.

Отправлено Дядя Миша 28-06-2022 в 12:31:

C++ Source Code:

1	void SaveGame()

3	PlayerPrefs.SetInt("SavedInteger", intToSave);

4	PlayerPrefs.SetFloat("SavedFloat", floatToSave);

5	PlayerPrefs.SetString("SavedString", stringToSave);

6	PlayerPrefs.Save();

7	Debug.Log("Game data saved!");

Правильно понимаю, миллион строчек SetInt, SetFloat, SetString это и есть твой быстрый простой и удобный способ сохранить данные?

Добавлено 28-06-2022 в 15:28:

Цитата:

Back in the day, many games had little need for saving data since you could finish a game in about an hour.

Раньше это когда? Сейвы были уже в Wolf3D.

Добавлено 28-06-2022 в 15:31:

Цитата:

No, your eyes do not deceive you. The actual act of saving your game takes only a few lines of code

Я не пойму, он издевается чтоли, или действительно верит в то что пишет?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-06-2022 в 12:32:

Цитата:

Дядя Миша писал:
Правильно понимаю, миллион строчек SetInt, SetFloat, SetString это и есть твой быстрый простой и удобный способ сохранить данные?

Смотря под какие цели, для простеньких проектов - вполне. Для чего то более крупного конечно можно это автоматизировать, но уже рученками ога.

Отправлено Дядя Миша 28-06-2022 в 12:35:

Дочитал статью. Изумительно, просто измуительно. Давно я такого индусского кода не видел. Значит в шарпе вообще нет встроенных средств сериализации. Даже в девятой версии или какая там сейчас актуальная.

Добавлено 28-06-2022 в 15:35:

Цитата:

FiEctro писал:
Для чего то более крупного конечно можно это автоматизировать

Каким образом? Ты понимаешь что первое от второго

C++ Source Code:

1	void SaveGame()

3	BinaryFormatter bf = new BinaryFormatter();

4	FileStream file = File.Create(Application.persistentDataPath

5	+ "/MySaveData.dat");

6	SaveData data = new SaveData();

7	data.savedInt = intToSave;

8	data.savedFloat = floatToSave;

9	data.savedBool = boolToSave;

10	bf.Serialize(file, data);

11	file.Close();

12	Debug.Log("Game data saved!");

Не отличается вообще ничем? Я не понял, почему первый способ он назвал простым, а второй сложным, если это одни и те же яйца.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-06-2022 в 12:37:

Цитата:

Дядя Миша писал:
Дочитал статью. Изумительно, просто измуительно. Давно я такого индусского кода не видел. Значит в шарпе вообще нет встроенных средств сериализации. Даже в девятой версии или какая там сейчас актуальная.

https://docs.unity3d.com/Manual/scr...ialization.html

Отправлено Дядя Миша 28-06-2022 в 12:57:

FiEctro совсем другое дело!
Надо понимать, это появилось только в 2021-м году?

Добавлено 28-06-2022 в 15:57:

А нет, с 2019-го. Т.е. даже не с пятой версии. Я кстати был уверен, что пятая версия щас самая актуальная, оказывается она уже давно устарела и deprecated. Очуметь можно. Частое обновлений версий вовсе не говорит о том, что продкт развивается. Это значит, что старыми версиями вообще было невозможно пользоваться.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-06-2022 в 14:16:

Цитата:

Дядя Миша писал:
А нет, с 2019-го. Т.е. даже не с пятой версии. Я кстати был уверен, что пятая версия щас самая актуальная, оказывается она уже давно устарела и deprecated. Очуметь можно. Частое обновлений версий вовсе не говорит о том, что продкт развивается. Это значит, что старыми версиями вообще было невозможно пользоваться.

Ох, что там было в 2019 году я не знаю. Полазий сам по справке там много интересного по шарпу и архитектуре Юнити, чем сидель и гадать на кофейной гуще что там есть, а чего нет.

Отправлено Crystallize 28-06-2022 в 14:23:

Цитата:

Дядя Миша писал:
PUSH_P

Это надо иметь базовые представления об асме чтоб такое дебажить?

Цитата:

Дядя Миша писал:
В кваке проще - там регулярная сетка AABB-дерева, в которой пространственный поиск весьма быстр.

Вот кстати да, юзер-френдли инструментов для работы с деревом бы, как с массивами например. Чтобы был счетчик вида [x][y] для х+1 можно было быть уверенным что оно рядом и касается предыдущего листа.

Отправлено Дядя Миша 28-06-2022 в 14:44:

Цитата:

Crystallize писал:
Это надо иметь базовые представления об асме чтоб такое дебажить?

Это RISC-архитектура, она сильно проще чем CISC. В CISC ты никогда не знаешь сколько аргументов нужно команде и сколько тактов она занимает, здесь аргументов не может быть более трёх и менее одного.
Да и собственно вся операция выводится на экран, думаю можно разобраться что происходит. Но опять же, это на случай если что-то скомпилилось с ошибкой. Т.е. это скорее для меня, для отладки компилятора.
Но в любом случае штука удобная и полезная.

Цитата:

Crystallize писал:
Вот кстати да, юзер-френдли инструментов для работы с деревом бы, как с массивами например

Любое дерево легко визуализировать как регулярную или нерегулярную сетку. В NT кстати есть такая визуализация. r_show_leafs 1

Добавлено 28-06-2022 в 17:44:

PS. Я потом наверное наглядно распишу как код на С++ подобном языке превращается в опкоды, чтобы вы не боялись это читать. Ну для тех, кто интерисуется конечно. Скорее всего такой низкий уровень отладки вам просто не понадобится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-06-2022 в 18:13:

Про отладку имелось ввиду что то вроде этого:
https://docs.microsoft.com/ru-ru/do...vots=dotnet-6-0

Отправлено Crystallize 28-06-2022 в 18:26:

Цитата:

Дядя Миша писал:
В NT кстати есть такая визуализация. r_show_leafs 1

А где-то еще есть такая?

Отправлено Дядя Миша 28-06-2022 в 18:41:

Брыкпоинт у меня тоже имеется, если речь об этом.
Еще можно стек размотать и показать map calls.
Единственный косяк - из-за близости архитектуры к реальной, она всё же может теоретически спровоцировать вылет интерпретатора, вместо безопасной остановки с ошибкой. Но думаю к финальной версии этого уже не будет.

Добавлено 28-06-2022 в 21:41:

Цитата:

Crystallize писал:
А где-то еще есть такая?

Больше нигде не знаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-06-2022 в 12:18:

Интересная всё же штука - целевая аудитория. Вот вышел этот видос про Xash у StalkerOS. Ну какая там графика в 2022-м году? Смех один.
А народ в каментах пишет - ура, отлично, давай-давай.
И наоборот - на Хабре блог Unigine публикует цикл разных статей (они активизировались в рамках потенциального импортозамешения) и народ на них льёт ощутимый негатив, на мой взгляд - часто на ровном месте.
Хотя казалось бы - отечественный производитель, может быть единственный в своём роде. Но нет - не любят наши его почему-то. Причём вопрос лежит даже не в технической плоскости. Это какая-то иррациональная неприязнь, на мой взгляд.
Вот и вопрос - что надо было сделать или наоборот не сделать, чтобы заслужить к себе такое удивительное отношение? Не понимаю.
Хотя может я и не прав, а там просто пара хейтеров в каментах тусуется?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-06-2022 в 12:55:

Цитата:

Дядя Миша писал:
И наоборот - на Хабре блог Unigine публикует цикл разных статей (они активизировались в рамках потенциального импортозамешения) и народ на них льёт ощутимый негатив, на мой взгляд - часто на ровном месте.

Наверное автор денег много просит.

Добавлено 29-06-2022 в 15:55:

Цитата:

Дядя Миша писал:
Хотя казалось бы - отечественный производитель, может быть единственный в своём роде. Но нет - не любят наши его почему-то. Причём вопрос лежит даже не в технической плоскости. Это какая-то иррациональная неприязнь, на мой взгляд.

Да всё очень просто, у нас очень любят обещать, но ничего не делать. По этому оптимизм выгорел весь. На западе тоже таким любят заниматься, но потраченные деньги как правило возвращают.

Отправлено Дядя Миша 29-06-2022 в 12:56:

Цитата:

FiEctro писал:
Наверное автор денег много просит.

Community Version Free Edition бесплатно, то есть даром.
Правда она появилась относительно недавно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-06-2022 в 12:57:

Цитата:

Дядя Миша писал:
Вот и вопрос - что надо было сделать или наоборот не сделать, чтобы заслужить к себе такое удивительное отношение? Не понимаю.

Я сто раз говорил - работа с комьюнити и понижение порога вступления тебе всё зарешают. Я вот и не понимаю почему тот же Ксерокс жнётся. Давно бы открыл уже джек и волатилу для модеров.

Отправлено Дядя Миша 29-06-2022 в 12:57:

Надо сказать, что лично мне очень не нравятся все эти анальные привязки даже к бесплатным версиям, когда движку надо логиниться на сайт разработчика и сообщать что юзер такой-то снова в сети и опять кубал полтора часа. Надо будет в дальнейшем продумать эти политику.
Я вообще ненавижу софт, намертво привязанный к сети.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-06-2022 в 13:50:

Дядя Миша
Заведи репозиторий, и не надо ничего привязывать. К тому же будешь спокоен что диск не сдохнет внезапно со всеми наработками.

Отправлено XaeroX 29-06-2022 в 14:25:

Цитата:

FiEctro писал:
Я вот и не понимаю почему тот же Ксерокс жнётся. Давно бы открыл уже джек и волатилу для модеров.

Мне кажется, у комьюнити вполне достаточно движков и редакторов для работы. Не хочу плодить сущности.

Добавлено 29-06-2022 в 10:23:

Цитата:

Дядя Миша писал:
Это какая-то иррациональная неприязнь, на мой взгляд.

Это национальная черта - ненавидеть всё отечественное, что хоть как-то выделяется. Тяжкое наследие советской унификации.
Западным, наоборот, принято восхищаться. Наличие западной прописки - это своеобразный знак качества. Мол, мы у них учимся, а не они у нас. Если, например, в России делают волатилу, которая запускается на старых системах - то это признак устаревания движка и общей отсталости автора. А если такую же волатилу делают в Канаде - то это новый интересный тренд, забота авторов о пользователях, и вообще полёт инженерной мысли.

Добавлено 29-06-2022 в 10:25:

Ну вот может, в свете последних событий, что-то изменится в вопросе преклонения перед западом? Хотя я в этом сомневаюсь. Это преклонение вбивали в головы ещё с тех времён, когда российская аристократия считала позорным говорить на русском языке, а не на французском. Так быстро ничего не поменяется.

__________________

Отправлено Дядя Миша 29-06-2022 в 15:10:

Цитата:

FiEctro писал:
Заведи репозиторий, и не надо ничего привязывать

Перечитай еще раз внимательно, пожалуйста.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 29-06-2022 в 23:04:

Цитата:

Дядя Миша писал:
Как-то KIQ давал свой движок потестить

Он был не на JavaScript, а на Java 8

Добавлено 30-06-2022 в 02:04:

Я конечно могу ошибаться, но главная проблема сериализации, в отличие от ручного SaveInt, SaveSomeShit - в том, что по сути это дамп, в случае явы или шарпа дамп объектов, а значит в бинарк записывается куча ненужного г..., чтобы потом можно было быстро сделать условный memcpy из файла сохранения

__________________
-Brain is dead-

Отправлено Дядя Миша 30-06-2022 в 06:12:

Цитата:

KiQ писал:
Он был не на JavaScript, а на Java 8

Я до сих пор не могу смириться с тем, что JavaScript и Java это два совершенно разных языка от разных авторов и никакой связи между ними нет.
Я вообще раньше думал, что у Java есть JIT, а у JavaScript нету, вот и вся разница.

Цитата:

KiQ писал:
Я конечно могу ошибаться, но главная проблема сериализации, в отличие от ручного SaveInt, SaveSomeShit - в том, что по сути это дамп, в случае явы или шарпа дамп объектов, а значит в бинарк записывается куча ненужного г

Правильно. Поэтому у меня в языке встроенные средства для определения размеров этих переменных. Максимальные значения и кол-во бит. Эта же информация используется для передачи по сети с заданной точностью. И компилятор, основываясь на этой информации может в отладочном режиме автоматически вставлять range-check проверки.
Этого больше нет ни в одном языке.

Добавлено 30-06-2022 в 09:12:

Хотя нет, вру, кажется в Delphi было нечто подобное. Но там явным образом требовалось каждому типу указывать диапазон, что не очень удобно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-07-2022 в 13:44:

Цитата:

XaeroX писал:
Это национальная черта - ненавидеть всё отечественное, что хоть как-то выделяется. Тяжкое наследие советской унификации.
Западным, наоборот, принято восхищаться. Наличие западной прописки - это своеобразный знак качества. Мол, мы у них учимся, а не они у нас.

Ты подменяешь понятия. В РФ и Союзе было дофига офигенной продукции. Ненависть как правило к тем кто в три дорога впаривает что то дешевое, либо даёт какие то нелепые обещания космического масштаба. И так уж получилось, что среди наших местных стартаперов такое в тренде.

Цитата:

XaeroX писал:
Ну вот может, в свете последних событий, что-то изменится в вопросе преклонения перед западом? Хотя я в этом сомневаюсь. Это преклонение вбивали в головы ещё с тех времён, когда российская аристократия считала позорным говорить на русском языке, а не на французском. Так быстро ничего не поменяется.

Логично что разговаривать на иностранных языках как и образование могли позволить себе только состоятельные граждане. А если ничего из этого нет, о чем говорить с этим человеком? О том какой Царь хороший, а все остальные ему завидуют? Или то что земля упадет на небесную твердь?

Отправлено Дядя Миша 01-07-2022 в 15:19:

FiEctro О, ты-то мне и нужен!

Как устроен GUID в Unity? Вот у нас есть 128 битный индентификатор ресурса. Из чего он получается? Из пути к этому ресурсу или из контрольной суммы самого ресурса? Или еще как-то иначе сделано?
Может есть где-то в документации об этом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 01-07-2022 в 15:20:

Цитата:

XaeroX писал:
Это национальная черта - ненавидеть всё отечественное, что хоть как-то выделяется.

Пусть оно попробует выделяться выгодно, а не хоть как-то. Глядишь и полюбят.

Отправлено Дядя Миша 01-07-2022 в 15:22:

Нашёл вот это: https://makaka.org/unity-tutorials/guid
Но там ни слова о том, как он создаётся.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-07-2022 в 15:55:

Дядя Миша
Фиг его знает, я не вникал. Посмотри тут:
https://unityatscale.com/unity-meta...iles-and-guids/
https://unityatscale.com/unity-meta...-file-deep-dive

Или даже тут?
https://gist.github.com/ZimM-LostPo...a3e5a1be183ac19

Если ты про идентификацию, то он просто мета файлики создает ко всем ресурсам.

Отправлено Дядя Миша 01-07-2022 в 16:51:

Цитата:

FiEctro писал:
просто мета файлики создает ко всем ресурсам

Я пытаюсь понять на основании чего генерируется вот это значение GUID.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 01-07-2022 в 17:11:

Цитата:

FiEctro писал:
Ненависть как правило к тем кто... даёт какие то нелепые обещания космического масштаба.

Ну и как, сильно у нас ненавидят Илона Маска?

Цитата:

FiEctro писал:
И так уж получилось, что среди наших местных стартаперов такое в тренде.

Это, имхо, в тренде у абсолютно любых стартаперов. Иначе им никто денег не даст.

Цитата:

nemyax писал:
Пусть оно попробует выделяться выгодно, а не хоть как-то. Глядишь и полюбят.

Что одному выгодно - другому совершенно невыгодно, и наоборот.
Я читал такую байку, что мол когда то ли в Европе, то ли в Америке захотели сделать ультра-бюджетный, ремонтопригодный и дешёвый в обслуживании автомобиль, чтобы обспечить им даже тех, кто испытывает бездомность на регулярной основе, то с изумлением обнаружили, что в России такой уже давно разработан и активно используется. Называется "жигули". А у нас тем временем постили картинки про "совершенство не нуждается в доработке" и "не можем повторить".
Ну ты можешь сказать - подумаешь, байка. А я скажу - нет пророка в своём отечестве.

__________________

Отправлено FiEctro 01-07-2022 в 17:13:

Цитата:

XaeroX писал:
Ну и как, сильно у нас ненавидят Илона Маска?

Вообще многие ненавидят, например Рогозин.

Цитата:

XaeroX писал:
Называется "жигули".

Жигули совсем не бюджетный автомобиль. Это как цветные принтеры, производитель продает себе в убыток, но зато потом зарабатывает на комплектующих куда больше чем за сток.

Цитата:

Дядя Миша писал:
Я пытаюсь понять на основании чего генерируется вот это значение GUID.

Я спросил ещё юнитистов, сказали что возможно по времени обнаружения файла.

Отправлено XaeroX 01-07-2022 в 17:20:

Цитата:

FiEctro писал:
Вообще многие ненавидят, например Рогозин.

А ты уверен, что за это?
Может, это ненависть между конкурентами.

Добавлено 01-07-2022 в 13:20:

Цитата:

FiEctro писал:
Жигули совсем не бюджетный автомобиль.

Я не в курсе, какая ситуация с авторынком сейчас, но когда я в 2009 году подумывал о покупке авто, лады были весьма доступны по цене даже в сравнении с ближайшим конкурентом в лице рено-логан. И кстати, мне они нравились (я катался на 2114 и 2115).
Ну понятное дело, тогда никто не слышал ни про какие подушки безопасности и системы курсовой устойчивости, а про АБС нам в автошколе рассказывали как про какую-то супермодную фишку.

__________________

Отправлено Дядя Миша 01-07-2022 в 17:51:

Цитата:

XaeroX писал:
Ну и как, сильно у нас ненавидят Илона Маска?

Недолюбливают, скажем так.

Раздели пожалуйста темы, у вас гляжу спец-олимпиада намечается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 01-07-2022 в 19:28:

Цитата:

Дядя Миша писал:
у вас гляжу спец-олимпиада намечается.

Лениво. Ладно, засчитайте мне техническое поражение.

__________________

Отправлено Дядя Миша 02-07-2022 в 08:27:

Ознакомился с материалами по ссылкам, что дал FiEctro но всё равно пока не очень понятно.

https://unityatscale.com/unity-meta...-file-deep-dive вот здесь к примеру написано что рядом с каждым ресурсом создаётся мета-файлик, который содержит не только GUID, но и настройки для ресурса.
Но это же абсурд! Смысл ресурса как раз в том, что он может бы переиспользован как угодно, а не иметь какие-то конкретные настройки.
Никто не запретит мне одну и ту же текстуру влепить как на уровень, так и в GUI. Так почему же у нас в этой схеме ресурс довлеет над материалом?
Получается что к каждому ресурсу полагается только один материал, а если вы хотите этот же ресурс использовать с другими настройками материала, вам надо... сделать копию этого ресурса. Изумительно!
В противовес этому, в том же Quake3 шейдеры рассматривались именно как высокоуровневая концепция, которая ссылается на реальные файлы, но на какие именно - это персональное дело каждого шейдера. Ресурс по сути не может иметь в себе каких-то настроек привязанных к редактору или компилеру. Точнее говоря может, если как раз процесс компиляции - неявный. В этом и есть главная проблема на мой взгляд. С одной стороны кажется удобным что можно избежать явного процесса компиляции, с другой стороны это превращается в некоторый ад, потому что движок обязан следить за всеми изменениями и оперативно перекомпилировать изменённые ресурсы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-07-2022 в 08:42:

Цитата:

Дядя Миша писал:
Но это же абсурд! Смысл ресурса как раз в том, что он может бы переиспользован как угодно, а не иметь какие-то конкретные настройки.
Никто не запретит мне одну и ту же текстуру влепить как на уровень, так и в GUI. Так почему же у нас в этой схеме ресурс довлеет над материалом?
Получается что к каждому ресурсу полагается только один материал, а если вы хотите этот же ресурс использовать с другими настройками материала, вам надо... сделать копию этого ресурса. Изумительно!

Ну так у тебя есть тоже для спрайтов отдельный формат, для UI тоже другой.
Там настройки компрессии для дифузок и нормалей, оптимизации текстуры, мип карты, кубамапы, прозрачность и вот это всё, он походу просто в ддс потом компилирует их. С моделями тоже самое, можно нарезать анимации, задать ИК эвенты и т.д. и т.п. Спрайты можно на тайлы нарезать и даже пришить к ним скелетку с развесовкой!

А система материалов это просто шейдер внутри которого происходит любая магия, значения переменных которого хранятся в .mat файлике.
Я вот например использую Шейдер форж для визуального программирования шейдеров.
https://acegikmo.com/shaderforge/nodes/

Единственный минус, он не умеет делать шейдер в несколько проходов, хотя сам шейдерный язык юнити это делать позволяет.

Ку3 система это абсолютно негибкий и захардкоженный костыль.

Отправлено Дядя Миша 02-07-2022 в 08:59:

Теперь вот по этой ссылке: https://unityatscale.com/unity-meta...iles-and-guids/
Для чего нужны GUID мне и так было понятно. В статье это лишний раз подтвердили. Если мы переименуем ресурс или переместим его куда-то еще, то Unity всё равно его обнаружит и подхватит. Казалось бы удобно?
На практике я ни разу не видел, чтобы у кого-то возникало желание переименовывать или перемещать ресурсы. Если у нас моделька пушки - кладём в models\weapons. Если у нас моделька монстра кладём models\monsters. Если у нас текстура, допустим дерева кладём textures\wood. Это простая и понятная схема, которая не требует никаких доработок или изменений. GUID же в Unity пропагандирует строго обратную модель - раскидайте ресурсы как попало, но мы их всё равно найдем.
Особенно любопытно в этом плане то, что во первых связь между ресурсом и его мета-файлом осуществляется всё равно по имени и пути, т.е. если разъединить ресурс с мета-файлом, начнётся интересное. Опять же я не знаю, если мы уничтожим мета-файл, будет ли новый сгенерирован с точно таким же GUID или нет? И если да, то на что он опирается? На внутренние данные файла? А если я изменю саму текстуру и удалю meta-файл, новый GUID уже будет отличаться от старого и все ссылки превратятся в тыкву?
А как я по старому GUID пойму на что он ссылался, оно же нечитабельно для людей? Вопросы-вопросы.
https://gist.github.com/ZimM-LostPo...a3e5a1be183ac19
Вот по этой ссылке мне удалось понять ключевое - ReadAllText, т.е. хэш всё же генерируется на основе данных всего файла. Отсюда же и принципиальная невозможность хранить GUID внутри самого файла.
Корочи очень спорная система на мой взгляд.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-07-2022 в 09:04:

Цитата:

Дядя Миша писал:
Если у нас моделька пушки - кладём в models\weapons. Если у нас моделька монстра кладём models\monsters. Если у нас текстура, допустим дерева кладём textures\wood. Это простая и понятная схема, которая не требует никаких доработок или изменений. GUID же в Unity пропагандирует строго обратную модель - раскидайте ресурсы как попало, но мы их всё равно найдем.

Это работает ровно до тех пор пока ты не начнешь подгружать ассеты. В твоём случае потом всё это говно придётся подчищать ручками, а в юнити его можно просто выгрузить. Ничего тебе не мешает сделать самому свою папку Assets\UnkleMike\models textures sounds levels и т.д.

Отправлено Дядя Миша 02-07-2022 в 09:11:

Цитата:

FiEctro писал:
Там настройки компрессии для дифузок и нормалей, оптимизации текстуры, мип карты, кубамапы, прозрачность и вот это всё, он походу просто в ддс потом компилирует их

Мой компилятор в DDS не требует никаких настроек, сам понимает что и во что сжимать, генерировать ли мип-уровни или нет. То есть вообще даже не возникал вопрос, чтобы ему надо было что-то указывать явным образом.
Правда он опирается на суффиксы в названии текстур, но не только.
Там есть встроенный анализтор, который позволяет 100% отличить текстуру от нормалмапы или чернобелое изображение от цветного, проверить альфа-канал и решить в какой формат оптимальнее всего сжимать.
Впрочем он детектит даже битые нормал-мапы, которые нельзя сжимать в ATI2N, потому что у них Z отрицательный. Я кстати совсем недавно с удивлением обнаружил что на спонзе есть несколько таких нормалмап.
У меня там целый блок анализа, который сжимает нормалмапу и смотрит качество расхождения и на основании этого делает выводы - оптимально ли сохранять эту текстуру в ATI2N или нет.

Добавлено 02-07-2022 в 12:11:

Цитата:

FiEctro писал:
Это работает ровно до тех пор пока ты не начнешь подгружать ассеты

Если вся игра сделана на ассетах, мне это напоминает делфи, где никто ничего не писал, а все искали платные компоненты. Подобный подход в перспективе ни к чему хорошему не приводит. Нельзя просто накидать в папку платных ассетов и думать, что из этого получится игра.
А знаете почему? Если бы игры можно было бы клепать таким образом, разрабы Unity вам бы его нипочём не дали. Они бы просто клепали такие ассеты, кидали бы их в папку и каждый месяц выпускали новую игру и наживались именно на этом. Ну кто бы отдал рабочий и ненапряжный способ заработка? Но они сами даже не пытаются игру сделать. Вот как раз поэтому.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-07-2022 в 09:12:

Ну вот захотел ты допустим кубамапу текстуру подгрузить, и она например одной картинкой сделана, ты что отправишь юзверя резать её вручную в фотошопе? Или например захочешь ты чтобы у тебя все текстуры в степень двойки сконвертировались в проекте, опять юзера отправишь ковырять в фотошоп? Наверное проще показать чем рассказать:
https://docs.unity3d.com/Manual/cla...reImporter.html

Цитата:

Дядя Миша писал:
Если вся игра сделана на ассетах, мне это напоминает делфи, где никто ничего не писал, а все искали платные компоненты. Подобный подход в перспективе ни к чему хорошему не приводит. Нельзя просто накидать в папку платных ассетов и думать, что из этого получится игра.
А знаете почему? Если бы игры можно было бы клепать таким образом, разрабы Unity вам бы его нипочём не дали. Они бы просто клепали такие ассеты, кидали бы их в папку и каждый месяц выпускали новую игру и наживались именно на этом. Ну кто бы отдал рабочий и ненапряжный способ заработка? Но они сами даже не пытаются игру сделать. Вот как раз поэтому.

У тебя какое то извращенное представление об ассетах. По сути это как те же либы в программировании, только обычно это просто наборы скриптов и преднастроенных ресурсов. Например тот же Shaderforge является визуальным редактором внутри IDE юнити и средствами юнити написанный фанатами. Ты же опять предлагаешь всё хардкодить ломая всю гибкость.

Отправлено Дядя Миша 02-07-2022 в 09:20:

В принципе проблема решения конфликтов имён может быть разрешена не через GUID, которые нечеловекочитаемые, а через пространство имён как в С++. То есть каждый ассет может иметь своё пространство имён и не мешать другим. Я потом подумаю над этой схемой. Но не раньше чем у меня появится свой мета-контейнер для хранения ресурсов.

А что касается ассетов содержащих код - так где гарантия, что куча таких ассетов не будет конфликтовать друг с другом? Это как раньше из кучи туторов код копипастили и оно друг с другом могло не работать, теперь по сути тоже самое, только копипастить ничего не надо, просто денег заплати и всё. Но проблема по сути не решена.

Добавлено 02-07-2022 в 12:19:

Цитата:

FiEctro писал:
Ну вот захотел ты допустим кубамапу текстуру подгрузить, и она например одной картинкой сделана

В форме креста что ли? А Юнити типа такие картинки может самостоятельно в кубемапу разложить?

Цитата:

FiEctro писал:
Или например захочешь ты чтобы у тебя все текстуры в степень двойки сконвертировались в проекте

Видишь ли какое дело - DXT в силу своей природы не любит текстуры не степени двойки, т.к. там блоки 4х4. Он бы их сконвертил в любом случае по возможности. И не потому что тебе там что-то захотелось, а потому что формату это требуется.
Опять таки, если у моделей есть какие-то настройки, ну там эвенты у анимаций, понятное дело, что это надо где-то хранить.
Ну так ведь это исходник. Который при компиляции может выдать некоторые ошибки. А если компиляция групповая перед экспортом, ты разве успеешь увидеть что он там тебе напишет?

Добавлено 02-07-2022 в 12:20:

Да и мне лично непонятно, ну вот я скачал чужой ассет, модельку гнума.
Это что, я могу её лично декомпилировать слегка отредактировать и выдать за свою? Или в юнити есть защита от декомпиляции чужих ресурсов?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-07-2022 в 09:20:

Цитата:

Дядя Миша писал:
А что касается ассетов содержащих код - так где гарантия, что куча таких ассетов не будет конфликтовать друг с другом? Это как раньше из кучи туторов код копипастили и оно друг с другом могло не работать, теперь по сути тоже самое, только копипастить ничего не надо, просто денег заплати и всё. Но проблема по сути не решена.

Они не будут кофликтовать, потому что в юнити как правило скрипты заизолированы друг от друга, и взаимодействуют друг с другом по правилам прописанным внутри скрипта. Это обычные классы как в программировании.

C++ Source Code:

1	public class MainHero : MonoBehaviour

3	public int health;

C++ Source Code:

1	public class AnotherHero : MonoBehaviour

3	MainHero mainHero;

4	int anotherHealth;

6	void Start()

8	mainHero = GameObject.FindGameObjectWithTag("YOUR MAINHERO OBJECT TAG").GetComponent<MainHero>();

10	anotherHealth = mainHero.health;

а два одинаковых класса MonoBehaviour выдадут просто ошибку компилятора.

Отправлено Дядя Миша 02-07-2022 в 09:26:

Вообще на мой взгляд вот эта практика "накидал отвсюду чужого, нажал кнопку export и получил игру" она невероятно порочная т.к. внушает ложные надежды и порождает иллюзии. Ну не работает это так.
Оно рано или поздно вылезет самым интересным образом, когда уже никто не сможет понять, что именно сглючило. Слишком уж много всего будет накидано.

Добавлено 02-07-2022 в 12:25:

Цитата:

FiEctro писал:
Ты же опять предлагаешь всё хардкодить ломая всю гибкость.

Я как раз не предлагаю ничего хардкодить, наоборот. Просто эта схема очень проблематичная.

Цитата:

FiEctro писал:
По сути это как те же либы в программировании, только обычно это просто наборы скриптов и преднастроенных ресурсов.

Так и проблемы у них ровно те же самые, что и у сторонних либ.

Добавлено 02-07-2022 в 12:26:

И еще мне непонятно что за загадочные обращения к Texture2D внутри шарпа. Там еще какой-то доступ к ландшафту. Очень всё это подозрительно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-07-2022 в 09:27:

Цитата:

Дядя Миша писал:
Вообще на мой взгляд вот эта практика "накидал отвсюду чужого, нажал кнопку export и получил игру" она невероятно порочная т.к. внушает ложные надежды и порождает иллюзии. Ну не работает это так.
Оно рано или поздно вылезет самым интересным образом, когда уже никто не сможет понять, что именно сглючило. Слишком уж много всего будет накидано.

Ты утрируешь, ассеты прекрасно отгружаются и дебажатся. Например я не понимаю зачем мне писать тот же матан зеркал и порталов с нуля, если это типовая задача которая уже имеет готовую реализацию? Всеравно будешь копипастить тот же самый код, только вместо 1 минуты ты потратишь несколько дней. Ассет оказался плохой и глючный? Не вопрос, отгружаем его, подгружаем новый и прописываем новые зависимости.

Цитата:

Дядя Миша писал:
И еще мне непонятно что за загадочные обращения к Texture2D внутри шарпа. Там еще какой-то доступ к ландшафту. Очень всё это подозрительно.

Юнити разделяет 2д текстуры и кубамапы(скайбоксы).

Отправлено Дядя Миша 02-07-2022 в 09:43:

Цитата:

FiEctro писал:
Например я не понимаю зачем мне писать тот же матан зеркал и порталов с нуля, если это типовая задача которая уже имеет готовую реализацию?

Так средства для этого должны быть заложены уже в самом движке, например. Сторонний ассет едва ли будет оптимальным.
Что мы и наблюдаем собственно. Гибко но очень тормозно.

Добавлено 02-07-2022 в 12:32:

Цитата:

FiEctro писал:
Юнити разделяет 2д текстуры и кубамапы(скабоксы).

Нет я про то, что обращение в шарпе идёт. Тоже ведь небыстрое дело.

Добавлено 02-07-2022 в 12:35:

Цитата:

FiEctro писал:
Ты утрируешь, ассеты прекрасно отгружаются и дебажатся

Однако код движения игрока как в халфе никто не сделал до сих пор

Кто-то сказал очень правильную вещь - запомните, тот говнокод, который шёл с движком в качестве примера НИКТО не будет переписывать, но это говно попадёт в продакшен в сотни игр. Собственно именно так и произошло. Фирменный мешок с гавном оказался всего лишь демкой примера как надо делать перемещение игрока. Естественно его никто не переписывал, ни у кого даже не возникло такой мысли, но зато теперь все уверены, что никакой другой физики на Юнити не бывает.
Вот наглядно к чему приводят некоторые стереотипы и иллюзии.

Добавлено 02-07-2022 в 12:37:

Впрочем точно такое же дерьмо со всеми ассетами происходит. Да и вообще с покупкой и продажей разных приложений всеми желающими.
Тот же Google Store когда начинался нас клятвенно заверяли - мы каждое приложение проверяем и тестируем и никакие вредоносные программы в наш магазин не попадут никогда. Ну естественно, когда он пополнялся одним приложением в неделю, оно так и было. А теперь зелёный свет абсолютно любому шлаку. Наверное даже до смешного доходит - в магазине можно легально купить вирус, который дополнительно украдёт у тебя все деньги.
То есть раньше ты его просто скачивал по глупости, а теперь еще и покупаешь.

Добавлено 02-07-2022 в 12:38:

Я это всё пишу не к тому, что ассеты - зло и их в NT не будет. Будут конечно, обязательно будут, но их концепция должна быть пересмотрена, т.к. это весьма важный аспект. Нельзя делать так как уже было сделано, мы все видели к чему это приводит. Надо хорошо продумать этот момент.

Добавлено 02-07-2022 в 12:43:

Ну да, когда я вплотную займусь ассетами, я буду очень рассчитывать на вашу помощь, чтобы не наступить на те же грабли. То есть вы как уже вкусившие все надостатки и достоинства существующих реализаций будете знать, что мне посоветовать

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-07-2022 в 09:47:

Цитата:

Дядя Миша писал:
Так средства для этого должны быть заложены уже в самом движке, например. Сторонний ассет едва ли будет оптимальным.
Что мы и наблюдаем собственно. Гибко но очень тормозно.

В любом случае - захочешь что то поменять, нужен будет сторонний ассет, твой рукописный или скаченный с интернета. Никто никогда в жизни не сможет предусмотреть всех вариантов которые захочет юзер, да и к тому же такое раздутие фичей из коробки приводит к уже куда более страшным багам нежели пара кастомных ассетов, который уже ложатся напрямую на плечи разработчика движка, тебе ли это не знать.

Цитата:

Дядя Миша писал:
Нет я про то, что обращение в шарпе идёт. Тоже ведь небыстрое дело.

Это компоненты класса материала. Через код ты обращаешься сначала к объекту, потом к его компоненту материала, а потом уже к Texture2D который является просто параметром для шейдера. Можно в принципе и сразу напрямую фигачить, но так не принято. И почему не быстрое? Чем оно от крестов отличается? Шарп такой же компилируемый язык.

Цитата:

Дядя Миша писал:
Однако код движения игрока как в халфе никто не сделал до сих пор

https://github.com/atil/fpscontroller
https://github.com/Olezen/UnitySourceMovement

Цитата:

Дядя Миша писал:
Однако код движения игрока как в халфе никто не сделал до сих пор
Кто-то сказал очень правильную вещь - запомните, тот говнокод, который шёл с движком в качестве примера НИКТО не будет переписывать, но это говно попадёт в продакшен в сотни игр. Собственно именно так и произошло.

...

Наверное даже до смешного доходит - в магазине можно легально купить вирус, который дополнительно украдёт у тебя все деньги.
То есть раньше ты его просто скачивал по глупости, а теперь еще и покупаешь.

Дык ну давай захардкодим всё, и пускай пользователи плюются в сторону автора движка и пишут костыли для обхода багов. Даже в юнити такой фигнёй иногда приходится заниматься. Вот захардкодили они получение клавиш с клавиатуры, а между сценами там вылазил баг связанный с тем что они отжимались самопроизвольно если были нажаты. И много лет ты ничего не мог с этим поделать, пока они не вынесли эту систему в открытый пакет с открытыми сорцами.

Движок это просто IDE с пустой сценой, а фичи это уже компоненты.

Отправлено Дядя Миша 02-07-2022 в 12:33:

Цитата:

FiEctro писал:
Чем оно от крестов отличается? Шарп такой же компилируемый язык.

Добавлено 02-07-2022 в 13:46:

Цитата:

FiEctro писал:
Вот захардкодили они получение клавиш с клавиатуры, а между сценами там вылазил баг связанный с тем что они отжимались самопроизвольно если были нажаты

Этот баг похоже в любом движке вылезает, в Ксаше тоже было нечто подобное.

Добавлено 02-07-2022 в 15:33:

Вот такой у меня вопрос возник. Предположим я купил ассет, немного его поюзал и понял, что он негодится. Решил возвернуть за него деньги, а сам его копию сделал по тихому такой и в архив положил. Ну ок, деньги вернули, а я свою копию распаковал и дальше юзаю как ни в чём не бывало?
Или скажем Unity по GUID увидел, что ассет используется, но в списке покупок не значится и заверещал - Тревога-Тревога!
И тут я такой перебиваю GUID ну как серийный номер автомобиля на раме и Вася-кот?! Или там хитрее устроено?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-07-2022 в 12:57:

Цитата:

Дядя Миша писал:
Вот такой у меня вопрос возник. Предположим я купил ассет, немного его поюзал и понял, что он негодится. Решил возвернуть за него деньги, а сам его копию сделал по тихому такой и в архив положил. Ну ок, деньги вернули, а я свою копию распаковал и дальше юзаю как ни в чём не бывало?
Или скажем Unity по GUID увидел, что ассет используется, но в списке покупок не значится и заверещал - Тревога-Тревога!
И тут я такой перебиваю GUID ну как серийный номер автомобиля на раме и Вася-кот?! Или там хитрее устроено?

Ассеты пиратят только в путь, GUID этого не учитывает. Можешь свободно скачать платный ассет с торрента и скомпилировать его в свой проект.

Отправлено Дядя Миша 02-07-2022 в 13:36:

Нет-нет, я именно про гипотетический вариант возврата денег с одновременным оставлением ассета у себя. Или там нет возврата денег?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-07-2022 в 13:53:

Дядя Миша
Деньги можно вернуть, ассет оставляешь у себя, но его больше нельзя будет скачать через твой аккаунт в ассет стор.

Отправлено Дядя Миша 02-07-2022 в 14:53:

А, ну с этим я уже сталкивался, когда скачивал Viking Village. Она хоть и бесплатная, но скачивать мне её не давали, мотивируя как раз тем, что якобы 6 лет назад я уже скачал этот ассет. Очевидно это никак не связано с оплатой, т.к. эта демка вообще бесплатная.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 02-07-2022 в 23:59:

Цитата:

XaeroX писал:
И кстати, мне они нравились (я катался на 2114 и 2115)

Волга-24 лучше, ну это все знают. А 3102 с гидроусилителем вообще шик

Добавлено 03-07-2022 в 02:42:

Цитата:

FiEctro писал:
потом уже к Texture2D который является просто параметром для шейдера

Для шейдера по сути важен только id текстуры. У меня такая обёртка

Добавлено 03-07-2022 в 02:42:

Работает даже без шейдеров. Всё остальное идёт юниформами

Добавлено 03-07-2022 в 02:45:

Кстати, давно хотел спросить, почему в OGL есть minFilter и magFilter. Ну то есть не maxFilter, а именно mag? То ли я перепил, то ли разработчик стандарта

Добавлено 03-07-2022 в 02:45:

Цитата:

Дядя Миша писал:

Ну по идее JIT же, как и в яве

Добавлено 03-07-2022 в 02:48:

Цитата:

Дядя Миша писал:
[B]Однако код движения игрока как в халфе никто не сделал до сих пор

Я делал код движения как в кваке на основе ксаша для купахтомаса. Даже с прыжком от стены. Но потом спирт завезли и я перестал делать, к сожалению

Добавлено 03-07-2022 в 02:50:

Цитата:

FiEctro писал:

public class AnotherHero : MonoBehaviour
2
{
3
__MainHero mainHero;
4
__int anotherHealth;
5
_
6
__void Start()
7
__{
8
____mainHero = GameObject.FindGameObjectWithTag("YOUR MAINHERO OBJECT TAG").GetComponent<MainHero>();
9
10
____anotherHealth = mainHero.health;
11
__}
12
__.
13
__.
14
__.
15
}

уродство какое

Добавлено 03-07-2022 в 02:52:

Цитата:

Именно так. Но современный мир увы несправедлив к истинным творцам. А вот тех, кто умеет быстро сговнять что-то рабочее и хайповое из примитивных пресетов - восхваляют и платят деньги. Взять тех же реперов или тиктокеров

Добавлено 03-07-2022 в 02:54:

Цитата:

Дядя Миша писал:
А, ну с этим я уже сталкивался, когда скачивал Viking Village

привязывается к аккаунту, видимо. Можно для хардора закинуть в хэш ещё ID какой-нибудь железки, или скажем IP например (те же кукисы активно это юзают)

Добавлено 03-07-2022 в 02:56:

Цитата:

Дядя Миша писал:
вирус, который дополнительно украдёт у тебя все деньги.
То есть раньше ты его просто скачивал по глупости, а теперь еще и покупаешь.

Ну хоть нологи не требует платить, хотя разница небольшая

Добавлено 03-07-2022 в 02:59:

Цитата:

FiEctro писал:
с тем что они отжимались самопроизвольно если были нажаты

Кажется это общая проблема с контекстом окна

__________________
-Brain is dead-

Отправлено Дядя Миша 03-07-2022 в 05:56:

Цитата:

KiQ писал:
Ну то есть не maxFilter, а именно mag?

minification\magnification. Уменьшение\увеличение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-07-2022 в 07:31:

Цитата:

KiQ писал:
Для шейдера по сути важен только id текстуры. У меня такая обёртка

"уродство какое"

Цитата:

Дядя Миша писал:
Ну по идее JIT же, как и в яве

https://habr.com/ru/company/plarium/blog/276589/

Цитата:

KiQ писал:
Именно так. Но современный мир увы несправедлив к истинным творцам. А вот тех, кто умеет быстро сговнять что-то рабочее и хайповое из примитивных пресетов - восхваляют и платят деньги. Взять тех же реперов или тиктокеров

Это мне напоминает плоскоземщиков. Мол ВЛАСТИ СКРЫВАЮТ от людей что Земля на самом деле плоский диск и стоит на трёх китах, а современные люди отупели от тиктока чтобы осознать это. Вот когда люди поймут что Земля плоская, начнут читать веды, и войдут в биорезонанс с анунаками с Нибиру, вот тогда заживем.

Цитата:

KiQ писал:
привязывается к аккаунту, видимо. Можно для хардора закинуть в хэш ещё ID какой-нибудь железки, или скажем IP например (те же кукисы активно это юзают)

Я перекидывал ассеты свободно с аккаунта где был залогинен, на другой комп где не был залогинен. Ничего страшного не случилось.

Цитата:

Дядя Миша писал:
Наверное даже до смешного доходит - в магазине можно легально купить вирус, который дополнительно украдёт у тебя все деньги.
То есть раньше ты его просто скачивал по глупости, а теперь еще и покупаешь.

Это враньё чистой воды, даже если вирус допустим и попал тебе на мобилу, пока ты сам вручную не дашь ему все разрешения, у него будут связаны руки.

Отправлено Дядя Миша 03-07-2022 в 07:47:

JIT не панацея, если язык сам по себе сконструирован таким образом, по типу явы и шарпа. Где на любой чих - выделение памяти, сборщик мусора.
Это не будет быстро работать.

Добавлено 03-07-2022 в 10:47:

Да и дата выхода статьи - 2016-й год. Ты уверен что это уже не deprecated?
Как вы любите говорить "с выходом новой версии изломали вообще всё".
Это обратная стороная хвалёной гибкости, народ зачастую привязывается к недокам и потом оно ломается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 03-07-2022 в 11:09:

Цитата:

KiQ писал:
уродство какое

Unity в общем и целом уродство, если читать обсуждения в этих ваших интернетах.

Цитата:

KiQ писал:
современный мир увы несправедлив к истинным творцам

Цитата:

FiEctro писал:
Вот когда люди поймут что Земля плоская, начнут читать веды, и войдут в биорезонанс с анунаками с Нибиру, вот тогда заживем.

Первое, что необходимо для успешной разработки - финансирование. Которое трудно получить, применяя подход "сделаю всё сам оптимально и 10 раз перепроверю", т.к. время - деньги. Вот и работает концепция

Цитата:

Дядя Миша писал:
"накидал отвсюду чужого, нажал кнопку export и получил игру"

это ведь быстро, и то, что нужно издателям.

Отправлено Дядя Миша 03-07-2022 в 11:18:

Цитата:

Ku2zoff писал:
это ведь быстро, и то, что нужно издателям.

Каким издателям? Весь стим завален подобными играми. Кто в них играет?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-07-2022 в 12:10:

Цитата:

Ku2zoff писал:
Первое, что необходимо для успешной разработки - финансирование. Которое трудно получить, применяя подход "сделаю всё сам оптимально и 10 раз перепроверю", т.к. время - деньги. Вот и работает концепция

Я не знаю, обсуждения Дяди Миши и КиКу на уровне "структура папок чисто кушная - значит это копипаста из кваки" ну или "если движок позволяет вставлять ассеты, значит никто не будет делать на нём игры, а только вставлять ассеты". И ведь они понимают что это совсем не так, но продолжают писать глупости. Чисто из ассетов конечно можно что то более играбельное собрать, но вот вопрос - кому оно нужно? Выглядеть будет убого, работать криво.
Да чего говорить, таже Паранойя 2 тоже ведь использует ресурсы из халфы что само по себе такой же ассет. Да и плеер контроллер Дядя Миша вроде тоже как бы там свой с нуля не писал. Вы так говорите будто это что то плохое.

Цитата:

Ku2zoff писал:
Unity в общем и целом уродство, если читать обсуждения в этих ваших интернетах.

Ну как сказать, у Юнити полно минусов и недостатков, для кого то они критичные или вообще "движок говно". Но они точно не в ассетах, а как раз таки наоборот в том что это модульность ещё недостаточно гибкая, и многие вещи захардкожены как у Кармака, без сорцев движка к ним никак доступ не получить.

Цитата:

Дядя Миша писал:
Каким издателям? Весь стим завален подобными играми. Кто в них играет?

Логично что если бы не было спроса, то не было бы столько игр.

Отправлено Ku2zoff 03-07-2022 в 13:07:

Цитата:

Дядя Миша писал:
Весь стим завален подобными играми. Кто в них играет?

Странно, что их вообще пропускают в стим. Печально, что уже и крупные проекты, имеющие издателей делают "и так сойдёт". Сколько багов было в киберпуке на момент выхода? А в сталкере?
Проблема сборки из ассетов не отсутствие стабильности и безбажность, а жуткая прожорливость. Когда автор берёт чужое и даже не пытается оптимизировать ручками. Лично играл в две 2D игры, у которых требования на уровне UT3 или чуть ниже: Lona: Realm of Colors и какая-то составлялка маленьких слов из больших. Обе на юнити. Для справки, Braid, имеющий нехилые такие шойдеры при перемотке времени, тоже тормозит, если задействовать эти шойдеры. Lona тормозит без всяких шойдеров. Реально, просадки фпс на 2D картинке.

Цитата:

FiEctro писал:
если бы не было спроса

Вот тут я сразу приплету VR игры, "за которыми будущее". Из которых половина является симуляторами избиения манекенов кирпичём, а другая половина симулятором рисования кое-чего на заборах.

Отправлено Дядя Миша 03-07-2022 в 13:25:

Цитата:

FiEctro писал:
ну или "если движок позволяет вставлять ассеты, значит никто не будет делать на нём игры

Я ничего подобного не утверждал.

Цитата:

FiEctro писал:
Логично что если бы не было спроса, то не было бы столько игр.

Да где он этот спрос?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-07-2022 в 13:26:

Цитата:

Ku2zoff писал:
Вот тут я сразу приплету VR игры, "за которыми будущее". Из которых половина является симуляторами избиения манекенов кирпичём, а другая половина симулятором рисования кое-чего на заборах.

Ну да, только ты не бежишь туда им писать что их проекты говно. Ты бежишь сюда, обсирать нормальных мододелов/игроделов, которые такими вещами не занимаются. Судить игры по движку, это как судить качество матрицы по картинке с котом.

Отправлено Ku2zoff 03-07-2022 в 15:26:

Цитата:

FiEctro писал:
Ты бежишь сюда, обсирать нормальных мододелов/игроделов, которые такими вещами не занимаются.

Перечисли пожалуйста, кого я обосрал.

Цитата:

FiEctro писал:
ты не бежишь туда им писать что их проекты говно

Ну дык маладёш в восторге, какой смысл фидбека от нескольких процентов людей, которые выросли на других играх, и у которых вкус не испорчен? Это как спорить с любителями плохого кино или дешёвых сериалов: как об стенку горох.

Цитата:

Дядя Миша писал:
Да где он этот спрос?

Ну очевидно, что он есть. Иначе не было бы столько проходного шлака. Проведи аналогию с Google Play, сам же упоминал, что там помойка. И это даже не касаемо игр. Очень много приложений в GP непонятно кем и для чего сделаны. Только приложений-ярлыков несколько десятков. Хотя уже много лет есть QSM, который могёт всё.

Отправлено FiEctro 03-07-2022 в 20:20:

Цитата:

Ku2zoff писал:
Ну дык маладёш в восторге, какой смысл фидбека от нескольких процентов людей, которые выросли на других играх, и у которых вкус не испорчен? Это как спорить с любителями плохого кино или дешёвых сериалов: как об стенку горох.

Так в том и суть, я захожу в стим, вижу говно стряпанное на коленке, куча положительных обзоров и скачек. Потом захожу на какой то более интересный инди проект и вижу в 5 раз меньше скачек и куча негативных обзоров от всякого рода диванных ценителей. В этой ситуации виноваты вообще не движки, а комьюнити, девелоперы лишь подстраиваются под рынок. Вспомнить только как тот же киберпанк гнобили, и фолыч, хотя это даже не инди, и заметьте их не русские делали.

Цитата:

Ku2zoff писал:
Перечисли пожалуйста, кого я обосрал.

Да потому что речь была вообще не об этом. Для вас почему то легально покупать контент для разработки это зашквар. А вот тащить ресурсы нелегально из других игр в свои моды, это верх всякой похвалы. Я нахожу такой подход лицемерием и двойными стандартами.

Отправлено Дядя Миша 03-07-2022 в 20:26:

Цитата:

FiEctro писал:
судить качество матрицы по картинке с котом.

Вот тут ты как раз заблуждаешься. Подобные картинки - это отличный тест качества матрицы.

Цитата:

FiEctro писал:
вижу говно стряпанное на коленке, куча положительных обзоров и скачек

Так эти положительные отзывы оставляют такие же разработчики по принципу "за что же, не боясь греха, петушка хвалит кукуха".
Ну ладно, мы пожалуй несколько отвлеклись.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-07-2022 в 09:44:

Важный момент хочу отметить - если я что-то критикую, то скорее не явление в целом, а то, в какие формы оно выродилось. И на этом этапе важно понять почему так получилось, то есть совершить исторический экскурс. Очень часто оказывается, что раздражающие и ненужные вещи - просто дань совместимости, которую уже нельзя выбрасывать.
Но в новом проекте от подобной практики можно отказаться.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 04-07-2022 в 21:57:

Цитата:

FiEctro писал:
Я не знаю, обсуждения Дяди Миши и КиКу на уровне "структура папок чисто кушная - значит это копипаста из кваки"

Я попрошу, про копипасту я нигде не говорил. И кстати, лучше кушной структуры папок нигде не встречал. И чтобы сейвы туда же писались. И реестр не засирать. В своём движке так и делал. Жаль, что он никому нахер не нужен

__________________
-Brain is dead-

Отправлено Crystallize 05-07-2022 в 02:25:

Цитата:

Дядя Миша писал:
На практике я ни разу не видел, чтобы у кого-то возникало желание переименовывать или перемещать ресурсы. Если у нас моделька пушки - кладём в models\weapons. Если у нас моделька монстра кладём models\monsters. Если у нас текстура, допустим дерева кладём textures\wood.

А если группировать ресурсы не по Аристотелю мягкость-сухость а по территориям в игровом мире? Скажем у меня есть район или глава wasteland которая мало пересекается по ресурсам с другими территориями и поэтому там будет лежать всё от грязи до зданий. Допустим я сам её делал целиком в уголке. Или её отдавали на аутсорс кому-то.

Отправлено Дядя Миша 05-07-2022 в 05:52:

Цитата:

Crystallize писал:
а по территориям в игровом мире?

В первом квейке текстуры принадлежащие одной карте прямо в ней и лежали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 05-07-2022 в 09:19:

Цитата:

Дядя Миша писал:
В первом квейке текстуры принадлежащие одной карте прямо в ней и лежали.

А ведь по-консольному динамически подгружать отдельные домики, энтити и прочие ресурсы при этом уже не получится?

Добавлено 05-07-2022 в 16:19:

Дядя Миша Твой интеллектуальный пакер текстур может быть широко востребован, так что не будет нужен никакой VTFedit скажем. Только подружи его с форматами того же Сорса и Сталкера скажем.

Отправлено FiEctro 05-07-2022 в 11:59:

Цитата:

Crystallize писал:
А если группировать ресурсы не по Аристотелю мягкость-сухость а по территориям в игровом мире? Скажем у меня есть район или глава wasteland которая мало пересекается по ресурсам с другими территориями и поэтому там будет лежать всё от грязи до зданий. Допустим я сам её делал целиком в уголке. Или её отдавали на аутсорс кому-то.

Офигенно когда карта допустим c2a1 будет требовать ресурсы из c1a0, или ещё хуже - дублировать их. Если уж и делить ресурсы то по их типу. Текстуры, спрайты, модели, сцены, материалы, звуки и т.д. Но опять же накидав себе какой нибудь пак текстур из сталкера, ты его уже никак нормально не удалишь, придётся вручную сидеть и вычищать. А если ты захочешь передать часть проекта ещё кому то, то это вообще жопа. Кидай весь проект целиком. Ассеты решают всё это говно.

В контексте Кармаковских движков роль ассетов могут выполнять pak файлы, но это уже будут скорее бандлы.

Отправлено Дядя Миша 05-07-2022 в 13:41:

Цитата:

Crystallize писал:
с форматами того же Сорса и Сталкера скажем

В сталкере DDS обычный. С этими текстурами нет нужды что-то делать.

Добавлено 05-07-2022 в 16:38:

Ассет, грубоговоря, это то, что можно представить в виде единого файла, а внутри на самом деле архив с ресурсами. Ну и соглашение о том какие ресурсы использовать из какого ассета. А так же возможность их выключать, например, без физического удаления.

Добавлено 05-07-2022 в 16:41:

Тут еще вот какой принципиальный момент. В старых движках место создания игры одновременно же было и её рабочим пространством.
Т.е. там где ты создаёшь и конструируешь - это уже и есть игра.
В Юнити не так, там надо нажать кнопку экспорт, она будет долго-долго шуршать и потом даже чёта сгенерирует. Правда нет никакой гарантии, что созданное будет беспроблемным и проходимым. Но если нет, то придётся заново всё перепроверять и переделывать. А без использования этой кнопки мы видим неоткомпилированный ресурс в редакторе только. Ну или в полном окне, но всё равно это немного не то.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-07-2022 в 14:14:

Цитата:

Дядя Миша писал:
Ассет, грубоговоря, это то, что можно представить в виде единого файла, а внутри на самом деле архив с ресурсами. Ну и соглашение о том какие ресурсы использовать из какого ассета. А так же возможность их выключать, например, без физического удаления.

Это как раз бандлы, используются чтобы их можно было загружать и выгружать уже в игре динамически. А ассет это как архив с гитхаба с прописанными внутри зависимостями. Он импортируется и полностью распаковывается как правило в отдельную папку, как обычные ресурсы. Но при необходимости благодаря прописанным метаданным ты их можешь выгрузить без вреда для остального проекта. И работает только в IDE Юнити.

Цитата:

Дядя Миша писал:
Тут еще вот какой принципиальный момент. В старых движках место создания игры одновременно же было и её рабочим пространством.
Т.е. там где ты создаёшь и конструируешь - это уже и есть игра.
В Юнити не так, там надо нажать кнопку экспорт, она будет долго-долго шуршать и потом даже чёта сгенерирует. Правда нет никакой гарантии, что созданное будет беспроблемным и проходимым. Но если нет, то придётся заново всё перепроверять и переделывать. А без использования этой кнопки мы видим неоткомпилированный ресурс в редакторе только. Ну или в полном окне, но всё равно это немного не то.

Вообще то там на самом видном месте есть кнопка плей, где ты можешь пропарсить всю игру прямо в редакторе, и прямо во время игры менять какие то параметры. Более того ты можешь проигрывать игру отдельно по каждому апдейту.

Отправлено Дядя Миша 05-07-2022 в 14:50:

Цитата:

FiEctro писал:
Вообще то там на самом видном месте есть кнопка плей, где ты можешь пропарсить всю игру прямо в редакторе

Объясни, почему я нажимаю кнопку плей и мгновенно попадаю в игру, а если жму экспорт, то оно шуршит минут 20. Ну значит это разные вещи.
Не всё так просто. Так блин, в этой деревне викингов даже лайтмапа была просчитана заранее. А она всё равно 20 минут шуршала.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-07-2022 в 15:17:

Цитата:

Дядя Миша писал:

Объясни, почему я нажимаю кнопку плей и мгновенно попадаю в игру, а если жму экспорт, то оно шуршит минут 20. Ну значит это разные вещи.
Не всё так просто. Так блин, в этой деревне викингов даже лайтмапа была просчитана заранее. А она всё равно 20 минут шуршала.

Вроде как всякий кэш необходимый для компиляции делает. Ну и шейдеры все перекомпилирует очень долго, да. При второй компиляции вроде как больше не тупит так долго.
Кстати шейдеры лежат в открытую, можешь поизучать, там и реалтаймовый GI по идее где то есть.
https://github.com/TwoTailsGames/Unity-Built-in-Shaders

И забей ты на викингов, это бенчмарк, начни с чего полегче, создай пустую сцену, заспавни кубик и навесь на него скрипт какой нибудь самописный.

Отправлено Crystallize 05-07-2022 в 18:24:

Цитата:

FiEctro писал:
Офигенно когда карта допустим c2a1 будет требовать ресурсы из c1a0, или ещё хуже - дублировать их.

А в первокваке же вроде текстуры дублируются?

Отправлено Дядя Миша 05-07-2022 в 19:08:

Цитата:

FiEctro писал:
это бенчмарк, начни с чего полегче

Вот эта игрушечная сцена - бенчмарк?!

*поперхнулся чяем*

Цитата:

FiEctro писал:
там и реалтаймовый GI по идее где то есть.

Ты про Geometrix этот? Да я сам такую штуку написать могу, вопрос только в том, как эффективнее представить дату вторичного освещения. А это без серии экспериментов определить невозможно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-07-2022 в 07:04:

Цитата:

Дядя Миша писал:
Да я сам такую штуку написать могу, вопрос только в том, как эффективнее представить дату вторичного освещения. А это без серии экспериментов определить невозможно.

Так для этого и скинул

Отправлено Дикс 10-07-2022 в 08:21:

Цитата:

Crystallize писал:
А в первокваке же вроде текстуры дублируются?

как и во второй, очень много дублей
Порой у них даже имена разные)

__________________
igroprom.d3.ru

Отправлено Crystallize 12-07-2022 в 04:02:

Было бы круто если освещение от неба будет примерно учитывать цвет на конкретном участке скайбокса. Потому в том же хл2 или сталкере на скайбоксах ближе к горизонту есть яркие пятна от освещенных облаков которые совершенно не учитываются ни солнцем, ни цветом амбиента.

Отправлено FiEctro 12-07-2022 в 05:51:

Я думаю в новом движке благодаря системе материалов такое будет сделать намного проще.

Отправлено Дядя Миша 12-07-2022 в 06:23:

Crystallize облака надо рендерить честно, а не рисовать их на скайбоксе. Это не так уж и сложно - в первом кризисе уже рендерили.

Добавлено 12-07-2022 в 09:18:

В таком случае скайбокс останется только залить цветом неба в соответствующее время суток, есть соответствующие математические модели.
Вот к примеру: http://steps3d.narod.ru/tutorials/sky-tutorial.html

Добавлено 12-07-2022 в 09:23:

Впрочем, повторюсь главный смысл идеологии XashNT - не навязывать правильную модель поведения разработчику. Кто захочет - будет рендерить честные облака, кто не захочет - будет использовать скайбокс или скролл-текстуру из первого квейка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 12-07-2022 в 07:05:

Цитата:

Дядя Миша писал:
облака надо рендерить честно, а не рисовать их на скайбоксе.

Но у тебя же движок склоняется к инди а не к конкуренции с Уе4ем. А для настройки "честных" облаков нужен ещё один инструментарий на уровне FacePoser какого-нибудь.
К тому же честные облака смотрятся скучновато. Единственным исключением был R.E.S.E.T. но там разрабы скамеры за 10 лет 2 ролика выпустили.

Отправлено FiEctro 12-07-2022 в 08:44:

Да вроде не сложно такое делается, environment lighting есть практически в любом мало мальски уважающем себя рейтрейсере, без всяких честных облаков.
https://learn.unity.com/tutorial/co...-settings-2019#
Дядя Миша опять всё усложняет. Но это больше актуально для рассеяного света, нежели прямого.

Добавлено 12-07-2022 в 11:44:

Дядя Миша
Кстати рекомендую ещё вот этот сайт по рендерингу в Юнити. Здесь чувак очень подробно всё объясняет с примерами. Плюс в некоторых туторах он буквально пытается воспроизвести некотрые элементы рендера Юнити средствами самой Юнити.
https://catlikecoding.com/unity/tutorials/
https://catlikecoding.com/unity/tutorials/rendering/
https://catlikecoding.com/unity/tut...ender-pipeline/
Много полезного из этого можно подчерпнуть.

Отправлено SNMetamorph 12-07-2022 в 08:50:

Цитата:

Crystallize писал:
Было бы круто если освещение от неба будет примерно учитывать цвет на конкретном участке скайбокса. Потому в том же хл2 или сталкере на скайбоксах ближе к горизонту есть яркие пятна от освещенных облаков которые совершенно не учитываются ни солнцем, ни цветом амбиента.

Такая фича есть в лайтбейкере психопата, в праймовские компиляторы тоже хочу подобное сделать

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 14-07-2022 в 11:31:

Возможно многие не понимают чем я сейчас занят, над чем работаю и почему в телеграм-канале ничего не пишу. Объясняю: в данный момент я выращиваю конкурента СиШарпу и Яве. А возможно и С++ в некотором смысле. Та скрипт-машина, которая планировалась изначально уже давным-давно вышла за рамки простейших скриптов, это будет настоящий полноценный язык, по возможностям приближающийся к настоящему С++, но лишенный его недостатков и имеющий все приятные особенности виртуальных машин. Естественно он будет гораздо медленнее С++, по моим замерам где-то 6-9 раз. Но в дальнейшем это можно будет решить при помощи JIT, сократив разрыв до двух раз всего.
Язык пишется не ваккууме, я сразу же портирую на него VCL - Delphi Visual Component Library, это нечто навроде Qt или wXWidgets, только гораздо приятнее в обращении. Ну Дельфисты знают.
Выбор на библиотеку отчасти пал из-за того что QuArK написан на Делфи, но это не единственная причина. Там весьма богатый набор всяческих кастомизаций для окошек, недоступный более нигде - ни на Qt ни в MFC ни в wxWidgets, ни в другом известном мне фреймворке. Отчасти это обусловленно особенностями самого языка Delphi. То что на нём написано невозможно портировать на С++. Но на мой будущий язык - вполне возможно. Чем, я собственно, сейчас и занят.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 14-07-2022 в 11:35:

Дядя Миша
А как насчет кросплатформенности всего этого?

Отправлено Дядя Миша 14-07-2022 в 11:42:

Закладывается, насколько это вообще возможно.
Сам Delphi, к примеру имеет две библиотеки - VCL, чисто под Windows, и CLX - враппер для Qt. Т.е. это вполне реально.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-08-2022 в 09:54:

Дядя Миша
Скажи, а почему ты не хочешь сделать для ui отдельный язык разметки подобный html? Помню когда мы с тобой обсуждали, ты говорил что это неплохая идея. Не надо лезть в код игры, и легко переносить такие интерфейсы из мода в мод. Только события подставляй.

Отправлено Дядя Миша 28-08-2022 в 11:03:

Это всё автоматически получится. Т.е. скриптовой язык будет грузить текстовые файлы с описанием окошек.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 28-08-2022 в 17:29:

Дядя Миша
Это всё конечно не моё дело, но твои пренебрежительные высказывания о Qt наводят на мысль, что ты о нём знаешь очень мало. И наоборот, этот VCL, наш кошмар из начала нулевых, вдруг внезапно становится "приятным в обращении"... Прям какая-то альтернативная реальность.

Но справедливости ради, сейчас иметь несколько альтернативных реальностей в мире - это норма. Мы теперь все так живём.

__________________

Отправлено Дядя Миша 28-08-2022 в 17:55:

Цитата:

XaeroX писал:
но твои пренебрежительные высказывания о Qt наводят на мысль, что ты о нём знаешь очень мало

Это чудовищно переусложнённая и практически неподдерживаемая вещь.
Простые кроссплатформенные окошки на ней клепать еще можно, но гарантировать нечто больше я бы не рискнул. Да собственно Jack и состоит из этих простейших окошек без излишеств.

Цитата:

XaeroX писал:
VCL, наш кошмар из начала нулевых

Ну вообще-то не VCL кошмар, а сам Delphi.

Добавлено 28-08-2022 в 20:55:

Цитата:

Библиотека использует собственный формат проекта, именуемый .pro файлом, в котором собрана информация о том, какие файлы будут скомпилированы, по каким путям искать заголовочные файлы и много другой информации. Впоследствии при помощи утилиты qmake из них получаются makefile для make-утилиты компилятора. Также есть возможность работы при помощи интеграторов с Microsoft Visual Studio 2003/2005/2008/2010.

Вот этого мне точно не надо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 28-08-2022 в 18:00:

Дядя Миша
Тогда уточни, что ты называешь излишествами?
На VCL написан, например, редактор партиклов pfxEd. Вроде окошки ничуть не сложнее.

Добавлено 28-08-2022 в 14:00:

Цитата:

Дядя Миша писал:
Вот этого мне точно не надо.

Я же говорю - у тебя очень повехностное понимание Qt.
Никаких pro-qmake в Джеке нет и никогда не было.
Но если вместо того, чтобы самому написать пару тяжеловесных гуёвых софтин на Qt, начать читать ~~статьи на хабре~~ документацию - складывается впечатление, что всё очень плохо.
Мне повезло - я столкнулся с Qt году ещё в 2008, когда там всё было проще. И простые подходы тех лет никто не запрещает использовать до сих пор, хотя фич для зумеров становится всё больше.

__________________

Отправлено Дядя Миша 28-08-2022 в 18:48:

Цитата:

XaeroX писал:
Тогда уточни, что ты называешь излишествами?

Ну посмотри как тот же QuArK устроен, к примеру.

Цитата:

XaeroX писал:
Я же говорю - у тебя очень повехностное понимание Qt.

И желания продолжать знакомство - нет. Почему я должен таскать вместе с движком библиотеку, которая весит в 5-6 раз больше него, ради функционала отрисовки окон, который в полном объеме есть в самой Windows? Я понимаю, в Linux рабочего стола нет, вот пусть там и таскают.
К тому же, там судя по всему точно такая же линуксовая идеология, поэтому между минорными версиями могут переколбасить весь интерфейс несколько раз и посадить критичные ошибки. Такой вопрос - рендерер шрифтов там тоже свой? И насколько он хорошо справляется?
Если где-то в Qt окажется критичная ошибка, ты будешь её лично исправлять? Или срочно обновлять версию Qt если эту ошибку там исправят?

Добавлено 28-08-2022 в 21:48:

И вообще. В наше непростое время привязываться к сторонним библиотекам и фреймворкам - это заведомо провальная тактика. Микрософт не зря приобрёл github и не зря возглавляет это направление.
Тактику микрософта все помнят? Embrace, extend, and extinguish.
Судя по всему в ближайшие пять-семь лет весь этот опенсорс очень сильно дискредитируют и выведут из тренда, сделав уделом маргиналов. Второй удар нанесут по Линуксу, но не раньше чем Гугл доделает свой новый андроид, который с Линуксом не имеет ничего общего.

Еще момент. Вот ты используешь Qt в Джеке, а представь что русским запретят использовать эту библиотеку и Valve скажет - мы больше не можем распостранять Jack в стиме, пока он использует эту библиотеку.
Да мало ли что может случится. Это десять лет назад казалось смешным и невозможным.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 28-08-2022 в 18:59:

Цитата:

Дядя Миша писал:
ради функционала отрисовки окон, который в полном объеме есть в самой Windows?

Ты уже как тот товарищ, который мечтал статически линковаться с kernel32.dll (не помню его ник).

Цитата:

Дядя Миша писал:
Я понимаю, в Linux рабочего стола нет, вот пусть там и таскают.

Кроссплатформенность же. У Qt не было задачи симулировать Windows на платформах, у которых оконная система проще. Они нашли собственное решение, хотя конечно в Win-имплементации есть в некоторой степени опора на уже готовые фичи WinAPI.

Цитата:

Дядя Миша писал:
И насколько он хорошо справляется?

Он использует системную отрисовку, как я понял.
Поэтому все растровые шрифты в волатиле/PW отрендерены под macOS. Потому что там самый лучший в мире растеризатор шрифтов.

Цитата:

Дядя Миша писал:
Если где-то в Qt окажется критичная ошибка, ты будешь её лично исправлять?

На предыдущей работе, где мы юзали Qt - исправляли, было дело. Сорцы-то открытые.

Добавлено 28-08-2022 в 14:59:

Цитата:

Дядя Миша писал:
Вот ты используешь Qt в Джеке, а представь что русским запретят использовать эту библиотеку и Valve скажет - мы больше не можем распостранять Jack в стиме, пока он использует эту библиотеку.

~~Я скажу, что я канадец и произошла чюдовищная ошибка.~~ С таким же успехом могут запретить Windows и Linux. И распространять в Стиме что-либо. Главное - что тебе технически не могут запретить использовать опенсорс, и распространять самиздатом. Вот если бы сорцы Qt были закрыты, а то и вообще доставлялись с серверов компании в процессе инсталляции приложения - тогда другой разговор.

Цитата:

Дядя Миша писал:
Это десять лет назад казалось смешным и невозможным.

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

__________________

Отправлено Дядя Миша 28-08-2022 в 19:10:

Цитата:

XaeroX писал:
Кроссплатформенность же.

Кроссплатформенность - это аналог толерантности. Десятилетиями жили и не парились и вот она вдруг всем резко понадобилась.
По факту эта кроссплатформенность выглядит в точности как BLM. Вместо того, чтобы признать за неграми равные права - белых отчего-то заставляют мыть им ноги. Т.е. раньше в Линуксе был вайн и всех это устраивало. Теперь ради мифической кроссплатформенности вайн заставляют таскать с каждым программным продуктом, но для того чтобы работало под виндой. Ничего не напоминает? Вдумайся что вся, т.н. кроссплатформенность обеспечивается набором библиотек для линукса, суммарный вес которых может в десятки раз превышать объем, собственно, приложения. Отличная кроссплатформенность. Так, как её в своё время реализовывал Кармак в той же ку2 речь даже не идёт.

Цитата:

XaeroX писал:
На предыдущей работе, где мы юзали Qt - исправляли, было дело.

А потом обновление выйдет и так сказать, что?

Добавлено 28-08-2022 в 22:10:

Цитата:

XaeroX писал:
С таким же успехом могут запретить Windows и Linux

Исключено. Надеюсь ты понимаешь почему. А вот какую-нибудь библиотеку - запросто.

Цитата:

XaeroX писал:
Главное - что тебе технически не могут запретить использовать опенсорс, и распространять самиздатом

Так это и необязательно. Главное - подорвать доверие. У нас в рунете есть некоторые форумы по халфе, где если человек не дай бог скажет что у него пиратка, так там чуть ли не в ФСБ звонок делают, чтобы его приехали и расстреляли. Для них такой человек хуже гитлера. Вот как можно было за 20 лет так промыть мозги за мелкий прайс?
Ты не хочешь понимать главного - программисты, это величайшие в мире модники. Самое главное для них - быть в тренде. Если завтра кто-то авторитетный скажет, что опенсорс это не круто, они с лёгкостью предадут анафеме и линукс и свои проекты на github. И даже сами удивятся этому.
Достаточно вспомнить как Кармак на несколько лет прибил DX, даже возможно сам того не желая. Ну это к вопросу - насколько это реально.
Более чем реально.

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

Так ты же вроде успешно разрешил эту задачу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-08-2022 в 23:11:

Цитата:

Дядя Миша писал:
Почему я должен таскать вместе с движком библиотеку, которая весит в 5-6 раз больше него, ради функционала отрисовки окон, который в полном объеме есть в самой Windows?

Насколько я помню Qt можно пересобрать выкинув всё лишнее, тогда он будет весить в разы меньше.

Цитата:

Дядя Миша писал:
Десятилетиями жили и не парились и вот она вдруг всем резко понадобилась.

Ну почему же, винда одно время умела досовские приложения запускать.

Цитата:

Дядя Миша писал:
но для того чтобы работало под виндой. Ничего не напоминает?

Так вокруг винды больше не вращается мир. Конкуренты не дремлют. Многие организации боясь телеметрии и проверок лицензии (в случае с РФ ещё и боязнь санкций) сейчас активно осваивают линуксы, и ты сам знаешь к чему всё это приведет - вырастет новое поколение пользователей для которых винда это рудимент, такой же рудимент как для нас дос, в целом она уже рудимент для многих андроид пользователей.

Цитата:

Дядя Миша писал:
И вообще. В наше непростое время привязываться к сторонним библиотекам и фреймворкам - это заведомо провальная тактика.

Она наименее рискованная. Ты быстро и дешево получаешь прототип, с которым уже можешь идти выбивать деньги.

Отправлено XaeroX 29-08-2022 в 00:37:

Цитата:

Дядя Миша писал:

А потом обновление выйдет и так сказать, что?

Ну что-что... Всё. В новом обновлении уже новые баги.

В общем, хотел я ещё позащищать Qt, но вдруг вижу сегодня в книжном магазине вот такое:

Ну теперь я прямо даже не знаю...

__________________

Отправлено Ku2zoff 29-08-2022 в 06:02:

Цитата:

FiEctro писал:
в целом она уже рудимент для многих андроид пользователей

Андроид пользователи это весьма специфическая категория. Я читал аналитику по лидирующим браузерам и ОСям за 30 лет. Винда и интернет эксплорер были лидерами довольно долгое время до массового распространения смартвоней. Где-то до 2012 года. После - ведроид и хром. Ну, как бы популяризация карманных гаджетов, мобильные интронеты и всё такое. Десктопное железо имеет замечательную особенность: совместимость с версиями винды, выходившими во временном промежутке 10-15 лет. Что же имеет смартфонное железо? Нет новой версии ведра для смарта, нет поддержки актуальных версий софта. То есть, винду десятку мы на 775 сокет с пентиумом д накатить можем, поставить хром можем, и лазать в интронетах можем. А на условный смартфон с 4 андроидом накатить даже 6-ой андроид не можем, не говоря уже об актуальных 10 и 11. Так что, считать андроид пользователей, когда речь идёт о востребованности ОСей и кроссплатформенности, не стоит. Если Гуглу захочется, весь Android станет рудиментом с выходом новой "абсолютно уникальной и в 100500 раз лучше, чем Android" операционки. И какая вообще кроссплатформенность в случае с андроидом? Имеется огромный зоопарк софта, заточенного под сенсорное управление. И он абсолютно не нужен больше нигде, кроме андроида. Портировать десктопные приложения на андроид тоже такое себе занятие, пока нет ноутбуков с этой осью.

Отправлено FiEctro 29-08-2022 в 06:23:

Цитата:

Ku2zoff писал:
Андроид пользователи это весьма специфическая категория.

Это для тебя она специфичная. А уж исторически сложилось так что андроид уже стандарт, такой же стандарт как и винда в свои лучшие годы. Это не отменяет озвученных тобой проблем, но увы имеем что имеем. Может когда нибудь гугл сам похоронит андроид, и заменит его какой нить ХромОС или ещё чем то, что будет спроектировано под все возможные платформы.

Цитата:

Ku2zoff писал:
И какая вообще кроссплатформенность в случае с андроидом? Имеется огромный зоопарк софта, заточенного под сенсорное управление. И он абсолютно не нужен больше нигде, кроме андроида. Портировать десктопные приложения на андроид тоже такое себе занятие, пока нет ноутбуков с этой осью.

Это надуманная тобой проблема, сенсорное управление во многих приложениях на андрюхе это вопрос пары строк в коде.

Цитата:

Ku2zoff писал:
Нет новой версии ведра для смарта, нет поддержки актуальных версий софта. То есть, винду десятку мы на 775 сокет с пентиумом д накатить можем, поставить хром можем, и лазать в интронетах можем. А на условный смартфон с 4 андроидом накатить даже 6-ой андроид не можем, не говоря уже об актуальных 10 и 11.

Я думаю всё возможно, просто с костылями и хаками. Да и общей массе этого не нужно, общей массе нужен айфон с циферкой 13 взамен 12.

Отправлено Дядя Миша 29-08-2022 в 06:51:

Цитата:

FiEctro писал:
Так вокруг винды больше не вращается мир

Напомни где именно ты прочитал это утверждение и почему так легко ему поверил.

Цитата:

FiEctro писал:
вырастет новое поколение пользователей для которых винда это рудимент

Не вырастет.

Цитата:

FiEctro писал:
Ты быстро и дешево получаешь прототип, с которым уже можешь идти выбивать деньги.

И тебя спрашивают, а чем твой прототип отличается от миллиона точно таких же, вон их там целая очередь. И все используют точно такой же набор чужих библиотек, как и ты.

Цитата:

FiEctro писал:
А уж исторически сложилось так что андроид уже стандарт

Андроид не стандарт, уже хотя бы потому что каждая новая версия андроида полностью отменяет старую.

Цитата:

FiEctro писал:
Может когда нибудь гугл сам похоронит андроид

Не может быть, а движение в этом направлении идёт полным ходом.
Андроид - это пакость сделанная в точности как ты описал. Берём чужие библиотеки, тяп-ляп и тут же продаём пользователю. Ну а теперь когда рынок захвачен можно спокойно делать новую операционку.

Добавлено 29-08-2022 в 09:51:

NeoAxis полностью построен на чужих библиотеках. Существует с 2006-го года. Т.е. примерно в одно время с Unity. Кому он нужен? Да никому.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-08-2022 в 07:27:

Цитата:

Дядя Миша писал:
Напомни где именно ты прочитал это утверждение и почему так легко ему поверил.

А где винда нужна кроме десктопа и ноутов? На серверах? На мобилках? В гос. аппарате? В науке? В устройствах умного дома?

Цитата:

Дядя Миша писал:
Не вырастет.

Вот скажи, стал бы ты пользоваться XP, если бы сразу начал пользоваться пекарней с семерки? Я думаю нет. Любому человеку банально лень переучиваться. И я прекрасно видел какие страдания и боль начинаются у андроид пользователя впервые севшего за винду.

Цитата:

Дядя Миша писал:
И тебя спрашивают, а чем твой прототип отличается от миллиона точно таких же, вон их там целая очередь. И все используют точно такой же набор чужих библиотек, как и ты.

Тебя инвестор никогда не похвалит за то что ты оптимизировал проект со 100мб до 10мб, а вот то что не сделал кросплатформенность, или вовремя не реализовал нужную фичу (а это как правило очень маленькие сроки рассчитанные впритык, за срыв которых наказывают рублём), тебя обязательно спросят. Я конечно с тобой согласен, с т.з. перфекциониста это отвратительный подход, и твой подход мне больше нравится. Но реальный мир распорядился иначе.

Цитата:

Дядя Миша писал:
Андроид не стандарт, уже хотя бы потому что каждая новая версия андроида полностью отменяет старую.

Ну не полностью, в целом опять же средний цикл жизни бюджетного смартфона 2 года. За эти 2 года врядли что то отвалится.

Цитата:

Дядя Миша писал:
Андроид - это пакость сделанная в точности как ты описал. Берём чужие библиотеки, тяп-ляп и тут же продаём пользователю. Ну а теперь когда рынок захвачен можно спокойно делать новую операционку.

Это дёшево и быстро. Вот представь к тебе в сервис придёт мастер, и будет ковырять 1 ноутбук полгода, ты подойдёшь к нему и спросишь - а чего ты с ним возишься? А он ответит - вы все говноеды, а я сделаю качественно и навека. Как ты будешь относиться к такому мастеру?

Отправлено Дядя Миша 29-08-2022 в 07:40:

Цитата:

FiEctro писал:
А где винда нужна кроме десктопа и ноутов? На серверах? На мобилках? В гос. аппарате? В науке? В устройствах умного дома?

Десктоп и ноут - это именно то, за чем и работают люди. Никому в голову не придёт мысль запускать игровой движок на устройствах умного дома.
А если в этих устройствах есть собственная операционная система и собственные приложения - никто не расстраивается, что их нельзя запустить на виндоуз и линукс.

Цитата:

FiEctro писал:
стал бы ты пользоваться XP, если бы сразу начал пользоваться пекарней с семерки?

Если бы я сразу начал пользоваться компьютером с предустановленной семёркой, была почти 100% вероятность, что я бы тогда не написал вообще никакого Ксаша. В лучшем случае родился бы очередной никому не нужный проект на github для портфолио.

Цитата:

FiEctro писал:
Тебя инвестор никогда не похвалит за то что ты оптимизировал проект со 100мб до 10мб

Ты сейчас живёшь прошлыми стереотипами. Это 10-15 лет назад, когда была задача срочно захватить рынки, всё делалось любой ценой. Поэтому тот же Unity всегда состоял из набора чужих библиотек, который постепенно предполагалось заменить своими реализациями, но...
Ты же видишь, что он с годами становится только тормознее и глючнее.
Да и нет уже запроса срочно пробиться на рынок, обставив всех конкурентов. Движков, использующих сторонние библиотеки - десятки, если не сотни. Они никому не нужны. Потому что обладают примерно похожим функционалом плюс\минус. Да дело вообще не в сторонних библиотеках, если ты вдруг не понял. Сторонние библиотеки - это СЛЕДСТВИЕ. Что твои идеи не выходят за рамки их возможностей.
А значит будет создано что-то такое, что уже тысячи раз воплощено в этих стандартных библиотеках. Если бы все мои идеи в них помещались - я бы даже не стал начинать всё это. Ну а какой смысл?

Цитата:

FiEctro писал:
Но реальный мир распорядился иначе.

Так задача в том, чтобы диктовать мировому сообществу свою непреклонную волю. Чтобы самому задавать тренды, а не пытаться догнать уже существующие. Пока ты их будешь догонять, они уже поменяются.

Цитата:

FiEctro писал:
к тебе в сервис придёт мастер, и будет ковырять 1 ноутбук полгода

Ну ты не путай замену сгоревших запчастей на исправные с выработкой новой концепции. Как будто бы отремонтировав этот ноутбук, его скопируют 8 миллиардов раз и раздадут всем гражданам Земли.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 29-08-2022 в 08:27:

Цитата:

FiEctro писал:
исторически сложилось так что андроид уже стандарт

Во-первых, не исторически, поскольку андроид очень молодая ОСь. Во-вторых, не сложилось, потому что никто никаким стандартам на андроиде не следует. Думаешь почему каждый производитель пилит свои оболочки? Не только, чтобы продавать побочные продукты и услуги. Но ещё и потому, что в чистом андроиде нет нихренашеньки для удобства пользователя. А для мобильных устройств это важно. Это не винда, где юзер априори загрузит сторонний софт, чтобы в нём РАБОТАТЬ. Тут искаропки должно быть всё, это же гаджет: включил, засунул симку и начал ПОТРЕБЛЯТЬ.

Цитата:

FiEctro писал:
Это надуманная тобой проблема, сенсорное управление во многих приложениях на андрюхе это вопрос пары строк в коде.

Ты не так понял. Я не про то сложность интеграции сенсорного управления. Я вот про что:

Цитата:

Дядя Миша писал:
если в этих устройствах есть собственная операционная система и собственные приложения - никто не расстраивается, что их нельзя запустить на виндоуз и линукс

Приложения для андроида нужны лишь пользователям самого андроида. Приложения для десктопа могут быть нужны пользователям андроида, но на сенсорном интерфейсе невозможно работать. Никто в здравом уме не будет таскать с телефоном или планшетом клавиатуру и мышь, когда можно пользоваться ноутбуком.

Цитата:

FiEctro писал:
общей массе этого не нужно, общей массе нужен айфон с циферкой 13 взамен 12

Тогда зачем вообще делать что-то кроссплатформенное? Ну я имею в виду из серьёзного софта, а не игрушек. Разве что мессенджеры, да софт для конференций.

Отправлено Дядя Миша 29-08-2022 в 08:41:

Вообще, как я изначально планировал смотреть в сторону кроссплатформенности:
1. нативная поддержка Windows
2. поддержка Linux через Wine
3. нативная поддержка Android

Но дело в том, что к моменту выхода рабочей версии XashNT, поддержка Android скорее всего готова не будет, к тому же движку нужно какое-то время, чтобы получить распространение в массах. И к этому моменту вполне может оказаться, что Andoid уже дропнут самим Гуглем, а вместо этого предлагается совершенно новая операционка. Причём она может быть интерфейсно совместима с Windows. Мелкомягкие же делают какой-то универсальный API в качестве стандарта. Вот уж что-что, а API у них всегда неплохо получались, равно как и их международная сертификация.
И это поставит окончательную точку в вопросах кроссплатформенности.
Будет такой единый API, которому все операционные системы будут обязаны соответствовать. И будут приложения, которые будут привязаны к этому API.
А смысл кроссплатформенности сведётся лишь к перекомпиляции исходного кода в соответствующий образ. И больше не надо будет таскать с собой зоопарк библиотек из линукса, который к тому же непонятно каких версий.
Такой мой прогноз на будущее кроссплатформенности.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-08-2022 в 09:00:

Цитата:

Дядя Миша писал:

Ты сейчас живёшь прошлыми стереотипами. Это 10-15 лет назад, когда была задача срочно захватить рынки, всё делалось любой ценой. Поэтому тот же Unity всегда состоял из набора чужих библиотек, который постепенно предполагалось заменить своими реализациями, но...

Сегодня это тоже актуально, особенно для мелких студий состоящих из 2х человек которые хотят явить миру что то интересное, и естественно на этим по быстрому заработать денег на новые более крупные проекты, чтобы можно было нанять сотрудников, арендовать офис и т.д.

Цитата:

Дядя Миша писал:

Ты же видишь, что он с годами становится только тормознее и глючнее.

Ничего подобного, Юнити щас наоборот все эти библиотеки выносит в сторонние ассеты, облегчая движок.

Цитата:

Дядя Миша писал:

Да и нет уже запроса срочно пробиться на рынок, обставив всех конкурентов. Движков, использующих сторонние библиотеки - десятки, если не сотни. Они никому не нужны. Потому что обладают примерно похожим функционалом плюс\минус. Да дело вообще не в сторонних библиотеках, если ты вдруг не понял. Сторонние библиотеки - это СЛЕДСТВИЕ. Что твои идеи не выходят за рамки их возможностей.

Использование библиотек != использование их фичей, ну тоесть конечно у приложения должна быть своя идея и концепция за счет чего оно будет выбиваться среди других таких же. Полно софта который собран буквально на коленке и является максимально глючным говном, но тем не менее он выстреливает за счёт своего удобства, и что даже всяким монополистам с огромными бюджетами и своим собственными библиотеками не удаётся повторить их успеха. Просто потому что у них по инерции все ресурсы вбуханы в одну концепцию, и чтобы что то поменять, им придётся перепахать буквально всё. А это большой риск даже для многомилионной компании.

Цитата:

Дядя Миша писал:
А значит будет создано что-то такое, что уже тысячи раз воплощено в этих стандартных библиотеках. Если бы все мои идеи в них помещались - я бы даже не стал начинать всё это. Ну а какой смысл?

В 99% именно так и происходит, но это не из-за того что софт плохой, а из-за того что сам автор не знает для чего он нужен. В первую очередь нужно задаться вопросами - а кто будет использовать твой продукт? И насколько большая эта аудитория? Как её максимально охватить? Чем он лучше уже имеющихся на рынке решений?

Цитата:

Ku2zoff писал:
Во-первых, не исторически, поскольку андроид очень молодая ОСь. Во-вторых, не сложилось, потому что никто никаким стандартам на андроиде не следует. Думаешь почему каждый производитель пилит свои оболочки? Не только, чтобы продавать побочные продукты и услуги. Но ещё и потому, что в чистом андроиде нет нихренашеньки для удобства пользователя. А для мобильных устройств это важно. Это не винда, где юзер априори загрузит сторонний софт, чтобы в нём РАБОТАТЬ. Тут искаропки должно быть всё, это же гаджет: включил, засунул симку и начал ПОТРЕБЛЯТЬ.

Это стадия отрицания, но тем не менее Андроид вне конкуренции среди АРМ архитектуры. И даже под айфоны ты можешь не собирать приложение, но вот под андроид обязательно тебя обяжут.

А что там работает/не работает, это дело десятое, и с тебя как с программиста будут спрашивать совсем другие вещи. А между работать/потреблять это очень узкая грань, чтобы "работать" тебе нужно "потреблять" инструменты и расходники, а иначе никак. Интернет у тебя тоже не из воздуха берется.

Отправлено Дядя Миша 29-08-2022 в 09:31:

Цитата:

FiEctro писал:
В первую очередь нужно задаться вопросами - а кто будет использовать твой продукт? И насколько большая эта аудитория? Как её максимально охватить? Чем он лучше уже имеющихся на рынке решений?

Совершенно верно. Вот этими вопросами я и задаюсь. А уже потом приходит понимание, что придётся почти всё писать самому.

Цитата:

FiEctro писал:
и естественно на этим по быстрому заработать денег на новые более крупные проекты

Ну то есть в очередной раз выкинуть на рынок какое-то дерьмо и по быстрому заработать. Эту поганую идеологию видимо уже открытым текстом вдалбливают в головы всем начинающим разработчикам. Скорее, быстрее, на коленке тяп-ляп. Чтобы не дай бог не составить конкуренции никому.

Цитата:

FiEctro писал:
Полно софта который собран буквально на коленке и является максимально глючным говном, но тем не менее он выстреливает за счёт своего удобства, и что даже всяким монополистам с огромными бюджетами и своим собственными библиотеками не удаётся повторить их успеха

Можно пример такого софта? То что ты описал может выстрелить при полном отсутствии альтернативы, на пустом рынке.

Добавлено 29-08-2022 в 12:31:

И еще одно соображение выскажу. В программировании не действуют законы физики. Когда идёт разработка реальных устройств эти самые законы очень сильно ограничивают в безудержном полёте фантазии. Никто скажем, не сделает автомобилю квадратные колёса, просто потому что так еще никто не делал. В программировании практически нет никаких сдерживающих факторов. Как сделаешь - так и будет. А если у кого-то что-то работает медленно - ему предложат купить новый компьютер.
Но дело даже не в скорости работы. Дело может быть в неоптимальности выбранного подхода. Насколько пользователю удобно взаимодействовать с софтом. А это комплексная тема, где нельзя ограничиваться просто дизайном интерфейсов, как это пробуют сделать сейчас. Дизайн интерфейсов не говорит какие задачи надо возложить на программу, а какие непременно должен выполнять пользователь, он вообще не рассматривает подобные задачи.Равно как и время отклика программы находится вне компетенции дизайна. Причём существует устойчивая тенденция к копированию решений друг у друга, ну просто потому, что "все так делают". И далеко не всегда это оптимальный путь.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 29-08-2022 в 10:36:

Цитата:

FiEctro писал:
Андроид вне конкуренции среди АРМ архитектуры

Какую долю рынка рабочих станций, серверов, да и просто офисных компьютеров сейчас занимают устройства на ARM архитектуре? Ноль целых хрен десятых или просто мало, если вдруг где-то это используется. Поэтому никто не обяжет никого собирать софт под андроид, если этот софт не планируется для мобильных устройств. Конечно, в будущем ситуация может измениться, тогда и будем посмотреть что стандарт, а что рудимент.

Цитата:

FiEctro писал:
А между работать/потреблять это очень узкая грань, чтобы "работать" тебе нужно "потреблять" инструменты и расходники, а иначе никак. Интернет у тебя тоже не из воздуха берется.

Между работать и потреблять очень большое различие. Работать предполагает зарабатывать, а потреблять предполагает тратить. "Потреблять" инструменты и расходники можно с любого устройства, не обязательно с мобильного. А вот уже применять их удобнее и логичнее на устройстве, заточенном под работу. Конечно, сейчас даже на мобилках можно монтировать видосы, например. Но это всё очень ограничено производительностью мобилки, её малой автономностью и неудобностью устройства ввода для данной конкретной задачи.

Отправлено FiEctro 29-08-2022 в 13:31:

Цитата:

Ku2zoff писал:
Между работать и потреблять очень большое различие. Работать предполагает зарабатывать, а потреблять предполагает тратить. "Потреблять" инструменты и расходники можно с любого устройства, не обязательно с мобильного. А вот уже применять их удобнее и логичнее на устройстве, заточенном под работу. Конечно, сейчас даже на мобилках можно монтировать видосы, например. Но это всё очень ограничено производительностью мобилки, её малой автономностью и неудобностью устройства ввода для данной конкретной задачи.

А как раньше люди без компьютеров работали? Что же это получается, по твоей логике мы все лентяи потребляторы? Да и что плохого в разумном потреблении, если ты это можешь себе позволить?

Отправлено Ku2zoff 29-08-2022 в 15:05:

FiEctro ты видишь какую-то неправильную логику. Работать ведь можно ничего из материальных ресурсов не потребляя, лишь расходуя своё время и используя талант или навыки. Например, быть пейсателем или певцом ртом. Или невыносимо талантливым племянником одного известного режиссёра. И вообще, нужно разграничивать ресурсозатраты на производство чего-л. и разбазаривание капитала на развлечения. Речь-то не совсем об этом изначально была. Речь была о кроссплатформенности, и о том, как она сильно нужна в современных реалиях. На самом деле кроссплатформенность - нишевое явление. Для профессионального (научного) софта, например. И то, это занятие сомнительное. Для серьёзной работы быстрее и в перспективе дешевле приобрести машину, на которой работает целевой софт, нежели портировать этот софт на уже имеющуюся машину.
Для каждой платформы есть свои задачи, с которыми прекрасно справляются приложения, написанные под эту платформу, и эти приложения нет никакого смысла портировать на другие платформы. Это всего лишь современный тренд.
Возможно, с подачи Apple или кого-то ещё, ARM архитектура через n-ное количество десятилетий вытеснит x86. Но тогда уже будут готовы универсальные API, которые прогнозирует Дядя Миша. От рудиментов со временем отказываются, это отчётливо прослеживается в индустрии железа. Весь зоопарк портов и интерфейсов, которые имелись у компов 90-х сейчас заменён PCI-E и USB. А что надо древнему софту - эмулируется. Так же будет и с платформ-специфичными фичами.

Отправлено Gandalv 29-08-2022 в 15:17:

Вы пытаетесь сравнивать операционки, которые вообще для разного предназначены.
Андроид делали для потребления контента. Да, на нем можно что-то разрабатывать, можно взять большой планшет, подключить клаву и мышь... Можно вообще на ноутбук поставить андроид, есть x86-совместимые билды. Но все равно работать будет неудобно, он на это не заточен. Нет поддержки многомониторности, нет мультиоконного интерфейса (ну ладно, в андроиде добавили разделение экрана между двумя приложениями, и то все тупит и тормозит). Нет быстрого переключения между окнами.

А вот винда годится не только для потребления, но и для производства контента (как и линукс, и макось). Поэтому эти операционки точно не умрут. По крайней мере, не андроид их убьет.

__________________
Углеродные звезды с древними спутниками, которые колонизируют разумные грибы...
Газовые гиганты, на которых обитает метеорологический разум...
Миры, растянутые на мембранах, где измерения пересекаются...
Это невозможно описать нашим ограниченным языком...

Отправлено Дядя Миша 29-08-2022 в 15:31:

Цитата:

Ku2zoff писал:
ARM архитектура через n-ное количество десятилетий вытеснит x86

От x86 одно название осталось, причём уже давно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 29-08-2022 в 15:37:

Цитата:

Gandalv писал:
Вы пытаетесь сравнивать операционки, которые вообще для разного предназначены.

Я об этом твержу уже несколько постов подряд, не так прямо, конечно. Но смысл именно такой: ОСи для разных задач, приложения для разных задач, так зачем делать кроссплатформенным приложение, которое будет выполнять поставленные задачи только на родной платформе?

Цитата:

Gandalv писал:
А вот винда годится не только для потребления, но и для производства контента (как и линукс, и макось). Поэтому эти операционки точно не умрут. По крайней мере, не андроид их убьет.

Если подумать, ничто не мешает андроиду годиться для производства контента. Контент производят не в ОСи, а в софте. И вот тут... бум! А зачем разрабам делать android-версию какого-нибудь профессионального видеоредактора? При том, что

Цитата:

Gandalv писал:
Можно вообще на ноутбук поставить андроид, есть x86-совместимые билды

x86 билды - редкостное нестабильное говнище, и никому, кроме горстки гиков не нужны.

Отправлено Gandalv 29-08-2022 в 16:23:

Цитата:

Ku2zoff писал:
Контент производят не в ОСи, а в софте

Да только контент производят как правило не в одной софтине, а используют целую связку софтин и плагинов. А задача ОС сделать так, чтобы они нормально работали в сопряжении и чтобы между ними было удобно переключаться и еще кучу всяких "мелочей". А у ондроеда с этим большие проблемы, как я уже написал выше.

Отправлено FiEctro 29-08-2022 в 16:37:

Цитата:

Ku2zoff писал:
FiEctro ты видишь какую-то неправильную логику. Работать ведь можно ничего из материальных ресурсов не потребляя, лишь расходуя своё время и используя талант или навыки. Например, быть пейсателем или певцом ртом. Или невыносимо талантливым племянником одного известного режиссёра.

Если цель сделать говно, наверное да. А так у тебя должен быть вкус и насмотренность. Хороший художник знает все популярные картины, хороший режиссер смотрит много хороших фильмов, хороший писатель очень начитанный, хороший программист изучит все широко известные шаблоны и алгоритмы, а певец слушает много других певцов и всё это потребление в чистом виде. Талант это и есть эта насмотренность. Человек разбирающийся в чём то сможет приступить к деятельности куда быстрее, чем человек который слышит об этой деятельности вообще впервые.

Цитата:

Ku2zoff писал:
И вообще, нужно разграничивать ресурсозатраты на производство чего-л. и разбазаривание капитала на развлечения. Речь-то не совсем об этом изначально была.

Без потребителя - нет производства. Это будет как план пятилетка, когда завод выпускал замки для дверей по плану, потом по плану их ставили в новостройки, народ менял их на свои, и по плану сдавал эти замки в металлолом.

Цитата:

Ku2zoff писал:
Речь была о кроссплатформенности, и о том, как она сильно нужна в современных реалиях. На самом деле кроссплатформенность - нишевое явление. Для профессионального (научного) софта, например. И то, это занятие сомнительное. Для серьёзной работы быстрее и в перспективе дешевле приобрести машину, на которой работает целевой софт, нежели портировать этот софт на уже имеющуюся машину.

Кросплатформенность это больший охват рынка, причем в тех сегментах где нет конкуренции. Тебе об этом любой эффективный менегер скажет.

Цитата:

Ku2zoff писал:
Но тогда уже будут готовы универсальные API, которые прогнозирует Дядя Миша.

Есть всякие Жавы, Сишарпы и Питоны. И Дядя Миша все равно плюётся. Оно и понятно, хошь не хошь, а эмулятор все равно возить на тележке где то рядом придётся. Тут как говорил Ксерокс остаётся только статически Кернел линковать.

Цитата:

Gandalv писал:
Андроид делали для потребления контента.

Андроид делали для АРМ архитектуры. Есть множество профессий где андроид планшеты и смартфоны используются исключительно для работы. Где вы эту байку про потребление вычитали интересно.

Цитата:

Дядя Миша писал:
Можно пример такого софта? То что ты описал может выстрелить при полном отсутствии альтернативы, на пустом рынке.

Из того с чем я работал: Zbrush, Substance Painter, Marvelous Designer, RealFlow.

Отправлено XaeroX 29-08-2022 в 16:40:

Цитата:

FiEctro писал:
Zbrush, Substance Painter, Marvelous Designer, RealFlow

Я правильно понял, что ты считаешь вышеперечисленное - максимально глючным говном, собранным на коленке?

__________________

Отправлено FiEctro 29-08-2022 в 16:43:

XaeroX
Истина познаётся в сравнении. И таки да, это очень косячный софт. Да чего говорить, оказалось в 2022 году многие до сих пор на милкшейпе сидят.

Отправлено XaeroX 29-08-2022 в 17:09:

Цитата:

FiEctro писал:
И таки да, это очень косячный софт.

Погоди. В любом софте есть баги, иногда весьма досадные. Почему ты считаешь, что перечисленный софт - "собран на коленке", то есть разработчики в целом забивали на процессы и стремились выкатить тяп-ляп?

Цитата:

FiEctro писал:
А так у тебя должен быть вкус и насмотренность. Хороший художник знает все популярные картины, хороший режиссер смотрит много хороших фильмов, хороший писатель очень начитанный, хороший программист изучит все широко известные шаблоны и алгоритмы, а певец слушает много других певцов и всё это потребление в чистом виде. Талант это и есть эта насмотренность.

Да-да, а хороший любовник посмотрит все на свете порнофильмы.

Мне кажется, вся эта насмотренность приводит к тому, что ты смотришь, и смотришь, и смотришь... А сам ничего не делаешь. И так до пенсии. А потом вздыхаешь - ну вот вроде бы и посмотрел достаточно, пора самому что-то сделать, а сил уже нет. При этом в голове - калейдоскоп чужих идей. И хорошо ещё, если хватит сил на ремейк ~~Чазма~~.

Добавлено 29-08-2022 в 13:09:

Я уже больше пятнадцати лет наблюдаю за нашими форумчанами, и пришёл к выводу, что чем меньше человек смотрел на наработки других - именно с целью воспитать вкус, а не как на отдельно взятые источники вдохновения, которых обычно немного - тем выше шансы, что он выкатил какой-нибудь релиз. Не всегда удачный (талант и пролетарское чутъё ещё никто не отменял), но тем не менее.

Проблема всех подобных обсуждений в том, что народ хочет вывести рецепт успеха. То есть, мол, будем делать вот это и вот это - и точно сделаем годный продукт, заработаем кучу бабок и арендуем офис в центре Торонто на 50-м этаже с видом на прекрасные закаты. Но оно так не работает, нет неко ких рецептов успеха, и американская мечта в стиле "работай усердно, Джон, и твой загородный дом с гаражом на два авто ждёт тебя" давно мертва. Просто одним удаётся, а другим нет. И те, кому удалось - редко могут рассказать, в чём заключался рецепт успеха. То есть они конечно могут что-то рассказать, и даже написать книгу (и продать её большим тиражом) - но не факт, что это будет иметь что-то общее с реальностью.

__________________

Отправлено Дядя Миша 29-08-2022 в 19:19:

Цитата:

FiEctro писал:
Есть всякие Жавы, Сишарпы и Питоны. И Дядя Миша все равно плюётся

Ты посмотри на размер их фреймворков и зоопарк версий. Тоже начнёшь плеваться.

Добавлено 29-08-2022 в 22:19:

Цитата:

XaeroX писал:
Мне кажется, вся эта насмотренность приводит к тому, что ты смотришь, и смотришь, и смотришь... А сам ничего не делаешь. И так до пенсии.

Так ведь был у нас когда-то форумчанин. Не помню его ник. Он всё время ролики на ютубе смотрел еще.

Цитата:

XaeroX писал:
И те, кому удалось - редко могут рассказать, в чём заключался рецепт успеха

Потому что второй раз такого благоприятного стечения событий уже не будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-08-2022 в 22:35:

Цитата:

XaeroX писал:
Погоди. В любом софте есть баги, иногда весьма досадные. Почему ты считаешь, что перечисленный софт - "собран на коленке", то есть разработчики в целом забивали на процессы и стремились выкатить тяп-ляп?

Дело не совсем в багах. Дело в том что они по сути дублируют возможности обычных 3д пакетов, но делают это намного лучше их в одной конкретной области, при том крайне сосут во всех остальных. И да большинство из этих прог были собраны на коленке, и уже потом развились из себя во что то более крупное.

Цитата:

XaeroX писал:
Я уже больше пятнадцати лет наблюдаю за нашими форумчанами, и пришёл к выводу, что чем меньше человек смотрел на наработки других - именно с целью воспитать вкус, а не как на отдельно взятые источники вдохновения, которых обычно немного - тем выше шансы, что он выкатил какой-нибудь релиз. Не всегда удачный (талант и пролетарское чутъё ещё никто не отменял), но тем не менее.

Я вижу здесь попытку подколоть. Но на самом деле это никак не влияет ни на успех, ни на провал проекта, ни просто его релиз. Код кваки ты же конечно никогда не смотрел, и в Deus Ex никогда не играл, взял с первого раза всё с нуля написал. Талант!

Цитата:

Дядя Миша писал:
Ты посмотри на размер их фреймворков и зоопарк версий. Тоже начнёшь плеваться.

Сама винда один большой сплошной набор жирных фреймворков. Что поделать теперь. Сколько только одни драйвера на видюху весят.

Отправлено XaeroX 29-08-2022 в 23:28:

Цитата:

FiEctro писал:
Я вижу здесь попытку подколоть.

Ну разумеется, ты её видишь, кто бы сомневался.

У тебя какая-то странная реакция на мои посты, где я совершенно обычным способом высказываю совершенно банальное мнение. Вот если бы я айс-пит упомянул - тогда другое дело, но я ведь не упомянул! Хотя, стоп.. Oh shi~

Вон Дядя Миша прямым текстом пишет:

Цитата:

Дядя Миша писал:
Так ведь был у нас когда-то форумчанин. Не помню его ник. Он всё время ролики на ютубе смотрел еще.

Но тут, конечно же, неко кой попытки подколоть нет.

Добавлено 29-08-2022 в 19:28:

Цитата:

FiEctro писал:
Код кваки ты же конечно никогда не смотрел, и в Deus Ex никогда не играл, взял с первого раза всё с нуля написал.

Цитата:

XaeroX писал:
именно с целью воспитать вкус, а не как на отдельно взятые источники вдохновения, которых обычно немного

Читай внимательнее, что я пишу.
От того, что я посмотрел код кваки - я не получил никакой насмотренности, ведь кругом коды разных других движков, куда я не заглядывал.
От того, что я поиграл в Deus Ex - я не получил никакой насмотренности, ведь кругом полно всяких других Action/RPG, типа того же Систем Шока, которые я если и видел, то пару раз на скриншотах, а про многие, скорее всего, до сих пор даже не подозреваю.
Если бы я занялся изучением чужих движков, и играл в десятки, а то и сотни игр - то, безусловно, получил бы отличное представление о том, во что народ играет, и как народ кодит движки, но это вряд ли приблизило к пресловутому коту Арсису.
А так, увидел пару-тройку вещей, которые зацепили, вдохновился, и пошло-поехало.

__________________

Отправлено Ku2zoff 30-08-2022 в 06:43:

Цитата:

FiEctro писал:
Кросплатформенность это больший охват рынка

Не-а. Чтобы охватить рынок как можно больше, нужно выбрать рынок как можно больше и подходящую целевую аудиторию. Хороший пример - Flappy Bird.

Добавлено 30-08-2022 в 13:43:

Не вздумай приплетать сюда игровые движки и консоли. В современных реалиях консоли почти не отличается от ПК. Даже архитектура (кто бы мог подумать, вот неожиданность, да?) у них x86. Рынок консолей всегда был знатной баблодойкой хомячков, чтобы это понять, достаточно немного изучить историю Японии. Если раньше, лет 40-30 назад покупка консоли была оправдана, пеки в игры не могли, то сейчас разницы нет. Консоли приобретают либо ради эксклюзивов, либо "избалованные придурки, которым некуда деньги девать."

Отправлено Дядя Миша 30-08-2022 в 06:56:

Цитата:

FiEctro писал:
Сама винда один большой сплошной набор жирных фреймворков.

У WinAPI слава богу нет никаких версий. Те функции, что доступны в 95-й, будут работать и на Win10.

Цитата:

Ku2zoff писал:
Рынок консолей всегда был знатной баблодойкой хомячков, чтобы это понять, достаточно немного изучить историю Японии.

Консоли изначально начинались как компьютер только для игр. Взрослый ПК стоил тысячу долларов, консоль стоила 100 долларов. В этом и был их смысл.
Но поскольку рынок со временем всё извращает, теперь консоль обойдется дороже ПК, пусть и б\у шного, однако вполне себе актуального.
Этого противоречия никто не хочет замечать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Chyvachok 30-08-2022 в 07:09:

Консоли у меня всегда вызывали вопрос, зачем они существуют в принципе, и почему люди любят хавать фекалии. Не знаю кто в здравом уме купит обрезанный недо-пк, когда есть собственно ПК? Особенно когда сейчас оно как я понимаю стоит по цене полноценного компа, не сильно в теме, потому что я никогда не видел смысла в них и не интересовался.

Отправлено XaeroX 30-08-2022 в 07:13:

Цитата:

Дядя Миша писал:
Те функции, что доступны в 95-й, будут работать и на Win10.

...но порой не так, как ожидалось. Помнишь, как старые версии халфы не запускались на икс-пи с ошибкой "оперативной памяти меньше 16 Мб"? Нужно было включать режим совместимости.

__________________

Отправлено FiEctro 30-08-2022 в 08:05:

Цитата:

Chyvachok писал:
Консоли у меня всегда вызывали вопрос, зачем они существуют в принципе, и почему люди любят хавать фекалии. Не знаю кто в здравом уме купит обрезанный недо-пк, когда есть собственно ПК? Особенно когда сейчас оно как я понимаю стоит по цене полноценного компа, не сильно в теме, потому что я никогда не видел смысла в них и не интересовался.

Это дешевле, не надо тратиться на монитор и переферию, лицензию винды и т.д. Всё идёт из коробки. Хотя в конечном итоге издатель всеравно выжмет денег больше конскими ценами на диски.

Отправлено Ku2zoff 30-08-2022 в 08:15:

Цитата:

FiEctro писал:
Это дешевле

Ты в какой-то другой реальности живешь, или в Нерезиновой другие цены, нежели в России? Монитор стоит дешевле хорошего телевизора, это раз. Игры на пк стоят значительно дешевле, это два. Периферия для ПК стоит дешевле, чем расходники для консоли, типа геймпадов. Видел цены на X-ящиковский геймпад в магазине на 3 буквы? 17 тысяч вечнодеревянных.

Отправлено FiEctro 30-08-2022 в 08:20:

Цитата:

Ku2zoff писал:
Видел цены на X-ящиковский геймпад в магазине на 3 буквы? 17 тысяч вечнодеревянных.

Расскажи нам во сколько обойдётся компьютер который потянет все игры уровня ps5 например со стабильными 120 фпс в 4к. При том что цены сейчас на ps5 колеблятся в районе 50-70к руб.

Цитата:

Ku2zoff писал:
Монитор стоит дешевле хорошего телевизора, это раз.

А хороший монитор стоит дороже хорошего телевизора, это два.

Цитата:

Ku2zoff писал:
Игры на пк стоят значительно дешевле, это два.

Здесь согласен, о чем написал выше. Но на консоли тоже игры пиратят.

Цитата:

XaeroX писал:
...но порой не так, как ожидалось. Помнишь, как старые версии халфы не запускались на икс-пи с ошибкой "оперативной памяти меньше 16 Мб"? Нужно было включать режим совместимости.

Да софт от 95й винды не всегда на самой 95й винде корректно работал, чего уж говорить про более свежие ОС. Поддержка очень условная, напоминает русскую рулетку.

Отправлено Дядя Миша 30-08-2022 в 08:57:

Цитата:

XaeroX писал:
Помнишь, как старые версии халфы не запускались на икс-пи с ошибкой "оперативной памяти меньше 16 Мб"?

Не сталкивался с таким.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 30-08-2022 в 09:50:

Цитата:

FiEctro писал:
со стабильными 120 фпс в 4к

Это необязательно. Раньше 3д ускорители были не у всех, и норот не жаловался, играл в софтваре.

Цитата:

FiEctro писал:
А хороший монитор стоит дороже хорошего телевизора, это два.

Это необязательно. Норот покупает за пару тыщ бу-шку у продавца со странным именем Срук, и не жалуется.

Цитата:

Дядя Миша писал:
Не сталкивался с таким.

Это какие-то ранние стимовские билды времён выхода кс 1.6, года 2003-2004. Вон-версии так себя не ведут.

Отправлено FiEctro 30-08-2022 в 10:22:

Цитата:

Ku2zoff писал:
Это необязательно. Норот покупает за пару тыщ бу-шку у продавца со странным именем Срук, и не жалуется.

Ну так купи б/у консоль за пару тыщ с рук

. Ты конечно загнул сравнивать б/у бюджетный хлам с новёхонькими консолями.

Отправлено Ku2zoff 30-08-2022 в 10:54:

FiEctro если нет разницы в итоговом результате, зачем платить больше? Я понимаю, что многим надо 200+ фпс при 4k, но остальные довольны тем, что хотя бы запускается в 30 фпс. На ютюбе полно видосов про бюджетные компы, и это массовое явление.

Отправлено Ku2zoff 30-08-2022 в 15:04:

Короче, какой можно подвести итог? Касательно XashNT. С одной стороны изначально делать его кроссплатформенным это, конечно, неплохо. С другой стороны, Xash3D стал кроссплатформенным после допиливания сторонними ребятами. И этот форк обрёл популярность только из-за того, что школоло смогло играть на смартвонях в сраную каэсочку. Не будь сраной каэсочки - никому кроссплатформенный ксаш (и голдсорс тоже) не нужен был бы. То есть, мы всё-таки упираемся в целевую аудиторию и целевые устройства. Поскольку ДМ очень сильно ориентируется на свалкера в тестировании и демонстрациях, логично предположить, что целевым устройством будет ПК, а целевой платформой шindows. А дальше уже портируют те, кому надо. Например, если сконвертируют мультиплеер свалкера, чтобы шкальники могли мериться органами по своей шкале, играя со смартвоней.

Отправлено Дядя Миша 30-08-2022 в 15:35:

Цитата:

Ku2zoff писал:
Поскольку ДМ очень сильно ориентируется на свалкера в тестировании и демонстрациях

Это самый простой способ добыть большие локации для тестирования.
Ну еще метро можно.

Добавлено 30-08-2022 в 18:35:

Вообще я на карты сталкера ориентируюсь как нечто абстрактное, что еще по силам создать сравнительно небольшой команде разработчиков - ландшафт, домики поставить, деревья там.
То есть скажем уровень детализации того же Метро потянуть гораздо сложнее будет - тут нужно владеть хорошими навыками блендера\макса.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 30-08-2022 в 15:49:

Цитата:

Ku2zoff писал:
Короче, какой можно подвести итог? Касательно XashNT. С одной стороны изначально делать его кроссплатформенным это, конечно, неплохо. С другой стороны, Xash3D стал кроссплатформенным после допиливания сторонними ребятами. И этот форк обрёл популярность только из-за того, что школоло смогло играть на смартвонях в сраную каэсочку. Не будь сраной каэсочки - никому кроссплатформенный ксаш (и голдсорс тоже) не нужен был бы. То есть, мы всё-таки упираемся в целевую аудиторию и целевые устройства. Поскольку ДМ очень сильно ориентируется на свалкера в тестировании и демонстрациях, логично предположить, что целевым устройством будет ПК, а целевой платформой шindows. А дальше уже портируют те, кому надо. Например, если сконвертируют мультиплеер свалкера, чтобы шкальники могли мериться органами по своей шкале, играя со смартвоней.

Ты не забывай, что Xash3D стал инструментом для уже сформированного огромного коммьюнити фанов HL/CS и соответствующей тонны уже сделанных ресурсов, в то время как XashNT не будет иметь вообще никакой подобной преемственности. По крайней мере, из того что я понял из написанного в этом топике. Ну и еще не стоит забывать лицензионный вопрос (то есть не будет никакого HLSDK в той форме, в которой он исходно есть). Соответсвенно, XashNT появится в вакууме, и ему пройдётся пройти путь, который не нужно было проходить Xash3D - то есть найти своё предназначение среди всех уже существующих и аналогичных решений. А по слухам из народа, к которому я довольно близок, народ посмотрев и поработав с Xash3D/XashXT вообще не горит желанием как то дальше связываться с XashNT.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 30-08-2022 в 16:07:

Цитата:

SNMetamorph писал:
в то время как XashNT не будет иметь вообще никакой подобной преемственности

Вообще-то будет. Как минимум для тех, кому понравился Xash3D.

Цитата:

SNMetamorph писал:
народ посмотрев и поработав с Xash3D/XashXT вообще не горит желанием как то дальше связываться с XashNT.

Еще бы понять, как они вообще начали на нём работать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 30-08-2022 в 16:11:

Цитата:

Дядя Миша писал:
Как минимум для тех, кому понравился Xash3D.

Так его юзают, не потому что он сам по себе интересный, а в первую очередь потому что это все имеет прямое отношение к Half-Life и HLSDK соответственно. Еще пока ни один человек не попадался, который бы из квейка пришёл сразу ковырять ксаш просто потому что ему движок понравился. У них там свои альтернативы есть, в даже еще бОльшем количестве.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Aynekko 30-08-2022 в 16:22:

Цитата:

Дядя Миша писал:
Вообще-то будет. Как минимум для тех, кому понравился Xash3D.

Мне ксаш зашел именно тем, что это та же халфа, только с раздутыми лимитами на все, что можно, и графическими плюшками. В отвязке от халфы будет уже не то. Если бы мне нужен был именно движок, я бы может взял анрилу какую-нибудь. Только там всю игровую логику с нуля делать, а в ксашмоде уже все готовое.
Но я так понимаю, что ксашНТ будет уже с игровой логикой от халфы, ведь там по сути ксашмод. Не совсем понятно.
В любом случае ксаш3д стал популярен именно благодаря халфе и (о ужас...) кс на мобилках. А вот у ксашНТ есть шанс популяризоваться только за счет имени ксаша3д, типа "новый ксаш". А как там дальше пойдет, никто не знает.

__________________
Мой мод на Xash

Отправлено XaeroX 30-08-2022 в 16:37:

Цитата:

Aynekko писал:
В отвязке от халфы будет уже не то.

У нас на форуме уже есть движок, отвязанный от халфы, и не особо заинтересовавший народ. Но его особо и не рекламировали, а в последние десять лет и SDK неко ких нет. Посмотрим, что получится с движком, который будут рекламировать и активно работать с комьюнити. Ну а вдруг?..

__________________

Отправлено FiEctro 30-08-2022 в 17:00:

Цитата:

SNMetamorph писал:
Так его юзают, не потому что он сам по себе интересный, а в первую очередь потому что это все имеет прямое отношение к Half-Life и HLSDK соответственно.

Учитывая что хлсдк так и не был до сих пор задокументирован, ну такое.

Отправлено Дядя Миша 30-08-2022 в 18:43:

Цитата:

SNMetamorph писал:
а в первую очередь потому что это все имеет прямое отношение к Half-Life и HLSDK соответственно.

Не совсем так. Халфа - это такой движок для минимальной возможности создать что-то приличное, по крайней мере лет 10-15 назад. Скажем та же первая параноя вполне себе тягалась с некоторыми играми 2005-го года и чем-то выглядела не хуже их. Опять-таки упощенный процесс создания ресурсов. Низкий порог вхождения. Но сам голдсорс уже совсем устарел, лимиты смешные. И тут выходит ксаш, который продлевает ему жизнь на несколько лет. И можно не переучиваться, а спокойно кубать с новыми возможностями.

Цитата:

SNMetamorph писал:
Еще пока ни один человек не попадался, который бы из квейка пришёл сразу ковырять ксаш просто потому что ему движок понравился

В квейке с одной стороны шареная палитра + вертексная анимация, но с другой - целая куча кастомных движков. Т.е. какие у них могли быть возможности от модифицированных движков, но с оригинальными ресурсами - они всё это получили уже в 2000-м году. Вполне естественно, что у них там уже стереотипы сложились, как всё это должно быть. Справедливости ради стоит отметить, что с халфы на квейк тоже никто не перебегает.

Цитата:

Aynekko писал:
Мне ксаш зашел именно тем, что это та же халфа, только с раздутыми лимитами на все, что можно, и графическими плюшками.

Ну вот представь что будет естественное расширение. С одной стороны можно будет по инерции всё еще кубать как в халфе,с другой - уже создавать серьезные уровни с физикой и графикой. Ну и набор энтить тоже никуда не денется.

Добавлено 30-08-2022 в 21:43:

И еще один неочевидный момент. От ксаша всегда ожидали гораздо больше чем он мог дать. То есть у меня точка отсчёта была халфа - я сравнивал с ней. Но народ от меня ждал возможностей как минимум CryEngine.
Такой вот удивительный кредит доверия. Я уж молчу, что на стримах P2 в каментах куча народу гадает - не то UE4, не то Сталкер, не то Сорс.
То есть их ожидания не то чтобы не оправдываются совсем, но как-то неравномерно что-ли.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 30-08-2022 в 18:50:

Цитата:

Дядя Миша писал:
Но народ от меня ждал возможностей как минимум CryEngine.

Народ сам ничего не ожидает, народу надо внушить идею.
Если ты покажешь демку с озером и тремя домиками - то народ мысленно дорисует в голове и будет ждать уровень размером со сталкеровские болота. А если показать народу уровни Wolfram - то и ожидания будут более чем скромные (а потом приятный сюрприз).

__________________

Отправлено SNMetamorph 30-08-2022 в 18:57:

Цитата:

Дядя Миша писал:
Справедливости ради стоит отметить, что с халфы на квейк тоже никто не перебегает.

Да, и это как раз мои слова подтверждает.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 30-08-2022 в 19:17:

Цитата:

XaeroX писал:
Если ты покажешь демку с озером и тремя домиками - то народ мысленно дорисует в голове и будет ждать уровень размером со сталкеровские болота.

Если народу показать сталкеровские болота, он будет ждать болота в 10 раз больше или всё же есть какой-то внутренний предел, когда они скажут - ну вот теперь норм.

Цитата:

XaeroX писал:
то и ожидания будут более чем скромные (а потом приятный сюрприз).

Увы, это так не работает. Если народу показать колидорные уровни, они этот движок вообще не будут даже рассматривать. Забудут через секунду.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 30-08-2022 в 20:04:

Цитата:

Дядя Миша писал:
или всё же есть какой-то внутренний предел, когда они скажут - ну вот теперь норм.

Ну если увидят в какой-нибудь игре болота ещё больше - то и будут ждать.

Цитата:

Дядя Миша писал:
Если народу показать колидорные уровни, они этот движок вообще не будут даже рассматривать. Забудут через секунду.

И так бывает, да. Но в таком разе думаешь - а может, оно и к лучшему? Народ же - он требовательный и непримиримый. Он за всё хорошее и против всего плохого. И будешь потом всю жизнь слугой народа. А это, как показывает история, ничем хорошим не заканчивается.

__________________

Отправлено Дядя Миша 30-08-2022 в 20:08:

Ну просто народ привычный. Если ему показать колидоры - он моментально себе представит, что колидоров могут быть многие километры. С незапамятных времён так. А если показать озеро и 3 домика, будут надеяться, что размеры карты ничем не ограничены.
У меня еще со времён xash_demo задумка так и не реализована в полной мере. Ну вот на новом движке надеюсь выполню так, как планировал в 2012-м. Но тогда не прокатило.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 30-08-2022 в 20:16:

Цитата:

Дядя Миша писал:
Если народу показать сталкеровские болота, он будет ждать болота в 10 раз больше или всё же есть какой-то внутренний предел, когда они скажут - ну вот теперь норм.

Я вообще как то даже не представляю, чем можно впечатлить народ. Графика уже относительно давно достигла предела, когда картинка в последующих поколениях игр не сильно отличается, а то и не отличается от предыдущих, ибо уже есть определенный уровень фотореалистичности, и дополнить его можно разве что какими-то малозначительными деталями, которые далеко не каждый заметит, да и вообще не факт, что будет высматривать.
Геймплей? Так попробуй еще найди игру с реально интересным геймплеем, среди того что сейчас релизят. Почему-то в старых играх с этим обстояло намного лучше.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено XaeroX 30-08-2022 в 20:57:

Цитата:

Дядя Миша писал:
А если показать озеро и 3 домика, будут надеяться, что размеры карты ничем не ограничены.

Да, можно будет сделать какую-нибудь оригинальную находку, радующую игроков. Помнишь, как в Half-Quake 2 нужно было ждать на уровне поезд 40 минут реального времени? А тут нужно будет бежать от одной локации к другой 40 минут реального времени. Вот это я понимаю - геймплей, не то что.

__________________

Отправлено Ku2zoff 31-08-2022 в 03:54:

Цитата:

SNMetamorph писал:
Я вообще как то даже не представляю, чем можно впечатлить народ.

Интересными игровыми механиками. Например, чтобы НПС не просто стояли на спавнах, а что-то делали, и разнообразное. Возьмём для примера катоф из первого Деуса. Они вроде бы просто ходят по картам и шипят на игрока, если он на них наступит. Но как-то я увидел, что от кота убегает мыш, а он за ней. Надо, чтобы кот мыш поймал и съел. Или другой пример: во втором Оверлорде миньоны могут напяливать себе на бошки всякую фигню, бухать и блевать. Вроде малозаметная мелочь, а забавляет.

Цитата:

SNMetamorph писал:
в старых играх с этим обстояло намного лучше

Это либо взгляд через призму ностальгии (синдром утъонка), либо закономерность. Сейчас очень много внимания уделяется визуальной составляющей игр. Раньше, когда у всех картинка была одинаково убогая, старались выделить свою игру чем-то другим. Графика - это конечно хорошо, но действительно удачные игры остаются интересными даже через десятилетия. Червяки какие-нибудь, например.

Добавлено 31-08-2022 в 10:49:

Цитата:

XaeroX писал:
А тут нужно будет бежать от одной локации к другой 40 минут реального времени.

Квест по поиску чувака в соседней деревне. Игрок туда прибегает, а ему говорят: "А чувак уехал 10 минут назад". И игрок 40 минут возвращается за ним в первую деревню. Прям как в Лост Альфе, где постоянная беготня с локации на локацию.

Добавлено 31-08-2022 в 10:54:

Цитата:

Дядя Миша писал:
если показать озеро и 3 домика

То надо будет показать ещё корованы и сделать, чтобы домики обязательно деревянные, и обязательно набигали.

Отправлено FiEctro 31-08-2022 в 06:03:

Цитата:

Ku2zoff писал:
Это либо взгляд через призму ностальгии (синдром утъонка), либо закономерность. Сейчас очень много внимания уделяется визуальной составляющей игр. Раньше, когда у всех картинка была одинаково убогая, старались выделить свою игру чем-то другим. Графика - это конечно хорошо, но действительно удачные игры остаются интересными даже через десятилетия. Червяки какие-нибудь, например.

Раньше как раз и пытались удивлять народ максимально реалистичным графоном на тот момент. Мол все делают шестигранник на лицо, а мы сделаем 10гранник

Сейчас ассортимент и разнообразие игр куда больше. А тогда выбирать особо не приходилось, особенно если у тебя не было интернета. Берешь наличку, идешь в местную рыгаловку и пытаешься выбрать среди кучи некачественных пираток что то интересное.

Цитата:

Ku2zoff писал:
Интересными игровыми механиками. Например, чтобы НПС не просто стояли на спавнах, а что-то делали, и разнообразное. Возьмём для примера катоф из первого Деуса. Они вроде бы просто ходят по картам и шипят на игрока, если он на них наступит. Но как-то я увидел, что от кота убегает мыш, а он за ней. Надо, чтобы кот мыш поймал и съел. Или другой пример: во втором Оверлорде миньоны могут напяливать себе на бошки всякую фигню, бухать и блевать. Вроде малозаметная мелочь, а забавляет.

Игроки любят новый опыт, в клоны чего либо они не особо охотно будут играть.

Цитата:

Ku2zoff писал:
Квест по поиску чувака в соседней деревне. Игрок туда прибегает, а ему говорят: "А чувак уехал 10 минут назад". И игрок 40 минут возвращается за ним в первую деревню. Прям как в Лост Альфе, где постоянная беготня с локации на локацию.

И чтобы во всех квестах желтый текст был на желтом фоне на желтых уровнях.

Цитата:

XaeroX писал:
как в Half-Quake 2

Автор халф квейка очень своеобразный человек обогнавший своё время. Сделай он его сейчас на каком нить движке и выложи в стим, получили бы новую Амнезию.

Цитата:

Дядя Миша писал:
Ну просто народ привычный. Если ему показать колидоры - он моментально себе представит, что колидоров могут быть многие километры. С незапамятных времён так. А если показать озеро и 3 домика, будут надеяться, что размеры карты ничем не ограничены.
У меня еще со времён xash_demo задумка так и не реализована в полной мере. Ну вот на новом движке надеюсь выполню так, как планировал в 2012-м. Но тогда не прокатило.

Для движка не надо ничего показывать. Нужны конкретные примеры и документация. Например в ксашмоде был набор карт который показывал конкретные фичи, вот это хорошо.

Отправлено Дядя Миша 31-08-2022 в 06:55:

Цитата:

Ku2zoff писал:
Игрок туда прибегает, а ему говорят: "А чувак уехал 10 минут назад".

Товарищ Полыхаев принадлежал к тому классу ответственных работников, которые "был или только что вышел".

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено AntiDote 31-08-2022 в 07:20:

так в чем сложность рисовалку карт вставить, если какой-то нонейм кодер сделал что можно шикарные карты рисовать прямо в paint (DrawMap) слабые вы кодеры

Отправлено Дядя Миша 31-08-2022 в 08:01:

AntiDote не жди пока другие сделают - сам вставь, будешь сильным кодером.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-08-2022 в 10:45:

AntiDote
Так чем тебя DrawMap не устраивает? Кстати гугл по этому запросу выдаёт фигню, где скачать можно пощупать? Рисуй да импортируй куда надо.

Отправлено Ku2zoff 31-08-2022 в 11:53:

FiEctro https://gamebanana.com/tools/5715

Отправлено SNMetamorph 31-08-2022 в 14:37:

Цитата:

Ku2zoff писал:
Это либо взгляд через призму ностальгии (синдром утъонка), либо закономерность.

Какая у меня может быть призма ностальгии, если я на 15-20 лет младше среднестатистического юзера HLFX? Для моего поколения призма ностальгии это игры по типу NFS: Most Wanted, Underground 1/2, и т.п. из промежутка 2006-2012

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено XaeroX 31-08-2022 в 14:47:

Цитата:

SNMetamorph писал:
если я на 15-20 лет младше среднестатистического юзера HLFX

Тебе всего 15 лет?

__________________

Отправлено Дядя Миша 01-09-2022 в 11:10:

В метро 2033 на удивление мелкие уровни. Вот к примеру мёртвый город, часть первая.

Компенсируется это живым окружением, т.е. там какие-то монстры прыгают, провода раскачиваются, машинки опять же могут сползти в пропасть.
Здесь на скриншоте только статика, до энтить\лампочек пока не добрался, когда-нибудь потом займусь.

Добавлено 01-09-2022 в 14:10:

И кстати. Вопреки расхожим представлениям, в метро таки есть лайтмапа.
Одна несжатая страница 2048х2048 на любой уровень, даже самый мелкий.
Видимо прикручивали когда форматы ресурсов менять было уже нельзя, может до последнего надеялись обойтись без лайтмапы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-09-2022 в 11:32:

Дядя Миша
А что всё такое шумное? Мипмаппинг отвалился? После компиляции развертка сохраняется, и можно накладывать оригинальные лайтмапы? И что по оптимизации отдаленной геометрии?

Отправлено Дядя Миша 01-09-2022 в 12:01:

Цитата:

FiEctro писал:
А что всё такое шумное? Мипмаппинг отвалился?

Конвертация текстур производилась сторонней утилитой MetroEx, она и похерила мипы. И альфа-каналы тоже.

Цитата:

FiEctro писал:
После компиляции развертка сохраняется, и можно накладывать оригинальные лайтмапы?

Нет, не сохраняется, но вообще можно сделать, я думал об этом.
Впрочем те кто ковырял формат метрошных карт, так и не раскопали где там хранятся лампочки. А у меня сейчас нет времени с этим подробно разбираться. Может в следующем году займусь.

Цитата:

FiEctro писал:
И что по оптимизации отдаленной геометрии?

Не знаю, там ставятся статик-модели, которые не вкомпиливаются в основной буффер. Вот у них есть два лода. Импосторов вроде бы нет.
Да игра коридорная, што там оптимизировать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-09-2022 в 05:53:

Цитата:

Дядя Миша писал:
Нет, не сохраняется, но вообще можно сделать, я думал об этом.

Можно сделать ключ, если оригинальная развертка для лайтмап калечная - делать свою, если нет то подгружать оригинальную.

Отправлено Дядя Миша 02-09-2022 в 06:55:

Компилятор прекрасно генерит собственную развертку, с этим нет особых проблем.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 02-09-2022 в 07:13:

Цитата:

Дядя Миша писал:
В метро 2033 на удивление мелкие уровни. Вот к примеру мёртвый город, часть первая.

Компенсируется это живым окружением, т.е. там какие-то монстры прыгают, провода раскачиваются, машинки опять же могут сползти в пропасть.
Здесь на скриншоте только статика, до энтить\лампочек пока не добрался, когда-нибудь потом займусь.

Добавлено 01-09-2022 в 14:10:

И кстати. Вопреки расхожим представлениям, в метро таки есть лайтмапа.
Одна несжатая страница 2048х2048 на любой уровень, даже самый мелкий.
Видимо прикручивали когда форматы ресурсов менять было уже нельзя, может до последнего надеялись обойтись без лайтмапы.

А чего так много DIPов на такую маленькую сцену? Всего 300к полигонов.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 02-09-2022 в 07:36:

Цитата:

SNMetamorph писал:
А чего так много DIPов на такую маленькую сцену?

А сколько надо?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-09-2022 в 07:40:

Дядя Миша
Для всяких статичных пропсов эффективнее использовать вручную созданную развертку. На порядок будет меньше косяков. Но лучше конечно провести эксперимент, можешь запечь лайтмапу на модельке Аликс например? У неё вроде нет перекрывающихся островков, так что можно сравнить оба метода.

Отправлено Дядя Миша 02-09-2022 в 07:56:

Цитата:

FiEctro писал:
Для всяких статичных пропсов эффективнее использовать вручную созданную развертку

Ну ты же смотрел карты и имел возможность убедиться, что с разверткой проблем нету.

Цитата:

FiEctro писал:
можешь запечь лайтмапу на модельке Аликс например

Могу, но там повертексное эффективнее ляжет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-09-2022 в 08:17:

Цитата:

Дядя Миша писал:
Ну ты же смотрел карты и имел возможность убедиться, что с разверткой проблем нету.

Помню ты на спонзе отлавливал какие то косяки. Так что наверное это уже не актуально.

Цитата:

Дядя Миша писал:
Могу, но там повертексное эффективнее ляжет.

Было бы интересно посмотреть как отработает твой лайтмаппер на такой сложной модели.

Отправлено Дядя Миша 02-09-2022 в 10:17:

У меня нет хорошего исходника этой модельки. То что есть - делал Raid путём разрезания сорсовского исходника на несколько кусков, чтобы голдсорсовский компилятор смог её скомпилировать. А затем голдсорсовская модель, минуя стадию декомпиляции была сконвертирована в формат, понятный XashNT. Поэтому получилось вот такое:

Вот повертексное, как я и говорил - смотрится получше

потому что несмотря на разрубленную модель, физическая связь между вертексами осталась.

Добавлено 02-09-2022 в 13:12:

Посчитал свет с samplesize 1. Чем-то похоже на повертексное, но с окантовкой в тех местах, где меш порубили на части.

Добавлено 02-09-2022 в 13:17:

Хмм, я признаться тоже удивился, ну почему лайтмапа выглядит с таким недостаточным разрешением, по сравнению с вертексным. А потом включил сетку:

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-09-2022 в 11:35:

Дядя Миша
Выглядит очень даже недурно, за исключением черных полосок. Хоть в первой итерации куда то отвалились тени. А причем тут Раид, есть у тебя компилятор сам строит развертку? Можно подробнее?

И как пишется информация для повертексного освещения? Он создаёт отдельный слот для цветов вертексов конкретной модели? Или просто берет освещение с пола и точечных объектов?

Цитата:

Дядя Миша писал:
Хмм, я признаться тоже удивился, ну почему лайтмапа выглядит с таким недостаточным разрешением, по сравнению с вертексным. А потом включил сетку:

Вот мне и интересно было как поведет себя лайтмаппер на такой малой сетке, потому что знаю что классический компилятор бы от неё сошел с ума (если бы хватило ещё лимитов).

Отправлено Дядя Миша 02-09-2022 в 12:38:

Цитата:

FiEctro писал:
Хоть в первой итерации куда то отвалились тени

Никуда они не отвалились. Там просто разрешение лайтмапы 1 люксель на 8 юнитов. Тень есть, но она более размытая.

Цитата:

FiEctro писал:
А причем тут Раид, есть у тебя компилятор сам строит развертку?

Да притом, что у меня нет исходника этой модели. Raid где-то надыбал сорсовскую, году в 2017-м, разобрал на запчасти, порезал на куски и так скомпилировал для голдсорса (моего компилятора моделей тогда еще не было). И вот эту модельку я сконвертировал в формат, понятный XashNT.
А теперь попытался осветить. Результат на скринах выше.

Цитата:

FiEctro писал:
И как пишется информация для повертексного освещения?

Да прямо в лайтмапу и пишется, я бы конечно мог хранить повертексное внутри вертекса, благо Uniform Mesh позволяет иметь внутри модели\уровня сколько угодно форматов вертекса, но во первых это не слишком удобно, а во вторых - не получится осветить instance-модели ни повертексно, ни полайтмапно. Т.к. у нас получится один уникальный массив с этой моделькой и куча отдельных массивов с освещением. Ни OpenGL ни D3D ни, скорее всего Vulkan, не позволяют состыковать два произвольных массива вместе и потом подать их на отрисовку. Поэтому храню в лайтмапе.

Цитата:

FiEctro писал:
Он создаёт отдельный слот для цветов вертексов конкретной модели?

Никаких слотов никто не создаёт. Освещение считается юниформе, нет разницы между лайтмапой и повертексным. Точнее разница есть только на этапе сбора информации вторичного освещения. Потому что одно дело собирать люксели лайтмапы с плоскости и совсем другое - давать цвета вертексам по "краям" полигона. Интерполятор отличается, собственно разница только в этом. Поэтому в ксаше очень тяжко определить каким именно образом освещена модель - повертексно или лайтмапой, даже со включенным r_lightmap 1. Единственное отличие заключается в gl_lightmap_nearest 1. Повертексное так и останется сглаженным, а вот лайтмапа превратится в квадратики.

Цитата:

FiEctro писал:
потому что знаю что классический компилятор бы от неё сошел с ума

Что такое классический компилятор?

О каких лимитах ты толкуешь? Для рассчёта этой карты коробки лайтмапперу понадобилось примерно 18 мегабайт оперативной памяти, если верить показаниям диспетчера задач.

Добавлено 02-09-2022 в 15:38:

И да, я кажется понял о чём ты толкуешь. Исторически большинство движков, ну может кроме Unity выросли из брашевых, либо соревнуясь с Кармаком, либо прямо из его исходников, поэтому всякие там кривые Безье или модели не имеют тех же самых возможностей, которые доступны брашам.
Такая ситуация в сорсе и насколько я знаю в UE4 тоже с этим не всё гладко, я там видел структуры брашевого уровня из 98-го года. И всё это тоже как-то уживается с моделями, которые были прикручены заведово позже. Да и в лайтмапере, если верить исходникам, тоже какие-то кейсы - освещение статик моделей, освещение ландшафта, освещение брашей. Хотя хз, я их прошлом году смотрел, поэтому могу напутать. И вероятно если эта ситуация регулярно воспроизводилась в разных движках, то у тебя и сложился такой вот стереотип, что нельзя всё это осветить одинаково. Что везде будут свои заморочки и ограничения. Ну незря же ты задал вопрос про "освещение с пола"?
Так вот, в XashNT повторюсь, абсолютно нет никакой разницы, какую геометрию подавать ему на вход - брашы, кривые безье, ландшафты, дисплейсементы, модели. Вообще никакой. Всё будет освещено еденым образом, будет иметь одинаково надёжную коллизию и все прочие сопутствующие возможности для геометрии. За исключением разве что жидкостей. Жидкость можно сделать только брашем, потому что для нее надо задать объем. Но я не думаю, что это большая проблема. Фейковую жидкость можно сделать и полигоном, но плавать в ней уже не получится.
В остальное разницы нет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-09-2022 в 22:00:

Цитата:

Дядя Миша писал:
Да притом, что у меня нет исходника этой модели. Raid где-то надыбал сорсовскую, году в 2017-м, разобрал на запчасти, порезал на куски и так скомпилировал для голдсорса (моего компилятора моделей тогда еще не было). И вот эту модельку я сконвертировал в формат, понятный XashNT.

https://www.cadnav.com/3d-models/model-37039.html

Попробуй эту

Отправлено Дядя Миша 03-09-2022 в 06:17:

Хм, в той модельке, что у меня - 50 тысяч полигонов, а тут всего пять.
Да и нечем мне открыть формат .max

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 03-09-2022 в 08:16:

Цитата:

Дядя Миша писал:
в той модельке, что у меня - 50 тысяч полигонов

Потому что та моделька - самопальная для Cinematic мода. Специально для дрочеров Аликс забабахали декольте. А эта моделька - оригинальная из хл2 или эпизодов.
50 тысяч полигонов на одного перса это конечно сильно. Я понимаю, когда огромные пропы имеют столько поликов, но ИМХО, персу 10-20 будет норм.

Отправлено Дядя Миша 03-09-2022 в 09:00:

Цитата:

Ku2zoff писал:
Потому что та моделька - самопальная для Cinematic мода

Ну да.

Цитата:

Ku2zoff писал:
Специально для дрочеров Аликс забабахали декольте

Там и сиськи имеются настоящие. Иногда бывали забавные случаи, что-то в рендерере ломалось, и аликс рисовалась без одежды

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-09-2022 в 09:10:

Дядя Миша
Сбрось сорсовскую модельку, я тебе попробую сконвертнуть. Мне лень качать гигабайты синематик мода ради одной модели.

Отправлено Дядя Миша 03-09-2022 в 09:29:

Так нету у меня сорсовской
У меня была уже сразу голдсорсовская-порезанная-скомпилированная.
Это у нас народ сразу даёт готовую модель. И Элбер свою ЧАЭС мне тоже дал в скомпилированном виде, я его когда спросил за исходники, он мне нашёл какие-то частичные ошмётки. Пришлось свой конвертор писать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-09-2022 в 09:31:

Нашел на геймбанане.
https://gamebanana.com/mods/182173

Попробуй эту.
https://drive.google.com/file/d/1ib...iew?usp=sharing

Отправлено Дядя Миша 03-09-2022 в 11:15:

Текстурку бы к модели

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-09-2022 в 12:56:

Дядя Миша
Мда, сорс моделеры конечно как всегда в своём репертуаре срут миллионами текстур и материалов. Удивительно как движок с таким обилием справляется.

Собственно всё вытянул, прилепил и упаковал в ротик положил.
https://drive.google.com/file/d/1Mk...iew?usp=sharing

Куда делись зрачки у модели, я хз. Впрочем они и в сорсе иногда отваливаются, похоже там отдельный шейдер для этого.

Кстати, а ксаш умеет парсить просто цвет материала модели?

Добавлено 03-09-2022 в 15:56:

P.S. Вот ещё кое что нашел по шарпу, может будет тебе интересно.
https://habr.com/ru/company/microsoft/blog/550996/

Отправлено Дядя Миша 03-09-2022 в 13:12:

Цитата:

FiEctro писал:
Собственно всё вытянул, прилепил и упаковал

Благодарю.

Цитата:

FiEctro писал:
похоже там отдельный шейдер для этого.

Ну естественно. Сорс всех этим и удивил еще в 2003-м. Когда шейдеров толком ни у кого не было, а тут уже глаза через них рисовались.

Цитата:

FiEctro писал:
Кстати, а ксаш умеет парсить просто цвет материала модели?

Нету такого. Но есть разные способы покрасить модель, если это вдруг понадобится.

Цитата:

FiEctro писал:
P.S. Вот ещё кое что нашел по шарпу, может будет тебе интересно.

Спасибо, почитаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 03-09-2022 в 16:08:

Цитата:

FiEctro писал:
Удивительно как движок с таким обилием справляется.

Движок-то справляется, а вот пеки обкакиваются. Думаешь почему у первого сорса почти из неоткуда возникли системные требования на уровне CryEngine 1?

Добавлено 03-09-2022 в 23:08:

Цитата:

Дядя Миша писал:
Сорс всех этим и удивил еще в 2003-м.

Были какие-то билды хл2 с мутными глазаме, видел на скринах. Но мне больше запомнились первые ператки хл2, где в русской озвучке персы не шевелили губами от слова совсем. А ещё этот вездесущий AI disabled.

Отправлено Дядя Миша 03-09-2022 в 20:01:

Чёт эта моделька запеклась гораздо хужее превидущей. Ну и плюс в лайтмаппере есть недоработка на фазе сбора рассчитанного отражённого света. Там в крации в чём суть. Индирект традиционно считается в более низком разрешении, нежели прямой свет. Ну как и в халфе, собственно.
На поверхности генерируются патчи с шагом, ну там обычно 64\128, тогда как у люкселя размер 16\8 и меньше. После рассчёта индиректа отражённый свет применяется ко всему патчу. Который, как вы понимаете - заведомо больше чем люксель. Прикол в том, что нельзя эту низкочастотную сетку тупо (единственный случай, когда этот слово уместно), скопировать на сетку лайтмапы. Потому что низкочастотный индирект проявится на лайтмапе.
Поэтому используется фаза сбора с интерполяцией. В том же VHLT она может занимать даже больше времени, нежели сам рассчёт непрямого освещения.
Но это по сути не главное. Главное то, что структуры для интерполяции между соседними полигонами могут занимать дьявольски много памяти.
Те кто пользуются VHLT, могут открыть диспетчер задач на фазе FacePatchLights и охренеть. А у меня - большие карты из того же сталкера.
То есть не вариант. Поэтому у меня идёт сбор соседних сэмплов через поиск в заданном радиусе и окклюзии через трассу. Вот, собственно в радиусе этого поиска и есть вышеозвученная недоработка. Она равна фиксированному значению, заданному пользователю - аналог параметра -chop. А моделька напоминаю состоит из микрополигончиков. Ну вообщем можете догадаться, что на один люксель для интерполяции собирается несколько тысяч сэмплов. И фаза FacePatchLights может реально длиться около часа, хотя конечно в этом нет никакой необходимости.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-09-2022 в 08:06:

Впрочем пару скринов всё же покажу

Мне не нравится. С другой стороны - освещать персов лайтмапой довольно дурацкая затея.

Добавлено 04-09-2022 в 10:59:

А повертексное показывать не буду. Там страх и ненависть в Лас-Всегасе получилось. Интересно почему так? Может у меня парсер obj кривой?

Добавлено 04-09-2022 в 11:06:

У этого obj полный разброд и шатания. Может не так сильно, как в ase, но тоже ничего хорошего. Пример того, что корректно читает мой парсер:

C++ Source Code:

1	g models/doors/door4

2	usemtl Material01

s 1

4	f 3/1/1 2/2/1 1/3/1

5	f 2/2/1 4/4/1 1/3/1

6	f 1/3/1 4/4/1 5/5/1

7	f 1/3/1 5/5/1 6/6/1

8	f 6/6/1 5/5/1 7/7/1

9	f 5/5/1 8/8/1 7/7/1

Здесь он интерпретирует команду g как выделение нового меша, причём имя меша автоматически становится именем текстуры. Это не вполне корректно, но в Overdose, откуда, я собственно и брал первоначальную реализацию obj-парсера, абсолютно все модели так прописаны. Причём usemtl в них вообще игнорируется, оно и понятно, те параметры, которые прописаны в mtl файле просто не нужны. Да и зачастую там дефолт какой-то прописан.
Достаточно только имени материала. В smd с этим нет никаких проблем, поэтому я использую его по возможности.

Теперь - как выглядит моделька Alyx

C++ Source Code:

1	usemtl Trenchcoat

s 1

3	f 1/1/1 2/2/2 3/3/3

4	f 4/4/4 3/3/3 2/2/2

5	f 4/4/4 5/5/5 3/3/3

6	f 6/6/6 7/7/7 8/8/8

Ну выпонели. Меш не выделен вообще, зато назначена текстура.
То есть obj каждый парсит как хочет. Есть где-то эталонный obj-парсер?
Но опять же, это совсем не означает, что конкретный контент будет им правильно читаться, т.к. сам контент сделан уже с нарушениями стандарта. Вот поэтому я и люблю smd, там подобные ситуации в принципе невозможны. Никаких разночтений и отсебятины.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 04-09-2022 в 09:38:

Цитата:

Дядя Миша писал:
То есть obj каждый парсит как хочет. Есть где-то эталонный obj-парсер?

Так и есть. Обж - обжу рознь. Я где то даже видел обж с поддержкой скелетной анимации. А есть ещё обж с поддержкой групп.

Мне вот тут посоветовали либу с кучей форматов - https://assimp-docs.readthedocs.io/...troduction.html можно например на её базе сделать универсальный конвертер моделей разных форматов в формат ксаша, не знаю. Хотя по мне обычного .fbx на всё хватит.

Цитата:

Дядя Миша писал:
Впрочем пару скринов всё же покажу

Черных швов уже меньше, это хорошо. Но сама лайтмапа выглядит странно. Но почему целиком они не ушли, модель то теперь нормальная? Кстати, что с расходом клипнодов? Надеюсь ты убрал этот дурацкий лимит? Я помню в халфе частенько приходилось оборачивать часть геометрии клипами, чтобы оно компилилось. А в некоторых случаях помогал только skip.

Цитата:

Дядя Миша писал:
Мне не нравится. С другой стороны - освещать персов лайтмапой довольно дурацкая затея.

Зато это отличный стресс тест для компилятора. Тут тебе и куча полигонов, и сложная геометрия. И сами полигоны маленькие. И самое главное, у неё не такая кривая UV как у спонзы. Почему я и попросил опробовать эту модельку.

Отправлено Дядя Миша 04-09-2022 в 09:52:

Цитата:

FiEctro писал:
Хотя по мне обычного .fbx на всё хватит.

fbx дерьмо переусложнённое, я не хочу с ним связываться.

Цитата:

FiEctro писал:
Черных швов уже меньше, это хорошо

Я вспомнил откуда швы. Генератор патчей для вторички отбрасывает патчи, размер которых меньше эпсилона 0.1. А в этой модели из-за кучи мелких треугольников очень много таких вот патчей. В сущности сама их природа плохо ложится на такую вот топологию. Я потом напишу новую версию компилятора, который вместо этих проблемных патчей будет для индиректа использовать люксели, из-за этого скорость рассчёта вторички резко упадёт, но можно написать рейтрейсер на CUDA, он обеспечит прирост скорости примерно в 10 раз, а значит то на то и выйдет. В результате получим эталонное вторичное освещение, и что немаловажно - уйдет ограничение по памяти на тренсферы, т.к. их больше не придётся хранить.
Ну это тоже всё потом, т.к. не горит.

Цитата:

FiEctro писал:
Зато это отличный стресс тест для компилятора

Абсолютно нет. Это как кирпич засунуть в стиралку.

Добавлено 04-09-2022 в 12:51:

Ну и да. Мне не нужна никакая "универсальная либа", потому что любая универсальная либа всё равно не будет содержать абсолютно все возможные форматы. На данный момент я конечно сам сделал подобие такой либы и встроил её в компилятор, но это больше для тестирования.
В дальнейшем будет система плагинов в редакторе, для импорта и иэкспорта из разных игр. Народ сам сможет выбирать какие именно форматы ему нужны. Там же вы сможете самостоятельно написать плагин для вашего любимого fbx.

Добавлено 04-09-2022 в 12:52:

А у самого XashNT есть нативные промежуточные форматы, очень простые и интуитивно понятные, которые, я надеюсь в дальнейшем вытеснят вообще все остальные.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 04-09-2022 в 10:19:

Цитата:

Дядя Миша писал:
fbx дерьмо переусложнённое, я не хочу с ним связываться.

Это стандарт которым пользуются все трёхмерщики, в отличие от obj в котором неизвестно что может храниться, темболее ничего кроме геометрии он не держит. Как ты собрался с анимированными моделями работать? Надеяться что кто то когда нибудь напишет СМД плагин для новых версий редакторов?

Цитата:

Дядя Миша писал:
Там же вы сможете самостоятельно написать плагин для вашего любимого fbx.

Движки в стиле "допиши весь пайплайн сам" думаю ты и сам не раз видел. И знаешь что они никому не нужны. Тут либо использовать общепринятые форматы, либо писать плагины для 3д редакторов самому, да ещё поддерживать их, оно надо? Ну или сидеть и надеяться на васяна который сам напишет плагины под нужные форматы.

Цитата:

Дядя Миша писал:
Там же вы сможете самостоятельно написать плагин для вашего любимого fbx.

Всё это излишняя трата времени и сил. Для того чтобы вставить модель из другой игры тебе нужен всего один формат с которым работают все остальные экспортёры из игр. А либу я скинул как референс.

Отправлено Дядя Миша 04-09-2022 в 10:47:

Цитата:

FiEctro писал:
Это стандарт которым пользуются все трёхмерщики

Ты видел SDK от FBX? Это дьявольски переусложнённая вещь. Скорее всего по своим способам хранения информации он заткнёт текстовые форматы далеко за пояс. Плюс он официально закрытый, проприетарный.

Цитата:

FiEctro писал:
Движки в стиле "допиши весь пайплайн сам" думаю ты и сам не раз видел

Не весь пайплайн, а только этот грёбаный FBX. Впрочем коллады всякие - в ту же топку. Это типичный такой подход - внедрим в формат сразу вообще всё, что только может понадобится и будем от этого использовать 0.0001%.

Цитата:

FiEctro писал:
Для того чтобы вставить модель из другой игры тебе нужен всего один формат с которым работают все остальные экспортёры из игр

Все эти т.н. экспортёры написаны очень криво, они толком ничего не экспортируют.

Цитата:

FiEctro писал:
Как ты собрался с анимированными моделями работать?

Я же говорю, в XashNT будут свои открытые форматы. Которые я разрабатываю не просто для того чтобы был еще один формат. Я надеюсь в дальнейшем сделать их широкопопулярными. Поскольку тут поле непаханное. Фактически продвижением промежуточных форматов для хранения трёхмерки никто и никогда не занимался. Ну вот я и займусь.

Добавлено 04-09-2022 в 13:41:

Сгенерировал все патчи для этой модельки. Это повертексное.

Добавлено 04-09-2022 в 13:47:

И еще вот какую вещь учтите. Абсолютно все промежуточные форматы были сделаны людьми под сиюминутные нужды, после чего внезапно на безрыбье обрели популярность. Форматы, которые специально делались как их универсальная замена, во первых не были ни к чему привязаны, во вторых были дьявольски переусложнены на ровном месте, типа того же glTF, либо обрастали слоями совместимости, как Filmbox. Ничего хорошего в этом нет.
Я рассматривал большинство этих хвалёных форматов и ни один меня не устроил по своему функционалу. Потому что в их основе либо гниалая концепция, либо вообще отсутствие таковой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 04-09-2022 в 10:56:

Цитата:

Дядя Миша писал:
Я надеюсь в дальнейшем сделать их широкопопулярными.

Каким образом? Будешь писать и поддерживать плагины для всех известных 3д пакетов?

Цитата:

Дядя Миша писал:
Я рассматривал большинство этих хвалёных форматов и ни один меня не устроил по своему функционалу. Потому что в их основе либо гниалая концепция, либо вообще отсутствие таковой.

Ну как бы у тебя движок и так свой формат использует, и это правильно. Я говорю, что мы из 3д пакета импортировать будем?

Цитата:

Дядя Миша писал:
Сгенерировал все патчи для этой модельки. Это повертексное.

Черные пятнышки

Но выглядит красивее лайтмапы. В отличие от предыдущей модели почему такое различие? Там и повертексная и лайтмаповая модель давали почти одинаковый результат.

Отправлено Дядя Миша 04-09-2022 в 12:15:

Цитата:

FiEctro писал:
Будешь писать и поддерживать плагины для всех известных 3д пакетов?

Ну плагины ведь можно дописывать постепенно и просто кидать их в папку с редактором. Да и народ, я думаю подключится к этому делу.

Цитата:

FiEctro писал:
Черные пятнышки

Где-то патчи недосгенерировались.

Цитата:

FiEctro писал:
В отличие от предыдущей модели почему такое различие?

Я немного залез в компилятор и разрешил там генерацию сверхмелкий патчей, специально чтобы собрать эту модель. Прошла собиралась на стоковых настройках. Всё это можно вынести в пользовательские будет, но у меня повторюсь, немного другая идея, выше написал.

Добавлено 04-09-2022 в 14:27:

Цитата:

FiEctro писал:
В отличие от предыдущей модели почему такое различие?

Предидущий скриншо, надо учитывать на неотредактированном obj.
Я там позаменял везде usemtl на g, чтобы привести в соответствие с правилами моего парсера.

Добавлено 04-09-2022 в 15:08:

Да, это полностью косяки вторички. Вот для сравнения - только прямой свет, повертексное освещение. Время работы лайтмаппера - 4 секунды.

Добавлено 04-09-2022 в 15:14:

А лайтмапа так и выглядит странно

Ну хрен с ней.

Добавлено 04-09-2022 в 15:15:

Если вы не поняли - в данной модели разрешение повертексного превосходит разрешении лайтмапы, раза эдак в 2-3, может больше.
Отсюда и такой результат.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-09-2022 в 22:57:

Попробовал бейкер Психопата, вот что получилось. Лайтмапа 4к, время запекания 25265ms.
Странная тень на ботинках - мой косяк, забыл убрать перекрытие островков.

Отправлено Дядя Миша 06-09-2022 в 06:32:

Цитата:

FiEctro писал:
Лайтмапа 4к

У меня она намного меньше.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 06-09-2022 в 20:24:

Цитата:

FiEctro писал:
Попробовал бейкер Психопата, вот что получилось. Лайтмапа 4к, время запекания 25265ms.
Странная тень на ботинках - мой косяк, забыл убрать перекрытие островков.

Выглядит конечно очень внушительно, реально как какая-то фарфоровая фигурка.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 07-09-2022 в 07:50:

На 4K лайтмапе - нет ничего удивительного. У меня на тех скринах, она где-то 256х256.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-09-2022 в 08:46:

У Психопата сама модель освещения более красивая, халфовская как то искуственно ненатурально и всё серым/грязным выглядит.

Отправлено Дядя Миша 07-09-2022 в 09:23:

Чем выше разрешение лайтмапы - тем лучше всё это выглядит, естественно.
Но я напоминаю, задача не в том, чтобы просто красиво осветить одну модельку на карте-коробке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-09-2022 в 10:53:

Цитата:

Дядя Миша писал:
На 4K лайтмапе - нет ничего удивительного. У меня на тех скринах, она где-то 256х256.

Попробовал 256х256, общая картина особо не поменялась. Это ещё учитывая что лайтмапа комнатки занимает где то 1/5 от всего листа. Время запекания 735ms.

http://alxgk.ru/uploader/img/25f132eb01369b82ed39af6f0bf76a1e.jpg

Даже ради интереса сделал лайтмапу 64х64. Тени все окончательно размылись, но общие детали сохраняются.

http://alxgk.ru/uploader/img/acd883a5ae2a150558396d3a03d1e327.jpg

Отправлено Дядя Миша 07-09-2022 в 12:26:

Значит там разрешение иначе считается. С переменной плотностью люкселей.

Добавлено 07-09-2022 в 14:38:

Ты люксели можешь визуализировать на этой лайтмапе?

Добавлено 07-09-2022 в 15:19:

Чтобы было понятнее об чём речь

Это соотношение люксель к юниту 1\1. Можно видеть что нос целиком поместился на одном люкселе, поэтому и выглядит так странно.

Добавлено 07-09-2022 в 15:26:

А вот соотношение люксель к юниту 1/0.1

11 страниц 1024х1024

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-09-2022 в 13:55:

Цитата:

Дядя Миша писал:
Значит там разрешение иначе считается. С переменной плотностью люкселей.

Да так оно и есть, но оно не строит развертку, а берет с модели.

Цитата:

Дядя Миша писал:
Чтобы было понятнее об чём речь

Кстати довольно неплохо развернуло. Можно на саму UV посмотреть?

Отправлено Дядя Миша 07-09-2022 в 14:31:

Цитата:

FiEctro писал:
Кстати довольно неплохо развернуло

Я тоже развертку беру с модели. Но не всегда, там анализатор, который принимает решение, использовать развертку с модели или построить свою собственную. Причём решение принимается для каждой конкретной группы в модели.

Добавлено 07-09-2022 в 17:05:

И еще важный момент. Взятие развертки с модели еще не означает что масштаб наглухо прибит гвоздями к заданному в самой модели.
я например его могу регулировать как угодно. Потому что лайтмапы на всё не напасёшься.

Добавлено 07-09-2022 в 17:31:

Впрочем я догадался, как там устроено. Сетка строится из соотношения тексель к люкселю 1\1, как в первом квейке, а потом все островки рескейлятся чтобы уместиться в страницу атласа заданного размера.
Я не очень понимаю, почему эти страницы произвольного размера и не принадлежат какой-то глобальной системе освещения. Может это исходные страницы так выглядят, а потом движок их переупаковывает?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 09-09-2022 в 10:51:

Любопытно, а в XashNT код так же как в Xash3D намертво привязан к 32 битам? Или там всё же заранее предусматривается какая-то портабельность на 64-битные платформы?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 09-09-2022 в 11:02:

Нет он изначально спроектирован таким образом, чтобы без проблем можно было перебраться на 64-бита. Единственное, что я пока нерешил - надо ли будет иметь две версии виртуального образа для виртуальной машины, 32-х битный и 64-х битный, или ограничиться только 32-х битным.

Проблема не только и не столько в 64-х битах, сколько в видеопамяти, например. Если текстур и геометрии много, а на видеокарте всего гигабайт памяти - ничего не поможет. OpenGL просто выдаст ошибку Out Of Memory и всё.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 09-09-2022 в 11:08:

Цитата:

Дядя Миша писал:
Проблема не только и не столько в 64-х битах, сколько в видеопамяти, например. Если текстур и геометрии много, а на видеокарте всего гигабайт памяти - ничего не поможет. OpenGL просто выдаст ошибку Out Of Memory и всё.

А разве они не начинают использовать ОЗУ? Я где то такое слышал, что при окончании видеопамяти, драйвер пытается её на ОЗУ эмулировать. Или это бред?

Отправлено Дядя Миша 09-09-2022 в 12:34:

Видеопамять дублируется в ОЗУ, естественно. То-то ж Сталкер так лагал, когда его текстуры в тогдашних видеокартах не помещались полностью.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 09-09-2022 в 17:20:

К слову, на Android в скором времени урежут поддержку 32-разрядных приложений. В этот раз на аппаратном уровне.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Ku2zoff 10-09-2022 в 02:40:

SNMetamorph ой, какая бида. Уже несколько лет приложухи доступны пакетами в нескольких вариантах. Есть 32 и 64 битные апк под разные версии arm. Что хомякам втюхают для ношения в карманах, то и будет целевой платформой. Одно мы знаем точно: десктопы конкретно нацелены на отказ от 32-битной архитектуры. Мелкомягкие даже крайнюю винду выпустили x64 only. И Apple таки грохнули 32-битную iOS пару лет назад.
Только на десктопе не всё так просто, как с мобилкаме. Мобильный софт сам по себе мерзкое говно, как и мобилки сами по себе мерзкое говно. Эта ниша очень и очень нестабильна. Сегодня в тренде одна повест(очка), завтра другая, послезавтра третья. На десктопе всё более-менее стабильно, если юзер не алень и не гонится за обновлениями ради обновлений. Винда уже лет 10 на подавляющем большинстве компов 64-битная, однако мелкомягкие не убирают из неё заветную папочку SysWOW64.
На десктопах эмуляция не то что других архитектур, даже других ОСей - это будущее в ближайшие лет 10-20. Хотя бы просто потому, что людям очень лениво перевыпускать уже законченный софт, особенно игры.

Отправлено (_-=ZhekA=-_) 10-09-2022 в 07:14:

Эпики уже примерно года два, как отказались от 32 битной версии анрила и ничего все живы

Отправлено Дядя Миша 10-09-2022 в 10:36:

Отказ от 32-х битной версии программы автоматически означает "теперь память можно не экономить вообще и набирать на работу кого угодно".

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 10-09-2022 в 10:37:

Цитата:

Дядя Миша писал:
Отказ от 32-х битной версии программы автоматически означает "теперь память можно не экономить вообще и набирать на работу кого угодно".

А что будешь делать, когда майкрософт откажется от поддержки 32 битных приложений? Рано или поздно они выпилят.

Отправлено Ku2zoff 10-09-2022 в 12:14:

Цитата:

Дядя Миша писал:
"теперь память можно не экономить вообще и набирать на работу кого угодно"

Не только оперативную память, но и место на накопителе. Понимаю, когда игрушки весят много - там текстуры занимают львиную долю места. Но вот когда софтина типа браузера весит почти гигабайт, это настораживает.

Отправлено FiEctro 10-09-2022 в 12:23:

Цитата:

Ku2zoff писал:
Не только оперативную память, но и место на накопителе. Понимаю, когда игрушки весят много - там текстуры занимают львиную долю места. Но вот когда софтина типа браузера весит почти гигабайт, это настораживает.

Мне кажется глупо сравнивать вес и производительность софта который имеет куда больше фишек, с более простым по функционалу софтом.

Отправлено Ku2zoff 10-09-2022 в 12:46:

Цитата:

FiEctro писал:
который имеет куда больше фишек, с более простым по функционалу софтом.

Это в браузере, например, много фишек? Говнохром не юзабелен без расширений от слова вообще. Огнелис скурвился, Опёра скурвилась. Нет ни одного современного браузера, который бы имел искаропки функционал старой оперы на Presto. Разве что кетайский Макстон. Но он чево-то тово, с каким-то облачным говном связан. Поди дропнут к седьмой версии.
Я до сих пор пользуюсь 2007-м офисом и всё круто. А товарищ пользуется офисом 365. Говорит, заколебали обновы. Я б даже 2003 студией до сих пор пользовался, если бы не IntelliSense/IntelliCode. И 12-ой оперой, если бы была совместимость с современными сайтами.

Отправлено Дядя Миша 10-09-2022 в 14:03:

Цитата:

FiEctro писал:
А что будешь делать, когда майкрософт откажется от поддержки 32 битных приложений?

Ну во первых я так далеко не заглядываю, а во вторых, будущее самого микрософта весьма туманно, поскольку все уже конкретно устали от его закидонов. Не в том смысле, что появилась какая-то новая ось, которая устраивает абсолютно всех, а в том, что большинство будет цепляться за ту же семёрку до последнего предела. Кому нужна 11-я винда? Что она даёт?
Единственный способ её впарить - насильно установить на ноутбук и продать комплектом.

Цитата:

Ku2zoff писал:
Не только оперативную память, но и место на накопителе

Место на накопителе как бы давно не ограничено, независимо от разрядности самой винды.

Цитата:

FiEctro писал:
не кажется глупо сравнивать вес и производительность софта который имеет куда больше фишек, с более простым по функционалу софтом.

У тебя есть чёткое представление сколько должна весить та или иная фишка и почему? Ну вот к примеру FBX SDK весит 100 мегабайт. Больше чем 95-я винда. Ты хочешь меня убедить, что он и умеет больше чем эта самая винда?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 10-09-2022 в 14:30:

Немного о весе прог... Я тут недавно из исходников гита собрал уе 5.1 и все в конечном результате получилось около 200гб ... И собирался двиг часов 5 если не больше на коре 9. Если всю хрень почистить он будет весить 20-25гб, но все же

Отправлено FiEctro 10-09-2022 в 16:44:

Цитата:

Дядя Миша писал:
У тебя есть чёткое представление сколько должна весить та или иная фишка и почему? Ну вот к примеру FBX SDK весит 100 мегабайт. Больше чем 95-я винда. Ты хочешь меня убедить, что он и умеет больше чем эта самая винда?

Ну вот ты сам и ответил на свой вопрос. Весят они столько потому что много поддеживают всяких форматов, а если ничего не будет поддерживаться, то и весить нечему

Ты наверное забыл что для того чтобы виндой 95 можно было повседневно пользоваться, её нужно было обмазывать дровами, фреймворками и кодеками, а чем нужно обмазывать 10ку ))) ? Сразу ставишь и пользуешься.

Цитата:

Дядя Миша писал:
Кому нужна 11-я винда? Что она даёт?

Если находятся люди которым нужна XP, то найдутся и те кому и 11 будет по душе. А вот на 95ю, которая весит 100мб ты что то тоже пересаживаться не желаешь.

Цитата:

Ku2zoff писал:
Говнохром не юзабелен без расширений от слова вообще.

Каких расширений? Например? Из расширений я юзаю разве что впн и адблок.

Отправлено Дядя Миша 10-09-2022 в 18:51:

Цитата:

FiEctro писал:
Весят они столько потому что много поддеживают всяких форматов

FBX SDK внезапно поддерживает... только FBX. Какие еще много всяких форматов?

Цитата:

FiEctro писал:
а чем нужно обмазывать 10ку ))) ? Сразу ставишь и пользуешься.

Ошибаешься. С десяткой обратная проблема. Из нее надо удалить примерно 10-15 гигабайт говна, отключить кучу служб и прочей ненужной фигни, чтобы ей можно было начать пользоваться. И всё равно она люто логает.

Цитата:

FiEctro писал:
А вот на 95ю, которая весит 100мб ты что то тоже пересаживаться не желаешь.

Вообще-то ты не установишь 95-ю на современный компьютер, кроме как на виртуальную машину. Внезапно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 10-09-2022 в 19:00:

Цитата:

Дядя Миша писал:
FBX SDK внезапно поддерживает... только FBX. Какие еще много всяких форматов?

FBX разных версий бывает. Там наверное тоже совместимость какая то. Сам сдк не щупал, не знаю.

Отправлено Дядя Миша 10-09-2022 в 19:32:

Цитата:

FiEctro писал:
Сам сдк не щупал, не знаю.

Ну то есть выдумал невесть что на ровном месте. Понятно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 10-09-2022 в 20:59:

Цитата:

Ku2zoff писал:
Это в браузере, например, много фишек? Говнохром не юзабелен без расширений от слова вообще. Огнелис скурвился, Опёра скурвилась. Нет ни одного современного браузера, который бы имел искаропки функционал старой оперы на Presto. Разве что кетайский Макстон. Но он чево-то тово, с каким-то облачным говном связан. Поди дропнут к седьмой версии.
Я до сих пор пользуюсь 2007-м офисом и всё круто. А товарищ пользуется офисом 365. Говорит, заколебали обновы. Я б даже 2003 студией до сих пор пользовался, если бы не IntelliSense/IntelliCode. И 12-ой оперой, если бы была совместимость с современными сайтами.

В этих браузерах СТОЛЬКО всяких библиотек и реализаций различных стандартов, и всё это разной степени говнокодности. И с годами этого всего становится только всё больше и больше. А старое приходится оставлять ради обратной совместимости. Вот оно и копится.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено FiEctro 10-09-2022 в 21:19:

Цитата:

Дядя Миша писал:
Ну то есть выдумал невесть что на ровном месте. Понятно.

А ты щупал?

Отправлено Дядя Миша 11-09-2022 в 07:01:

FiEctro ну естественно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 11-09-2022 в 07:50:

Цитата:

FiEctro писал:
Каких расширений? Например?

Например, расширение, которое запрещает окну браузера закрываться при закрытии последней вкладки. Идиотское поведение с этим закрытием. Не надо только сейчас заступаться за идиотов из гугла, и советовать не закрывать последнюю вкладку, пока не откроешь новую. Word, Excel, Photosop и море другого софта же не закрываются, когда закрываешь вкладку с последним открытым документом. Другие мелочи, типа параллельного просмотра, нормально настраиваемой панели быстрого доступа, кастомизации интерфейса в целом. Зато автоматический переводчик постоянно занудствует, пока его не отключишь. Ну это понятно, гуглу надо знать не только адреса, но и содержимое страниц, которые посещает юзер.

Отправлено Дядя Миша 17-09-2022 в 19:52:

Пусть тут пока полежит.
https://www.siliconstudio.co.jp/mid...that-scales.pdf

Добавлено 17-09-2022 в 22:52:

Кстати хороший пейпер. Enlighten передали японцам, которые в отличие от чопорных англичан, наконец-то честно рассказали, как он всё-таки работает. Именно так, как я полагал и именно так, как я сам и планировал сделать. Вкратце - берём типичный алгоритм рассчёта непрямого освещения Instant Radiocity (Quake2, Half-Life), делаем очень редкую сетку, считаем трансферы, потом очень сильно их ужимаем и сохраняем на диск.
Собственно это и есть самый сложный момент. Ну и генерация патчей втч.
А когда у нас есть матрица светопереноса, любое решение сходится за доли секунды. Причём обновлять можно только видимую часть мира. Это абсолютно надёжно, быстро, не запаздывает во времени и не имеет артефактов. Ну предрассчёты, да. Фактически отражённый свет работает только для статичной геометрии. Впрочем для лайтпроб можно точно так же посчитать светоперенос.
Главный плюс такого подхода - его можно применять в продакшене.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 18-09-2022 в 08:26:

Дядя Миша
Ну так мы с тобой тогда ещё 8 лет назад разбирались как это работает. Вроде как и тогда к похожим выводам пришли. Просто да, в первых пдфках не очень доходчиво было описано.

Вот кстати тоже тебе в копилочку:
https://github.com/sonicether/SEGI
https://forum.unity.com/threads/bak...eleased.536008/
https://unityassetcollection.com/ba...-free-download/

Добавлено 18-09-2022 в 11:26:

Цитата:

Дядя Миша писал:
Фактически отражённый свет работает только для статичной геометрии.

Ну не совсем, если это например вагончик, то относительно мира она динамичный. А вот относительно игрока внутри он статичный.

Отправлено Дядя Миша 18-09-2022 в 09:04:

Цитата:

FiEctro писал:
Ну так мы с тобой тогда ещё 8 лет назад разбирались как это работает

Англичане старательно замалчивали всю инфу. А японцы взяли и вывалили.
Техника использования предрассчитаных трансферов может по разному называться, главное что без предрассчётов в принципе не обойтись.
Но я и не планировал.

Добавлено 18-09-2022 в 11:57:

Цитата:

FiEctro писал:
Вот кстати тоже тебе в копилочку:

Да не надо мне воксели показывать, они память дико жрут.

Добавлено 18-09-2022 в 12:04:

Да, чтобы у вас не сложилось превратного представления, будто бы я там что-то навязываю. Движок, равно как и тулзы гибко конфигурируются под рассчёт любого типа освещения, можно к примеру запускать компилятор уровней с параметром -nolightmaps, это сгенерит более эффективную для отрисовки геометрию, а свет считать в шейдерах полностью.
Можно использовать только лайтмапы, а можно будет смешанные режимы, т.е. полностью на усмотрение пользователя.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 18-09-2022 в 20:09:

Дочитал тот документ по Enlighten. Ну что сказать? Опять куча лайтпроб, нерегулярная сетка, масса проблем и их героическое преодоление.
Всё то, с чем я столкнулся еще в P2, только в гораздо больших масштабах.
Надо подумать, возможно имеет смысл генерировать эти лайтпробы прямо на лету, но опираясь на информацию от трансферов и VPLS.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 18-09-2022 в 20:36:

Цитата:

Дядя Миша писал:
возможно имеет смысл генерировать эти лайтпробы прямо на лету

Их кстати можно оптимизировать увеличивая плотность там где резкий переход света и уменьшать там где таких переходов нет.

https://docs.unity3d.com/550/Docume...ightProbes.html
https://docs.unity3d.com/ru/2019.4/...ingObjects.html

Отправлено Дядя Миша 19-09-2022 в 10:06:

Это при условии, что источник света неподвижен, а больше всего лайтпроб на открытом пространстве, где мы хотим сделать смену дня и ночи.
То есть всё это имеет ограниченное применение.
У меня тут есть любопытная мысль, на стыке LPV и Enlighten замутить технологию, может быть что-то и получится из этого. Из LPV взять генерацию лайтпроб налету в регулярных сетках, а из Enlighten - те самые предрассчитанные данные. Ну в смысле идеи взять, а не код, конечно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-09-2022 в 11:45:

Цитата:

Дядя Миша писал:
Из LPV взять генерацию лайтпроб налету в регулярных сетках

Так, а откуда ты данные возмешь? Ладно если лайтпроба рядом со стеной, а если она на улице высоко в воздухе, с каких трансферов она будет брать информацию о своём освещении?

Отправлено Дядя Миша 19-09-2022 в 13:47:

Ничего пока не скажу, это так, задумки на будущее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 19-10-2022 в 07:22:

Сегодняший день, 19.10.2022 можно официально считать датой рождения нового языка программирования.
Это не день, когда я внезапно принял решение о создании такого языка. Это не день, когда я набросал первый прототип и провёл первый юнит-тест, в стиле Hello World. Это день, когда мне удалось портировать на новый язык исходный код меню из XashNT, написанный на С++ и провести серию тестов по стабильности, производительности, да и вообще соответствию языка ожидаемому поведению. Теперь, когда, всё это сделано, уже можно с ответственностью заявить - язык создан, опробован в деле и будет как минимум использоваться внутри среды разработки игр XashNT. Подобно тому, как для первого квейка использовался QuakeC или для Unity используется C#. Однако заложенные в нём возможности позволяют использовать язык и для любых других задач, в отличие от того же QuakeC, он не прибит гвоздями намертво к игровому движку и там нет никаких явных привязок.

Язык имеет собственное имя: HeadShot или просто Shot. В этом можно усмотреть аллюзии на С++ который позволяет стрелять себе в ногу. А мой язык позволит выстрелить сразу в голову и не мучаться. Или же намёк на то, что с его помощью можно писать игровой код для шутеров, в которых хедшоты - важная часть игрового процесса. В принципе оба утверждения в какой-то степени справедливы. Но в какой именно, я конечно не скажу, т.к. любой продукт должен обрастать собственными легендами с момента появления. Расскажу поподробнее как я пришёл к выводу, что мне нужен собственный язык, что в нём планировалось сделать и что уже сделано, а что еще только предстоит.

Идею создания собственного языка я вынашивал примерно с 2006-го года, но тогда, у меня разумеется, не было для этого никакого опыта. Поэтому я планировал использовать расширенный QuakeC из движка FTE. Этот движок, к слову, развивается до сих пор, причём по большей части упор делается именно на расширение возможностей QuakeC. К сожалению изначальные рамки, заданные для этого языка Кармаком, сделали невозможным добавление в него многих возможностей и особенностей С++, которые на мой взгляд оказались бы весьма полезными. Я так же рассматривал другие языки, которые бы меня полностью устроили, однако ничего подобного так и не удалось найти. Минимальное соответствие моим требованиям было только у AngelScript, но и там были вещи, которые меня не устроили. К тому же, с момента, когда было принято решение о портировании VCL, он отпал автоматически. Возможно кто-то не в курсе, но портировать Delphi на C++ в ряде случаев - нерешаемая задача. Заодно, у тех, кто внимательно следит за моими "невероятными приключениями", наверняка встал вопрос - отчего же я не взял уже портированую библиотеку VCL, для C++ Builder. Ведь разработчики Delphi выпускали и такой продукт тоже и там VCL тоже была. Так вот если внимательно изучить рантайм, то вы увидите, что там VCL присутствует в своём оригинальном виде, т.е. по прежнему на языке Delphi. Никто и никогда не портировал её на С++, в нём отсутствует ряд возможностей, которые она активно использует. В частности там нет свойств и нет виртуальных конструкторов. А вот на C# она успешно портирована, как раз потому что, этот язык и создавался с учётом возможности портирования подобного кода. То есть в каком-то смысле я повторяю путь Микрософта начала нулевых. Но конечно у меня есть собственные идеи, насчёт всего этого. Исходя из всего вышесказанного было принято единственное верное решение - нужен свой собственный язык. В котором следует реализовать как минимум привычный синтаксис и поведение С++ и заодно те вещи, ради, которых всё это и затевалось. Перечислю их:
1. Возможность легкого отправления объектов по сети. Для чего у члена класса просто ставится необходимый атрибут и больше ничего делать не надо. Всё остальное происходит автоматически. Опционально можно указать сколько бит переменной должно быть передано.
2. Возможность легкой сериализации объектв. Полностью аналогично первому пункту - атрибут у переменной и опционально указать кол-во бит.
3. Возможность портирования кода с Delphi. Здесь нам понадобятся виртуальные конструкторы и свойства с расширенными возможностями.
4. Язык ни в коем случае не должен иметь привязки к игровому движку, как это случилось, например с QuakeC, но одновременно должен позволять максимально плотную интеграцию для увеличения скорости работы и её упрощения.
5. Язык должен иметь синтаксис и поведение полностью аналогичные С++, при этом предоставляя программисту такие возможности, которых в С++ нет и они там не появятся уже никогда. А если и появятся, то это будет сделано через костыли типа STL.
6. По возможности сохранить в языке идеологию, заложенную Страуструпом - вы не платите за то, чем не пользуетесь. Практически все известные мне скриптовые языки эту концепцию игнорируют.
7. Встроенные в язык средства отладки, позволяющие выводить исполняемый код на экран, расставлять точки остановки, ошибки внутри исполняемой среды языка не должны приводить к краху всего приложения - ну вообще стандартные возможности песочницы.
8. Не слишком удручающая скорость выполнения кода, даже без преобразования опкодов в реальные исполняемые коды x86. Т.е. без JIT-конвертации.
9. Возможность манипулирования объектами со стороны рантайма, например для реализации физики объектов, подобно тому как это было сделано в Quake.
Вот такие задачи были мной поставлены и надо сказать, у меня получилось практически всё из намеченного. Так же у языка будет возможность работы на 64-х битных системах, я изначально закладывал это в его архитектуру, но пока в этом просто нет необходимости.

Архитектура системы комманд - RISC. Команды имеют фиксированную длину и три операнда (но необязательно используются все три). Из них смещения на данные в случае 16-битных смещений составляют 6 байт, а в случае 32-битных смещений соответственно 12. Плюс 4 байта информации. Из которых 8 бит - номер опкода и по 8 бит мета-информации на каждый операнд, где 2 бита - размер операнда, а 6 бит флаги их состояний. В отличие от CISC-системы команд, их легко проматывать и полностью исключена возможность вредоносного вмешательства из-за переполнения буффера, когда данные трактуются как команда.

Немного о практическом применении, с учётом накопленного опыта. Valve, как вы знаете, купив первый Quake у Кармака, очень быстро упёрлась в возможности этого ограниченного языка и было принято решение переписать игровую библиотеку на С++. Это было сделано в спешке, поэтому кодинг под GoldSource напоминает пляски на ~~картофельном поле с дедом~~граблях. Абсолютно все сталкивались, не с тем, так с этим.
Просто раз уж у нас тематический форум по халфе, в каком-то смысле, вы все хорошо знаете, о чём я говорю. Так вот для многих эти ужасы послужили негативным стимулом вообще забросить программирование.
Что характерно, Valve не отошла от этой практики и в последующих движках, но там действительно уже было невозможно ориентироваться, даже на мой взгляд.
Плюс разработка под С++ требует наличия на компьютере тяжеловесной MSVC. Иногда требуется какая-то строго опредлённая версия, иначе потребуются дополнительные пляски с бубном. Unity со своим C# аналогично требует наличия MSVC. К тому же у меня в последнее время сложилось нехорошее впечатление, что сигналом для выхода новой версии Unity как раз и служит новая версия СиШарпа. Может быть в 2005-м году, когда Юнитех сделал свой выбор пользу Шарпа, он еще не выглядел так страшно, как сейчас, хотя тенденция уже тогда просматривалась. Так или иначе, но лично мне совершенно не хочется зависеть от капризов разработчиков стороннего языка и следить, чтобы код мог компилироваться на целом букете компиляторов. В дальнейшем, если новый язык выйдет за рамки XashNT и получит некоторое распространение для решения иных прикладных задач, об этом придётся задуматься, но пока что здесь обеспечена необходимая целостность.
А редактор исходного кода я встрою прямо в основной редактор, таким образом вам вообще не придётся использовать студию для разработки игр на XashNT. Но конечно не исключена возможность и сопряжения компилятора с теми видами продвинутых блокнотов, к которым вы привыкли. Да и в самой студии, вроде как есть возможность подмены компилятора. Это что касается вопросов редактирования исходников.

Сказано достаточно, теперь самое время ответить на ваши вопросы, которые у вас возможно появились по вышенаписанному.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено MrThomasCooper 19-10-2022 в 07:39:

Плюшка из Делфи, в виде «набросал контроллов и готово» перекочевала тоже?

И насколько оно будет совместимо со старыми версиями винды и старым железом в целом?

Отправлено Дядя Миша 19-10-2022 в 08:00:

Возможно у нас здесь собралась аудитория которая не слишком хорошо знает все возможности С++, да и не факт, что многим это будет интересно, но я всё же опубликую список того, чего ещё нет в моём языке (в отличие от С++) и что планируется туда добавить, т.к. разработка языка еще не завершена, хотя в сущности поставленная задача уже выполнена.

Итак, что еще планируется добавить в язык:
1. Перегрузка операторов. Полезна для создания абстрактных типов данных, вроде векторов, матриц и комплексных чисел, но и не только.
2. Поддержка функций внутри функций как в Delphi, ну или лямбда-выражений, пока еще не определился точно. К слову сказать трюк с объявлением локального класса прямо внутри функции, как это возможно в С++, у меня тоже работает, хотя, как и так, не даёт никаких преимуществ, в плане оптимизации.
3. inline-разворачивание функций. Это весьма сложная вещь, которая прячется за простым интерфейсом. К тому же я не уверен, что в случае скриптового языка от нее будет какая-то польза. Но серию экспериментов я конечно проведу. Для методов get\set (невиртуальных свойств), развертывание, к слову уже имеется, т.к. это часть их природы.

4. Шаблоны для функций. На данный момент поддерживаются только шаблоны для объектов. Не то чтобы сложно, просто руки пока не дошли.

5. Доступ к защищенным членам класса с выводом соответствующих ошибок. На данный момент компилятор не учитывает секции private\protected\public, хотя и хранит информацию о них. Это в сущности мелочь, т.к. при ошибке доступа просто выдаётся соответствующее предупреждение компилятора, больше ничего не делается.

6. Механизм исключений. Он не является особенностью именно С++, т.к. есть много где. И он идеально ложится на RISC-архитектуру. Аналогично пункту 4 пока не дошли до него руки.

Все остальные возможности и особенности С++, по крайней мере те, которые регулярно используются так или иначе уже реализованы. Постепенно всё будет приводится к соответствию стандартов самого С++, если речь идёт об унаследованных особенностях, а те вещи, которых в С++ нет, будут максимально тесно интегироваться с уже имеющимися для обеспечения максимальной целостности нового языка.

Добавлено 19-10-2022 в 10:45:

Цитата:

MrThomasCooper писал:
Плюшка из Делфи, в виде «набросал контроллов и готово» перекочевала тоже?

Совершенно верно. Причём эта особенность в дальнейшем появится и для внутриигрового меню тоже. А возможно и новые энтити можно будет создавать похожим образом.

Цитата:

MrThomasCooper писал:
И насколько оно будет совместимо со старыми версиями винды и старым железом в целом?

Ну на XP будет работать точно. Ниже не уверен.

Строго говоря XashNt по возможности прозрачен для железа, т.е. его потребление ресурсов в первую очередь зависит от тяжести ресурсов самой игры. Понятное дело, что уровни сталкеровского типа нагрузят видеокарту куда сильнее, нежели коридоры из кваки. А если вы планируете сделать тетрис, то всё будет летать даже на самых слабых конфигурациях. Впрочем в процессе разработки я уже использовал некоторые возможности WinAPI, которых не было в Windows ниже XP.
Но не думаю, что это представляет проблему. Если Xp до сих пор еще используют, то людей, сидящих под 2K или Win98 я себе не представляю.

Добавлено 19-10-2022 в 11:00:

Надо будет сформулировать все ключевые пункты концепции XashNT, я про них периодически упоминаю, то там, то здесь, но надо собрать их воедино, чтобы пользователи знали чего именно ожидать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 19-10-2022 в 08:10:

Цитата:

Дядя Миша писал:
Плюс разработка под С++ требует наличия на компьютере тяжеловесной MSVC.

Ты аккуратнее с такими заявлениями.

Добавлено 19-10-2022 в 04:10:

Цитата:

Дядя Миша писал:
Если Xp до сих пор еще используют, то людей, сидящих под 2K или Win98 я себе не представляю.

Ну, у них просто борода длиннее, и возможно - до сих пор где-то хранится советский паспорт.

__________________

Отправлено (_-=ZhekA=-_) 19-10-2022 в 10:23:

Дядя Миша
Это все конечно хорошо, а есть рабочая версия - запустить посмотреть, что и как?

Отправлено Дядя Миша 19-10-2022 в 12:35:

(_-=ZhekA=-_) есть. Читай F.A.Q.
https://hlfx.ru/forum/showthread.php?s=&threadid=5696

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-10-2022 в 12:50:

Цитата:

Дядя Миша писал:
Но не думаю, что это представляет проблему. Если Xp до сих пор еще используют, то людей, сидящих под 2K или Win98 я себе не представляю.

Это ещё ньюфаги

https://dtf.ru/life/888434-gollande...azu-ne-slomalos

Отправлено (_-=ZhekA=-_) 20-10-2022 в 05:42:

Цитата:

Дядя Миша писал:
(_-=ZhekA=-_) есть. Читай F.A.Q.
https://hlfx.ru/forum/showthread.php?s=&threadid=5696

Ок, ясно

Отправлено FiEctro 21-10-2022 в 09:26:

Цитата:

Дядя Миша писал:
Так или иначе, но лично мне совершенно не хочется зависеть от капризов разработчиков стороннего языка и следить, чтобы код мог компилироваться на целом букете компиляторов.

Получается про портирование на другие платформы можно забыть?

Отправлено Дядя Миша 21-10-2022 в 09:29:

О каком портировании идёт речь, не понял.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-10-2022 в 10:40:

Дядя Миша
На ведроид например, или макось.

Отправлено Дядя Миша 21-10-2022 в 12:29:

ну вообще-то наоборот, виртуальная машина везде будет работать без портирования. В этом и смысл.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-12-2022 в 09:58:

Традиционно подведу итоги уходящего года.

Наверное это был самый неинформативный год в плане разработки Ксаша.
Ну что поделать? Мои планы не поменялись, я по прежнему считаю, что графический интерфейс следует размещать внутри виртуальной машины.
Разумеется это не я первый придумал, это давно практикуется с явой и шарпом. Вот только ни один из уже существующих скриптовых языков меня не устроил. Я бы мог пуститься в пространные рассуждения почему сложилась такая ситуация, но не стану. Вы всё равно ничего не поймете. Не потому что глупые, а потому что вам это абсолютно неинтересно. Но если всё же кому-то будет интересно, я распишу дополнительно ниже. Пока что отмечу тот факт, что собственный скриптовой язык открывает замечательные возможности. недоступные ни на Яве ни на Шарпе, поскольку в этих языках обязательно не будет того, что нужно, и придётся ждать, когда оно там появится, неизвестно в какой форме оно там появится и как после этого сломается совместимость. В качестве примера могу привести тот же Unity, где смена мажорного номера версии ознаменовала собой переход на новую версию Шарпа. То есть разработчики целиком и полностью зависят от сторонних библиотек, сужая и без того невеликое пространство решений.

Впрочем даже выбирая Lua или AngelScript вы всё равно оказываетесь в зависимости от авторов этих библиотек. Были, как вы знаете два движка с собственными скриптовыми языками - это Unigine и Godot. Первый пытался частично эмулировать функционал С++, но к сожалению использовал порочную модель Шарпа и Явы (всё - объект), что разумеется сказалось на его производительности. Поэтому большой объемный код на таких скриптах не напишешь. Впрочем в Unreal до третьей версии включительно сохранялась та же самая ситуация. Скрипты есть, а их производительность не годится для написания чего-то боле-мене серьезного. У Годота язык старался быть похожим на Питон, который использует ту же самую объектную модель со всеми вытекающими. И с той же низкой производительностью. Как итог все движки предлагают альтернативу - использование С++ библиотек, что полностью ломает первоначальную задумку и вносит элемент хаотичности.

В Ксаше я поступил иначе. Мой язык изначально планировался как скриптовой и с высокой нагрузочной способностью. Грубо говоря это песочница с синтаксисом и поведением С++, но при этом имеющая такие возможности, которые в самом С++ реализованы не будут никогда. А если и будут, то очень коряво и неудобно. Разумеется всё это успешно обходят - прописывая подобные вещи вручную. Но ведь смысл как раз в том и заключается, чтобы автоматизировать очевидное, получив при этом новые возможности. Практически весь 2022-й год я и бился над решением этой задачи. Пока ещё рано говорить с полной уверенностью, но мне определённо нравится то, что у меня получилось.

И теперь я наконец-то смогу вернуться к своей изначальной цели - написанию универсального редактора и универсального вьювера, интерфейсы которых будут реализованы на том самом скриптовом языке, а значит смогут быть отредактированы юзерами, если им вдруг захочется поменять расположение контролов или вообще создать новые окна.
Но, как вы понимаете, сам скриптовой язык предлагает куда более широкие возможности, нежели правка исходного кода таких меню. Теперь так же будет доступна возможность редактирования внешнего вида из текстовых файлов, причём изменения в исходном коде потребуются минимальные - т.к. сама виртуальная машина уже обеспечивает весь необходимый функционал. Да и сохранение абсолютно всех настроек как редактора, так и вьювера теперь стали весьма простым делом.

Язык создавался не только для меню. На этом же языке будет написан и игровой код движка. И здесь я вижу одну потенциальную возможность, которой лишены как Юнити, так и Унреал с КрайЭнджином.
В Юнити фактически нет игрового кода. Там есть сэмплы-примеры, написанные на скорую руку и крайне неоптимально. Предполагалось, что для реального проекта их перепишут правильно. Однако, как вы понимаете, те, кто пытался создавать свои проекты на Юнити поверили рекламным обещаниям, что там вообще не придётся писать код. В результате похабные примеры из сэмплов перекочевали в реальные игры и мы с удовольствием наблюдаем "фирменную" физику Юнити - да-да, тот самый мешок с гамном на пенсии. В Унреал и Крае строго обратная проблема - игровые библиотеки из коробки умеют практически всё, но разобраться в десятках мегабайт этих абстракций мало кому под силу. Без обучающих курсов тут делать просто нечего. Кажется я придумал весьма оптимальный способ решения этой проблемы.

Ну а в наступающем 2023-м я надеюсь у меня для вас будет куда больше различных новостей и планируется очередная бета-версия. Ориентировочно в мае-июне.

Ещё раз всех с наступающим!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-12-2022 в 11:34:

Цитата:

Дядя Миша писал:
Впрочем даже выбирая Lua или AngelScript вы всё равно оказываетесь в зависимости от авторов этих библиотек.

А можно твою ВМ подключить к другому проекту? Всмысле отдельно от ксашдвижка?

Цитата:

Дядя Миша писал:
создавать свои проекты на Юнити поверили рекламным обещаниям, что там вообще не придётся писать код.

Хотелось бы увидеть пруфы.

Цитата:

Дядя Миша писал:
В результате похабные примеры из сэмплов перекочевали в реальные игры и мы с удовольствием наблюдаем "фирменную" физику Юнити - да-да, тот самый мешок с гамном на пенсии.

В Юнити почти тот же самый PhysX который ты и у себя в ксаше использовал. Только более новый. Что касается самого чарактер контролера то он там такой же как в PhysX. Но в целом народ написал уже и своих чарактер контроллеров, в т.ч. и с поддержкой ИК.

Цитата:

Дядя Миша писал:
В Унреал и Крае строго обратная проблема - игровые библиотеки из коробки умеют практически всё, но разобраться в десятках мегабайт этих абстракций мало кому под силу.

Будто в крестах разбираться многим под силу. А в Анриле как раз кресты.

Цитата:

Дядя Миша писал:
Теперь так же будет доступна возможность редактирования внешнего вида из текстовых файлов

Это прошлый век, напиши простенький редактор для верстки интерфейсов. как в том же Делфи.

Цитата:

Дядя Миша писал:
Ещё раз всех с наступающим!

Да, тебя тоже с наступающим

Отправлено Дядя Миша 29-12-2022 в 13:08:

Цитата:

FiEctro писал:
А можно твою ВМ подключить к другому проекту? Всмысле отдельно от ксашдвижка?

Да, она создавалась с таким рассчётом, чтобы работать как та же Ява или Шарп. Она не прибита гвоздями к движку.

Цитата:

FiEctro писал:
Хотелось бы увидеть пруфы.

Да весь рунет подобной рекламой завален был одно время. Наверное на свои курсы заманывали.

Цитата:

FiEctro писал:
В Юнити почти тот же самый PhysX который ты и у себя в ксаше использовал

Физика игрока не идёт в физдвижке изкаропки, т.к. в каждой игре она своя.
Изкаропки там разве что сэмпл как взбираться на ступеньки.

Цитата:

FiEctro писал:
Будто в крестах разбираться многим под силу

Когда все АТД снабжены стандартными операциями, а низкий уровень вообще нигде не мозолит глаза, то С++ выглядит как типичный скриптовой язык. Я это любопытное свойство заметил еще в 2006-м году, но тогда этого никто не оценил.

Цитата:

FiEctro писал:
напиши простенький редактор для верстки интерфейсов. как в том же Делфи.

Понятное дело, но ведь редактировать-то он будет те самые текстовые файлы, а не что-то ещё.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-12-2022 в 14:33:

Цитата:

Дядя Миша писал:
Да весь рунет подобной рекламой завален был одно время. Наверное на свои курсы заманывали.

Юнити никогда не позиционировался как конструктор где можно игру собрать без кода. Какие то определенные компоненты там уже есть, это да, их писать заново не нужно. Но изначально с самых первых версий Юнити был завязан на шарп.

Возможно речь идёт про горешкольников которые накачивают готовые ассеты не проверяя их на совместимость, и заливают это говно в стим. Ну это скорее проблема таких людей, нежели маркетинг Юнити.

Добавлено 29-12-2022 в 17:33:

Цитата:

Дядя Миша писал:
Когда все АТД снабжены стандартными операциями, а низкий уровень вообще нигде не мозолит глаза, то С++ выглядит как типичный скриптовой язык. Я это любопытное свойство заметил еще в 2006-м году, но тогда этого никто не оценил.

Проблема нативных крестов то что ты там должен каждый пердеж описывать, вспомни сколько говна надо накидать чтобы теже формы сделать, или окошко OpenGL отрисовать. Я до сих пор не понимаю, на кого это рассчитывалось? Почему это нельзя было обернуть нормально?

Отправлено XaeroX 29-12-2022 в 14:38:

Цитата:

FiEctro писал:
вспомни сколько говна надо накидать чтобы теже формы сделать, или окошко OpenGL отрисовать

А каким же образом это связано с языком? Или в других языках окошко OpenGL создаётся как-то иначе? Да вроде точно так же, с вызовом ровно того же набора функций.

__________________

Отправлено FiEctro 29-12-2022 в 14:55:

Цитата:

XaeroX писал:
А каким же образом это связано с языком? Или в других языках окошко OpenGL создаётся как-то иначе? Да вроде точно так же, с вызовом ровно того же набора функций.

Да вот фиг знает, вроде бы и никак. Но я частенько вижу такую мешанину именно на крестах, может и на других языках тоже самое. Это просто плохой пример организации, когда вместо того чтобы сделать вызов, ты ещё должен дописать ему кучу параметров.

Отправлено Дядя Миша 29-12-2022 в 15:12:

Цитата:

FiEctro писал:
Проблема нативных крестов то что ты там должен каждый пердеж описывать, вспомни сколько говна надо накидать чтобы теже формы сделать, или окошко OpenGL отрисовать.

А тож можно подумать, на Делфи оно не так? Но сюрприз - там это всё уже за тебя написали. Вот и весь фокус.

То есть надо сразу дать народу хорошую стартовую базу. А когда эта база встроена уже прямо в язык, начинаются проблемы совместимости в последствии.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 29-12-2022 в 15:13:

Цитата:

FiEctro писал:
Это просто плохой пример организации, когда вместо того чтобы сделать вызов, ты ещё должен дописать ему кучу параметров.

Это ты ещё код создания окошка на Vulkan не видел.

Добавлено 29-12-2022 в 10:13:

Цитата:

Дядя Миша писал:
Но сюрприз - там это всё уже за тебя написали. Вот и весь фокус.

Не в делфи, а в VCL.
А в крестах всё за тебя написали в том же Qt.
Ну и любой движок, понятное дело, умеет создавать окошки с рендерами.

__________________

Отправлено Дядя Миша 29-12-2022 в 15:45:

Цитата:

XaeroX писал:
Не в делфи, а в VCL.
А в крестах всё за тебя написали в том же Qt.

Но VCL идёт вместе с Делфи, а Qt - неидёт. Может в этом всё дело?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-02-2023 в 22:15:

Так товарищи, я наконец-то добрался до той части работы в процессе которой мне будет о чём с вами поговорить и надеюсь вам будет интересно.
А именно: портирование игрового кода на мой новый язык. Этот процесс обратный тому, что когда-то сделали Valve, когда перенесли свой игровой код с QuakeC на С++. И вот теперь настала пора сделать наоборот - перенести код с С++ на скритовую машину. Конечно её функционал превышает таковой не только у QuakeC, но и у самого С++ (уступая лишь по быстродействию), иначе бы вся эта затея попросту не имела смысла.

На первый взгляд это кажется несложной задачей, однако я напомню - 80% глюков GoldSource как раз и обусловлены этой спешной заменой виртуальной машины на библиотеку. Кармак, к слову, проделал тоже самое в Quake2, из-за чего добавление новых полей в объект для сохранения превратилось в жуткую боль, ну кто пробовал тот знает. Да и сам код объектов на чистом Си весьма неудобен и не располагает к пониманию. В Source из-за отсутствия в языке встроенных способов задания мета-информации код превратился в нагромождение каких-то адских таблиц и абстрактных классов, в которые без подготовки соваться страшно. Игровой код Unreal - ну там тоже вся мета руками прописана. Unity... На мой взгляд СиШарп для игровых объектов вообще не годится. Не для этого он создавался. Ну вообщем изучив основные проблемы и разработав собственный язык, я теперь готов вам предоставить своё виденье того как это должно выглядеть. Фронт работ следующий:

1. Новый механизм сейв-рестора. В отличие от халфовского классического, где надо было постоянно прописывать какие-то таблички, здесь от пользователя не требуется ничего. Максимум - пометить переменную-член класса, которую не надо сохранять.

2. Новый физический движок. С парент-системой, рагдоллами, катающимися бочками, машинками, полной предиктабельностью по сети и возможно с надувными коровами (???), впрочем насчёт последнего я не уверен. Но нечто вроде матрасов из хл2 будет. Так же будут возможны деформабли и разрушабли. Но это попожжы.

3. Новый дельта-калькулятор. Больше не будет никаких загадочных структур entity_state_t, clientdata_t и weapon_data_t, в которых вечно не хватает места, а изменить их нельзя. Новый сетевой движок будет строить индивидуальные дельта-таблицы автоматически для всех типов энтить, вот только ему не придётся прописывать жуткие таблицы-подсказки, как это сделано в сорсе.

4. Новая система предиктинга. В идеале - всех объектов, которые видны и осязаемы. Логика, понятное дело, на клиент передаваться не будет.
Впрочем в этом аспекте у меня еще нет чёткой картинки как тут всё будет устроено, детали будут уточняться по ходу разработки, т.к. надо будет провести ряд экспериментов.

5. Собственно портирование игровых энтить на новый скриптовой язык. На данный момент, как вы наверное уже догадались будет портирован весь набор энтить из ксаш-мода 0.82. Но вообще энтити могут быть из любой игры.

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

Теперь собственно вы можете высказать какие-то свои пожелания, задать уточняющие вопросы, а так же познакомить меня с особенностями организации игровых объектах в Юнити\Унреале в тех аспектах, которые кажутся вам важными\интересными.
После того как эта задача будет завершена - начнётся самое интересное, но об этом я расскажу не раньше чем она будет завершена.

В идеальном случае планирую управится за три месяца: Февраль, Март, Апрель.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Raid 08-02-2023 в 05:19:

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

Отправлено FiEctro 10-02-2023 в 05:54:

Цитата:

Дядя Миша писал:
Покажи пример интуитивной фигни.

Вот в этой теме: https://hlfx.ru/forum/showthread.ph...2635#post212635
Чтобы здесь не оффтопить.

Ну ё моё. Уже показывал. Любая фигня которая содержит интуитивно понятную справку. Обидно что на халфу так и не сделал за все годы никто ничего подобного.

https://manual.yoyogames.com/GameMa...L_Reference.htm

https://acegikmo.com/shaderforge/nodes/

Отправлено Дядя Миша 10-02-2023 в 09:58:

Но на чтение этой справки уйдут годы
Тебе не кажется что обучение на реальных примерах гораздо быстрее, нежели на чтении справки, которая может давно уже не соответствовать реальному положению дел?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 10-02-2023 в 10:08:

На чтение телефонного справочника тоже уйдут годы, но его от корки до корки не читают.

Отправлено Дядя Миша 10-02-2023 в 10:24:

Я уже как-то писал, что главная проблема большинства скриптовых языков - это встроенные методы, которые нигде не отсвечивают и узнать о них можно в двух случаях:
1. если специализированная студия сама тебе его предложила автозаполнением
2. из справки

Но чтобы сработал первый метод, надо хотя бы немного ознакомиться с возможностями языка и на чтение этой справки уйдет порядочно времени.
Тогда как в том же С++ можно просмотреть заголовки и в аочию увидеть что доступно изкаропки. Но конечно это предполагает наличие некоторого опыта.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 10-02-2023 в 11:24:

Цитата:

Дядя Миша писал:
1. если специализированная студия сама тебе его предложила автозаполнением

Оно показывает далеко не всегда подробно. В основном какие то капитанские вещи, мол принимает такие аргументы, а для чего, а фиг его знает.

Цитата:

Дядя Миша писал:
2. из справки
Но на чтение этой справки уйдут годы

Это не правда, в справке есть поиск. Суть не в зазубривании справки, а в быстром понимании инструментов движка. Ввёл в гугл Transform.Translate, и получил быстро ответ, какие ты более быстрые методы знаешь?

Цитата:

Дядя Миша писал:
Тебе не кажется что обучение на реальных примерах гораздо быстрее, нежели на чтении справки, которая может давно уже не соответствовать реальному положению дел?

Я помню ты сам говорил что ковыряться в чужом коде это занятие кхм для особо целеустремлённых, а вот что делать остальным? Примеры это конечно хорошая вещь когда они обёрнуты и оформленны в стиле - вот смотри эта вещь нужна для этого и больше ни для чего другого. Как например было на демо карте ксашмода. Но сможешь ли ты сделать достаточно таких демок?

А если это что то из менее очевидного, вроде сетевого Api? Там как это в примерах показать?

Цитата:

Дядя Миша писал:
Тогда как в том же С++ можно просмотреть заголовки и в аочию увидеть что доступно изкаропки. Но конечно это предполагает наличие некоторого опыта.

Ну научи нас им пользоваться в том же хлсдк, я конечно ковырял, но там как и в случае с подсказками - какое то капитанство. Нужно самому всё это ковырять и проверять чтобы понять что оно в реале делает. Почему я и написал что это не интуитивно. Разве что всё рядом в // комментариях описывать.

Отправлено nemyax 10-02-2023 в 11:47:

Образцовый справочник по скриптовым апям — у блендера: https://docs.blender.org/api/current/
Всегда актуальный, так как генерируется из исходников модулей. Хорошо организованный, так что я не понимаю, чего там можно долго искать.

Отправлено Дядя Миша 10-02-2023 в 15:07:

Цитата:

FiEctro писал:
Это не правда, в справке есть поиск

Но в поиск надо еще знать что вбивать.

Цитата:

FiEctro писал:
Я помню ты сам говорил что ковыряться в чужом коде это занятие кхм для особо целеустремлённых, а вот что делать остальным?

Ну вот представь, захотел ты сделать ротатаблю и тут тебе пример - исходник ротатабли. Захотел сделать пушаблю - и тут тебе пример, исходник пушабли. Ну и монстра. Ты их изучил начал кой-чего понимать.
А что не начал - посмотрел в справку, уже зная что искать.

Цитата:

FiEctro писал:
Как например было на демо карте ксашмода

Что именно ты имеешь в виду?

Цитата:

FiEctro писал:
Почему я и написал что это не интуитивно.

Возможно. Я думаю нужна не только сухая справка, кто и что делает, но и общий обзор возможностей языка и подкапотного устройства. Чтобы иметь общее представление о работе, а не воспринимать это как чёрный ящик.

Добавлено 10-02-2023 в 18:07:

Цитата:

nemyax писал:
Образцовый справочник по скриптовым апям — у блендера

C++ Source Code:

import bpy

bpy.data.objects["Cube"].data.vertices[0].co.x += 1.0

Даа, без подсказок от студии такое с первого раза напечатать не просто.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 10-02-2023 в 15:21:

Цитата:

Дядя Миша писал:
Ну вот представь, захотел ты сделать ротатаблю и тут тебе пример - исходник ротатабли. Захотел сделать пушаблю - и тут тебе пример, исходник пушабли.

Ну если оно оформлено ввиде отдельного скрипта, ещё куда не шло. Но если размазано по всему коду как в hlsdk ты сам понимаешь, это уже надо изначально там ориентироваться.

Я думаю просто достаточно описать что делают те или иные методы.

Отправлено Дядя Миша 10-02-2023 в 15:28:

Цитата:

FiEctro писал:
Ну если оно оформлено ввиде отдельного скрипта, ещё куда не шло

Ну вот я сейчас переписываю ксаш-мод на свой язык и стараюсь всё оформить так, чтобы любой смог разобраться даже без чтения документации. А с документацией так вообще.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 10-02-2023 в 16:08:

Дядя Миша
Кстати будут ли у тебя какие то упрощения для работы с сейв реестром и неткодом?

Отправлено Дядя Миша 10-02-2023 в 16:37:

Цитата:

FiEctro писал:
Кстати будут ли у тебя какие то упрощения для работы с сейв реестром и неткодом?

Виртуальная машина - в том числе и для этого. Да, я уделил этому особенное внимание.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 10-02-2023 в 20:20:

Цитата:

Дядя Миша писал:
Но в поиск надо еще знать что вбивать.

Так в этом и суть. Пишешь: фигня которая преобразует эйлеры в кватернионы, и он сам даёт тебе ответ.

Цитата:

Дядя Миша писал:
Что именно ты имеешь в виду?

Готовая сцена с демонстрацией реализации фичей.

Цитата:

Дядя Миша писал:
Ну вот представь, захотел ты сделать ротатаблю и тут тебе пример - исходник ротатабли. Захотел сделать пушаблю - и тут тебе пример, исходник пушабли. Ну и монстра. Ты их изучил начал кой-чего понимать.

Это сильно зависит от подачи. Если тебе сейчас дать код неизвестно чего например на питоне, так ещё и часть которого закрыта, насколько тебе просто будет его понять?

Цитата:

Дядя Миша писал:
Возможно. Я думаю нужна не только сухая справка, кто и что делает, но и общий обзор возможностей языка и подкапотного устройства. Чтобы иметь общее представление о работе, а не воспринимать это как чёрный ящик.

Интересно а как ты сам видишь это? Я понимаю что тебе не хочется вести и поддерживать эту справку, может встречал ещё какие либо интересные варианты? Мне никаких альтернатив кроме комментариев в самом коде в голову больше не лезет.

Отправлено Дядя Миша 11-02-2023 в 07:23:

Цитата:

FiEctro писал:
фигня которая преобразует эйлеры в кватернионы

А сперва забиваешь в поиск, что такое углы Эйлера и что такое Кватернионы.

Цитата:

FiEctro писал:
Если тебе сейчас дать код неизвестно чего например на питоне

Я питон вообще не воспринимаю как язык. Это какой-то прикол.

Цитата:

FiEctro писал:
Я понимаю что тебе не хочется вести и поддерживать эту справку

Справка будет в любом случае. Меня волнует порог вхождения. А для этого нужна обратная связь, чтобы понять что у народа вызывает трудности.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-02-2023 в 10:05:

Цитата:

Дядя Миша писал:
Меня волнует порог вхождения.

Я думаю что стоит сделать небольшую игровую сцену которая демонстрирует все основные фичи движка для 2д и 3д. А так же описать в справке те методы которыми реализованы эти фичи. Что касаемо интерфейса UI редактора, сделать возможность всплывающих подсказок. Неплохо бы так же сделать сразу для этого и какую то систему для локализаций. Чтобы в дальнейшем можно было менять язык одной кнопкой.

Так же сделать простенький ланчер, который бы уведомлял пользователей об апдейтах движка, например с того же GitHub и имел внутри список проектов.

https://devtribe.ru/files/100001/1000982/image-1537523949.png?d=1537525011

https://docs.unity3d.com/ru/2019.4/uploads/Main/gs_version_build_target.png

Отправлено Дядя Миша 11-02-2023 в 12:53:

Будут и демки и примеры и документация. Но самое главное - это обратная связь с пользователями. Сделал демку, думаешь всем всё понятно, а на практике никому ничего не понятно. Но все молчат как на уроке в советской школе.

Добавлено 11-02-2023 в 15:53:

Цитата:

FiEctro писал:
Так же сделать простенький ланчер, который бы уведомлял пользователей об апдейтах движка,

Не нравится мне этот зоопарк. Между версиями либо что-то сломано, либо вообще несовместимо. Они же там выбрасывают иногда некоторые вещи.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-02-2023 в 13:35:

Цитата:

Дядя Миша писал:
Не нравится мне этот зоопарк. Между версиями либо что-то сломано, либо вообще несовместимо. Они же там выбрасывают иногда некоторые вещи.

Для этого и нужны версии в заголовках и метаданных. Чтобы вывести юзверю заветное окошко - этот файл больше не поддерживается. Ну либо заморочиться и делать встроенный конвертер из старого формата в новый как в юнити. Там с допотопных версий можно апгрейднуть проект в современные. Правда большинство функций и шейдеров окажется уже deprecated. В сорсе нечно подобное и было, правда там это можно было узнать только когда уже скормил движку файл не той версии.

Добавлено 11-02-2023 в 16:13:

Цитата:

Дядя Миша писал:
Сделал демку, думаешь всем всё понятно, а на практике никому ничего не понятно. Но все молчат как на уроке в советской школе.

Опять же как и писал ранее зависит от реализации. Если можно будет ткнуть на объект и сразу попасть в скрипт который его обрабатывает. Если можно будет легко отследить порядок выполнения кода, если можно будет отследить сколько какой скрипт потребляет. То это сильно понизит планку вхождения. Я понимаю что ты мыслишь как программист старой школы, которому даже и подсветка синтаксиса не особо нужна, не то что инструменты дебага. Но новичкам нужно чтобы все свистело и пердело, чтобы движок их тыкал напрямую носом в строку в коде где они накосячили. Чем больше пользователь будет чуствовать контроль над ситуацией, тем комфортнее ему будет работать с движком.

Если уж совсем упарываться по интуитивности, рекомендую глянуть Скретч, он очень простой и примитивный, расчитаный совсем на маслят, и копировать конечно я его не предлагаю, однако можно посмотреть и поиграться какие вещи авторы выносят на передний план чтобы новичку было проще разобраться. https://scratch.mit.edu/projects/ed...rial=getStarted

Отправлено Дядя Миша 11-02-2023 в 14:07:

Цитата:

FiEctro писал:
можно будет отследить сколько какой скрипт потребляет

Потребляет ЧЕГО?

Цитата:

FiEctro писал:
простой и примитивный, расчитаный совсем на маслят,

А маслята это кто?

Добавлено 11-02-2023 в 17:07:

Сходил по ссылке. Я резко отрицательно отношусь к визуальному программированию. Оно мозги так переформатирует, что человек не может выбраться из своего мира иллюзий.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-02-2023 в 15:42:

Цитата:

Дядя Миша писал:
Потребляет ЧЕГО?

Ресурсы проца. https://docs.unity3d.com/Manual/Profiler.html

Цитата:

Дядя Миша писал:
Сходил по ссылке. Я резко отрицательно отношусь к визуальному программированию. Оно мозги так переформатирует, что человек не может выбраться из своего мира иллюзий.

Это да, я к тому как сам интерфейс и первое знакомство с ним организовано.

Отправлено (_-=ZhekA=-_) 11-02-2023 в 16:18:

Цитата:

Блюпринты в уе это самое лучшее, что вообще, когда-либо придуманное и тому, кто это придумал нужно сделать отдельный вход в рай...

Отправлено Дядя Миша 11-02-2023 в 18:27:

Цитата:

FiEctro писал:
Ресурсы проца

Приведи пример того, что может потреблять ресурсы выше погрешности.

Цитата:

(_-=ZhekA=-_) писал:
Блюпринты в уе это самое лучшее, что вообще, когда-либо придуманное

Это пока их немного. А когда счёт этих элементов идёт на сотни - крыша едет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-02-2023 в 18:36:

Цитата:

Дядя Миша писал:
Приведи пример того, что может потреблять ресурсы выше погрешности.

Поиск, перебор и сортировка всех объектов по сцене, инстансы, обращение к их компонентам, генерация чанков, да много чего. А ты думал откуда фризы берутся

Цитата:

Дядя Миша писал:
Это пока их немного. А когда счёт этих элементов идёт на сотни - крыша едет.

Ты просто не знаешь что там можно делать группы

Отправлено (_-=ZhekA=-_) 11-02-2023 в 18:53:

Цитата:

Дядя Миша писал:
Это пока их немного. А когда счёт этих элементов идёт на сотни - крыша едет.

Там все сделано для людей и никаких проблем с этим нет

Цитата:

FiEctro писал:
Ты просто не знаешь что там можно делать группы

И не только

Отправлено Дядя Миша 12-02-2023 в 07:49:

Цитата:

FiEctro писал:
Поиск, перебор и сортировка всех объектов по сцене, инстансы, обращение к их компонентам, генерация чанков, да много чего

Поиск не должен быть линейным. Перебор один раз за кадр, возможно в отдельном потоке. Инстанцирование не должно занимать время, равно как и обращение к компонентам, насчёт чанков не понял. Какие-то надуманные проблемы, ИМХО. Да, если на уровне десятки тысяч объектов, то конечно их перебор за кадр занимает время, и с этим ничего не сделаешь. Но это приводит к общему падению фпс, а не к фризам.

Цитата:

FiEctro писал:
Ты просто не знаешь что там можно делать группы

Я просто спрашиваю, когда вы упрятали их в группу и потом этих групп становится тоже несколько сотен - легко разобраться? В твоём примере сквозной линейный вызов, а если там будет ещё десять непрямых обращений?

Добавлено 12-02-2023 в 10:49:

Фризы - это вероятно сборщик мусора просыпается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-02-2023 в 10:10:

Цитата:

Дядя Миша писал:
Поиск не должен быть линейным. Перебор один раз за кадр, возможно в отдельном потоке. Инстанцирование не должно занимать время, равно как и обращение к компонентам, насчёт чанков не понял. Какие-то надуманные проблемы, ИМХО.

Они надуманные если ты о них уже знаешь, а человек незнакомый с движком может запутаться. Чанки как в майнкрафте, когда тебе надо обрабатывать массивы по 100х100х100 объектов

, конечно можно это делать более оптимизировано не плодя объекты, но это не сильно спасёт.

Добавлено 12-02-2023 в 13:10:

Цитата:

Дядя Миша писал:
Я просто спрашиваю, когда вы упрятали их в группу и потом этих групп становится тоже несколько сотен - легко разобраться? В твоём примере сквозной линейный вызов, а если там будет ещё десять непрямых обращений?

Группа оформляется в отдельную ноду со своими инпутами и отпутами, и ничем не отличается от вызова обычной функции. Вообще была речь не о нодах и визуальном программировании, а о том как авторы организуют первое знакомство с их системой, вот это я хотел показать.

Отправлено (_-=ZhekA=-_) 12-02-2023 в 11:32:

Цитата:

Дядя Миша писал:
Я просто спрашиваю, когда вы упрятали их в группу и потом этих групп становится тоже несколько сотен - легко разобраться?

С этим нет проблем, так как можно коллапсить делать отдельные функции, макросы и прочее. )
На скрине справа отдельно созданные функции и переменные. Еще можно комментировать код, если что ))) То есть ты сам решаешь, как будет выглядеть твой визуальный код - нагроможденным или минималистичным. В материал едиторе тоже принты ) А вообще блюпринты это тот же С++ только оформлен визуально, эпики очень грамотно сделали, хочешь юзаешь принты, хочешь юзаешь С++, а хочешь и то и другое сразу, еще можно подключать\отключать плагины

Добавлено 12-02-2023 в 14:32:

Дядя Миша
А еще можно - писать С++ прям в нодах

Отправлено Дядя Миша 12-02-2023 в 13:17:

Цитата:

FiEctro писал:
Они надуманные если ты о них уже знаешь, а человек незнакомый с движком может запутаться

Так это должно быть на нижнем уровне, а для пользователя - прозрачно.

Цитата:

FiEctro писал:
Группа оформляется в отдельную ноду со своими инпутами и отпутами, и ничем не отличается от вызова обычной функции

А с памятью как работа организована?

Цитата:

(_-=ZhekA=-_) писал:
А вообще блюпринты это тот же С++ только оформлен визуально, эпики очень грамотно сделали, хочешь юзаешь принты, хочешь юзаешь С++

Оба решения неоптимальные, скажем так. Принты - это для прототипирования. Но перед выпуском игры их рекомендуется обратить в код на С++, чтобы меньше лагало.

Цитата:

FiEctro писал:
Чанки как в майнкрафте, когда тебе надо обрабатывать массивы по 100х100х100 объектов

Почему ты привёл трёхмерный массив? Какие объекты он в себя включает?

Цитата:

FiEctro писал:
конечно можно это делать более оптимизировано не плодя объекты, но это не сильно спасёт.

Не плодя объекты - КАКИЕ?

В моём представлении объект, это нечто законченное. Ну скажем ротатабля или монстр.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-02-2023 в 13:33:

Цитата:

Дядя Миша писал:
А с памятью как работа организована?

Я не настолько силён в анриле, наверное как и в крестах. Лучше Жеку спросить.

Цитата:

Дядя Миша писал:
Оба решения неоптимальные, скажем так. Принты - это для прототипирования. Но перед выпуском игры их рекомендуется обратить в код на С++, чтобы меньше лагало.

Да прототипирование, но оно и хороший способ ознакомить пользователя с основными фишками. Но в целом я тоже считаю что в ксаше блюпринты лишние. Лучше пусть будет простой и понятный синтаксис.

Цитата:

Дядя Миша писал:
Почему ты привёл трёхмерный массив? Какие объекты он в себя включает?

Потому что в трехмерных массивах количество элементов растёт многократно. И выгрузить или переписать разом более 1 ляма элементов для проца серьёзная задача.

Цитата:

Дядя Миша писал:
Не плодя объекты - КАКИЕ?

Ну можно же сразу геометрию построить не создавая 1 лям кубиков и записывая им координаты в мировом пространстве. Но это тоже по меркам ЦП не быстро. Вообще поэкспериментируй с генерацией аля майнкрафт у себя в движке, сразу увидишь реальную производительность.

Цитата:

Дядя Миша писал:
В моём представлении объект, это нечто законченное. Ну скажем ротатабля или монстр.

Игровой объект это абстракция которая имеет координаты в мировом или локальном пространстве (ну и имя, индекс, всякие теги, слои и т.д.), по крайней мере по меркам юнити. А к нему ты уже любой скрипт привязать можешь, хоть ротатоблю, хоть монстра, хоть всё вместе, и он будет пытаться отыграть обе роли одновременно

Отправлено (_-=ZhekA=-_) 12-02-2023 в 14:08:

Цитата:

FiEctro писал:
Да прототипирование, но оно и хороший способ ознакомить пользователя с основными фишками. Но в целом я тоже считаю что в ксаше блюпринты лишние. Лучше пусть будет простой и понятный синтаксис.

А что, например, мешает добавить два варианта и пользователь сам для себя решит, какой ему больше подходит\нравится

Дядя Миша
Блюпринты аля анрил сложно добавить?

Цитата:

Дядя Миша писал:
А с памятью как работа организована?

Примерно так же, как и на С++ как сделаешь, так и будет работать, если сделал криво, то и работать будет криво вылеты и прочая срань...

Добавлено 12-02-2023 в 17:08:

Цитата:

На принтах онли можно без проблем делать игры, если руки прямые и никаких тормозов не будет

Отправлено Дядя Миша 12-02-2023 в 14:14:

Цитата:

FiEctro писал:
Я не настолько силён в анриле, наверное как и в крестах

Ну я имею в виду - на уровне пользователя. Допустим ты там захотел кое-что сохранить. Ты создаёшь еще один какой-то объект, или может глобальную переменную или выделяешь память?

Цитата:

FiEctro писал:
Потому что в трехмерных массивах количество элементов растёт многократно

Я спрашивал про конкретный пример такой необходимости. Что это за игра со стеком объектом из 100х100х100? Ну явно не майнкрафт, там объектов на порядок больше. С другой стороны - маловероятно, чтобы на типичном игровом движке можно было бы сделать майнкрафт, он на такое не рассчитан.

Цитата:

FiEctro писал:
Ну можно же сразу геометрию построить не создавая 1 лям кубиков и записывая им координаты в мировом пространстве

Нет, подожди. Мы говорили про объекты. С чего ты вдруг перескочил на геометрию?

Цитата:

FiEctro писал:
Вообще поэкспериментируй с генерацией аля майнкрафт у себя в движке, сразу увидишь реальную производительность.

Даже простой перебор массива из миллиарда элементов, это ОЧЕНЬ-ОЧЕНЬ долго. Вот это:

C++ Source Code:

for( int i = 0; i < UINT_MAX; i++ );

Работает четыре секунды на Core i3. Безо всякого движка. Ты я вижу узнал какие-то удивительные для себя вещи и теперь хочешь со мной ими поделиться?

Цитата:

FiEctro писал:
Игровой объект это абстракция которая имеет координаты в мировом или локальном пространстве

Ну нет. Игровой объект - это сугубая конкретика, которую мы частично может представить абстракцией. То есть func_button можно выполнять роль двери, а не только кнопки. А Monster_barney - необязательно имеет модельку barney, это в принципе может быть любой дружественный персонаж. Если мы не хотим писать для него отдельный класс, а хотим заменить только его наборы реплик и модельку. Теоретически это вообще может быть monster_generic, у которого настраивается абсолютно всё.
Но практика показала что это дико неудобно дизайнеру. Когда у него громадный лист из monster_generic и вообще непонятно какой из них кто.

Цитата:

FiEctro писал:
А к нему ты уже любой скрипт привязать можешь, хоть ротатоблю, хоть монстра, хоть всё вместе, и он будет пытаться отыграть обе роли одновременно

И в итоге нормально не отыграет ни одну. Я конечно не знаю, может быть есть зубры кодинга на юнити, но как правило там очень примитивные и глючные объекты - те, которые делали сами разработчики.

Добавлено 12-02-2023 в 17:14:

Цитата:

(_-=ZhekA=-_) писал:
А что, например, мешает добавить два варианта и пользователь сам для себя решит, какой ему больше подходит\нравится

Сама практика использования С++ для игровых объектов - неверная. Так быть не должно. Если бы блюпринты были отдельным языком, я бы сказал что это круто. Но это большей частью визуал в редакторе и надстройка над препроцессором С++. Я изучал их устройство. Не могу сказать что мне это понравилось. Эпики свой UnrealScript к четвертой версии довели до полного непотребства, я как-то разбирал во что он превратился. Поняли, что дальше так нельзя и замуитили вот эти БлуПринты.

Цитата:

(_-=ZhekA=-_) писал:
Блюпринты аля анрил сложно добавить?

Но у меня не предусмотрена компиляция в С++.

Цитата:

(_-=ZhekA=-_) писал:
если сделал криво, то и работать будет криво вылеты и прочая срань...

Блюпринты вылетают в винду?

Цитата:

(_-=ZhekA=-_) писал:
На принтах онли можно без проблем делать игры

Кстати. Ты же свою игру доделал?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 12-02-2023 в 14:29:

Цитата:

Дядя Миша писал:
Но у меня не предусмотрена компиляция в С++.

Ну, и не имел ввиду прям копию делать, а чтобы принцип был, как а анриле примерно, но использовался твой язык )

Цитата:

Дядя Миша писал:
Блюпринты вылетают в винду?

Да, могут, например, если сделать бесконечный цикл или еще, как-нибудь накосячить тебе в редакторе выскочит ошибка, но если собрать проект, то будет вылет )

Цитата:

Дядя Миша писал:
Кстати. Ты же свою игру доделал?

Да, делал, она пока стоит на паузе, но я сделал две разные проги конфигураторов на анриле на принтах

Отправлено FiEctro 12-02-2023 в 14:38:

Цитата:

Дядя Миша писал:
Ну я имею в виду - на уровне пользователя. Допустим ты там захотел кое-что сохранить. Ты создаёшь еще один какой-то объект, или может глобальную переменную или выделяешь память?

Да просто переменную глобальную создаешь и записываешь в неё. Ничего выделять не надо, да и зачем этот гемор с регулярным выделением и очисткой памяти? Это же ВМ.

Цитата:

Дядя Миша писал:
Я спрашивал про конкретный пример такой необходимости. Что это за игра со стеком объектом из 100х100х100? Ну явно не майнкрафт, там объектов на порядок больше. С другой стороны - маловероятно, чтобы на типичном игровом движке можно было бы сделать майнкрафт, он на такое не рассчитан.

Есть 2д игруха, Factorio например, там уже реально объекты со своими свойствами, и с каждым может взаимодействовать игрок.

Цитата:

Дядя Миша писал:
Нет, подожди. Мы говорили про объекты. С чего ты вдруг перескочил на геометрию?

Это предупреждая твой вопрос, зачем делать всё объектами

Цитата:

Дядя Миша писал:
Даже простой перебор массива из миллиарда элементов, это ОЧЕНЬ-ОЧЕНЬ долго. Вот это:

Так я о чём, и когда у тебя миллиард объектов это ещё очевидно, а если в течении игры у тебя там что то регулярно накапливается, как это отлаживать? Вот почему мониторинг удобен.

Цитата:

Дядя Миша писал:
Ну нет. Игровой объект - это сугубая конкретика, которую мы частично может представить абстракцией. То есть func_button можно выполнять роль двери, а не только кнопки. А Monster_barney - необязательно имеет модельку barney, это в принципе может быть любой дружественный персонаж. Если мы не хотим писать для него отдельный класс, а хотим заменить только его наборы реплик и модельку. Теоретически это вообще может быть monster_generic, у которого настраивается абсолютно всё.
Но практика показала что это дико неудобно дизайнеру. Когда у него громадный лист из monster_generic и вообще непонятно какой из них кто.

То что ты перечисляешь не объекты, а классы. Объекты их наследуют. Даже в хаммере объекты могут существовать без контекста, как пустышка.

Цитата:

Дядя Миша писал:
И в итоге нормально не отыграет ни одну.

Отыграет, вращение монстров для юнити ерунда, а вот по Кармаку тебе бы пришлось плодить дополнительное свойство у монстра.

Цитата:

Дядя Миша писал:
там очень примитивные и глючные объекты - те, которые делали сами разработчики.

Как раз объекты созданные разработчиками очень стабильные.

Отправлено Дядя Миша 12-02-2023 в 15:46:

Цитата:

(_-=ZhekA=-_) писал:
а чтобы принцип был, как а анриле примерно, но использовался твой язык )

Ну если в качестве блюпринтов представить разные логические объекты, то да, наверное что-то такое можно попробовать сделать.

Цитата:

(_-=ZhekA=-_) писал:
но если собрать проект, то будет вылет )

Оно при сборке вероятно автоматически компилится в С++.

Добавлено 12-02-2023 в 18:46:

Цитата:

FiEctro писал:
Да просто переменную глобальную создаешь и записываешь в неё. Ничего выделять не надо, да и зачем этот гемор с регулярным выделением и очисткой памяти?

Так у памяти тоже есть время жизни. Сквозь всю игру, или только на этом уровне. Или пока жив конкретный объект.

Цитата:

FiEctro писал:
Есть 2д игруха, Factorio например, там уже реально объекты со своими свойствами

В 2D игрухе - трёхмерный стек? Ты явно чего-то недоговариваешь

Цитата:

FiEctro писал:
а если в течении игры у тебя там что то регулярно накапливается, как это отлаживать?

Но объекты не могут накапливаться "просто так". Если мы перешли на новый уровень, то старые объекты все удалились, а новые создались. Исключение составляют только глобальные объекты. Но они не накапливаются и не удаляются. Создаются один раз в начале игры и всё.

Цитата:

FiEctro писал:
То что ты перечисляешь не объекты, а классы. Объекты их наследуют

Похоже ты смешал воедино игровые объекты и классы С++.

Цитата:

FiEctro писал:
Даже в хаммере объекты могут существовать без контекста, как пустышка.

Приведи пример объекта без контекста.

Цитата:

FiEctro писал:
Отыграет, вращение монстров для юнити ерунда, а вот по Кармаку тебе бы пришлось плодить дополнительное свойство у монстра.

В Ксаш-моде привязать монстра к ротатабле совсем несложно. И будет вращающийся монстр. Только он не должен покидать пределы ротатабли, иначе это будет глупо выглядеть. С другой стороны - есть же стационарные монстры, типо того же Чтона.

Цитата:

FiEctro писал:
Как раз объекты созданные разработчиками очень стабильные.

Ну вообще-то я имел в виду инди-девелоперов. Но и авторы Юнити тоже знаешь ли лажают. Физику мешка с гамном напомнить? Тут был чисто человеческий фактор. Они её написали за пять минут просто для примера. И НИКТО НЕ СТАЛ ЕЁ ПЕРЕДЕЛЫВАТЬ. Во первых из-за стереотипа, что авторы ошибиться не могут, а во вторых, физику всё равно никто писать не умеет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 12-02-2023 в 16:07:

Цитата:

Дядя Миша писал:
Ну если в качестве блюпринтов представить разные логические объекты, то да, наверное что-то такое можно попробовать сделать.

Но, только, чтобы на этих принтах можно было сделать полностью любую игру )

Цитата:

Дядя Миша писал:
Оно при сборке вероятно автоматически компилится в С++.

Мне не особо важно, как оно там устроено\работает, мне важно, что на принтах онли, можно сделать почти все, что угодно и это будет работать )

Отправлено FiEctro 12-02-2023 в 16:19:

Цитата:

Дядя Миша писал:
Ну вообще-то я имел в виду инди-девелоперов. Но и авторы Юнити тоже знаешь ли лажают. Физику мешка с гамном напомнить?

Я не знаю о какой физике мешка с гамном речь, в Юнити обычный PhysX, и использует для физики он все PhysXовские констрейнты как в примерах PhysX. Если ты про плеер контроллеры то на Юнити множество его реализаций, и в большинстве инди проектов над его реализацией особо не заморачиваются, из-за чего управление игроком не очень адекватное в сравнении с другими проектами. Ты можешь и свой плеер контроллер написать к примеру.

Цитата:

Дядя Миша писал:
В Ксаш-моде привязать монстра к ротатабле совсем несложно. И будет вращающийся монстр. Только он не должен покидать пределы ротатабли, иначе это будет глупо выглядеть. С другой стороны - есть же стационарные монстры, типо того же Чтона.

Это просто парент, а я говорю о наследовании свойств объектом из разных скриптов. Это как в ООП.

Цитата:

Дядя Миша писал:
Приведи пример объекта без контекста.

Point entity. Просто точка без свойств.

Цитата:

Дядя Миша писал:
Похоже ты смешал воедино игровые объекты и классы С++.

В том и дело, что все скрипты Юнити это классы, иницилизация которых происходит с иницилизацией объекта к которому они привязаны.

Цитата:

Дядя Миша писал:
Так у памяти тоже есть время жизни. Сквозь всю игру, или только на этом уровне. Или пока жив конкретный объект.

Пока жив объект да. Но можно его вынести в Don't destroy и тогда он станет глобальным.

Цитата:

Дядя Миша писал:
Но объекты не могут накапливаться "просто так". Если мы перешли на новый уровень, то старые объекты все удалились, а новые создались. Исключение составляют только глобальные объекты. Но они не накапливаются и не удаляются. Создаются один раз в начале игры и всё.

В юнити объекты не привязаны к конкретной сцене, ты можешь например упаковать объект в префаб, а потом делать его инстанс его по всей игре как тебе вздумается.

Отправлено Дядя Миша 12-02-2023 в 19:01:

Цитата:

(_-=ZhekA=-_) писал:
Но, только, чтобы на этих принтах можно было сделать полностью любую игру )

Полностью любая игра - это далеко не только движок.

Цитата:

FiEctro писал:
Я не знаю о какой физике мешка с гамном речь

Я обозревал игры Носкова, ты читал эти обзоры. Вот там физика мешка с гамном. Как впоследствии выяснилось - это дефолтная физика игрока в четвертом Юнити, автор игры тут непричём. Как выяснилось дополнительно - пример этой физики был написан разработчиками Юнити на коленке буквально в последний момент и в надежде что никто его не будет использовать в играх, а напишет свою и нормальную физику. И конечно-конечно-конечно же, эта физика стала визитной карточкой четвертого Юнити.

Цитата:

FiEctro писал:
в Юнити обычный PhysX, и использует для физики он все PhysXовские констрейнты

PhysX симулирует твёрдые тела, жидкости, надувных коров и рвущиеся тряпки. Симулировать поведение игрока из коробки он очевидно не может, равно как и любой другой физический движок. Потому что во всех играх физика игрока отличается и привязана к жанру. Поэтому разработчики Юнити по быстрому что-то там сделали на Шарпе весьма неоптимальное, просто для примера. И это попало в кучу игр.

Цитата:

FiEctro писал:
Ты можешь и свой плеер контроллер написать к примеру.

Абсолютно любой человек может прийти к успеху и стать миллиардером. Или известным учёным и получить Нобелевку. Или же первым человеком на Марсе. Абсолютно любой, да.

Цитата:

FiEctro писал:
а я говорю о наследовании свойств объектом из разных скриптов

Ну как правило от подобного наследования нет особого смысла. Т.к. все необходимое достигается простым склеиванием объектов через парент-систему. Это как в математике. Если у тебя есть два объекта A и B, то их сложение даст объект AB, но не C.

Цитата:

FiEctro писал:
Point entity. Просто точка без свойств.

Да, ты действительно так и не разобрался в HL SDK.

Цитата:

FiEctro писал:
В том и дело, что все скрипты Юнити это классы, иницилизация которых происходит с иницилизацией объекта к которому они привязаны.

Что ты называешь скриптами? СиШарп?

Цитата:

FiEctro писал:
В юнити объекты не привязаны к конкретной сцене

Ну это неправильно. Это ошибочное решение, но зато для разработчиков Юнити такое сделать намного проще. А голова болеть будет уже у индюков. Потому что абсолютно любую игру можно разбить на уровни, т.е. дискретизировать её. И разработчик игры будет точно знать - мы вышли с уровня, все объекты удалились, сохранилось только то что мы сами захотели - например достижения.
Ну и дальше у нас выбор - либо грузить следующий уровень, либо показать игроку финальные титры.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-02-2023 в 19:37:

Цитата:

Дядя Миша писал:
Я обозревал игры Носкова, ты читал эти обзоры. Вот там физика мешка с гамном. Как впоследствии выяснилось - это дефолтная физика игрока в четвертом Юнити, автор игры тут непричём. Как выяснилось дополнительно - пример этой физики был написан разработчиками Юнити на коленке буквально в последний момент и в надежде что никто его не будет использовать в играх, а напишет свою и нормальную физику. И конечно-конечно-конечно же, эта физика стала визитной карточкой четвертого Юнити.

Четвертая версия Юнити это очень древняя версия. Возможно тогда физика и правда была какая то другая, я хз - не юзал.

Цитата:

Дядя Миша писал:
PhysX симулирует твёрдые тела, жидкости, надувных коров и рвущиеся тряпки. Симулировать поведение игрока из коробки он очевидно не может, равно как и любой другой физический движок. Потому что во всех играх физика игрока отличается и привязана к жанру. Поэтому разработчики Юнити по быстрому что-то там сделали на Шарпе весьма неоптимальное, просто для примера. И это попало в кучу игр.

Ну вот ты и ответил почему в Юнити оно так, а никак иначе. Движок ни к какому жанру не привязан. Но к слову написание плеер контролера с нуля вообще задача очень нетривиальная, и может быть реализована несколькими способами в зависимости насколько ты хочешь заморочиться. Я помню собирал одну карту с холмистой местностью для ксаша, так я там даже на ровном месте запинался, а иногда и проваливался вниз, ну я же не пишу теперь при каждом поводе что в ксаше физика плохая? Хорошая там физика, просто на такие вещи не предназначена.

Цитата:

Дядя Миша писал:
Абсолютно любой человек может прийти к успеху и стать миллиардером. Или известным учёным и получить Нобелевку. Или же первым человеком на Марсе. Абсолютно любой, да.

Да ладно, ты вон предлагал вообще моделерам писать плагины для их 3д пакетов сОмостоятельно

Цитата:

Дядя Миша писал:
Ну как правило от подобного наследования нет особого смысла. Т.к. все необходимое достигается простым склеиванием объектов через парент-систему. Это как в математике. Если у тебя есть два объекта A и B, то их сложение даст объект AB, но не C.

Парент система передаёт координаты, больше ничего. Ты просто сделаешь больше объектов и более нестабильную физику таким подходом. Сам подумай, зачем тебе для например ротатабли хранить две координаты XYZ и два значения угла по XYZW в глобальном и локальном пространстве? Хотя и в Юнити тоже иногда так делают.

Цитата:

Дядя Миша писал:
Да, ты действительно так и не разобрался в HL SDK.

Да, ты действительно так и не разобрался что такое объект

Цитата:

Дядя Миша писал:
Что ты называешь скриптами? СиШарп?

Файл скрипта с СиШарп кодом внутри, который подключается как компонент объекта.

Цитата:

Дядя Миша писал:
Ну это неправильно. Это ошибочное решение, но зато для разработчиков Юнити такое сделать намного проще. А голова болеть будет уже у индюков. Потому что абсолютно любую игру можно разбить на уровни, т.е. дискретизировать её. И разработчик игры будет точно знать - мы вышли с уровня, все объекты удалились, сохранилось только то что мы сами захотели - например достижения.
Ну и дальше у нас выбор - либо грузить следующий уровень, либо показать игроку финальные титры.

Да собственно реализация может быть любой. Вопрос только насколько это удобно будет работать.

Отправлено Дядя Миша 12-02-2023 в 20:12:

Цитата:

FiEctro писал:
Четвертая версия Юнити это очень древняя версия.

Ну сейчас-то какая актуальная? Пятая?

Цитата:

FiEctro писал:
Движок ни к какому жанру не привязан

Это не так. Если движок вообще не привязан ни к какому жанру, он будет одинаково плохо работать во всех. Что мы, собственно и наблюдаем.
Но в дальнейшем его могут начать затачивать под тот сектор, в котором он наиболее востребован. А в голове остаётся стереотип с прошлых версий, якобы движок годится для всего.

Цитата:

FiEctro писал:
Я помню собирал одну карту с холмистой местностью для ксаша, так я там даже на ровном месте запинался, а иногда и проваливался вниз, ну я же не пишу теперь при каждом поводе что в ксаше физика плохая?

Ты так и не понял к чему я привёл тот пример с игроком. Ну ладно, может потом поймешь.

Цитата:

FiEctro писал:
Да ладно, ты вон предлагал вообще моделерам писать плагины для их 3д пакетов сОмостоятельно

Нёмыч таки написал.

Цитата:

FiEctro писал:
Парент система передаёт координаты, больше ничего

Так по сути единственное, что и требуется в игровой ситуации. Вот у тебя есть объект дверь и объект стекло. Ты их соединил парентом и получилась дверь со стеклом. Если же ты их унаследуешь, у тебя получится стекло со свойствами двери и дверь со свойствами стекла? Но наследование для такого избыточно.

Цитата:

FiEctro писал:
Да, ты действительно так и не разобрался что такое объект

Я понимаю, что сказать что-то хочется, но по существу нечего. Объект это безразмерный термин, куда каждый вкладывает что-то своё.

Цитата:

FiEctro писал:
Вопрос только насколько это удобно будет работать.

Это да.

Добавлено 12-02-2023 в 23:12:

Цитата:

Дядя Миша писал:
Ты их соединил парентом и получилась дверь со стеклом. Если же ты их унаследуешь, у тебя получится стекло со свойствами двери и дверь со свойствами стекла? Но наследование для такого избыточно.

Я поясню почему наследование в игровых объектах, как правило не приводит к желаемому. В объектно-ориентированном языке все объекты - суть абстракция, над которой не властны физические законы. В играх объекты зажаты в жесткие рамки - их данные передаются по сети, их визуальная часть как правило не имеет обратной связи с физической и масса других мелочей, которые как правило ломают всю концепцию наследования.
Поэтому остаётся только физическая связка в трёхмерном пространстве, которая ничего не ломает и не нарушает. И всегда даёт тот результат, который ты ожидал.
А наследование таковых объектов приводит к появлению котоламповых историй на башорге, как в игре про вторую мировую свиней делали из фашистов и у свиней даже был пистолет, который они периодически пытались достать. Или поезда из персонажей в DLC фаллаута.
Оно когда в коде скрыто никто не задумывается что там происходит.
А когда его пытаются в визуальных объектах применить, обычно вот такое и происходит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-02-2023 в 22:08:

Цитата:

Дядя Миша писал:
Ну сейчас-то какая актуальная? Пятая?

Версии с 2018 по текущий год. К слову народ пытался писать свои QLike и HLLike контроллеры, но сделать что то особо похожее у них не вышло, впрочем мне не показалось что физика у них совсем уж плохая, но доработать бы не помешало.

Цитата:

Дядя Миша писал:
Это не так. Если движок вообще не привязан ни к какому жанру, он будет одинаково плохо работать во всех. Что мы, собственно и наблюдаем.
Но в дальнейшем его могут начать затачивать под тот сектор, в котором он наиболее востребован. А в голове остаётся стереотип с прошлых версий, якобы движок годится для всего.

Это ничем не обоснованное утверждение. Первокваку вон под гонки не затачивали, однако же на ней их делали.

Цитата:

Дядя Миша писал:
Так по сути единственное, что и требуется в игровой ситуации. Вот у тебя есть объект дверь и объект стекло. Ты их соединил парентом и получилась дверь со стеклом. Если же ты их унаследуешь, у тебя получится стекло со свойствами двери и дверь со свойствами стекла? Но наследование для такого избыточно.

Стеклу вообще не нужен никакой объект, ему нужен материал с шейдером. Но если стекло например разбивается, конечно дверь не нужно тоже разбивать, и тут действительно нужно привязать парентом. Но вот представь что у тебя на двери например просто триггер при касании с которым эта дверь открывается, нужно ли этому триггеру создавать и аттачить дополнительный объект? В целом оба варианта допустимы, но однако.

Цитата:

Дядя Миша писал:
Поэтому остаётся только физическая связка в трёхмерном пространстве, которая ничего не ломает и не нарушает. И всегда даёт тот результат, который ты ожидал.
А наследование таковых объектов приводит к появлению котоламповых историй на башорге, как в игре про вторую мировую свиней делали из фашистов и у свиней даже был пистолет, который они периодически пытались достать. Или поезда из персонажей в DLC фаллаута.
Оно когда в коде скрыто никто не задумывается что там происходит.

Так, а что в этом плохого? В халфе вроде тоже монстры много чего наследуют.
Если это помогает сократить время на разработку, то это безусловный плюс, а то что хряк пытается достать пистолет которого у него нет, так я думаю ты бы и не заметил, если бы это кто то не написал. Тут скорее проблема не наследования, а уровня этого наследования. Нужно было нпцшкам сделать базовый класс и уже наследовать от него, а не друг от друга.

Добавлено 13-02-2023 в 01:08:

Цитата:

Дядя Миша писал:
Это да.

К слову в Юнити есть ещё Асинхронная загрузка локаций, типа безшовных уровней аля ДаркСоулс.

Отправлено (_-=ZhekA=-_) 13-02-2023 в 05:15:

Цитата:

Дядя Миша писал:
Полностью любая игра - это далеко не только движок.

У тогда, игр типа метро, сталкер, фолаут 4

Отправлено Дядя Миша 13-02-2023 в 06:39:

Цитата:

FiEctro писал:
но сделать что то особо похожее у них не вышло

Ну естественно не вышло. Любой современный физ.движок работает с полигональной коллизией, а халфо-квейковская больше ориентируется на пробы в солидах, которых там попросту нет. Переписать этот момент корректно - довольно нетривиальная задача, вот никто и не справился.

Цитата:

FiEctro писал:
Первокваку вон под гонки не затачивали, однако же на ней их делали.

Я в первую очередь имею в виду, сколько игроков может быть в онлайне одновременно. От этого целиком зависит клиент-серверная архитектура.
А в гонках ну 5-10 машин атсилы.

Цитата:

FiEctro писал:
Но вот представь что у тебя на двери например просто триггер при касании с которым эта дверь открывается

Если дверь просто стоит на земле, то и триггер ни к чему не привязан. Если дверь - часть поезда, триггер привязан к поезду. Логично и наглядно.
Конечно можно унаследоваться от двери и триггера одновременно, но какой смысл? Триггер - посылает сигнал, дверь - открывается. Таким образом унаследование приведёт к тому, что дверь будет открываться и посылать сигнал. Наследование не приводит волшебным образом к тем свойствам, которые ты имел в виду. Вот что я хочу сказать.

Цитата:

FiEctro писал:
В халфе вроде тоже монстры много чего наследуют.

Ну не двери же.

Цитата:

(_-=ZhekA=-_) писал:
У тогда, игр типа метро, сталкер, фолаут 4

Под этот жанр движок и делается, да.

Добавлено 13-02-2023 в 09:39:

Кстати. Как в Унреалах\Юнитях дела обстоят с давилками?
Ну в смысле дверь - не просто дверь, а именно пресс, который всё сдвигает и давит, как в кваке. Или на котором можно стоять и он тебя корректно подымает и опускает. И даже камера не дёргается. Или там все ротатабли надо писать самостоятельно и если не получилось - сам дурак, короткую юбку надел?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-02-2023 в 11:00:

Цитата:

Дядя Миша писал:
Кстати. Как в Унреалах\Юнитях дела обстоят с давилками?
Ну в смысле дверь - не просто дверь, а именно пресс, который всё сдвигает и давит, как в кваке. Или на котором можно стоять и он тебя корректно подымает и опускает. И даже камера не дёргается. Или там все ротатабли надо писать самостоятельно и если не получилось - сам дурак, короткую юбку надел?

Всё аналогично PhysX. Никакой юнитивской физики нет.

Цитата:

Дядя Миша писал:
Я в первую очередь имею в виду, сколько игроков может быть в онлайне одновременно. От этого целиком зависит клиент-серверная архитектура.
А в гонках ну 5-10 машин атсилы.

Это скорее определяется толщиной пакета

Цитата:

Дядя Миша писал:
Если дверь просто стоит на земле, то и триггер ни к чему не привязан. Если дверь - часть поезда, триггер привязан к поезду. Логично и наглядно.
Конечно можно унаследоваться от двери и триггера одновременно, но какой смысл? Триггер - посылает сигнал, дверь - открывается. Таким образом унаследование приведёт к тому, что дверь будет открываться и посылать сигнал. Наследование не приводит волшебным образом к тем свойствам, которые ты имел в виду. Вот что я хочу сказать.

Я просто не вижу смысла зачем городить огород из кучи объектов, когда можно задать всё одному? Но как ты описал в Юнити тоже можно делать.

Цитата:

Дядя Миша писал:
Ну не двери же.

Помню был ролик где в хл2 барнакл жрал страйдеров и верталёты.

Отправлено (_-=ZhekA=-_) 13-02-2023 в 11:30:

Цитата:

Дядя Миша писал:
И даже камера не дёргается.

Я как-то давно в уе4 делал лифт на несколько этажей на принтах и вроде норм все работало ) на уе5 я хз еще не пробовал, но думаю, что будет также норм )
В анриле с этим все просто. Ты создаешь актор в него добавляешь нужную тебе модель и в этом же акторе или в другом месте пишешь код, как и куда эта модель должна двигаться так же есть ООП )

Отправлено Дядя Миша 13-02-2023 в 12:47:

Цитата:

FiEctro писал:
Это скорее определяется толщиной пакета

Я смотрю ты взял на вооружение пагубную американскую идею, если что-то не получается - надо удвоить усилия, сжечь все ресурсы до тех пор пока не получится. А если всё равно не получилось - сделать вид, что так и было задумано.

Цитата:

FiEctro писал:
Я просто не вижу смысла зачем городить огород из кучи объектов, когда можно задать всё одному?

Это анти-паттерн, супер-класс называется.

Цитата:

(_-=ZhekA=-_) писал:
Я как-то давно в уе4 делал лифт на несколько этажей на принтах и вроде норм все работало

В UE с этим проблем никогда и не было.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 07-03-2023 в 16:16:

Ну чтож, наконец-то добрался до портирования кода монстров.
Это можно сказать вообще моё первое болимение углублённое изучение их кода. Никогда до этого я монстрами не интерисовался и вообще не знаю, что они там вытворяют. Ну а сейчас, поскольку портирую, придётся поизучать.
Это к слову ни в коем случае не означает, что в XashNT будет именно халфовский AI. Я портирую халфовскую (точнее ксаш-модовскую) библиотеку по ряду причин:

1. выстроить интерактивное взаимодействие между движком и скриптовой частью.
2. отладить это взаимодействие на реально существующих уровнях
3. дать вам портированный ксаш-мод, чтобы вы могли спокойно продолжать работу на новом движке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 08-03-2023 в 20:24:

Решил в целях расширения кругозора ознакомиться с работой AI (точнее поиска пути) в различных движках. Ну сперва взял сталкера. Там жеж типо искуственная жизнь, интересно. Начал разбираться как всё устроено. Вообщем есть некие ноды. Между нодами есть некие связи. Причём эти ноды загружаются из редактора. Пошёл читать ликбез по сталкеру. А там вот эта картинка...

Аппроксимация навмеша при помощи точек. Я конечно хз, как эта сетка генерится, судя по всему - автоматически. Не могу представить, чтобы кто-то в здравом уме вот такое вручную расставлял да ещё с такой плотностью.
Однако нанести сетку на ландшафт - много ума не надо. А как насчёт извилистых коридоров? К тому же сетка на полу никак не поможем ориентироваться летающим и водоплавающим монстрам. Она годится только для сухопутных. Что особенно интересно - эта сетка потом ещё дополнительно проверятся на reacahbility. Т.е. доверия к тому что расставили - мало.

Добавлено 08-03-2023 в 19:57:

Да, чуть не забыл самое главное. В этой сетке если присмотреться к картинке не всегда четыре направления. Иногда их три. Таким образом обозначаются препятствия. Также в структуре каждой ноды имеются ограничивающие плоскости, но я пока не разобрался для чего они нужны.

Добавлено 08-03-2023 в 19:59:

Впрочем нет, гоню. Плоскость там одна - обозначает уровень наклона пола.

Добавлено 08-03-2023 в 23:24:

Более подробно расписано тут:
https://www.amk-team.ru/forum/topic...aktika-oshibki/
Чёт у меня волосы на голове от ужаса зашевелились. На гигантской карте визуально вручную контролировать, чтобы все ноды корректно соединились, иначе наградой будет вылет компилятора, расставлять\удалять невидимые стены, чтобы предотвратить расползание сетки (аналог замкнутого пространства в кваке), и вишенкой на торте - надо поставить на карту хотя бы один нод перед генерацией иначе вылет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 09-03-2023 в 09:18:

Это не сильно от навмеша отличается, только зачем так объектами спамить?

Отправлено Дядя Миша 09-03-2023 в 11:22:

Я не знаю откуда берутся навмешы. Может из исходной геометрии, а может их руками расставлять надо. А может сперва из исходной, а потом руками исправлять. Но видимо с точками проще управляться, чем с мешем.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-03-2023 в 07:21:

Дядя Миша
А в ку3 как?

Отправлено Дядя Миша 13-03-2023 в 09:22:

Вот я же сейчас и хочу сделать как в ку3 и в doom3. Там строится отдельное дерево, которое очень похоже на клипноды, но содержит в себе гораздо больше информации и этой информацией могут пользоваться монстры для навигации.
Минус в том, что оно поддерживает только брашы и патчи, модели не поддерживает. Вот я сейчас как раз добавляю в это дерево модели. Посмотрим что получится. Идея в том, чтобы не расставлять никаких навмешей и нодов.
В крайнем случае - окружить специальным монстерклипом некоторые конструкции. Но в норме монстры должны нормально взаимодействовать с моделями. Если скажем модель - это дом. В доме есть подвал и туда ведёт лестница. Нам достаточно приложить к лестнице func_ladder (которым сможет пользоваться и игрок тоже) и монстры смогут аналогично заходить в дом, спускаться и подыматься в подвал.

Добавлено 13-03-2023 в 12:22:

В крайнем случае, если моя затея не выгорит, я сгенерирую регулярную сетку из нодов, как это сделано в сталкере, но мне этот путь не очень нравится.
Во первых этих нодов чудовищно много получается, во вторых их зачастую приходится исправлять руками на некоторых границах, в третьих это ноды только для ходьбы по земле, они не учитывают ни воду, ни воздух. В отличие от кутришных.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-03-2023 в 16:31:

Дядя Миша
Так по идее всё что торчит нормалью вверх это простейший навмеш? Ну можно ещё делать отступы от стен у которых нормаль торчит куда то в Vector3.right

Я как раз когда делал скольжение по стенам, заметил что можно так же заставить монстров прожектплайнами огибать препятствия

Отправлено Дядя Миша 13-03-2023 в 19:22:

Цитата:

FiEctro писал:
Так по идее всё что торчит нормалью вверх это простейший навмеш?

да, но толку от такого навмеша не особенного много. Т.к. он не позволяет выполнить поиск пути. Да и вообще точки для поиска пути куда удобнее навмеша. В том же сталкере как сделано? Всё, как ты выразился, что торчит нормалью вверх покрывается сетью навигационных нодов. Они потом линкуются друг с другом, моделлер исправляет ошибки автоматической расстановки и из этого даже что-то получается.

Ну а мы вернёмся к нашим баранам. Итак, попытка втупую просчитать BSP дерево из произвольного меша ожидаемо успешно завершилась неудачей. Ну и неудивительно. Если бы это проходило гладко, все бы по прежнему юзали BSP. В данном случае мы имеем дело с двумя важными допущениями:
1. хулл надутый
2. визуальная форма неважна.

Т.е. часть деталей исчезнет просто по факту надувания хулла, ну а мелкие полигончики, те самые которые и вносят столько проблем в построение BSP из произвольных полигонов, мы без проблем можем аппроксимировать до ориентированного ббокса. В принципе можно и до выровненного по AABB, но ориентированный ббокс всё равно не сильно сложнее построить.

Итак всё что нам надо - это отделить большие крупные полигоны от мелких. Мелкие превратить в ббокс, а крупные скормить анализатору BSP как есть. Хорошо, но вопрос, а как это сделать правильно?
Мы не можем отбраковывать полигоны просто по размеру - в итоге в дерево попадёт какой-то мусор. Конечно игроку с таким деревом не коллидить, а монстр будет просто избегать подобных мест, но это в любом случае не выход. Надо отметить что любые симплификаторы как правило используют очень сложные избыточные эвристики, которые зачастую по времени занимают еще дольше, чем собственно построение дерева.
Нам это тоже не подходит. Но есть еще одно допущение:
- Никто в здравом уме не соединяет детальные полигоны с основной геометрией. Обычно детальную геометрию накладывают поверх базовой.
А значит - у них нет общего шва. Вот и ответ на вопрос. Подобно тому как мы находим шареные полигоны для наложения лайтмапы по совпадающим текстурным координатам, мы можем разобрать меш любой сложности по общим швам. Ну а дальше в дело вступает очень простая эвристика:
1. если группа меньше чем размер клипхулла - просто превращаем в единичный ббокс.
2. если группа больше - смотрим средний, минимальный и максимальный размер площади полигона в группе. Так же делаем выводы относительно её конвексности.
Ну и по совокупности решаем, как с ней поступить и во что превратить.
Самое сложное, как и в случае с наложением лайтмапы - это конечно жы деревья. Как с ними поступать я пока что не придумал. Тут нужна декомпозиция на несколько ббоксов, ну да посмотрим. Так сказать, в процессе имплементации.
Не переключайтесь. У меня уже есть положительные результаты, но я пока не тороплюсь их показывать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-03-2023 в 19:29:

Цитата:

Дядя Миша писал:
- Никто в здравом уме не соединяет детальные полигоны с основной геометрией. Обычно детальную геометрию накладывают поверх базовой.

Мне не нравится это допущение. Для герметизации структурной геометрии в ней могут быть довольно мелкие полигоны.

Отправлено Дядя Миша 13-03-2023 в 20:13:

Цитата:

nemyax писал:
Для герметизации структурной геометрии в ней могут быть довольно мелкие полигоны.

Ну и пусть. Главное что они пошарены с крупными по вертексам.
А вот когда группа вся состоит из мелких полигонов - это однозначно детальный сабмеш.

Добавлено 13-03-2023 в 23:13:

Хорошо, другими словами скажу. Когда мы на плоский браш накладываем маленький детальный - CSG разбивает большой браш на месте соприкосновения с детальным. В моделировании никто подобными вещами не занимается и слава богу. То есть мы можем принять это допущение как абсолютное.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-03-2023 в 20:29:

В халфе были инфо_ноды, как они работают? Может их банально просто автоматически расставлять?

Отправлено Дядя Миша 13-03-2023 в 20:33:

Цитата:

FiEctro писал:
В халфе были инфо_ноды, как они работают?

Грубо говоря - патч_корнеры, которые автоматически находят своих соседей. Ну оно конечно сложнее устроено, но для начального понимания, достаточно и этой информации. К тому же монстры зачастую от этих связей не отходят и бегают по ним как по рельсам.

Добавлено 13-03-2023 в 23:33:

Цитата:

FiEctro писал:
Может их банально просто автоматически расставлять?

Автоматически можно расставить только регулярную сетку. А халфовские ноды, даже живые люди толком расставлять не умеют. Это надо каким-то чудом детектировать повороты за угол, дверные проёмы, нуитд.
И всё равно оно нормально работать не будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 15-03-2023 в 06:25:

Создал новый бинарный формат для хранения исходников с расширением - usm. Это тоже мета-контейнер, который может хранить в себе любой тип данных - например уровни, модели со скелетом, анимации или просто статичные мешы. Меняются только содержимое секций, их имена и кол-во.
Детектирование того или инго формата происходит по трафарету необходимого набора секций. Так же возможно мутирующее определение, когда целый уровень детектируется просто как статичный меш.
Единственный момент, с которым я пока что не определился - вероятно пары ключ-значение стоит иметь рядом в отдельном текстовом файлике, чтобы можно было их оперативно отредактировать из блокнота, как это мы делаем порой с обычным форматом map. Просто для удобства. Но возможно это и не понадобится.
Расширение формата пока не окончательное, могу выслушать ваши предложения. USM - Uniform Source Mesh.

Добавлено 15-03-2023 в 09:25:

Да, пока не забыл. Тем кто внимательно следит за ходом разработки, наверняка известно, что в XashNT уже был такой промежуточный формат под названием CSM. Он никуда не делся, но формат уже залочен и дальше меняться не будет. Скорее всего я выложу его спеки, чтобы вы могли его активно использовать в своих проектах. Это очень удобный и хороший формат для хранения статических мешей, который включает в себя абсолютно всё необходимое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 15-03-2023 в 06:45:

Цитата:

Дядя Миша писал:
Это очень удобный и хороший формат для хранения статических мешей, который включает в себя абсолютно всё необходимое.

А смысл, когда для статичных мешей есть .obj? Да и зачем вообще отдельный формат для статичных мешей?

Цитата:

Дядя Миша писал:
могу выслушать ваши предложения

Напиши мини утилиту для конвертации в твой формат из популярных форматов, возми ту либу что я скидывал. Это намного упростит жизнь, чем для каждого пакета писать конвертёр для ноунеймовских форматов, и мучиться со всякими говно smd плагинами.

Цитата:

Дядя Миша писал:
Это тоже мета-контейнер, который может хранить в себе любой тип данных - например уровни, модели со скелетом, анимации или просто статичные мешы.

Шейпкеев не будет?

Отправлено Дядя Миша 15-03-2023 в 07:33:

Цитата:

FiEctro писал:
А смысл, когда для статичных мешей есть .obj?

obj текстовый формат, он занимает чудовищно много места для больших мешей, к тому же не в состоянии хранить развертку лайтмапы. Единственный формат, который потенциально способен хранить развертку лайтмапы, это ASE, но он тоже текстовый и там непонятно в какой ориентации хранится модель. Всё это очень неудобно. Я уже наподкидывался с этим зоопарком.

Цитата:

FiEctro писал:
Шейпкеев не будет?

Говорю же мета-контейнер. Туда в дальнейшем можно будет добавлять всё что угодно, не нарушая совместимости. Причём как прямой, так и обратной.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 15-03-2023 в 08:42:

Цитата:

Дядя Миша писал:
Всё это очень неудобно. Я уже наподкидывался с этим зоопарком.

Это верно, потому и выжили лишь только несколько популярных форматов. Всё остальное народ бросил на помойку. Но нужно тоже понимать что формат не может существовать отдельно от 3д пакетов.

Цитата:

Дядя Миша писал:
Туда в дальнейшем можно будет добавлять всё что угодно, не нарушая совместимости.

Даже БСП?

Отправлено nemyax 15-03-2023 в 08:46:

FiEctro
БСП вриатле можно отнести к категории source mesh.

Отправлено Дядя Миша 15-03-2023 в 09:17:

Цитата:

FiEctro писал:
Даже БСП?

и BSP и MDL и SPR будут хранится в точно таких же контейнерах.
Разница будет только в именах секций и четёрых байтовом идентификаторе в самом начале файла. Опять же идентификатор в данном случае становится просто подсказкой, которая ни к чему не обязывает, поскольку структура секций с ним никак не связана. Это беззаголовочный формат, с устойчивостью к повреждению отдельных секций. Я довольно долго над ним размышлял, прежде чем сделать. Попытался искоренить все недостатки известных мне форматов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ZGreen 15-03-2023 в 09:34:

Это что выходит, все ресурсы будут с одинаковыми расширениями? Тогда может уж вовсе без расширения пусть лежат, одинаково удобно\неудобно.

Отправлено Дядя Миша 15-03-2023 в 10:20:

Почему с одинаковыми? У них так же и останутся расширения .bsp, .mdl, .spr, и прочие.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 15-03-2023 в 10:52:

Зачем спрайтам собственное расширение? Это же просто материал.

Отправлено ZGreen 15-03-2023 в 13:35:

Цитата:

Дядя Миша писал:
У них так же и останутся расширения

Фуф, привидится же.

А в чем преимущество такого контейнера перед обычными бинарными файлами с заголовком?

Отправлено Дядя Миша 15-03-2023 в 14:34:

Цитата:

FiEctro писал:
Зачем спрайтам собственное расширение? Это же просто материал.

Это не просто материал. Во первых спрайты содержат геометрию. Т.е. в теории в качестве спрайта может выступать очень простенькая объемная модель. Или кустик с травкой. Ну что-такое вообщем. В терминологии XashNT это тоже канает за спрайт. Ну а в какую категорию отнести подобные мелочи? Это не модель в полноценном понимании этого слова, т.к. у нее нет никакой анимации. Это не статичная модель, т.к. статичные модели уже намертво вкомпилены в сцену. Это не динамичная полноценная модель, т.к. у нее и коллизии-то нету. Так что спрайт. К тому же я помню у Хумуса была такая обрезалка геометрии спрайтов в точности по размеру видимой текстуры, чтобы избежать оверфиллинга. Вот на моём формате спрайтов это вполне возможная вещь. Так что нет, ты неправ, спрайт - это не просто материал.

Цитата:

ZGreen писал:
А в чем преимущество такого контейнера перед обычными бинарными файлами с заголовком?

Главное преимущество в том, что этот формат специально создавался для лёгкого сохранения прямой и обратной совместимости. Невозможно учесть всё что понадобится в будущем, вероятно что-то будет меняться. Так вот формат изначально устроен таким образом чтобы одновременно содержать в себе старые и новые данные и автоматически выбирать нужное. Или же просто игнорировать новые данные. Всё это конечно делается и без хитрых форматов, но зачастую никакой обратной совместимости не гарантирует. Здесь я это заложил в архитектуру, чтобы избежать проблем в дальнейшем.
Можете посмотреть какой зоопарк версий уровней и моделей был у того же сорса. Да и в Юнитях вроде при смене версии тоже всё меняется.

Добавлено 15-03-2023 в 17:34:

ZGreen
Да ты бы скачал демку штоле. Ты же можышь.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 15-03-2023 в 14:38:

Цитата:

Дядя Миша писал:
Это не просто материал. Во первых спрайты содержат геометрию. Т.е. в теории в качестве спрайта может выступать очень простенькая объемная модель. Или кустик с травкой. Ну что-такое вообщем. В терминологии XashNT это тоже канает за спрайт. Ну а в какую категорию отнести подобные мелочи? Это не модель в полноценном понимании этого слова, т.к. у нее нет никакой анимации. Это не статичная модель, т.к. статичные модели уже намертво вкомпилены в сцену. Это не динамичная полноценная модель, т.к. у нее и коллизии-то нету. Так что спрайт. К тому же я помню у Хумуса была такая обрезалка геометрии спрайтов в точности по размеру видимой текстуры, чтобы избежать оверфиллинга. Вот на моём формате спрайтов это вполне возможная вещь. Так что нет, ты неправ, спрайт - это не просто материал.

Все возможности спрайтов описываются шейдером, единственное что может содержать в себе спрайт именно как отдельная сущность это всякие якоря для интерфейса и данные о его нарезке. В основном это всё нужно для работы в 2д.
Геометрия может быть любая, например мы делали спрайты из треугольников, а лишнее обрезали, т.к. это экономия в 2 раза. А ты предлагаешь всё захардкодить. Потом например есть партикли они же то же юзают спрайты, но сама партикля по себе это вовсе и не спрайт.

Цитата:

Дядя Миша писал:
Можете посмотреть какой зоопарк версий уровней и моделей был у того же сорса. Да и в Юнитях вроде при смене версии тоже всё меняется.

В Юнитях нативная поддержка форматов популярных 3д пакетов, а так же встроенные утилиты миграции, которые без проблем позволяют конвертировать большинство ресурсов даже из доисторических версий. Но вот код нет, не позволяют, но там легко это поправить. Вся работа с ресурсами в Юнити сведена до уровня работы с файлами в проводнике, без нудного задрачивания команд .qc и дебага недокоментированых ошибок.

Отправлено Дядя Миша 15-03-2023 в 15:16:

Цитата:

FiEctro писал:
В основном это всё нужно для работы в 2д.

Для 2D у меня формат шрифтов, а не спрайтов, очевидно же.

Добавлено 15-03-2023 в 18:16:

Цитата:

FiEctro писал:
В Юнитях нативная поддержка форматов популярных 3д пакетов, а так же встроенные утилиты миграции, которые без проблем позволяют конвертировать большинство ресурсов даже из доисторических версий. Но вот код нет, не позволяют, но там легко это поправить. Вся работа с ресурсами в Юнити сведена до уровня работы с файлами в проводнике, без нудного задрачивания команд .qc и дебага недокоментированых ошибок.

Вот ты ейбогу ведёшь себя как восторженный адепт. Слово в слово повторяешь за Жэкой. Только он хвалит Unreal, а ты Unity. Хотя вас обоих об этом никто не просил, денег вам за это никто не платил и игр ваших так до сих пор никто и не увидел

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 15-03-2023 в 15:26:

Цитата:

Дядя Миша писал:
Для 2D у меня формат шрифтов, а не спрайтов, очевидно же.

А иконки тоже шрифт?

Цитата:

Дядя Миша писал:
Вот ты ейбогу ведёшь себя как восторженный адепт. Слово в слово повторяешь за Жэкой. Только он хвалит Unreal, а ты Unity. Хотя вас обоих об этом никто не просил, денег вам за это никто не платил и игр ваших так до сих пор никто и не увидел

Ну тебя тоже никто не просил обсирать Юнити. Хотя как бы там есть за что его обсирать, но вряд ли ты про это знаешь

Что касаемо денег, я вам с Ксероксом платил, в отличие от того же Юнити. Так это ещё вопрос, кто чей адепт.

Не воспринимай мои слова что я считаю что ты должен и обязан что то делать так. Я просто информирую как это можно сделать по другому, более удобно. И Юнити здесь не при чем. Эта парадигма применяется и в Анриле, и в Годоте, и в Унигине, и Крайтеке, и остальных ААА движках

Отправлено ZGreen 15-03-2023 в 16:59:

Я так полагаю под спрайтом Дядя Миша подразумевает не просто ориентированную картинку как было во времена Голда, а просто декоративный объект без коллизий и т д. это может быть и картинка и моделька и все, на что хватит фантазии. Верно я понимаю?

Цитата:

Дядя Миша писал:
Да ты бы скачал демку штоле. Ты же можышь.

Я могу качать, но не знаю откуда.

Отправлено XaeroX 15-03-2023 в 17:37:

Цитата:

FiEctro писал:
Что касаемо денег, я вам с Ксероксом платил, в отличие от того же Юнити. Так это ещё вопрос, кто чей адепт.

Звучит как жалоба обманутого вкладчика.

Вообще-то я многое для вас сделал, несоразмерно больше, чем размер донатов.
Даже func_rotating в волатиле был сделан специально для тебя, после твоей жалобы, о чём имеется специальный комментарий в исходниках.

__________________

Отправлено ZGreen 15-03-2023 в 17:50:

Дядя Миша, прошу прощения. разул глаза и увидел раздел на форуме. Я просто стал участником невольно, поэтому сразу и не распознал.

Отправлено KiQ 15-03-2023 в 18:00:

Цитата:

Дядя Миша писал:
Это не модель в полноценном понимании этого слова, т.к. у нее нет никакой анимации

Ну чего ж так? Если уж брать пример с кустиком, то там сам б-г велел какую-никакую анимацию покачивания сделать. Ну или уже программно, от силы ветра, например

Цитата:

FiEctro писал:
А иконки тоже шрифт?

Ты таки не поверишь, сейчас плотно занимаюсь веб-разработкой и в среде фронтендщиков весьма популярен шрифт https://fontawesome.ru/ как раз с большим набором иконок. Впрочем, это довольно старая практика, когда стандартные глифы заменяют на нужную графику

__________________
-Brain is dead-

Отправлено nemyax 15-03-2023 в 18:18:

Цитата:

KiQ писал:
Если уж брать пример с кустиком, то там сам б-г велел какую-никакую анимацию покачивания сделать.

Of course, we want our mushroom to move, just like in real life. ©

Отправлено Дядя Миша 15-03-2023 в 18:53:

Цитата:

FiEctro писал:
А иконки тоже шрифт?

Какие иконки?

Цитата:

FiEctro писал:
Эта парадигма применяется и в Анриле, и в Годоте, и в Унигине, и Крайтеке, и остальных ААА движках

Миллионы мух не могут ошибаться?

Цитата:

ZGreen писал:
Я так полагаю под спрайтом Дядя Миша подразумевает не просто ориентированную картинку как было во времена Голда, а просто декоративный объект без коллизий и т д. это может быть и картинка и моделька и все, на что хватит фантазии. Верно я понимаю?

Совершенно верно. Если в шейдере есть деформация относительно углов взгляда игрока, то он будет себя вести как самый настоящий спрайт из халфы\кваки. А если таковой деформации нет, то будет обычный низкополигональный объект без коллизий. Справедливости ради по возможности рендеринга он ничем не уступает например мировой модельке. Т.е. в спрайт можно затолкать целый уровень. Правда смысла в том никакого, но мало ли?

Цитата:

XaeroX писал:
о чём имеется специальный комментарий в исходниках

Но поскольку исходники никто не видел, то и слова твои тоже не проверить.

Цитата:

KiQ писал:
Если уж брать пример с кустиком, то там сам б-г велел какую-никакую анимацию покачивания сделать

А. ну это через шейдер делается без проблем.

Добавлено 15-03-2023 в 21:53:

Ну а я продолжаю заниматься нелёгким, но весьма интересным делом - компиляцией полигональной модели в составе BSP дерева. Сегодня сделал важную оптимизацию - разбил исходную модель по смежным рёбрам на отдельные группы. Мой препроцессор моделей умел это и делать и ранее, однако тогда в его задачи входило лишь построение развертки для лайтмап, поэтому те группы не совпадают с группами, в которых геометрия связана именно по рёбрам. Следующий шаг - маркировка группы по одному из двух признаков. Либо это планарная группа (но в планарной группе может быть дырка, что надо задетектировать отдельно). Либо это конвексная группа (в которой теоретически тоже может быть дырка). Остальное остаётся сгруппированным без явного признака для всей группы (но отдельные сурфейсы могут быть помечены тем или иным образом).
Следующий шаг - генерация брашей из конвексных групп. Тут нас так же подстерегает опасность незакрытых брашей. В самом деле, представьте на полу лежит квадратик плитки, ну стандартная ситуация. А нижнего полигона у него просто нет, т.к. игрок его всё равно не увидит. Поэтому конструктор брашей должен учитывать подобные вещи и оперативно добавлять брашам недостающие стороны. К счастью именно для брашей (в отличие от моделей) сделать подобное исправление - пара пустяков и прекрасно укладывается в простейший алгоритм. В принципе этот механизм в состоянии закрывать все недостающие стороны, даже если у браша каким-то чудом осталась всего одна. Такое случается, например после валидации, когда якобы закрытый браш остаётся невалидным и проблемная сторона удаляется вновь. Но как правило после повторного прохода валидность восстанавливается. Правда с каждым проходом он всё меньше и меньше похож на исходный браш по своей форме и больше напоминает форму своего ббокса, но это некритично, напоминаю, что всё это и затеяно ради колоизации в первую очередь.

Следующий шаг - проверка размера неконвексных групп на размер хулла. И если этот размер заведомо меньше\не сильно больше, то такую группу можно смело превратить в конвексный браш. Идея заключается в том, что для надутого хулла с большей степенью вероятности коллидить с этой группой точно по её полигонам всё равно будет невозможно - т.к. хулл по размерам больше чем все эти полигоны. Так что в конечном итоге без разницы. Ну и наконец оставшиеся полигоны отправятся в дерево и примут участие в его построении.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 15-03-2023 в 19:14:

Цитата:

Дядя Миша писал:
Какие иконки?

Элементы 2д интерфейса и hud

Цитата:

Дядя Миша писал:
Миллионы мух не могут ошибаться?

А где ты миллионы мух видел

Цитата:

XaeroX писал:
Звучит как жалоба обманутого вкладчика.

Так это вы регулярно жалуетесь, что мол я вообще никакого участия не принимал.

Цитата:

XaeroX писал:
Даже func_rotating в волатиле был сделан специально для тебя, после твоей жалобы, о чём имеется специальный комментарий в исходниках.

Хоть на этом спасибо.

Отправлено XaeroX 15-03-2023 в 19:36:

Цитата:

Дядя Миша писал:
Но поскольку исходники никто не видел, то и слова твои тоже не проверить.

Ответил в соседней теме, чтобы не оффтопить.

__________________

Отправлено KiQ 15-03-2023 в 19:51:

Цитата:

Годоте

Мне нравится Годот, но я видимо пропустил момент, когда его причислили к ААА движкам. Как по мне, хоть он и не уступает по возможностям основным игрокам, но всё же продукт достаточно нишевый и направленный в сторону инди-сегмента

Цитата:

Дядя Миша писал:
А. ну это через шейдер делается без проблем.

Тут двояко. Да, можно и через шейдер, но на том-же хл-лабе валялась куча моделек деревьёв с анимированными ветками, например. Но в целом при наличии полноценной grass system как в XT очевидно более рентабельно делать через шейдер, да

__________________
-Brain is dead-

Отправлено Дядя Миша 15-03-2023 в 20:17:

Цитата:

FiEctro писал:
Элементы 2д интерфейса и hud

Аа, ну да это тоже шрифт.

Цитата:

KiQ писал:
но на том-же хл-лабе валялась куча моделек деревьёв с анимированными ветками, например

Ну я еще планировал делать анимированные статики. Это такие деревья, которые вкомпилены в карту, но при этом у них сохраняются кости, которые можно анимировать. XashNT такое позволяет.

Добавлено 15-03-2023 в 23:17:

Вообще в меню можно рендерить либо отдельные текстуры, либо картинки\буквы из шрифта. Единственное ограничение - в 2D не работают всякие шейдеры и система материалов. Я просто не стал распространять её влияние на меню. Но зато в меню можно взаимодействовать с полноценными 3д объектами и даже сделать полностью трёхмерное меню

И вот на них уже материалы естественно работают.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 16-03-2023 в 06:58:

Ещё вот какая шляпа. Все редакторы строят брашы немного по разному. Тоесть эпсилоны там разные в chop is dish. Поэтому брашы, валидные с точки зрения компилятора редакторы злобно взрывают на гигантские плоскости.

Но кстати. Я вчера наконец-то осознал в чём профит сохранения плоскостей как трёх точек. Мы с вами помните гадали, зачем такая избыточность? Ну там в голову лезло, что эти точки хранились в целочисленных координатах по некоторым причинам, однако для текстового формата это не сказать чтобы прямо какая-то догма. Но оказывается есть и ещё один профит. В том случае когда браш построить не удалось, QuArK рисует, правильно что? Да эти же самые полигончики, подсвечивая их другим цветом. А как я узнал? Да очень просто. Я всегда сохранял в карту стоковые плоскости, ну те, которые размером на весь уровень. А вчера думаю, дай-ко сохраню уже те полигоны, которые компилятор превратил в браш. Ну и сохранил. Каково же было моё удивление, когда на некоторых из них QuArK браши так и не смог построить, но аккуратно отрендерил на их месте треугольнички, формой в целом напоминающие те самые брашы, которые могли бы быть на их месте.

Я конечно не знаю, может так только QuArK умеет, а другие редакторы нет.
Но вообще интересно, конечно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 16-03-2023 в 07:40:

Цитата:

Дядя Миша писал:
и игр ваших так до сих пор никто и не увидел

Разработка игры пока стоит на паузе, не до нее сейчас, но я уже на анриле написал 2 конфигуратора и пишу еще одну прогу, так что есть что показать

А еще есть Area 51

Отправлено Дядя Миша 16-03-2023 в 07:48:

Так, ну чтож, для успешного завершения генерации брашей из моделей, осталось только написать генератор конвексных хуллов из произвольных полигонов. Это когда мы на вход подаём разные полигоны а на выходе получаем единый браш, который отдалённо напоминает исходную форму.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 16-03-2023 в 09:15:

Цитата:

Дядя Миша писал:
Ну я еще планировал делать анимированные статики. Это такие деревья, которые вкомпилены в карту, но при этом у них сохраняются кости, которые можно анимировать. XashNT такое позволяет.

Анимированные статики в мемориз

Такое ощущение что ты не понимаешь что такое модель и что такое кости. Иначе не могу понять чем вызвано стремление создавать дополнительные сущности? Ведь статик это модель без костей вообще. То что в ГС для статиков нужна кость, это скорее частный случай, чем всеобщая практика. Ещё модель без костей можно анимировать через шейдер да, некоторые даже умудряются записывать сдвиги вершин в текстуру, и двигая UV по ней, анимировать персонажей, но это не тип модели, а просто материал с шейдером.

Цитата:

Дядя Миша писал:
Так, ну чтож, для успешного завершения генерации брашей из моделей, осталось только написать генератор конвексных хуллов из произвольных полигонов. Это когда мы на вход подаём разные полигоны а на выходе получаем единый браш, который отдалённо напоминает исходную форму.

Помню мы со СразуРашеном строили в центре триса точку и спускали её в другую сторону относительно нормали получая конвексный тэтраэдр который побить крайне сложно, тем самым преобразуя obj в браши практически в неизменном виде.

Отправлено Дядя Миша 16-03-2023 в 12:21:

Цитата:

FiEctro писал:
Ведь статик это модель без костей вообще

Совершенно верно. Но повторюсь, в XashNT возможно иметь статики с костями, которые будут частью уровня. Это нужно для реалистичной процедурной анимации деревьев, а то, что они статики - помогает в дополнительной оптимизации отрисовки. Если ты этого не понимаешь - ну сиди дальше на Юнити.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 16-03-2023 в 12:44:

Цитата:

Дядя Миша писал:
Это нужно для реалистичной процедурной анимации деревьев,

Так, а что мешает их так же анимировать без костей?

Цитата:

Дядя Миша писал:
Если ты этого не понимаешь - ну сиди дальше на Юнити.

Юнити это только частный случай. Не нравится Юнити, открой Анрил, там тоже самое всё.

Отправлено Дядя Миша 16-03-2023 в 13:53:

Цитата:

FiEctro писал:
Так, а что мешает их так же анимировать без костей?

Без костей некрасиво.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 17-03-2023 в 12:33:

Подведу некоторые промежуточные итоги. В целом сконвертировать модельный уровень в брашы - возможно. Колоизационная часть по возможности принимает форму конвексных хуллов, сложные конструкции налету декомпозируются в конвексные. Всё это конечно довольно небыстро, но уж всяко быстрее чем работа VHACD, который несчастную тубаретку мучал почти 8 минут и отожрал на это гигабайт оперативы.
К тому же с переходом на новый формат, я могу легко и просто предрассчитать брашы с помощью модельного процессора и тут же сохранить их в usm-файлик. Если он изменится, то процессор перерассчитает брашы автомагически. Таким образом загруженная моделька сразу же даст мне набор готовых брашей, а я просто выберу куда мне их подевать.
Структуральные отправятся на построение BSP, а детальные отфильтруются в это дерево. Одно могу сказать точно - тот принцип построения дерева, который использовался в Q3 и D3 для модельной геометрии абсолютно не подходит. Он там всё кромсает и портит. Неудивительно, да вообщем-то и не имеет значения. Я просто отфильтрую детальные брашы в лиф, ну будет навигационная трасса потреблять чуть-чуть больше ресурсов при анализе построения пути. Некритично. Зато построение такого дерева займет не часы, а минуты. С этим моментом я определился. Теперь, собственно, вернёмся к превращению нашей полигональной геометрии в брашы.

Как я уже говорил из модели формируются группы в которых у треугольников смежные рёбра. Классификация на данный момент умеет определять следующие типы этих групп:
1. планарная группа. Ну понятно. декаль, вода или окошко. Или может плакат на стенке. Чот такое.
2. Конвексная группа. Ну тут всё просто - это 100% детальный браш. Т.к. части уровня не могут быть набором конвексных треугольников. А даже если и могут - это всё равно детальный браш
3. Почти конвексная группа. Браш не может быть почти конвексным, а вот моделька - запросто. Метод построения немного иной, но визуально результат практически такой же.
4. Группа смотрящая внутрь себя. Это очевидно мировая геометрия, какой-то колидор или лаз. Ну вообщем детальная геометрия всегда смотрит наружу себя. Конечно никто не мешает сделать сложную комплексную модель, у которой будет как наружная часть, так и внутреняя, простейший пример - ящик без одной стенки, в сталкере такие попадаются, а вертексы все шареные. Но очевидно, он не подходит под определение группы, которая смотрит исключительно в себя.
5. Ландшафт. Ну тут тоже понятно, что мировая геометрия.
6. Все оставшиеся группы. Здесь самое интересное начинается. Потому что под определение всех оставшихся групп подходят как унитазы, так и стенки уровня. То есть это неконвексная группа. Замкнутость\разомкнутость в данном случае не имеет никакого значения - моделлёры зачастую убирают лишние полигоны, поскольку за них этого никто не сделает. То есть у унитаза вполне может отсутствовать нижняя часть модели, где он соприкасается с полом. А у структурных стен вполне может оказаться какой-то разрыв в рёбрах - например одну стенку просто вдвинули в другую, да и всё. Связи между рёбрами нет, а герметичность есть. То есть передо мной стоят ещё две важные задачи:
1. отличить детальные группы от мировых (точнее говоря, всё что не задетектируется как детальная группа станет структуральной), потому что надёжного способа задетектировать часть уровня вообще не существует, приходится действовать методом исключения - задетектировать все детальные группы, то что останется и будет структурной. Этот путь гораздо надёжнее и проще, поскольку есть масса способов выявить детальные полигоны и ни одного - чтобы выявить структуральные. К тому же моделлёры их вообще никак не различают и модели делаются без учёта всего вот этого.
2. Аппроксимировать вогнутую детальную группу при помощи множества AABB. Я с подобной задачкой ещё не сталкивался, так что пока у меня нету однозначной идеи как именно это сделать. Собственно сама аппроксимация делается элементарно, вопрос только в том, как задетектировать, когда нам уже надо бросать одну группу и переходить к следующей. Тут очевидно надо искать ось для текущей группы полигонов или что-то вроде этого. Ну и вот когда эта ось вдруг резко меняется - значит переходим к созданию следующей группы. А то что получившиеся мешы будут незакрытыми как минимум с двух сторон не представляет никакой проблемы, я вчера написал автозакрыватель брашей, очень простой и эффективный алгоритм, который работает во всех случаях.

Добавлено 17-03-2023 в 15:33:

Перечитал и понял, что наихудший кейс - это трубы, внутри которых можно бегать. Они отправятся в мировую геометрию, детальными их сделать, увы не получится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 17-03-2023 в 12:40:

Возможен ли будет стол из единой мадельки, под который можно залезть?

Отправлено Дядя Миша 17-03-2023 в 12:42:

Цитата:

nemyax писал:
Возможен ли будет стол из единой мадельки, под который можно залезть?

Если ты каким-то образом изловчишься и у столешницы с ножками абсолютно везде будут смежные рёбра, то такой стол аппроксимируется конвексными примитивами. Если же нет, то анализатору будет куда как меньше работы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ZGreen 17-03-2023 в 18:25:

А вот рандом-тайлинг текстур в КсашНТ оживет или это сущая глупость?

Отправлено Дядя Миша 17-03-2023 в 19:17:

Ну его здесь пользователь может сам оживить - через шейдер и многослойную текстуру. Причём даже на уже выложенной демке.
Единственное, надо будет придумать какой-нибудь seed.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 19-03-2023 в 10:41:

Так ну штожы, моё мини-исследование подходит к своему логическому завершению, в принципе всё что я хотел узнать - я узнал. Результатами с вами поделюсь позже, когда всё систематизирую и обдумаю.
А пока что вот вам скриншот для затравки. Радиатор отопления, разобранный на конвексные брашы. Он не прошёл сквозь CSG, потому там видно лишние детали.

Добавлено 19-03-2023 в 13:41:

Строго говоря, когда этот хулл надуется по своим размерам, тут останется три браша, ну или что-то вроде этого.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-03-2023 в 10:49:

Дядя Миша
Это колоизация?

Отправлено Дядя Миша 19-03-2023 в 11:32:

Да, она.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-03-2023 в 18:42:

А что со сферой будет? И всякими изогнутыми объектами?

Отправлено Дядя Миша 19-03-2023 в 18:52:

Да со сферами как раз-таки ничего - сфера-то конвексная.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 20-03-2023 в 07:05:

Ну чтож, подведу итоги моего мини-исследования:

1. В принципе превращать полигональную геометрию в брашы можно и даже без критичных артефактов.
2. На сравнительно больших (но по меркам Сталкера игрушечных) картах, только лишь на генерацию брашей для одного хулла уходит чертовски много времени. Это без учёта работы CSG и построения BSP. Скажем на testers_mp_factory это заняло более часа. И вероятно еще пару часов считал бы CSG, а потом BSP строился ещё пару часов. А потом был бы ещё долгий поиск возможных путей для навигации. Проблема здесь конечно не в том, что долго, а в том, что алгоритм разбит на слишком большое кол-во этапов, на каждом из которых накапливается ошибка. Насколько я помню даже в оригинале кутришные карты имели массу дополнительных брашей, для того чтобы навигация монстров работала боле-мене нормально. Так что нет, этот метод к сожалению не годится и неактуален в настоящее время.
3. Поскольку в BSP30 лимит всего-навсего на 65 киловертексов, это автоматически предотвращает от вставки на уровень слишком больших\детализированных моделей. А мои механизмы разбора вполне жизнеспособные, то я вполне могу имплементировать это в p2st. Собственно, он и так умеет вкомпиливать модели в карту при помощи встроенной энтити misc_model (и это будет работать на голдсорсе), однако у таких моделей не было коллизии. Теперь же с учётом накопленного опыта можно учитывать и коллизию тоже. И даже использовать достаточно грубые модели в отсечении видимости - например как тот пресловутый домик. Когда у меня появится время, я скорее всего выпущу обновление p2st с полноценной поддержкой вкомпиливания моделей в уровни. Но повторюсь, эти модели должны быть не слишком полигональными.
4. Можно замутить в Xash3D AAS-систему из Q3 (для XashNT она не годится, о чём я подробно расписал в во втором пункте). Но если бы её делал я, то не декомпилил бы карту целиком и полностью, а строил AAS прямо на основе хуллов, получая набор полигонов прямо с них. При помощи того самого визуализатора клипнодов, я бы просто добавил полигоны на уже существующее дерево, заново выполнил бы ему портализацию и рассчитал reachability. Возможно, что в p2st я тоже проделаю часть этой работы, посмотрим.
5. В процессе исследования сделал несколько интересных открытий и исправил некоторые вещи. Кое-о-чем я уже рассказал выше. Так же отремонтировал склеивалку конвексных полигонов. Это позволит более эффективно создавать поверхности для патчей в радиосити. Так что получилась неожиданная побочка - исправление для моего лайтмаппера.
6. Использовать полигональную геометрию для отсечения видимости в принципе можно, но лучше этого не делать, причины расписаны во втором пункте - слишком долго, если компилятор будет пихать такую геометрию по собственному усмотрению. К тому же с вероятностью 99% она не будет замкнутой (ради чего всё и затевалось), а значит не сможет ничего отсечь и время будет потрачено впустую. В том же сталкере некоторые домики обстраивали брашами с окнами-порталами. В принципе нечто подобное делать можно. Например модельное здание многоэтажки, у которого в каждом окне находится портал. Причём порталы тоже сделаны полигонами. И явно указано, что эту модель надо целиком добавить в построение BSP. Полагаю это будет наиболее оптимальный метод. К тому же анализатор всё равно выбросит детальные группы и добавлять их не будет. То есть - строго по желанию пользователя.
7. Для навигации монстров придётся всё же использовать автоматически расставленные ноды, но я сделаю это не так, как это сделано в сталкере, у меня есть некоторые идеи насчёт всего вот этого. И еще есть мысль, что даже для этого облака точек возможно выполнить портализацию, как если бы мы имели дело с настоящим уровнем. Только здесь будет как бы двухмерное BSP.

Добавлено 20-03-2023 в 10:05:

Да, по поводу вот этого https://hlfx.ru/forum/showthread.ph...3460#post213460 скажу отдельно.
Оно хоть и работает, но лишено практического смысла. Колоизация ведь надувается по размеру хулла, а значит все эти мелкие детали пропадут автомагически. А для точечной трассы вполне достаточно просто пропустить в дерево оригинальные полигоны.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 20-03-2023 в 07:14:

Цитата:

Дядя Миша писал:
3. Поскольку в BSP30 лимит всего-навсего на 65 киловертексов, это автоматически предотвращает от вставки на уровень слишком больших\детализированных моделей. А мои механизмы разбора вполне жизнеспособные, то я вполне могу имплементировать это в p2st. Собственно, он и так умеет вкомпиливать модели в карту при помощи встроенной энтити misc_model (и это будет работать на голдсорсе), однако у таких моделей не было коллизии. Теперь же с учётом накопленного опыта можно учитывать и коллизию тоже. И даже использовать достаточно грубые модели в отсечении видимости - например как тот пресловутый домик. Когда у меня появится время, я скорее всего выпущу обновление p2st с полноценной поддержкой вкомпиливания моделей в уровни. Но повторюсь, эти модели должны быть не слишком полигональными.

Это уже интересно, а что с разверткой и поддержкой тайлов?

Добавлено 20-03-2023 в 10:14:

Цитата:

Дядя Миша писал:
слишком долго

А если приминенять многопоточность и ГПУ?

Отправлено Дядя Миша 20-03-2023 в 10:02:

Цитата:

FiEctro писал:
А если приминенять многопоточность и ГПУ?

Если что-то долго, но даёт хорошие результаты - это имеет смысл оптимизировать. Но здесь алгоритм разбит на слишком много этапов и на каждом накапливается ошибка. А для ручного исправления этой ошибки надо собрать, посмотреть что получилось, исправить, собрать, посмотреть что получилось. То есть это время множится и тратится впустую.

Цитата:

FiEctro писал:
Это уже интересно, а что с разверткой и поддержкой тайлов?

Так же я говорю - уже существующий p2st умеет вкомпиливать модели в карту, я же твою лошадку вкомпиливал. Сколько раз мне ещё надо это написать, чтобы ты заметил?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 20-03-2023 в 10:22:

Цитата:

Дядя Миша писал:

Так же я говорю - уже существующий p2st умеет вкомпиливать модели в карту, я же твою лошадку вкомпиливал. Сколько раз мне ещё надо это написать, чтобы ты заметил?

А на лошатке были тайлы?

Отправлено Дядя Миша 20-03-2023 в 11:24:

Так это ж твоя лошадка? Ты лучше меня должен помнить.

Добавлено 20-03-2023 в 14:24:

Вообще они поддерживаются, если что.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 20-03-2023 в 11:25:

Цитата:

Дядя Миша писал:
Так это ж твоя лошадка? Ты лучше меня должен помнить.

Это модель с интернета.

Отправлено Дядя Миша 20-03-2023 в 20:02:

Что ещё хотелось бы сказать по поводу всего вот этого?
Да, я практически не выкладывал скриншотов, но это потому что не видел ничего особенного в сделанном. Если бы какой-то результат превзошёл мои ожидания я бы обязательно поделился.
К тому же, я фактически занимался не навигацией монстров, а генерацией брашей из исходного уровня, будучи изначально настроенным скептически к этой затее. Вот как раз из-за долгого времени ожидания. Ну да не принципиально. Побочные результаты потом всё равно найдут своё применение, когда у меня будет на это время.
Чтож, пришла пора уже напрямую заняться AI, точнее построением навигационного графа. Я ставил свои опыты в компиляторе уровней, но видимо это неразумно и стоит его вынести в отдельную утилиту.
Утилита будет называться aigraph.exe. Ну и да, запускать её можно будет как до рассчёта освещения так и после (или даже вместо).
Я абсолютно ничего не знаю о построении графов, ну только про алгоритм A* кое-что слышал. Но идти привычным путём не хочу. Я вам уже выше приводил пример сколько проблем влечёт тупая автоматическая генерация нодов. Попробую сделать по своему. Поскольку тема для меня новая, то любой результат скорее всего будет представлять какой-то интерес, поэтому постараюсь выкладывать скриншоты и сопровождение к ним в телеграм-канале. Вообще мне представляется, что генерация навигационного графа куда проще чем написание лайтмаппера, но посмотрим.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 20-03-2023 в 22:05:

может натолкнет на кое какие мысли

Цитата:

Дядя Миша писал:

Вообще мне представляется, что генерация навигационного графа куда проще чем написание лайтмаппера, но посмотрим.

Не скажи, это ты статичный навмеш генеришь, а если у тебя динамические объекты там какой нибудь лифт, вагончик, мост раздвижной, дверь наконец? И всё летит в тартарары.

Отправлено Дядя Миша 21-03-2023 в 06:36:

Цитата:

FiEctro писал:
а если у тебя динамические объекты там какой нибудь лифт, вагончик, мост раздвижной, дверь наконец?

Эти объекты проверяются во время игры. К тому же для подвижныъ объектов генерятся собственные навмешы, которые перемещаются вместе с ними.
Я ведь давно уже говорил, что любой подвижный объект может рассматриваться как локальный мир.

Цитата:

FiEctro писал:
может натолкнет на кое какие мысли

Это автоматически создалось? Сгенерировать такой меш несложно, но в моих мыслях это начальная точка, исходная геометрия, а не готовый навигационный путь. Надо только подумать как его закодировать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-03-2023 в 08:19:

Цитата:

Дядя Миша писал:
Это автоматически создалось?

Да. Но проблема в том что это статика.

Отправлено Дядя Миша 21-03-2023 в 08:33:

Я и делаю статичный граф. Динамический во время игры проверяется, очевидно же.

Посмотрел как в том же сталкере всё это устроено. Навскидку что могу сказать - калечная трасса. Там есть проверка на ббоксы, но она не использовалась, видимо слишком часто давала недостоверные результаты.
Поэтому все тесты - через луч. Ессно, там куча нодов попадает куда не следовало бы.

Добавлено 21-03-2023 в 11:33:

Я исхожу из того, что трасса в игре и трасса в компиляторе навигации должна быть идентичной. Мы же вычисляем в оффлайне всё то, что можно проделать в реалтайме, но не нужно. т.к. можно рассчитать предварительно.

Эх, опять куча подготовительной работы, загрузи то, загрузи это.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-03-2023 в 08:36:

Цитата:

Дядя Миша писал:
Динамический во время игры проверяется, очевидно же.

Расскажи подробнее как навигация работает у динамических объектов.

Отправлено Дядя Миша 21-03-2023 в 08:44:

Цитата:

FiEctro писал:
Расскажи подробнее как навигация работает у динамических объектов.

Цитата:

Дядя Миша писал:
Я абсолютно ничего не знаю о построении графов, ну только про алгоритм A* кое-что слышал.

На данный момент времени ты в этом шаришь лучше меня. Я понятия не имею как там всё устроено. Я могу только рассказать, как сделал бы лично я. Но не буду. Сначала надо разобраться со статикой. Мне эта задача представляется куда более сложной. Потому что динамики - мало. В том же сталкере может быть одна-единственная дверь на гигантском уровне.
А вот статики там дохрена и пойди найди ещё путь среди всех этих йолок и сосен.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-03-2023 в 09:44:

Цитата:

Дядя Миша писал:
На данный момент времени ты в этом шаришь лучше меня.

Честно говоря - не шарю вообще. В Юнити с этим тоже проблема, и каких то универсальных решений для динамики я не видел. Разве что как то прибивать гвоздями к ним статичный навмеш что тоже задача нетривиальноя. По поводу дверей я думаю тоже стоит разделять навмеш на какую то сетку или сегменты чтобы их можно было отключать если туда разместили какое то препятствие, наверное в сталкере такая сетка из точек для этого и нужна. Но это чисто мои догадки, как на самом деле, я не знаю.

Отправлено Дядя Миша 21-03-2023 в 11:05:

Для начала надо загрузить колоизацию, которую рассчитал makebsp.
Когда у нас есть колоизация, то мы можем вытворять разные интересные штуки (в штанах).

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-03-2023 в 11:29:

Дядя Миша
Мне кажется что навмеш вообще сомнительная фигня. Он слишком избыточен на больших дистанциях, где этого не требуется, а на вблизи наоборот очень грубый где наоборот требуется большая точность. Кажется что для поиска по всей карте достаточно использовать обычные точечные ноды которые просто показывают нам что они друг друга видят, что то вроде регулярной сетки лайтгрида (это можно использовать и для летающих нпц), а вот в области видимости нпц уже строить в реальном времени детальную сетку навигации включая динамические объекты. Причем с дистанцией можно детализацию этой сетки уменьшать.

Отправлено Дядя Миша 21-03-2023 в 15:09:

У регулярной сетки есть один большой минус - она иногда промахивается мимо дверных проёмов и прочих узких мест. Подгонять геометрию под сетку тоже весьма сомнительное дело.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-03-2023 в 15:32:

Цитата:

Дядя Миша писал:
У регулярной сетки есть один большой минус - она иногда промахивается мимо дверных проёмов и прочих узких мест. Подгонять геометрию под сетку тоже весьма сомнительное дело.

Это как пример, возможно есть более эффективный способ расстановки этих нодов, главное чтобы они видели друг друга, так то их много не нужно.

Отправлено Дядя Миша 21-03-2023 в 15:41:

Цитата:

FiEctro писал:
возможно есть более эффективный способ расстановки этих нодов

Вот я сейчас и копаю в этом направлении.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Chyvachok 22-03-2023 в 08:01:

Цитата:

Дядя Миша писал:
Потому что динамики - мало. В том же сталкере может быть одна-единственная дверь на гигантском уровне.
А вот статики там дохрена и пойди найди ещё путь среди всех этих йолок и сосен.

У меня сложилось впечетление что динамики в сталкере мало потому что ИИ не умеет их обходить и как-то взаемодействовать, что видно по модам на машины всякие, НПС просто прут в них если поставить ее на пути. Тоже самое если через какой-то спавнер спавнить большие пропы. Есть мелкие пропсы на локациях где полтергеи, но опять же, они такие что НПС столкнут их просто с пути.

Если не ошибаюсь они то и не шибко аномалии обходят, кроме статичных расставленных маппером, и не редко мододелы делают НПС неуязвимыми к ним и огню чтобы они не дохли в них и в кострах. С кострами вообще рофл, но там правда чуть другой баг, там НПС просто спавнятся в центре лагера когда игрок на локацию переходит, а это костер и сгорают, хотя с другой стороны оно создавало свою особую атмосферу в ТЧ, будто сталкера такие суровые челы что провинившегося просто сжигают в костре травя анекдоты, бедный Волк, сколько играл, он всегда оказывался сожжённым в костре на Армейских Складах.

Отправлено Дядя Миша 23-03-2023 в 16:58:

Я поначалу превращал ячейки навмеша в полигоны, полигоны в брашы, брашы записывал в карту, а карту смотрел в кварке, но во первых эти самые карты могли легко достигать полгигабайта в размерах и кварк их очень долго открывает (но всё-таки открывает), а во вторых (и это главное), смотреть на навмеш в сферическом ваккууме удобно лишь до поры до времени, а потом всё-же хочется оценить его в совокупности с препятствиями. Первые эксперименты в картинках:

Добавлено 23-03-2023 в 19:58:

У вас разумеется возникнет вопрос, почему навмеш залазит под солиды, отвечу - потому что никакого тестирования на солиды в построении этого навмеша ещё не участвовало. Выброшены только ячейки, которые не смогли получить нормальный размер 32х32.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 23-03-2023 в 23:16:

Интересно как оно отработает на склонах, на том же грасстресте

Отправлено Дядя Миша 24-03-2023 в 05:07:

Склоны не проблема, проблема не попадание в ячейки регулярной сетки. По крайней мере в текущей принятой концепции. Да и пока оно никак не работает, я просто меш строю и визуализирую его.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 24-03-2023 в 05:09:

Zbot используют вроде навмеши или навзоны. Отлично бегают. Эти боты еще используются в л4д и ксго. И код есть. Совместить бы их вейпоинты с хл монстрами...

__________________
Мой мод на Xash

Отправлено Дядя Миша 24-03-2023 в 06:20:

Моя основная задача - это построение самого навмеша. Может показаться, что это просто полигоны, но в действительности он состоит из сотен тысяч квадратиков, размером точно с хулл игрока\монстра. При сохранении в карту я просто эти квадратики объединяю обратно, т.к. для визуализации это не нужно. А как он будет представлен в итоге, я ещё не решил.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 24-03-2023 в 07:11:

Цитата:

Дядя Миша писал:
размером точно с хулл игрока\монстра.

Кстати это тоже проблема, я так понимаю нужно ещё хранить размеры хулла который может туда влезть.

Отправлено Дядя Миша 24-03-2023 в 07:19:

Сейчас самое главное - построить непрерывный меш, чтобы монстр мог везде ходить. А способов его оптимизации много и они особой проблемы не представляют. Сложность же заключается в том, что навмеш генерируется из произвольной геометрии. Из брашей было бы не в пример проще.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 24-03-2023 в 08:39:

Цитата:

Дядя Миша писал:
Сложность же заключается в том, что навмеш генерируется из произвольной геометрии.

Так это вроде просто нужно сделать копию геометрии с нужными нормалями и обрезать лишнее?

Отправлено Дядя Миша 24-03-2023 в 08:42:

крайне желательно нарезать эту геометрию на квадратные патчи. Каждый патч по размеру хулла монстра, чтобы можно было точно проверить куда он может шагать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 25-03-2023 в 08:03:

Подведу некоторые промежуточные итоги. Всё нижесказанное я пишу исходя из главных допущений при построении ai-карты - никаких ручных правок, мы хотим чтобы компилятор нам самостоятельно всё посчитал. Мы же к примеру лайтмапу не дорисовываем, если компилятор ошибся. Так оно и здесь должно быть. Да, задачка не слишком простая, но решаемая.

1. В сталкере (впрочем как и практически везде) не было нормальной трассы по форме объекта и тем более трассы произвольной формой объекта, а не только bbox. Последний там как-раз бы, но не использовался. Видимо применение bbox test в сочетании с регулярной сеткой приводило к большому кол-ву мёртвых зон. Поэтому там трасса только точечная используется. Что приводит к необходимости ручного редактирования всего этого дела.

2. AAS для уровней из произвольной геометрии не годится. Максимум уровень первой-второй кваки (он собственно для них и делался, а потом его кое-как натянули на Q3 и D3). Там приходится слишком многое окружать специальными брашами, чтобы монстр не попал в плохие места. К тому же там AI очень сильно завязан на предрассчёты и специальные контентсы.
На полигональных уровнях всё это нормально работать не будет. Ну или будет очень-очень долго считаться и не факт, что коллизия получится нормальной для всех случаев. Мелкие полигоны, сами знаете, провоцируют щели и прочие ошибки точности.

3. Навмешы подошли бы лучше, но у них есть проблема. Ступеньки! В идеале навмеш должен быть непрерывным, чтобы монстр мог бежать придерживаясь его внутреннего объема. Ступенька - это разрыв в навмеше. Ладно, если бы все лестницы были прямые, то можно было бы аппроксимировать их пологим подъемом. На практике лестницы бывают и витые и с разным шагом ступенек. То есть тут какая-то ручная правка всё равно потребуется. Ручная правка означает, что навмеш частично приходит из исходника. Это ничем не лучше клипбрашей, которыми в халфе обстраивают модели, иммитируя коллизию. Модель поменялась, клипбраш остался прежний, коллизия не совпадает. В Метро Эксодус был забавный ляп, ну все наверное помнят - на карте "Поволжье" бандюки бегали по воздуху. Вот как раз геометрия поменялась, а навмеш старый остался. Не вариант.

4. Остаются только ноды-точки. У каждой точки должна быть связь с другой точкой. И у каждой связи должна быть специальная подсказка для кода WalkMove или чего-то подобного. А именно - что представляет собою следующая нода. Ну навскидку как это могло бы выглядеть:
0. move stop - стена
1. move normal - обычный шаг
2. move step up - ступенька вверх
3. move step down - ступенька вниз
4. move fall - падение с высоты (обратная связь разорвана и покажет move stop)
5. jump to water - следующий шаг приведёт к падению в воду
6. jump from water - следующий шаг это waterjump
Возможно ещё какие-то ситуации упустил, но в целом примерно так.
И подобные подсказки избавляют нас от кучи лишних проверок на самом деле. AI надо будет лишь убедиться, что путь не перекрыт каким-то динамическим объектом. Локальные сетки так же могут присутствовать на моделях, встроенных в карту. Чтобы монстр, например мог ходить по вагончику поезда или чему-то подобному.
Ну и самое любопытное - в эти сетки можно инжектировать позиции точечных энтить и отсекать все те части, которые оказались недосягаемыми, подобно тому, как портализация убирает все внешние части геометрии.
Единственный момент - построение оптимального графа сквозь путешествие через пол-карты может быть не столь быстрым, однако это не критично, поскольку монстры так далеко не заглядывают. Обычно это в случае получения нового задания - например пробежать по скрипту в указанную точку или найти укрытие. А в обычных состояниях они довольствуются локальным шагом на размер хулла и эта сетка идеально поможет им ориентироваться в пространстве.

ЗЫ. я тут уже три версии построения навигации опробовал. Напоминает разработку лайтмаппера, тот тоже менялся раз 15, пока я не нащупал наиболее оптимальный путь. Впрочем и с компилятором уровней было так же и с разработкой собственного языка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 27-03-2023 в 20:08:

Идеи для построения путей навигации неожиданно нашли применение в лайтмаппере. У меня там оставалась одна нерешённая проблема с генерацией патчей для радиосити. И вот я внезапно додумался как решить её красиво и эффективно. И удивился, почему эта идея мне раньше не приходила в голову. Поясню в чём была проблема:

Когда у нас брашевая геометрия, обработанная CSG, лайтмаппер работает в идеальных условиях. Когда у нас произвольная полигональная геометрия, условия уже далеко не такие идеальные. К тому же с модельной геометрией делать как правило ничего нельзя. Сквозь CSG её не пропустишь, рубить нежелательно. К тому же там много кривых поверхностей. Наложить лайтмапу в таких условиях проблематично но вполне реально. А вот нарубить эти поверхности на регулярную симметричную сетку уже гораздо труднее. Раньше я действовал просто - пытался объединить все треугольники лежащие на одной плоскости, а затем рубил геометрию на квадарты-патчи с заданным шагом. Процентов 40 патчей при этом оставалось состоять из двух-трёх кусков. А каждый патч генерирует собственные трансферы и потребление памяти растёт экспоненциально.
И тут мне в голову пришла здравая мысль - надо попытаться смержить уже нарубленные патчи! Зная длину ребра довольно просто проверить две ситуации:
1. В результате объединения получился квадратный патч с нужной стороной ребра
2. В результате объединения получился еще не квадратный патч, но аксиальные стороны ребра у него подходящие и он скоро будет достроен до квадрата. Чтобы объединение происходило веселее, я поместил кусочки патчей в AABB-дерево. В данном случае дерево использовалось не для поиска. а для сортировки. На каждой ноде скопились именно те кусочки, которые и надо было объединить. Мне осталось линейно пробежаться по нодам (ну или обработать каждую ноду в отдельном потоке) и доклеить разобранные патчи. Экономия в результате оптимизации составила до 40%! Второй позитивный момент заключался в том, что раньше я выбрасывал сверхмалые патчи, из-за чего потенциально менялась общая яркость светопереноса и приходилось нормализовывать излучающий свет. Сейчас я ничего не выбрасываю, поскольку велик шанс, что эти мелкие кусочки в процессе склейки достроятся до квадратного патча. Получился стабильный и прозрачный алгоритм, который в любых условиях должен хорошо себя проявить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 28-03-2023 в 07:38:

Чтож, возвращаюсь к генерации навигационных путей. Поскольку нодов адски много надо разработать эффективный дисковый формат для их хранения. Подобный формат предполагает различные допущения.
Я выбрал следующие:
Максимальный размер уровня, который может быть покрыт нодами +\-98304 юнита. Т.е. квадрат ~2.4 километра.
Минимальный размер хулла (по любому измерению) составляет 24 юнита.
Это с запасом, т.к. в халфе например минимальный размер хулла - 36 юнитов (+\- 16). Меньше делать смысла нет, да и этот хулл, как вы понимаете, смогут использовать все, кто меньше по размерам. Уж если персонаж проходит, то и тараканы, мышы, крысы тоже пролезут. Вероятно понадобится еще один хулл - для больших персонажей. Сама система предусматривает наличие нескольких Ai-хуллов для каждой модели уровня. По аналогии с клипнодами.
И точно так же некоторых хуллов может и не быть вовсе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-03-2023 в 08:29:

Ну прикольно хардкодить хулл для каждого персонажа прямо в карту. Может тогда всё же воксельную сетку сделать лучше?

Отправлено Дядя Миша 28-03-2023 в 12:08:

FiEctro а ты думаешь в других играх оно не так? В сталкере размер патча точно так же означает приблизительный хулл монстра. Только он там вообще один и если монстры крупные. то начинаются проблемы. Поэтому крупные монстры в основном в подземельях тусуются, где проходы широкие.

Добавлено 28-03-2023 в 15:07:

Исходя из накопленной информации, обычно нужно не более двух хуллов на уровень: хулл персонажа-хумана и хулл крупного монстра.

Кстати в халфе тот факт, что мелкая живность боится яркого света - не случаен. Потому что они в качестве навигации как раз и используют яркость света и стремятся найти тёмный угол. Они же не по нодам бегают.
Это просто кто-то очень удачно предложил и оно совпало с реальным поведением.

Добавлено 28-03-2023 в 15:08:

Цитата:

FiEctro писал:
воксельную сетку

Гы-гы. А у воксельной сетки размер ячейки чем определяться будет? Правильно - тем же самым размером хулла %)

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 28-03-2023 в 12:24:

Цитата:

Дядя Миша писал:
А у воксельной сетки размер ячейки чем определяться будет

Может имеется в виду, что можно взять максимальный, и потом его дробить по вокселям?

Цитата:

Дядя Миша писал:
Потому что они в качестве навигации как раз и используют яркость света

То есть каждый таракан лукапит в лайтмапу?

__________________
-Brain is dead-

Отправлено Дядя Миша 28-03-2023 в 13:29:

Цитата:

KiQ писал:
То есть каждый таракан лукапит в лайтмапу?

удивительные открытия - каждый день!

Цитата:

KiQ писал:
Может имеется в виду, что можно взять максимальный

А максимальный чему будет равен?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ZGreen 28-03-2023 в 14:49:

Там тараканы еще в мясину лукапят.

Отправлено Дядя Миша 29-03-2023 в 11:55:

Согласно новой концепции, вот такая вот сетка из нодов у меня получилась.
Пустые места - это те, где ноды создать по каким-то причинам не удалось, учитывая, что изначально они генерятся из реальной геометрии, а геометрия может быть порезана как угодно. Но ничего страшного. В дальнейшем я полагаю эти точки можно будет восстановить. У нас же сетка!
А зная шаг и уклон, можно попробовать экстраполировать недостающие ячейки. Я долго с этим маялся и в конечном итоге пришёл к выводу, что экстраполяция в данном случае будет надёжнее, чем собирать их из осколков реальной геометрии (с учётом того, что я и так это делаю).

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-03-2023 в 11:59:

Вот, если кому интересна более сложная геометрия:

Время рассчётов - менее секунды. Правда здесь пока ещё трассировка не выполняется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-03-2023 в 12:03:

Вот еще более большая карта. Тут эта сетка уже 12 секунд считается.

Добавлено 29-03-2023 в 15:02:

Ну впрочем, понятно, что большая часть этой сетки может быть удалена за ненадобностью. И не просто удалена, а удалена автоматически.
Используя всё тот же старый добрый метод портализации.

Добавлено 29-03-2023 в 15:03:

Чтож, теперь, эта сетка - всего лишь предварительные данные. Теперь, собственно, предстоит рассчитать настоящий граф, которым будут пользоваться монстры.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-03-2023 в 12:17:

Я так вижу с наклонными поверхностями оно выглядит не очень, но в целом результат наверное не хуже чем в сталкере

Отправлено Дядя Миша 29-03-2023 в 13:34:

Я целенаправленно удаляю ячейки, которые не смогли склеиться в квадратик. А не смогли они потому что там было секущее ребро треугольника. Попробую их реконструировать и посмотрю что из этого получится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-03-2023 в 21:53:

В сталкере любопытно устроено - там, как я уже и говорил надо несколько нодов поставить на реальную геометрию руками. А дальше от них во все стороны как бы разрастётся сетка. Мне это не нужно - т.к. у меня сетка из реальной геометрии генерится, процентов на 60 наверное. Но дальше - тот же самый метод - генерация недостающих нодов.
Интересное кино, конечно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 30-03-2023 в 12:13:

Склеил уже существующие ноды между собой в отладочных целях.
Отладочную текстурку попятил из сталкера, надеюсь вы меня за это не осудите

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-03-2023 в 05:46:

Почему на относительно ровной поверхности, он генерирует какой то шум?

Отправлено Дядя Миша 31-03-2023 в 05:58:

Потому что поверхность наклонная, а симулятор ходьбы ещё не написан.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-03-2023 в 11:01:

Хоть и наклонная но плоскость. Почему шум то? Вон в верхней части у тебя вся плоскость покрылась нодами, а ровно в одном месте отсустсвует квадратик, чем это место отличается от остальных на этой плоскости?

Отправлено Дядя Миша 31-03-2023 в 11:51:

Потому что на том месте были секущие рёбра и раздолбали квадратик на столько частей, что он обратно не смог склеиться. Да это ерунда в сущности, сколько их там смогло поставиться. Главное чтобы на каждой изолированной поверхности хоть одна штука была. А это требование вполне соблюдается.

Добавлено 31-03-2023 в 14:49:

Они же потом дальше расползутся как тараканы.

Добавлено 31-03-2023 в 14:51:

ЗЫ. Если бы я генерировал ноды на брашевой геометрии, то поставились бы все, естественно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 01-04-2023 в 10:14:

К сожалению, автоматическая генерация нодов на поверхностях, это хоть и быстрый и надёжный, но несостоятельный подход. Он был бы идеален на брашевой геометрии, прошедшей CSG-процессинг, и удаление всех невидимых поверхностей. Но на модельной геометрии эта штука попросту генерит ноды в таких местах, куда никто попасть не сможет. И удалять эти лишние ноды потом крайне затруднительно. То есть получится множество островков, не связанных между собой, и каждый на свой рассчёт займет время. А потом эти островки будут всё равно удалены. То есть произведена бессмысленная работа, по факту.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено KiQ 01-04-2023 в 19:45:

Дядя Миша то есть наиболее оптимальным всё равно является расставление клип-брашей поверх моделек?

__________________
-Brain is dead-

Отправлено Дядя Миша 01-04-2023 в 20:03:

KiQ не, клипхуллы я вам нагенерю. Я говорил именно про составление навигационного графа. Представь ситуацию, что часть модели вдвинули в землю и там тоже создались ноды. Они не нужны, их потом удалять придётся.
Т.е. бессмысленная работа была проделана.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-04-2023 в 10:48:

Ну вот для халфовских уровней, получается что-то такое.
С полигональными всё сложнее, хотя и там результаты неплохие.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-04-2023 в 10:50:

Дядя Миша
Комнату с костюмом пропустило, и место где Барник стоит тоже. Что то совсем уж детские болячки у такого подхода.

Цитата:

Дядя Миша писал:
Но на модельной геометрии эта штука попросту генерит ноды в таких местах, куда никто попасть не сможет. И удалять эти лишние ноды потом крайне затруднительно. То есть получится множество островков, не связанных между собой, и каждый на свой рассчёт займет время. А потом эти островки будут всё равно удалены. То есть произведена бессмысленная работа, по факту.

Можно проверять соседа по высоте хулла, и если там ничего нет, либо оно выше или ниже то ничего не создавать, раз ты уже и так делаешь проверку. По идее это и лестницы должно починить. Ну, а csg что на моделях не работает?

Отправлено Дядя Миша 05-04-2023 в 13:26:

Цитата:

FiEctro писал:
Комнату с костюмом пропустило, и место где Барник стоит тоже

Ступеньки слишком мелкие. Симулятор ходьбы ещё не до конца настроен.

Цитата:

FiEctro писал:
Что то совсем уж детские болячки у такого подхода.

Покажи нам вариант, где болячки не детские.

Цитата:

FiEctro писал:
Ну, а csg что на моделях не работает?

Для уничтожения лишнего модель должна содержать объем. Так-то порезать можно конечно, но это ничего не даст.

Добавлено 05-04-2023 в 16:26:

Кстати вот эта расстановка нодов только лишь кажется простейшим делом.
Особенно если учесть что все эти ноды расползлись от позиции info_player_start.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-04-2023 в 13:31:

Цитата:

Дядя Миша писал:

Кстати вот эта расстановка нодов только лишь кажется простейшим делом.
Особенно если учесть что все эти ноды расползлись от позиции info_player_start.

А что будет если игрок телепортируется вначале из другой никак не связанной комнаты?

Отправлено Дядя Миша 05-04-2023 в 13:40:

Цитата:

FiEctro писал:
А что будет если игрок телепортируется вначале из другой никак не связанной комнаты?

Можно добавлять произвольные начальные точки, откуда будут генерироваться ноды, в данном случае - info_teleport_destination.
Или место спавна монстра можно тоже обозначить такой точкой.

Для больших брашевых моделей точка должна по имени быть с нею связана, тогда AI-карта построится и для брашевой модели тоже. Ну или необязательно брашевых, главное что не статичных.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 08-04-2023 в 16:19:

ИДЕАЛЬНО!!!

Давно не было, чтобы я был прямо вот так вот доволен, но здесь именно тот самый случай. В моушен-симуляторе есть несколько очевидных трудностей, связанных с тем, что под ногами у монстра может быть какая угодно геометрия и мы должны просто и надёжно определить, что там такое, а в некоторых случаях - апрроксимировать её. Какие трудности нам могут встретится?

1. Это конечно же обрыв. Из-за того что сетка регулярная, хулл монстра, может зацепить её краешком, но монстр фактически парящий над пропастью - это некрасиво. И тем более, если подобная сетка была рассчитана в оффлайне.

2. Полигональный мусор. Самый простой пример полигонального мусора - костры в сталкере. Разумеется можно каждый костёр окружить func_mosnterclip, но как вы понимаете - это не наш метод. Да и зачем, если эта задачка решается чисто аналитическими методами.

3. Ступеньки большие, нереалистичные. На эти ступеньки обычно нода навигации ложиться целиком. Самый простой кейс.

4. Ступеньки маленькие, реалистичные. С ними жопа, потому что такие ступенькие обычно захватывают двойную высоту максимально разрешённого шага, из-за чего построение сетки всё время норовит прерваться. Плюс их вообще логичнее "сглаживать", т.к. центр монстра, находящийся как бы под статичной геометрией позволяет нормально работать инверсной кинематике и монстры ставят ноги точно на ступеньки (т.е. монстр ходит по нодам, а инверсная кинематика трейсит реальную геометрию).

Ну и вот ниже на скрине результат того, что у меня получилось.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ZGreen 08-04-2023 в 16:25:

Выглядит так уютно, что уже хочется обвести Фримена рамочкой и отправить обшаривать шкафчики! Здорово!

Отправлено Дядя Миша 08-04-2023 в 16:57:

Чтож, система получилась сверх-чувствительной к полигональному мусору, это именно то, что надо. Даже если монстр будет игнорировать мировую геометрию для навигации, ничего хорошего в том, что он полезет прямо в нагромождение полигонов - нету. Однако в том же сталкере довольно много такого мусора, типа маленького камушка, который тоже детектируется и нода туда не ставится. Такие мелкие вещи, я полагаю стоит игнорить.

Впрочем надо будет всё же попробовать взять колоизацию из оригинальных карт, её там ручками делали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 08-04-2023 в 17:14:

Цитата:

Дядя Миша писал:
1. Это конечно же обрыв. Из-за того что сетка регулярная, хулл монстра, может зацепить её краешком, но монстр фактически парящий над пропастью - это некрасиво. И тем более, если подобная сетка была рассчитана в оффлайне.

Я не очень понимаю, но зачем делать приоритет навмеш агенту перед физикой? В чём сакральный смысл этих парящих/проваливающихся NPC?

Цитата:

Дядя Миша писал:
Ну и вот ниже на скрине результат того, что у меня получилось.

Выглядит хорошо

Отправлено Дядя Миша 08-04-2023 в 17:31:

Цитата:

FiEctro писал:
Я не очень понимаю, но зачем делать приоритет навмеш агенту перед физикой?

Это многоцелевая сетка. Она может служить лишь навигатором пути, т.е. высота будет игнорироваться, а может и навмешем. Я её специально делал именно такой. И с рассчётом на IK.
Так же в нодах заключена карта укрытий, чтобы монстр выбирал пути отхода. Но этим я ещё не занимался.
К тому же понадобится еще дополнительный проход, исправляющий разные косяки и в целом сглаживающий пути. На стерильной брашевой геометрии старых игр он не нужен, но на полигональной непременно понадобится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 09-04-2023 в 12:48:

Сетка на кордоне. Расползлась от единственной ноды под info_player_start и осталась точно в границах, очерченных колючей проволокой.
14 мегабайт занимают эти ноды. В принципе немного.

Осталось проверить две вещи: как будет строиться сетка, если взять коллизию из оригинальных карт сталкера (её там руками сглаживали) и проверить как всё это строится на карте ai_test из Lost Alpha, которая специально была сделана для тестирования навигации.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 10-04-2023 в 07:13:

Дядя Миша
С ходячими монстрами понятно, а как дела с летающими и плавающими?
В анриле там просто ставишь навмеш на весь уровень потом идет генерация пару сек и забываешь об этом ) Летающие летают, а ходячие ходит )

Отправлено Дядя Миша 10-04-2023 в 07:24:

Цитата:

(_-=ZhekA=-_) писал:
С ходячими монстрами понятно, а как дела с летающими и плавающими?

С плавающими в принципе тоже несложно, брашы воды - это и есть навмеш для плавающих монстров. Ну и так же легко сделать переход из воды и обратно. А летающим придётся расставлять некие контрольные точки в воздухе, иначе никак.

Цитата:

(_-=ZhekA=-_) писал:
В анриле там просто ставишь навмеш на весь уровень

Но ведь его сперва надо сделать. А это явно не две секунды.

Добавлено 10-04-2023 в 10:24:

Впрочем я не исключаю варианта, что когда-нибудь поэкспериментирую и с навмешами тоже, т.к. формат уровней XashNT позволяет добавлять туда какие угодно данные, без нарушения совместимости.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 10-04-2023 в 07:33:

Цитата:

Дядя Миша писал:
Но ведь его сперва надо сделать. А это явно не две секунды.

Перетащил на уровень, растянул, как нужно, выравнил и вася кот )))

Отправлено Дядя Миша 10-04-2023 в 07:45:

Цитата:

(_-=ZhekA=-_) писал:
Перетащил на уровень, растянул, как нужно

Подожди-подожди. Откуда перетащил?

И что значит "выровнял-растянул"?

Дай ссылку на видео по изготовлению навмеша.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 10-04-2023 в 07:56:

Цитата:

Дядя Миша писал:
Дай ссылку на видео по изготовлению навмеша.

https://www.youtube.com/watch?v=dyenYdA6fb8

Отправлено Дядя Миша 10-04-2023 в 08:29:

Ну вот тут возникает уже много вопросов:

1. почему вокруг аксиальных препятствий возникли такие неровные вырезы. Это похоже работу солвера комплексных чисел, типа Eigen.

2. Зачем наверху препятствий остались маленькие островки навмешей.

3. Как эти островки соединятся с основным навмешем?

Принцип работы я понимаю, алгоритм тоже, мои первые опыты по генерации навмеша примерно так и выглядели.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 10-04-2023 в 08:41:

Цитата:

Дядя Миша писал:
2. Зачем наверху препятствий остались маленькие островки навмешей.

3. Как эти островки соединятся с основным навмешем?

Если у монстра есть логика забираться на что-то, то когда он заберется то будет юзать этот навмеш, который создается сверху

Добавлено 10-04-2023 в 11:41:

Цитата:

Дядя Миша писал:
1. почему вокруг аксиальных препятствий возникли такие неровные вырезы. Это похоже работу солвера комплексных чисел, типа Eigen.

Я не разбирался, но может для этого есть настройки, чтобы было более точнее, хз

Отправлено FiEctro 10-04-2023 в 08:58:

Цитата:

Скорее всего чтобы немного сгладить прямые углы. Неестественно когда монстры ходят как по линеечке огибая невидимые углы.

Цитата:

Дядя Миша писал:
2. Зачем наверху препятствий остались маленькие островки навмешей.

Потому что статичная геометрия. Да и мало ли, вдруг у тебя монстр по ним прыгать будет?

Цитата:

Дядя Миша писал:
3. Как эти островки соединятся с основным навмешем?

Особо не вникал, но на юнити видел примеры где монстр мог например спрыгнуть с такого ящика на пол и наоборот запрыгнуть. Чем то на ступеньки похоже.

Отправлено Дядя Миша 10-04-2023 в 09:34:

Цитата:

(_-=ZhekA=-_) писал:
Если у монстра есть логика забираться на что-то, то когда он заберется то будет юзать этот навмеш, который создается сверху

Т.е. переход между навмешами монстр осуществляет по собственному усмотрению, так? А есть ли какая-то максимальная дистанация на которой он может найти соседние? Или скажем если где-то навмеша нет, то он бегает по обычной геометрии?

Добавлено 10-04-2023 в 12:34:

Цитата:

FiEctro писал:
Скорее всего чтобы немного сгладить прямые углы.

Тогда почему они хаотично неровные, причём даже там, где никакого угла и близко нету?

Цитата:

FiEctro писал:
Потому что статичная геометрия.

И что, что статичная?

Цитата:

FiEctro писал:
видел примеры где монстр мог например спрыгнуть с такого ящика на пол

Это понятно. Вопрос был как они соединяются.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 10-04-2023 в 09:53:

Цитата:

Дядя Миша писал:
Т.е. переход между навмешами монстр осуществляет по собственному усмотрению, так?

Ну, да. То есть монстр залез на препятствие и попал в зону навмша, который создался сверху и пошел дальше, если его там нет, то монстер, залезет и остановится или пойдет обратно туда, где есть навмеш.

Цитата:

Дядя Миша писал:
А есть ли какая-то максимальная дистанация на которой он может найти соседние?

Не встречал, возможно нужно писать отдельно в коде АИ для монстра.

Цитата:

Дядя Миша писал:
Или скажем если где-то навмеша нет, то он бегает по обычной геометрии?

Монстр остановиться у границ созданного навмеша и за ее пределы не пойдет

Отправлено Дядя Миша 10-04-2023 в 10:28:

Меня в навмешах более всего интерисует вопрос, как там пути находятся.

Возможно аналитической трассировкой внутри самого навмеша, но навскидку я ничего не придумал.

Добавлено 10-04-2023 в 13:28:

Или, учитывая, что навмешей может быть множество - как строится путь от одного края карты до другого, если на этом пути - сотня не связанных друг с другом навмешей.
Ну то есть вот мы дали команду монстру бежать к черту на рага, как он это выполнит? Есть примеры?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 10-04-2023 в 10:45:

Ты можешь на уровне поставить один NavMeshBoundsVolume на весь уровень или можешь их хоть 500 понаставить и все они автоматом будет работать, как один. Я не пробовал, но думаю, если монстру дать команду бежать с одного края карты на другой и при этом навмеш будет только на половине карты, то он до туда добежит и остановиться. Если же навмеш есть везде и путей прохода несколько к концу карты, то монстр может выбрать любой и побежит ) Еще много зависит, что прописано в коде АИ на то или иное действие )

Отправлено FiEctro 10-04-2023 в 10:53:

Цитата:

Дядя Миша писал:
Или, учитывая, что навмешей может быть множество - как строится путь от одного края карты до другого, если на этом пути - сотня не связанных друг с другом навмешей.
Ну то есть вот мы дали команду монстру бежать к черту на рага, как он это выполнит? Есть примеры?

Скорее всего будет искать кротчайший путь.

Отправлено Дядя Миша 10-04-2023 в 13:50:

Цитата:

(_-=ZhekA=-_) писал:
Я не пробовал, но думаю, если монстру дать команду бежать с одного края карты на другой и при этом навмеш будет только на половине карты, то он до туда добежит и остановиться

А попробуй, как будет время. Интересно же.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 11-04-2023 в 12:24:

Цитата:

Дядя Миша писал:
А попробуй, как будет время. Интересно же.

Мне пока не до этого, делаю новый интерфейс для новой проги на анриле

Отправлено FiEctro 11-04-2023 в 13:23:

Цитата:

Дядя Миша писал:
Это понятно. Вопрос был как они соединяются.

Вот тут глянь, правда это уже Юнити, но у Анрила я думаю практически всё тоже самое.

Отправлено Дядя Миша 11-04-2023 в 15:50:

Цитата:

FiEctro писал:
Вот тут глянь, правда это уже Юнити

Ну вот же в настройках запекания навмеша - точно так же выбирается фиксированный размер хулла, под который этот навмеш и запекается.
Так почему же ты меня критиковал, если в юнити навмеш точнотакже строится под фиксированный хулл?

Добавлено 11-04-2023 в 17:09:

Абсолютно те же самые настройки - высота хулла, диаметр хулла, высота ступеньки и максимальный угол наклона.

Добавлено 11-04-2023 в 17:13:

Вот кстати отдельно отмечу нехороший прикол. По умолчанию любой примитив считается динамическим и ни на что не влияет. Ему надо долго ставить целую кучу галок. Тогда как логичнее было бы сделать наоборот - по умолчанию всё статик. Впрочем раньше там вроде как даже коллизия по умолчанию не генерировалась.

Добавлено 11-04-2023 в 17:35:

Ага, ну в принципе понял. Навмешы соединяются между собой при помощи прыжка в длину и прыжков в высоту\вниз.
Единственное чего я понять по прежнему не могу - как монстр ориентируется внутри самого навмеша. Может конечно и вовсе никак.
В квейке монстры просто рандомом бежали примерно в нужном направлении и за счёт этого рандома огибали препятствия.
Но это не сработает в случае нескольких сеток или достаточно заковыристых путей, типа лабиринта.
Я просто пытаюсь понять, как в случае меша рассчитывается путь пошагово.
А если скажем будет развилка? Пример в аттаче (вид сверху). Где крестик, это начальная позиция монстра, а нолик - конечная. Как он поймет, что ему надо бежать не вправо, а влево?

Добавлено 11-04-2023 в 17:37:

Поясню, что лично мне непонятно. Когда такой меш аппрокимирован множеством связанных между собой точек, путь находится через тот же A* алгоритм. Но как это же самое сделать фактически для куска геометрии?

Добавлено 11-04-2023 в 17:55:

Посмотрел вот это видео:

И до меня внезапно дошло. Он же там включил показ рёбер внутри самого навмеша. Ну да, смежные рёбра, через дерево находим в каком треугольнике лежит наша точка. И дальше через смежные рёбра находим треугольник, со стартовой позицией.

Добавлено 11-04-2023 в 17:56:

Всё. В принципе мне всё понятно. Спасибо за помощь.

Добавлено 11-04-2023 в 18:50:

Впрочем нет. Один вопрос у меня всё-таки остался. Монстр прямо ходит по этому навмешу, или какбы утопает в нём?
И скажем, как бы выглядел навмеш, если бы на земле был прям разбросано много-много всяких там камушков, мелкого мусора, сама земля была бы неровной. Уроки-то на стерильной геометрии демонстрируют.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 11-04-2023 в 16:48:

Цитата:

Дядя Миша писал:
И до меня внезапно дошло. Он же там включил показ рёбер внутри самого навмеша.

В анриле нет ребер у навмеша, там есть границы за которые монсты не выходят и все просто залито цветом - это значит, что в пределах этого цвета монстр может ходить куда вообще хочет и как хочет

Отправлено FiEctro 11-04-2023 в 18:25:

Цитата:

Дядя Миша писал:
Ну вот же в настройках запекания навмеша - точно так же выбирается фиксированный размер хулла, под который этот навмеш и запекается.
Так почему же ты меня критиковал, если в юнити навмеш точнотакже строится под фиксированный хулл?

Так а где я писал что это хорошо? В Юнити та же беда с хуллом, и это превносит некоторый гемор при работе с ним, но зато тут можно крутить практически все его параметры, и подгонять для каждой карты свой параметр хулла. К тому же ты можешь запечь сразу несколько навмешей для каждого типа хулла. Это будет немного костыльно, но вроде как возможно. Навмеш Юнити довольно ограниченная штука и требует дополнительной обработки уже внутри NPC.

Цитата:

Дядя Миша писал:
Вот кстати отдельно отмечу нехороший прикол. По умолчанию любой примитив считается динамическим и ни на что не влияет. Ему надо долго ставить целую кучу галок. Тогда как логичнее было бы сделать наоборот - по умолчанию всё статик. Впрочем раньше там вроде как даже коллизия по умолчанию не генерировалась.

Это прикол самой Юнити, по умолчанию у неё все объекты динамик. Статичные объекты это уже другой слой абстракции. В целом покажется неудобно да, но на практике с динамикой мы работаем чаще. А статику, один раз сделал и забыл.

Цитата:

Дядя Миша писал:
Впрочем нет. Один вопрос у меня всё-таки остался. Монстр прямо ходит по этому навмешу, или какбы утопает в нём?
И скажем, как бы выглядел навмеш, если бы на земле был прям разбросано много-много всяких там камушков, мелкого мусора, сама земля была бы неровной. Уроки-то на стерильной геометрии демонстрируют.

Физика имеет приоритет. Ты можешь посмотреть то место где капсула ходит по ступенькам. Навмеш там пологий, но сама капсула резво прыгает по ступенькам. Например ты сделал навмеш, и уже только потом вырезал в полу дырку там где можно было ходить, агент просто пойдёт туда как ни в чём не бывало, и провалится вниз, ничего не заподозрив.
Про поиск пути подробнее тут:
https://docs.unity3d.com/Manual/nav-InnerWorkings.html

Отправлено Дядя Миша 11-04-2023 в 19:05:

Цитата:

(_-=ZhekA=-_) писал:
В анриле нет ребер у навмеша

Они просто не визуализируются, а так есть.

Цитата:

FiEctro писал:
Так а где я писал что это хорошо?

Других вариантов всё равно нет и не будет.

Цитата:

FiEctro писал:
о зато тут можно крутить практически все его параметры, и подгонять для каждой карты свой параметр хулла

Когда до тебя уже дойдет, что возможность крутить "практически все параметры" - это беда, а не преимущество. Оно изкапропки должно работать так как ожидалось.

Цитата:

FiEctro писал:
К тому же ты можешь запечь сразу несколько навмешей для каждого типа хулла.

Вот этого не понял. Зачем для одного и того же хулла разные навмеши?

Цитата:

FiEctro писал:
Это прикол самой Юнити, по умолчанию у неё все объекты динамик

Так я и говорю про это. Ну неужели нельзя было в глобальных настройках сделать выбор, типа "interpret new objects as" static\dynamic? Казалось бы, ну что мешало, а сколько бы лишних действий исчезло.

Цитата:

FiEctro писал:
но на практике с динамикой мы работаем чаще

Наоборот. Статика - весь уровень, игровой путь, который может меняться для улучшения геймплея. А динамика что? Её очень мало, относительно статики. Ладно, бы речь шла про майнкрафт, где всё - динамика.

Цитата:

FiEctro писал:
Физика имеет приоритет

Не совсем корректное определение, поскольку ты думаешь, что навмеш используется для определения столкновений, как это было ранее. Но нет, он совсем не для этого. Я тебя понял, примерно так и я думал.

Добавлено 11-04-2023 в 22:05:

Цитата:

FiEctro писал:
Про поиск пути подробнее тут:
https://docs.unity3d.com/Manual/nav-InnerWorkings.html

Ознакомился. Ну вообщем-то ничего нового в этой области так и не придумали и вероятно тут ничего меняться уже не будет. Да может оно и к лучшему.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-04-2023 в 19:16:

Цитата:

Дядя Миша писал:
Когда до тебя уже дойдет, что возможность крутить "практически все параметры" - это беда, а не преимущество. Оно изкапропки должно работать так как ожидалось.

Изкаробки значит надо от идеи хуллов вообще отказываться.

Цитата:

Дядя Миша писал:
Вот этого не понял. Зачем для одного и того же хулла разные навмеши?

Наоборот для разных. Один навмеш для мелких монстров, другой для более крупных.

Цитата:

Дядя Миша писал:
Так я и говорю про это. Ну неужели нельзя было в глобальных настройках сделать выбор, типа "interpret new objects as" static\dynamic? Казалось бы, ну что мешало, а сколько бы лишних действий исчезло.

Тебе не надо выставлять каждому объекту персонально. Достаточно задать только родительскому объекту сцены, а дочерние уже подтянут сами. Такая галочка кстати вроде где то в настройках зарыта, но на практике никто не юзает, а может её уже выпилили хз.

Добавлено 11-04-2023 в 22:16:

Цитата:

Дядя Миша писал:
Ознакомился. Ну вообщем-то ничего нового в этой области так и не придумали и вероятно тут ничего меняться уже не будет. Да может оно и к лучшему.

Держи уже анриловский до кучи. Но в целом, они очень похожы, ты прав.

https://docs.unrealengine.com/udk/T...hReference.html
http://web.cs.wpi.edu/~imgd4000/d16...pathfinding.pdf

Отправлено Дядя Миша 11-04-2023 в 20:34:

Цитата:

FiEctro писал:
Изкаробки значит надо от идеи хуллов вообще отказываться.

Так нет альтернативы. И не предвидится. У тебя есть какие-то идеи на этот счёт?

Цитата:

FiEctro писал:
Один навмеш для мелких монстров, другой для более крупных.

Ну там довольно вариабельно. Там где пройдет гуманоид - мелкий рогатый скот тоже пролезет.

Цитата:

FiEctro писал:
Но в целом, они очень похожы, ты прав.

https://ru.wikipedia.org/wiki/A* - 1968 год. Как ты думаешь, если бы можно было изобрести что-то умнее\оптимальнее, этого бы до сих пор не сделали?

Добавлено 11-04-2023 в 23:18:

Строго говоря, современное представление навмеша - это такое же допущение, сделанное на основе облака точек, которое без проблем конвертируется в выпуклые полигоны. Недостаток точек - в потреблении памяти, но зато в узлах можно хранить дополнительную информацию в юниформе. В отличие от навмеша, где сетки связываются дополнительными структурами.

Добавлено 11-04-2023 в 23:27:

Цитата:

FiEctro писал:
https://docs.unrealengine.com/udk/T...hReference.html

Ну вот когда я на том видео увидел рёбра у навмеша, у меня мгновенно сложилась общая картинка в голове, как всё это устроено до мельчайших подробностей. Т.е. читая документацию, я уже заранее знаю - ничего нового (для меня), там не будет. Но всё же читаю - мало ли.
Вообщем смысл в том, чтобы превратить регулярную сетку в полигоны.
И это как раз и делается через солвер комплексных чисел.
Конкретно вот эти пункты

Цитата:

Square merge to reduce number of polys and speed up the following steps
Merge all polys into concave slabs separated only by differences in slope
Decompose concave slabs into convex shapes

Потому что вот те характерные артефакты достигаются именно аналитическими методами. За что я их и не люблю, собственно.
В Юнитехе, как видишь тоже не любят.

Добавлено 11-04-2023 в 23:34:

Цитата:

Currently whenever starting a pathsearch an AI first needs to determine which pathnode it should start pathing from. This is accomplished via an octree check to return the pathnodes in range, and then doing raycasts from the AI to the pathnodes in order to find the closest, reachable path node. The same must be done for the path destination if the destination is not on the graph already. Some of this can (and is) mitigated via caching, etc.. but the fact remains that a non trivial amount of raycasts must be done by pathing AIs periodically at run time. Using a navigation mesh the ambiguity which FindAnchor resolves does not exist. We simply find the polygon the AI is currently inside, and that is our start location. The same is true for our destination.

Кстати бред полный. На регулярной сетке AABB-tree мгновенно справляется безо всяких рейкастов, издержки практически нулевые.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-04-2023 в 21:27:

Цитата:

Дядя Миша писал:
Так нет альтернативы. И не предвидится. У тебя есть какие-то идеи на этот счёт?

Локальный и глобальный поиск. Т.е. постройка навмеша налету вблизи нпц (что то вроде лидара), и использование какой то предрасчитанной очень простой модели для дальнего поиска, возможно какой то упрощенной геометрии карты, по типу как для радиосити и так же просто проверять соседние полигоны с нужным углом нормали.

https://3dnews.ru/assets/external/illustrations/2021/01/29/1031346/lidar_01.jpg

Отправлено Дядя Миша 12-04-2023 в 05:38:

Цитата:

FiEctro писал:
Т.е. постройка навмеша налету вблизи нпц (что то вроде лидара)

Поздравляю! Ты изобрел первый квейк, где монстры были тупыми как пробка. Впрочем в халфе они тем же самым занимаются, несмотря на наличие нодграфа.

Цитата:

FiEctro писал:
использование какой то предрасчитанной очень простой модели для дальнего поиска, возможно какой то упрощенной геометрии карты

Упрощённая геометрия карты как раз и базируется на хулле. Никаким другим образом ты её не сузишь, чтобы монстр не тыкался в стены.

Цитата:

FiEctro писал:
упрощенной геометрии карты, по типу как для радиосити

Если для радиосити использовать упрощённую геометрию - всё чорное будет.
К тому же твой подход худо-бедно работает, если на уровне несколько монстров, которые стоят и один преследует игрока. А если там толпа в сотню монстров ломится через полкарты?

Добавлено 12-04-2023 в 08:35:

И то что у тебя на видео - каждая точка это рейкаст. Причём здесь еще идеальный случай показан - пересечение с ландшафтом, которое легко оптимизировать. Можешь себе представить какой дроп нас ожидает хотя бы на 32-х машинках.

Добавлено 12-04-2023 в 08:38:

Справедливости ради стоит отметить, что в сталкере существовала т.н. оффлайн-сетка - сверх редкая, отмечающая только ключевые точки на карте. Она расставлялась только вручную и помечала всякие там базы долга, деревню новичков, квестовые места. Чтобы монстр на соседней карте мог перемещаться между этими местами. Но понятное дело игрок его увидеть не мог.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-04-2023 в 08:05:

Цитата:

Дядя Миша писал:
Если для радиосити использовать упрощённую геометрию - всё чорное будет.

У Геометрикс не черное.

Цитата:

Дядя Миша писал:
Поздравляю! Ты изобрел первый квейк, где монстры были тупыми как пробка. Впрочем в халфе они тем же самым занимаются, несмотря на наличие нодграфа.

А как там в первокваке?

Отправлено Дядя Миша 12-04-2023 в 10:17:

Цитата:

FiEctro писал:
А как там в первокваке?

Локальные пробы на клипхуллах.

Цитата:

FiEctro писал:
У Геометрикс не черное.

Там через лайтпробы сделано. Я же приводил ссылку на пейпер в этой теме.

Добавлено 12-04-2023 в 13:17:

Зашол в дискорд и чуть не попутал. Наш-то Психопат там какой-то SMD v.3 пилит. Чтобы координаты лайтмапы хранить. Т.е. энтропию увеличивает.
Но я уже принял решение сделать формат CSM общедоступным, поскольку недавно его залочил для дальнейших изменений. XashNT в качестве рабочего будет теперь использовать формат USM - абстрактные контейнеры, а CSM я сделаю общим достоянием, XashNT его останется поддерживать только на чтение. Плюс в том, что это очень простой и удобный формат, который уже содержит всё необходимое и при этом не требует много кода для загрузки, он специально был таким создан. И под него уже существует плагин для Блендора.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-04-2023 в 10:31:

Дядя Миша
опиши подробнее структуру этого формата

Отправлено nemyax 12-04-2023 в 10:32:

Цитата:

Дядя Миша писал:
И под него уже существует плагин для Блендора.

Отут: https://bitbucket.org/nemyax/xashnt-tools/src
io_scene_csm_import.py
io_scene_csm_export.py

Отправлено Дядя Миша 12-04-2023 в 14:40:

Цитата:

FiEctro писал:
опиши подробнее структуру этого формата

Я создам специальную тему с подробной документацией, примерами и в комплекте будут идти конверторы.

К тому же у меня сейчас наступает ответственный момент - в каком формате будут хранится исходники ресурсов для уровней и моделей.
Именно исходники, прошу заметить.
Есть два варианта на ваше рассмотрение:

1. абстрактный бинарный формат-контейнер, который может хранить в себе любые данные, возможно, предрассчитанные в редакторе, которые в дальнейшем будет использовать компилятор уровней.

2. классический формат .map, такой собирательный образ, где я попытаюсь конечно учесть все возможности уже имеющихся.

Я сам больше склоняюсь к бинарному формату, однако у него есть минус - в блокноте его уже не отредактируешь. Так же возможен совмещённый формат из двух файлов - описание объектов в текстовом и бинарный контейнер.

Просьба поучаствовать и изложить своё виденье.

Добавлено 12-04-2023 в 17:40:

ЗЫ. Товарищи, которым я разослал приглашения на участие в телеге, могут разослать и своим друзьям тоже. Это такой ответственный момент, что чем больше народу - тем лутшее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-04-2023 в 14:43:

Бинарный формат однозначно. Его парсить быстрее.

Цитата:

Дядя Миша писал:
в блокноте его уже не отредактируешь.

Надо нормальный редактор писать, а не таким извратом заниматься

Отправлено Дядя Миша 12-04-2023 в 14:47:

Цитата:

FiEctro писал:
Надо нормальный редактор писать, а не таким извратом заниматься

Да то понятное дело. Будет и редактор. Это всё шаги на пути к его созданию.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 13-04-2023 в 08:05:

Так, ну чтож, навскидку могу обозначить следующие принятые решения:

1. формат исходников будет бинарным
2. это будет нативный формат как для редактора, так и для компилятора - т.е. любая потеря точности при экспорте в промежуточный формат будет исключена. Что в редакторе, то и в готовом уровне.
3. Формат будет представлять собой универсальный мета-контейнер с возможностью его бесконечного расширения и одновременного сохранения как прямой, так и обратной совместимости.
4. Компилятор сможет полноценно использовать всю информацию, которая была задана в редакторе - например о группах.

Единственный минус подобного подхода, как уже и было сказано выше - отсутствие возможности текстового редактирования исходника. Но я думаю это не представит особенной проблемы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-04-2023 в 08:34:

Дядя Миша
Посмотри в сторону json он легко парсится даже на обычных крестах и при этом вроде как имеет как бинарное так и текстовые варианты представления. И довольно быстро работает в обоих вариантах. Зачем придумывать велосипеды, к тому же ни с чем не совместимые? К тому же универсальность Жсонов позволяет их использовать так же и для других вещей такие как сейвы и конфиги.

Цитата:

Дядя Миша писал:
Там через лайтпробы сделано. Я же приводил ссылку на пейпер в этой теме.

Лайтпробы для динамики. А для статичной геометрии всё работает и без лайтпроб.

Отправлено SNMetamorph 13-04-2023 в 08:56:

Цитата:

FiEctro писал:
Посмотри в сторону json он легко парсится даже на обычных крестах и при этом вроде как имеет как бинарное так и текстовые варианты представления. И довольно быстро работает в обоих вариантах. Зачем придумывать велосипеды, к тому же ни с чем не совместимые? К тому же универсальность Жсонов позволяет их использовать так же и для других вещей такие как сейвы и конфиги.

В целом, я с тобой согласен, BSON не такой уж плохой вариант, и парсить легко будет где угодно и на каком угодно языке. Для части языков есть даже парсеры которые для ускорения юзают SIMD. Ну и к тому же он стандартизованный.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 13-04-2023 в 10:08:

Цитата:

FiEctro писал:
Зачем придумывать велосипеды, к тому же ни с чем не совместимые?

Я не велосипеды придумываю, как может показаться, а продавливаю собственные стандарты. Не потому что мне хочется "что-то своё", а как раз потому что я вижу все объективные недостатки уже существующего, учитываю их и делаю форматы, лишённые всех этих недостатков.
И не просто делаю абстрактные форматы, а форматы, которые активно используются и с открытой документацией.

Сегодня все советуют использовать джейсоны, завтра точно так же будут советовать использовать мои форматы. Вопрос времени.

Добавлено 13-04-2023 в 13:08:

Цитата:

SNMetamorph писал:
Для части языков есть даже парсеры которые для ускорения юзают SIMD

Вот это вот вообще не понял. Ускоряют инкремент массива на один байт?
Ускоряют проверку байта на сравнение с другим символом?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-04-2023 в 10:53:

Цитата:

Дядя Миша писал:
Не потому что мне хочется "что-то своё", а как раз потому что я вижу все объективные недостатки уже существующего, учитываю их и делаю форматы, лишённые всех этих недостатков.

А какие недостатки у жсона

Отправлено SNMetamorph 13-04-2023 в 11:03:

Цитата:

Дядя Миша писал:
Вот это вот вообще не понял. Ускоряют инкремент массива на один байт?
Ускоряют проверку байта на сравнение с другим символом?

https://github.com/simdjson/simdjso...ormance-results

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 13-04-2023 в 12:05:

Цитата:

FiEctro писал:
А какие недостатки у жсона

Цитата:

FiEctro писал:
Бинарный формат однозначно. Его парсить быстрее.

Цитата:

SNMetamorph писал:
https://github.com/simdjson/simdjso...ormance-results

Воистину кому-то было нечем заняться.
И ты готов вот эту кучу кода утянуть в свой проект и регулярно проверять её насчёт обновления? А еще лучше - десять, двадцать, сто библиотек, и специальный планировщик, который всё это автоматически обновляет и билдит и тут же прогоняет юнит-тесты. Правда давно уже никто не понимает как это всё работает и старается не дышать рядом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 13-04-2023 в 12:07:

Цитата:

Дядя Миша писал:
И ты готов вот эту кучу кода утянуть в свой проект и регулярно проверять её насчёт обновления? А еще лучше - десять, двадцать, сто библиотек, и специальный планировщик, который всё это автоматически обновляет и билдит и тут же прогоняет юнит-тесты. Правда давно уже никто не понимает как это всё работает и старается не дышать рядом.

А какой смысл её обновлять если оно и так работает нормально? Не, ну если зачем-то вдруг понадобится обновиться, то это все делается буквально заменой одной строчки в vcpkg-манифесте. А так я без понятия, зачем подобные вещи обновлять, ибо там уже и так есть всё что нужно.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 13-04-2023 в 12:36:

Цитата:

SNMetamorph писал:
А какой смысл её обновлять если оно и так работает нормально?

Раньше допущения делались на уровне концепций, а теперь - на уровне обновления сторонних библиотек. Растём, чоужтам.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-04-2023 в 13:13:

Цитата:

Так в чём проблема? Напиши свой парсер, причём тут формат? Ну могу скинуть тот что я юзаю, там всего 1 .h файлик, и никаких дополнительных библиотек

Правда он для работы только с текстовым Жсоном, но доработать под бинарный возможно.

Цитата:

Дядя Миша писал:
А еще лучше - десять, двадцать, сто библиотек,

По моему опыту это скорее плюс чем минус, главное конечно не перегибать с этим. Есть много библиотек которые ну очень мало весят.

Цитата:

Дядя Миша писал:
И ты готов вот эту кучу кода утянуть в свой проект и регулярно проверять её насчёт обновления?

Вместо этого конечно наплодить зоопарк форматов, и заставлять пользователей твоего движка регулярно проверять насчёт обновления, а ещё писать утилиты миграции

Историю сорсовских hlbsp v.... и hlmdl v.... я ещё помню

Отправлено Дядя Миша 13-04-2023 в 14:46:

Цитата:

FiEctro писал:
По моему опыту это скорее плюс чем минус, главное конечно не перегибать с этим

Если стоит ограниченная задача, которую надо быстро решить и забыть - конечно плюс.

Цитата:

FiEctro писал:
Напиши свой парсер, причём тут формат?

При том, что JSON избыточный формат. Т.е. он минималистичен лишь относительно XML. А так всё равно избыточен.

Цитата:

FiEctro писал:
а ещё писать утилиты миграции

Ну утилиты миграции понадобятся в любом случае.

Цитата:

FiEctro писал:
Историю сорсовских hlbsp v.... и hlmdl v.... я ещё помню

Вот там-то как раз формат был нерасширяемым. Отсюда и постоянная смена версий с нервотрёпкой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 14-04-2023 в 22:21:

SNMetamorph

Цитата:

А так я без понятия, зачем подобные вещи обновлять, ибо там уже и так есть всё что нужно

Всё что нужно, в том числе уязвимости, по классике Си и С++. Ничего не утверждаю, но мало ли.

Добавлено 15-04-2023 в 01:21:

Я уже не говорю о том, что для валидации JSON документа придётся явно выдумывать что-то своё, так как стандарт не учитывает существование схем, в конце концов это просто способ представления JavaScript объектов. А JSON такой -- запросто можно пропустить ключ или не тот тип ему выставить, неймспейсов у него кстати тоже нет.

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 15-04-2023 в 05:34:

Вообщем пока решил всё же сделать текстовый формат исходников.
Как раз с неймспейсами.

Добавлено 15-04-2023 в 08:34:

Цитата:

a1batross писал:
в конце концов это просто способ представления JavaScript объектов

Ну так и Entity String - способ представления QuakeC объектов. Только вообще лишённый избыточности. Правда и иерархических вложений там нет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 16-04-2023 в 10:55:

Подведу небольшие итоги:

1. Формат описания исходников карт всё же будет текстовый.
2. Формат будет универсальный, абстрактный, позволяющий его легко расширять до бесконечности.
3. Формат с прямой и обратной совместимостью, т.е. если встретятся незнакомые описания, парсер их просто пропустит.
4. Формат иерархический вложенный, базируется на двух ключевых конструкциях:
- токенах, начинающися с решётки #, как директива препроцессору
- ключевых словах без решётки, обозначающих именованную секцию фигурных скобок. Имя каждой такой секции оканчивается на "Def", хотя будущим стандартом это и не регламентируется.

Подобная схема уже отлично себя зарекомендовала в файле настройек для компилятора уровней и в описании материалов (тоже абстрактная универсальная система). Пример простейшего map-файла:

C++ Source Code:

1	#version 1.0

EntityDef

5	"classname" "worldspawn"

6	"message" "Test Level"

  ConvexDef

10	"flags" "C_SOLID"

    "id"	"0"

12	"group" "0"

    SideDef

16	"material" "AAATRIGGER"

17	"plane" "0 0 1 1000"

18	"uaxis" "1 0 0"

19	"vaxis" "0 1 0"

      "id"		"0"

21	"group" "0"

    SideDef

25	"material" "AAATRIGGER"

26	"plane" "0 0 -1 1010"

27	"uaxis" "1 0 0"

28	"vaxis" "0 1 0"

      "id"		"0"

30	"group" "0"

    SideDef

34	"material" "AAATRIGGER"

35	"plane" "0 1 0 1000"

36	"uaxis" "1 0 0"

37	"vaxis" "0 1 0"

      "id"		"0"

39	"group" "0"

    SideDef

43	"material" "AAATRIGGER"

44	"plane" "0 -1 0 1010"

45	"uaxis" "1 0 0"

46	"vaxis" "0 1 0"

      "id"		"0"

48	"group" "0"

    SideDef

52	"material" "AAATRIGGER"

53	"plane" "1 0 0 1000"

54	"uaxis" "1 0 0"

55	"vaxis" "0 1 0"

      "id"		"0"

57	"group" "0"

    SideDef

61	"material" "AAATRIGGER"

62	"plane" "-1 0 0 1010"

63	"uaxis" "1 0 0"

64	"vaxis" "0 1 0"

      "id"		"0"

66	"group" "0"

EntityDef

73	"classname" "info_player_start"

74	"origin" "0 0 64"

Оно чем-то напоминает Valve Map Format, но там идёт жесткая привязка к версиям редатора и другие ограничения. К тому же подобный формат может без проблем хранить не только уровни, но и модели, ландшафты и любые другие данные, главное ввести соответствующую именованную секцию. Причём парсер по глубине вложений понимает что перед ним - уровень или модель. Если на верхнем уровне секция MeshDef, значит это просто модель. Если же на верхнем уровне секция EntityDef, значит это уровень. Так же, напоминаю, будет доступна старая фишка когда уровни могут вкладываться друг в друга.

Модели вы сможете хранить в следующих форматах:
1. CSM - бинарный файл для хранения моделей. Содержит вспомогательную информацию для облегчения и ускорения компиляции, в частности - развертку для построения лайтмап, но не только. Редактировать можно Блендером. Компиляции не требует. Поддерживаются только статичные модели без костей.

2. MDL - нативный формат самого XashNT (возможно в будущем привычные расширения bsp, mdl, spr я заменю на какие-то иные, но тут зависит от мнения пользователей). Может содержать анимации, однако при вкомпиливании в карту остаётся только один статичный кадр. Но зато его можно выбрать в настройках энтити.

3. Старые форматы md3, ase, obj, smd. Компилятор автоматически превратит их в CSM. Но возможно будет лучше это сделать в процессе миграции с других игр. Пока ещё не знаю точно.

4. Собственно новый абстрактный формат описания уровней (расширение пока что не придумано).

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 16-04-2023 в 11:39:

интересно, а как отличить "material" и "AAATRIGGER" где параметр, а где его значение? только по очереди?

Отправлено Дядя Миша 16-04-2023 в 12:02:

Цитата:

FiEctro писал:
интересно, а как отличить "material" и "AAATRIGGER" где параметр, а где его значение? только по очереди?

ключ-значение ВСЕГДА идут парами.

Добавлено 16-04-2023 в 15:02:

Судя по всему этот же абстрактный формат придёт и на смену SMD, да и вообще любому другому формату исходников.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 16-04-2023 в 15:51:

Цитата:

Дядя Миша писал:
ключ-значение ВСЕГДА идут парами.

Ну и удалили мы "material" в начале, и всё местами поменялось

Отправлено Дядя Миша 17-04-2023 в 05:30:

Цитата:

FiEctro писал:
Ну и удалили мы "material" в начале, и всё местами поменялось

Ты в своих халфовских картах пробовал делать нечто подобное?

Или скажем, в CISC архитектуре, команды идут вперемешку с данными. Удали один байт и тоже всё перепутается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 17-04-2023 в 08:00:

так можно просто запятую поставить:
"material" "AAATRIGGER",
"plane" "0 0 1 1000",
"uaxis" "1 0 0",
"vaxis" "0 1 0",
"id" "0",
"group" "0"

Тогда сразу будет понятно какое поле битое. Можно будет вывести в консоль сразу номер строки. Зачем усложнять отладку?

Цитата:

Дядя Миша писал:
Удали один байт и тоже всё перепутается.

Дык то байты, а то текст

Отправлено Дядя Миша 17-04-2023 в 12:12:

Никакие запятые там нахрен не нужны.
Если соответствующий ключ не будет найден, он просто скипнется и работоспособность будет восстановлена, начиная со следующего ключа.
Это само-восстанавливающийся формат данных, если ты не знал.

Добавлено 17-04-2023 в 15:12:

Вот как раз наличие запятых и усложнит отладку и замедлит парсинг.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 01-05-2023 в 10:12:

В телеграме выложил серию постов, отчёты о проделанной работе и о том, что предстоит сделать в ближайшее время. Ну а здесь хочу просто немного порассуждать на тему того, что является самым сложным в разработке, даже не софта, а как в моём случае - полноценной экосистемы.
Так уж получилось, что сейчас все увлекаются эко-системами. Какой-то изолированный программный продукт никого не удивляет и мало кому нужен.
Вот и XashNT разрабатывается как эко-система для разработки игр.
Изначально в 2019-м году я такой задачи перед собой не ставил, но в процессе дело приобрело невиданный размах и общественную значимость.

Так вот самое сложное, на мой взгляд - это определить границы экосистемы, а значит и ответственности. С одной стороны, заложенный потенциал, позволит всему этому разрастаться ещё достаточно долго если(тут следует перечисление всех возможных сценариев развития событий). Но исходя из пессимистичного варианта (я по прежнему продолжаю работу над движком в гордом одиночестве), границы моей ответственности будут ограничены редактором и созданием полноценного work-flow в будущем.
Это означает, что в идеале для разработки на XashNT не понадобятся никакие сторонние редакторы. Но конечно такое состояние будет достигнуто далеко не сразу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 13-05-2023 в 16:54:

Цитата:

Дядя Миша писал:
В телеграме выложил серию постов, отчёты о проделанной работе и о том, что предстоит сделать в ближайшее время.

Не хотелось бы чтобы это стало традицией, когда реальная инфа вся в телеграме.

Вот здесь можно скачать модельки Лондона в каких-то географических форматах, 1-2Гб, может получиться мощная тестовая карта.
nload/?mapService=EA/SurveyIndexFiles&Mode=spatial

Отправлено Дядя Миша 13-05-2023 в 18:46:

Здесь я в основном пишу отвлечённые мысли, когда есть что писать.
а в телеграме - конкретику.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 13-05-2023 в 19:53:

Сорян вот правильная ссылка
https://environment.data.gov.uk/Def...es&Mode=spatial

Отправлено Дядя Миша 29-05-2023 в 13:31:

В рамках написания универсального конвертора-мигратора со старых игр на XashNT, наконец-то дошли руки до обещанного декомпилятора уровней из халфы\кваки. Что тут можно сказать:

1. Информации, которая хранится в Q1BSP\HLBSP недостаточно для полноценной реконструкции брашей. Я не могу извлечь эту информацию из дерева, потому что соответствующие ветки дерева помечены как outside и обрублены ещё на этапе компиляции. Они все просто ссылаются на common outside leaf.

2. Тем не менее, учитывая вышесказанное, можно создать гигантский куб, по размеру всей модели и пропустить его сквозь дерево, нарубив внутренности на конвексные брашы. У такого подхода две очевидных проблемы:
- результат декомпиляции, запечённый в куб практически не подлежит дальнейшему редактированию.
- текстурные координаты для сурфейсов при таком подходе ищутся перебором примерно подходящих и в большинстве случаев оканчиваются фейлом. Нет хорошего способа наложить текстурные координаты на получившиеся брашы. Если не путаю, то BSPc вообще их не накладывает.

3. Таким образом декомпиляция по методу, описанному во втором пункте не годится - мы же хотим чтобы карту можно было ещё и редактировать в дальнейшем. Был ещё один декомпилятор под названием BSPTwoMap. Он на первый взгляд давал куда более лучшие результаты, но на самом деле просто превращал каждый полигон в отдельный браш. Т.е. максимально тупой способ.

4. Учитывая всё вышесказанное, надо было придумать что-то иное. Раз уж внешние стены всё равно до брашей не восстановишь, то их можно превратить в тонкие брашы, достроив недостающее. И в то же время, там где сторон достаточно для полноценной реконструкции - создавать настоящие браши. Именно такой подход я и принял за основу своего декомпилятора. Однако меня ждала весьма неожиданная и непреодолимая засада.

5. Дело в том, что перед тем, как уложить фейсы на ноду, компилятор их рубит на квадратики, согласно размерам их лайтмапы. Как легко догадаться, отличить сурфейс, разрубленный секущей плоскостью ноды, от сурфейса, разделённого субдивайдером на квадартики нет даже теоретической возможности. Казалось бы, ну и что такого? Надо просто смержить все сурфейсы да и всё. Но как раз тут нас и подстерегает вышеупомянутая засада:

6. Излишний мержинг убивает валидные стороны брашей! Т.е. если где-то были два браша у которых была планарная верхушка, существует очень высокая вероятность что эти две стороны смержатся в одну и там где могло бы получится два симпатичных замкнутых браша, получится 12 брашей из их сторон. Я бы не сказал, что эта ситуация возникает абсолютно всегда. Я больше скажу - брашей подлежащих полноценной реконструкции практически на всех картах удивительно мало, но оно и понятно. Ведь BSP в первую очередь задаёт геометрию, а детализации там весьма мало. Вот и получается что на какую-нибудь халфовскую карту приходится от силы 50-60 брашей, которые можно реконструировать. А всё остальное превращается в новые брашы из одной-единственной стороны. Т.е. это такой компромиссный вариант между BSPc и BSPTwoMap.

7. Теоретически в дальнейшем мне в голову придут какие-то новые идеи насчёт всего этого. Но пока - вот так.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 29-05-2023 в 18:31:

В NT будут триггеры которые могут регистрировать высокоскоростные объекты?

Отправлено Дядя Миша 29-05-2023 в 19:16:

Crystallize да, конечно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 30-05-2023 в 08:52:

Цитата:

Дядя Миша писал:
- текстурные координаты для сурфейсов при таком подходе ищутся перебором примерно подходящих и в большинстве случаев оканчиваются фейлом. Нет хорошего способа наложить текстурные координаты на получившиеся брашы. Если не путаю, то BSPc вообще их не накладывает.

Почему? Это же просто UV для отдельного сурфейса. Почему его нельзя просто скопировать? или там проекцию сделать?

Цитата:

Дядя Миша писал:
Он на первый взгляд давал куда более лучшие результаты, но на самом деле просто превращал каждый полигон в отдельный браш. Т.е. максимально тупой способ.

В целом да, но при этом геометрию косячит меньше всего. А в случае с ILE благодаря тому что мы использовали пирамидки, можно было импортировать даже obj. Правда без текстурных координат.

Добавлено 30-05-2023 в 11:52:

Цитата:

Дядя Миша писал:
6. Излишний мержинг убивает валидные стороны брашей! Т.е. если где-то были два браша у которых была планарная верхушка, существует очень высокая вероятность что эти две стороны смержатся в одну и там где могло бы получится два симпатичных замкнутых браша, получится 12 брашей из их сторон. Я бы не сказал, что эта ситуация возникает абсолютно всегда. Я больше скажу - брашей подлежащих полноценной реконструкции практически на всех картах удивительно мало, но оно и понятно. Ведь BSP в первую очередь задаёт геометрию, а детализации там весьма мало. Вот и получается что на какую-нибудь халфовскую карту приходится от силы 50-60 брашей, которые можно реконструировать. А всё остальное превращается в новые брашы из одной-единственной стороны. Т.е. это такой компромиссный вариант между BSPc и BSPTwoMap.

Наверное их надо проверять совпадают ли у них UV и текстурные координаты, и находятся ли они в одной плоскости, если да, то можно мержить, если нет, то это разные браши. В общем у них должна быть общая нормаль, общие UV координаты, и вершины плоскости должны быть конвексными.

Отправлено Crystallize 30-05-2023 в 09:48:

Цитата:

FiEctro писал:
А в случае с ILE благодаря тому что мы использовали пирамидки, можно было импортировать даже obj.

Я помню пробовал импортировал, там конверсия шла как-то с большим трудом. https://www.models-resource.com/dre...e2/model/15153/

Отправлено Дядя Миша 30-05-2023 в 11:27:

Цитата:

FiEctro писал:
Это же просто UV для отдельного сурфейса.

Ну во первых не UV, а текстурная матрица, а во вторых, как ты предлагаешь найти какой UV соответствует какому полигону? Если эти же самые полигоны размолоты в кучу после компиляции, а при выгрызании дыр в кубе они размолоты совершенно иначе. Если бы они совпадали - можно было бы сравнивать повертексно, все вертексы совпали - накладываем текстуру.

Цитата:

FiEctro писал:
В целом да, но при этом геометрию косячит меньше всего

Для NT я мог бы вообще дропнуть весь уровень в единую модель и так скомпилить. Но ето неспортивно.

Цитата:

FiEctro писал:
В общем у них должна быть общая нормаль, общие UV координаты, и вершины плоскости должны быть конвексными.

Вот в том-то и кроется весь ужас. Что абсолютно всё совпадает, но при этом брашы - разные. Единственное чего я надумал - это многопроходной подбор, построение матрицы смежности и её анализ. Если какой-то фейс цепляется к остальным всего через одно ребро - значит он не из этого браша.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено marikcool 30-05-2023 в 19:15:

сначало может от сабдивайд избавиться, вычистив разбиение и даже если вручную разбито мапером это тоже почиститься заодно. чистка на основе названия текстуры и текстурных координат и положения полигона в пространстве и общих вершин. получатся такие сложные многовершинные полигоны.

потом их уже разбить и превратить в обычные примитивы браши. этот результат вычесть от изначальной карты, останется много или мало кусков не распарсеной архитектуры. каждый из кусков превратить в модельку, за одно и ббокс подсчитать и впендюрить его к примитивам брашем, чтобы можно сходу карту скомпилить.

__________________
vk.com/skullcapstudios

Отправлено Дядя Миша 30-05-2023 в 20:05:

Цитата:

marikcool писал:
сначало может от сабдивайд избавиться, вычистив разбиение

Как определить где субдивайд, а где разделение деревом?

Цитата:

marikcool писал:
чтобы можно сходу карту скомпилить

ну карту к слову можно сразу компилить. Дырок нет.

У меня несколько иная идея сейчас - надо матрицу смежности строить.
Потом как-нибудь опробую. Пока что лимит времени выделенный на декомпилятор истёк. Другие задачи ждут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-05-2023 в 05:58:

Цитата:

Дядя Миша писал:
Ну во первых не UV, а текстурная матрица, а во вторых, как ты предлагаешь найти какой UV соответствует какому полигону? Если эти же самые полигоны размолоты в кучу после компиляции, а при выгрызании дыр в кубе они размолоты совершенно иначе. Если бы они совпадали - можно было бы сравнивать повертексно, все вертексы совпали - накладываем текстуру.

Ну импортёры БСП в модельки же как то их находят? И в отличие от разного рода декомпиляторов, текстуры там не сползают. Может стоит сначала сконвертировать в модель и уже с ней работать? Я просто не очень силён в специфике БСП архитектуры.

Добавлено 31-05-2023 в 08:58:

Цитата:

Дядя Миша писал:

Вот в том-то и кроется весь ужас. Что абсолютно всё совпадает, но при этом брашы - разные.

Ну было 2 браша, мержнули их в один. Главное чтобы в инвалид его не превратит, какая разница? Всеравно работаем только с внешней стороной, все остальные грани можно покрасить в NULL.

Отправлено Дядя Миша 31-05-2023 в 06:03:

Цитата:

FiEctro писал:
Ну импортёры БСП в модельки же как то их находят?

Какая связь? Там достаточно смержить все фейсы и записать результат в obj. Они их и не ищут. Ты вероятно просто не понял сути проблемы.

Цитата:

FiEctro писал:
И в отличие от разного рода декомпиляторов, текстуры там не сползают

У меня текстуры тоже не сползают.

Цитата:

FiEctro писал:
Ну было 2 браша, мержнули их в один

Так не получится в один, в том-то и дело. Потому что от второго браша остался только один фейс. А остальное попало в наружние фейсы и было удалено.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 31-05-2023 в 06:15:

Цитата:

Дядя Миша писал:
Так не получится в один, в том-то и дело. Потому что от второго браша остался только один фейс. А остальное попало в наружние фейсы и было удалено.

Может в пэйнте нарисуешь чтоб мы поняли?

Отправлено FiEctro 31-05-2023 в 06:49:

Цитата:

Дядя Миша писал:
У меня несколько иная идея сейчас - надо матрицу смежности строить.

Что такое матрица смежности и как она решает эту проблему?

Отправлено Дядя Миша 31-05-2023 в 08:05:

Цитата:

FiEctro писал:
Что такое матрица смежности и как она решает эту проблему?

это матрица с информацией, сколько у каждого фейса смежных ребёр.
Можно конечно построить настоящие рёбра, но для брашей это оверкилл получается.

Цитата:

Crystallize писал:
Может в пэйнте нарисуешь чтоб мы поняли?

Фиолетовые стороны - это задние стороны браша. Чтобы из разрозненных фейсов гарантированно сконструировать браш, надо не менее четырёх.
Можно конечно и меньше, но его потенциально может раздуть на полкарты.
Идеальный случай, когда мы можем задетектировать планарные дыры в браше. А не одну вогнутую дыру. А для этого надо именно не меньше четырёх сторон. Далее. Стороны подбираются по общим рёбрам. Не по коллинеарным, а именно по общим! Теперь смотрим на картинку.
Красный фейс когда-то тоже был брашем, но дерево его уничтожило, оставив только один фейс. На уровне мержилки фейсов, красный и зелёный логично объединить в один. Но тогда браш - уже не соберётся никаким образом. Мог бы собраться один браш из фиолетовых и зелёной стороны и ещё один - из красной.
А если смержить красную и зеленую стороны, вместо этого получится пять брашей, созданных из фейсов, надеюсь теперь понятно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-05-2023 в 08:27:

Кстати, а как работает сорсовский декомпил? Он строит браши на порядок качественнее чем голдсорсовский.

Цитата:

Дядя Миша писал:
Для NT я мог бы вообще дропнуть весь уровень в единую модель и так скомпилить. Но ето неспортивно.

Кстати интересно, насколько реально применять к вкомпиливыемым моделькам CSG операции? Например вот торчит ящик из под земли, нижние грани находятся снаружи уровня, реально их обрезать?

Добавлено 31-05-2023 в 11:27:

Цитата:

Дядя Миша писал:
надеюсь теперь понятно.

Мне кажется прежде чем их мержить, их надо как то заранее подготовить, возможно сделать веса типа какие полигоны лучше мержить с другими, дабы если встретится такая фигня не нужно было пересчитывать всё, а только соседей. Ну типа как VIS где каждый лист знает что он видит, а что нет.

Отправлено Дядя Миша 31-05-2023 в 08:59:

Цитата:

FiEctro писал:
Кстати, а как работает сорсовский декомпил?

Начиная с ку2 в карту сохраняются браши, поэтому там подобной проблемы вообще нет. Даже в первом дууме куда больше информации для точной реконструкции уровня. Речь именно про Q1/HLBSP.

Цитата:

FiEctro писал:
насколько реально применять к вкомпиливыемым моделькам CSG операции?

Реально, но не особо эффективно. CSG лучше всего работает с выпуклыми объемами.

Цитата:

FiEctro писал:
Например вот торчит ящик из под земли, нижние грани находятся снаружи уровня, реально их обрезать?

На полигональном уровне невозможно определить "снаружи и внутри".
Ну то есть принципиального ограничения нет, но оно просто того не стоит.
Ты будешь часами ждать рассчётов, ради удаления десятка тысяч полигонов (из миллиона), которые ни на что не повлияют.

Цитата:

FiEctro писал:
возможно сделать веса типа какие полигоны лучше мержить с другими

Пробовал мультипроходной мержинг - сперва мержим все полигоны, не имеющие форму прямоугольника, затем - только имеющие. Кое-что кое-где конечно исправилось, но это половинчатое решение.
Потому что НЕТ чёткого критерия, что можно друг с другом мержить, а что нельзя. А нет его как раз потому что сурфейсы рассчены как деревом, так и субдивайдером лайтмапы. Поди отличи одно от другого.

Добавлено 31-05-2023 в 11:56:

К тому же компилятор, перед тем как рассечь сурфейсы субдивайдером мержит результат рассечения нодами. Это возможно просто потому, что уже не играет роли в момент пересечения с нодой трасса ограничена деревом, так что можно мержить их обратно без проблем. Т.е. информация о сторонах брашей частично теряется уже на этапе компиляции.

Добавлено 31-05-2023 в 11:58:

Для понимания, скажу, то что сделал я:
- имеет идеально наложенные текстуры
- собирается без дырок
- к сожалению большинство брашей созданы из одного фейса, в силу природы HLBSP.

Если мне удасться осуществить свою задумку - кол-во таким брашей, созданных из одного сурфейса просто упадёт на какой-то процент, от 10 до 20, но не более того. И это максимум что тут вообще можно сделать.

Добавлено 31-05-2023 в 11:59:

Альтернатива - создавать гигантский куб и выгрызать дыры в нём.
Дальнейшее редактирование подобного декомпила очень сильно затруднено.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-05-2023 в 09:09:

Цитата:

Дядя Миша писал:
Альтернатива - создавать гигантский куб и выгрызать дыры в нём.

А если ограничить толщину стенок чтобы они не доходили до границ куба? Вот например насчитало тебе браш длинной 10000 юнитов, а ты его принудительно говоришь нет, у тебя будет толщина 16 юнитов. Да и куб наверное можно не один сделать, что то вроде нарезать карту кордоном и для каждого участка сделать свой куб?

Отправлено Дядя Миша 31-05-2023 в 10:00:

Цитата:

FiEctro писал:
А если ограничить толщину стенок чтобы они не доходили до границ куба?

ты точно хорошо понимаешь как устроено BSP-дерево? Конкретно в HLBSP.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-05-2023 в 11:44:

Цитата:

Дядя Миша писал:
ты точно хорошо понимаешь как устроено BSP-дерево? Конкретно в HLBSP.

Так, а смысл от него на этапе декомпиляции? Почему нельзя просто с геометрией работать?

Отправлено Дядя Миша 31-05-2023 в 12:47:

Цитата:

FiEctro писал:
Почему нельзя просто с геометрией работать?

Вот мой декомпилятор и работает просто с геометрией, а деревом не пользуется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 05-06-2023 в 02:34:

Цитата:

Дядя Миша писал:
Crystallize да, конечно.

Не забудь в фичелисте упомянуть

В других брашевых движках вообще есть такое?

А там как, из двух последних снапшотов берутся хуллы игрока, обтягиваются общим конвексным триггером, и он проверяется на пересечение с другим триггером?

Отправлено Дядя Миша 05-06-2023 в 06:28:

Просто проверка пересечений с триггером как и с любой другой геометрией.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 05-06-2023 в 06:41:

Дядя Миша Хм, но это же как будто тоже что и раньше. Тогда как же детектируется скоростной объект который раньше не ловился?

Отправлено Дядя Миша 05-06-2023 в 07:54:

Раньше триггер детектировал столкновение только когда объект проделывал путь за кадр. Т.е. движение на шаг, новая позиция, проверка на попадание в триггер. Сейчас же триггеры ловятся на всём пути этого движения.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 05-06-2023 в 10:16:

Цитата:

Дядя Миша писал:
Сейчас же триггеры ловятся на всём пути этого движения.

Так а как реализовано это самое "на всём пути"? Путь же состоит из дискретного набора оригинов, поторые на некотором расстоянии друг от друга.

Отправлено Дядя Миша 05-06-2023 в 11:55:

Цитата:

Crystallize писал:
Так а как реализовано это самое "на всём пути"?

Трассировка формой объекта.

Добавлено 05-06-2023 в 14:55:

Цитата:

Crystallize писал:
Путь же состоит из дискретного набора оригинов

Это наиболее распространённый но не единственный подход. Впрочем, я уже объяснял и не раз. Где-то в этой же теме.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 04-07-2023 в 02:06:

Цитата:

Дядя Миша писал:
Трассировка формой объекта.

Ну я ж сказал, две позиции игрока обтягиваются триггером-параллелограммом.

Цитата:

Дядя Миша писал:
Впрочем, я уже объяснял и не раз. Где-то в этой же теме.

Не припомню.

Если в NT будет liblist.gam то надо как-то автоматически защищать его от перезаписи. А то два дня ищешь почему ничего не работает, а потом оказывается что в мае, видимо от того что старый Кварк ставил, он перезаписал в директории мода либлист мода и вписал туда пути к стоковым дллкам valve.
Да и в Xash3D тоже будет круто если кто-то сделает.

Отправлено Дядя Миша 07-08-2023 в 19:24:

Наконец-то дошли руки до важнейшей вещи. Честно говоря не знаю, может быть во всех современных играх оно давно уже именно так и сделано, а может быть и нет. Речь идёт о наших любимых разрешениях экрана, конечно же. В старых играх эти разрешения были намертво вкомпилены прямо в код игрового движка, а игроку предлагалось выбрать разрешение самостоятельно. Ну или при первом запуске игра могла сама сделать это за него, ориентируясь на разрешение рабочего стола.
Основная проблема была в том, что можно было выбрать неверное разрешение и даже спалить некоторые модели мониторов таким образом.
Или же получить от кого-то игру с конфигом для одного монитора, запустить на своём компьютере и получить Out Of Range или нечто подобное.
Тут конечно уместно спросить - почему бы не получить список доступных разрешений монитора прямо из системы? А очень просто. Дело в том, что исторически, до появления DVI и тем более HDMI не существовало никакого способа узнать какие же разрешения поддерживает тот или иной монитор. Вы наверное помните, что года до 2002-го к мониторам прикладывали диск с драйвером и инструкцией в PDF. Так вот драйвер по сути был текстовым inf-файлом, который содержал только и исключительно список поддерживаемых монитором расширений, ну и его оригинальное название. А больше он не делал ничего. Потом впоследствии конечно эти драйвера стали встраиваться прямо в дистрибутив Windows самим Микрософтом, а интерфейсы DVI и HDMI позволяли получить список поддерживаемых режимов путём чтения микросхемы EDID на матрице.
Для тех кто не в курсе, поясню, что эта микросхема - аналог текстового драйвера, только в аппаратном исполнении и просто припаяна на саму матрицу. Т.е. путём перепрошивки туда можно записать любую пургу, хотя это конечно сложнее, чем редактирование inf-файла. Ну так вот. Все эти способы, так или иначе не дают надёжного определения рабочего разрешения. Поэтому я сделал следующие допущения:

1. LCD и AMOLED матрицы имеют только одно-единственное рабочее разрешение. Да, они могут работать в меньших, но в отличие от CRT, картинка будет мыльной и просто отвратительной. Поэтому данные режимы никто никогда не использует, а современные винды неплохо научились определять то самое дефолтное разрешение.
2. Эксперименты с максимально поддерживаемым разрешение и максимально поддерживаемой частотой экрана гораздо лучше и надёжнее ставить в свойствах системы, а не внутри какой-то игры. Игра зависнет и вам придётся собрать всю пыль с кнопки Reset.
3. Поэтому мы можем с уверенностью предполагать, что разрешение и частота обновления на рабочем столе - это единственное валидное разрешение полного экрана. Таким образом игра для полного экрана сможет использовать именно его и только его.
4. Разрешения которые нам вернул EnumDisplayModes с учётом того, что там много дубликатов и мусора мы можем пропустить сквозь фильтр разрешения десктопа. Очевидно что оконные разрешения не могут превосходить полноэкранное ни по какому из измерений и тем более не могут превосходить частоту кадровой или отличаться по битности.
Таким образом у нас всегда формируется список из актуальных и безопасных разрешений экрана.
5. И горячее сочетание Alt+Enter запоминает размер оконного режима - эта штука в старом ксаше так и не работала нормально.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 08-08-2023 в 05:41:

Цитата:

Потом впоследствии конечно эти драйвера стали встраиваться прямо в дистрибутив Windows самим Микрософтом, а интерфейсы DVI и HDMI позволяли получить список поддерживаемых режимов путём чтения микросхемы EDID на матрице

Для DDC даже в VGA разъемах заюзали несколько пинов.

Цитата:

1. LCD и AMOLED матрицы имеют только одно-единственное рабочее разрешение. Да, они могут работать в меньших, но в отличие от CRT, картинка будет мыльной и просто отвратительной. Поэтому данные режимы никто никогда не использует, а современные винды неплохо научились определять то самое дефолтное разрешение.

Это я в ЛС уже писал, но повторю для дискуссии тут.

Нынче люди больше ценят borderless windowed режим, нежели чем полную смену видеорежима. Возможно как раз дело в массовом переходе на LCD и в том что смена видеорежима обычно создает проблемы типа съехавших иконок на рабочем столе или сломанного альт-таба.

Даже для рендеринга в меньшем разрешении обычно делают просто управление собственно разрешением рендерера, а результат потом растягивается до нативного разрешения, линейно или нынче даже с FSR 1 для ленивых и FSR 2 для не самых ленивых.

Цитата:

4. Разрешения которые нам вернул EnumDisplayModes с учётом того, что там много дубликатов и мусора мы можем пропустить сквозь фильтр разрешения десктопа. Очевидно что оконные разрешения не могут превосходить полноэкранное ни по какому из измерений и тем более не могут превосходить частоту кадровой или отличаться по битности.

Я кстати когда-то вычислил что дубликаты там отчасти из-за режимов с другой частотой. Вот LCD, как и CRT разгоняются, поэтому в каком-то смысле смена видеорежима всё равно полезна -- просто не менять само разрешение рабочего стола, а только частоту обновления.

__________________
Xash3D FWGS форк

Отправлено FiEctro 08-08-2023 в 06:28:

>> Основная проблема была в том, что можно было выбрать неверное разрешение и даже спалить некоторые модели мониторов таким образом.
Или же получить от кого-то игру с конфигом для одного монитора, запустить на своём компьютере и получить Out Of Range или нечто подобное.

Эта проблема решается сбросом разрешения на то что у пользователя при первом запуске. Например если эта запись не найдена в реестре или конфиге.

Отправлено Дядя Миша 08-08-2023 в 06:52:

Цитата:

a1batross писал:
Для DDC даже в VGA разъемах заюзали несколько пинов.

Что-то такое припоминаю, да. Но оно не было обязательным к использованию.

Цитата:

a1batross писал:
Нынче люди больше ценят borderless windowed режим

borderless более лагучий на всех виндах старше семёрки.

Цитата:

a1batross писал:
или сломанного альт-таба

Но альт-таб кои-где разрабы сами выключали.

Цитата:

a1batross писал:
дубликаты там отчасти из-за режимов с другой частотой

Но только лишь отчасти.

Цитата:

a1batross писал:
просто не менять само разрешение рабочего стола, а только частоту обновления

Не-не-не. Рабочая частота должна быть одна - та же что и на рабочем столе.

Цитата:

FiEctro писал:
Например если эта запись не найдена в реестре или конфиге.

Старый ксаш сваливался в оконный режим если соответствующее разрешение не поддерживалось в полный экран. При этом окно своими краями зачастую уходило за пределы экрана.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 08-08-2023 в 08:17:

Дядя Миша
А не смотрел как этот механизм реализован в Унигине/Крайенгине/Анриле?

Отправлено Дядя Миша 08-08-2023 в 08:21:

Нет не смотрел. Скорее всего вариации на аналогичную тему.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-08-2023 в 10:32:

Я надеюсь будет побежден тот баг когда в оконном режиме в меню Xash3d нажимались не те элементы меню что под видимым курсором, а другие чуть в стороне.

Отправлено Дядя Миша 08-08-2023 в 14:58:

Там теперь и меню совершенно другое. Ничего общего со старым.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 08-08-2023 в 16:19:

Borderless windowed режим нужен. В fwgs его тоже до сих пор нет. Не один я о нем прошу, он очень удобен.

__________________
Мой мод на Xash

Отправлено Дядя Миша 08-08-2023 в 16:57:

Главное удобство от borderless - сообщения из телеги не мерцают, да.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 09-08-2023 в 06:53:

Цитата:

Дядя Миша писал:
Там теперь и меню совершенно другое. Ничего общего со старым.

Показал бы хоть скрин или видео, интересно глянуть

Отправлено Дядя Миша 09-08-2023 в 08:40:

Новый ксаш - он не про вау-эффекты, которые можно показать на картинках или видео. Хотя конечно со временем и таковые появятся.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 09-08-2023 в 14:43:

(_-=ZhekA=-_) Так всё же выложено давно о_О

Добавлено 09-08-2023 в 21:43:

Расскажи чем вообще занимался по движку в эти месяцы? С того поста в тг немало времени прошло.

Отправлено Дядя Миша 09-08-2023 в 15:06:

Вкратце - планирую собрать нечто вроде первой играбельной демки - порта первого квейка. Сам по себе он конечно не представляет интереса, но мне это нужно, чтобы протестировать все подсистемы движка в рабочем режиме и убедиться, что всё функционирует.
На следующий год планируется написание редактора ну и дальше будет только эволюционное обновление без нарушения совместимости.
На движке уже можно будет делать собственные игры.

Добавлено 09-08-2023 в 18:06:

Из действительно масштабных задач осталось три:

1. разработка сетевой подсистемы движка и её увязка с архитектурой движка и виртуальной машиной.
2. Завершение портирования библиотеки VCL на Shot
3. Разработка собственного редактора (собственно ключевые компоненты редактора, это как раз портированная библиотека VCL и мой язык).

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 10-08-2023 в 08:03:

Дядя Миша
Ты там кстати вкурсе кстати что первый квейк обновили ? Добавили новые компании и прочие плюшки.

Отправлено Дядя Миша 10-08-2023 в 08:28:

Цитата:

FiEctro писал:
Ты там кстати вкурсе кстати что первый квейк обновили

Ты имеешь виду версию от Night Dive Studios?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 10-08-2023 в 08:47:

Цитата:

Crystallize писал:
(_-=ZhekA=-_) Так всё же выложено давно о_О

Где?

Цитата:

Дядя Миша писал:
Вкратце - планирую собрать нечто вроде первой играбельной демки - порта первого квейка. Сам по себе он конечно не представляет интереса, но мне это нужно, чтобы протестировать все подсистемы движка в рабочем режиме и убедиться, что всё функционирует.

Это до конца года?

Цитата:

Дядя Миша писал:
3. Разработка собственного редактора (собственно ключевые компоненты редактора, это как раз портированная библиотека VCL и мой язык).

За основу будешь, что-то брать или полностью с нуля писать?
На какой редактор будет примерно похож?

Отправлено FiEctro 10-08-2023 в 09:31:

Цитата:

Дядя Миша писал:
Night Dive Studios

Да вроде оно. Насколько его ресурсы совместимы с твоим ремейком?

Отправлено Дядя Миша 10-08-2023 в 10:03:

Цитата:

(_-=ZhekA=-_) писал:
Это до конца года?

Да.

Цитата:

(_-=ZhekA=-_) писал:
За основу будешь, что-то брать или полностью с нуля писать?
На какой редактор будет примерно похож?

Редактор будет со сменными интерфейсами. Пользователи смогут сами добавлять в интерфейс элементами или написать полностью свой.
Разумеется первый пример интерфейса я напишу сам. Будет похоже на QuArK, но это пока в теории. Там есть несколько очень удачных находок в интерфейсе, которые я и хочу взять.
Ну а народ потом постепенно напишет интерфейс в стиле Хаммер, в стиле Юнити или Тренчбруума.

Добавлено 10-08-2023 в 13:03:

Цитата:

FiEctro писал:
Насколько его ресурсы совместимы с твоим ремейком?

Ресурсы XashNT не совместимы ни с чем, очевидно же. Но есть мощный конвертор ресурсов из старых игр в форматы, понятные XashNT.
В том римейке на KexEngine для меня представляет интерес только модельки монстров со скелеталкой и развесовкой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 10-08-2023 в 12:31:

Цитата:

Дядя Миша писал:
Ну а народ потом постепенно напишет интерфейс в стиле Хаммер, в стиле Юнити или Тренчбруума.

Как будут какие наработки, сбрось в ветке бетатестеров поиграться. Пускай он даже не выводит вьюпорты, а просто рисует кнопочки и прочие UI вещи. Кстати чем закончилась та эпопея с делфи библиотеками?

Цитата:

Дядя Миша писал:
Редактор будет со сменными интерфейсами.

Самое главное на будущее на забудь сделать чтобы игру можно было прямо в редакторе тестить, и да разрешение вьюпортов выставлять.

Отправлено Дядя Миша 10-08-2023 в 13:39:

Цитата:

FiEctro писал:
Как будут какие наработки, сбрось в ветке бетатестеров поиграться

Само собой.

Цитата:

FiEctro писал:
Кстати чем закончилась та эпопея с делфи библиотеками?

Цитата:

Дядя Миша писал:
2. Завершение портирования библиотеки VCL на Shot

Написал же. Пока не доделал - отложил. Библиотека там большая, сложная, а язык у меня - новый. Не такое это простое дело - создавать языки. Сперва я должен был убедиться что он у меня правильно работает и производительности ему хватит. Поэтому занялся портированием игрового кода, кода меню, HUD. Таким образом язык стал гораздо стабильнее, я в нём исправил некоторые ошибки. Скоро вернусь к портированию VCL.

Цитата:

FiEctro писал:
Самое главное на будущее на забудь сделать чтобы игру можно было прямо в редакторе тестить

Дурацкая это затея - игра в редакторе. Тут только два варианта возможны:
1. Тест в редакторе будет отличаться от теста в движке
2. Игровые форматы будут вообще без оптимизации
Классическая задачка про два стула.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 10-08-2023 в 14:03:

Цитата:

Дядя Миша писал:
Дурацкая это затея - игра в редакторе.

В анриле круто сделано, хочешь тестируй сразу во вьюпорте, а хочешь в отдельном окне и еще несколько режимов есть и все это налету, красота

очень удобно тестить логику ну и конечно же настраивать освещение и материалы

Отправлено XaeroX 10-08-2023 в 14:26:

Цитата:

(_-=ZhekA=-_) писал:
В анриле круто сделано, хочешь тестируй сразу во вьюпорте, а хочешь в отдельном окне и еще несколько режимов есть и все это налету, красота

Што ж вы халфу мучили, а не перешли на анрил сразу в 1998 году?
Емнип, всё это было в UnrealEd с самых первых версий.

Добавлено 10-08-2023 в 10:26:

Цитата:

Дядя Миша писал:
Классическая задачка про два стула.

Ну в Serious Sam (2001) как-то же сделали. Вполне удобно было, хотя я под него совсем мало помапал.

__________________

Отправлено Дядя Миша 10-08-2023 в 15:27:

Цитата:

(_-=ZhekA=-_) писал:
хочешь тестируй сразу во вьюпорте, а хочешь в отдельном окне и еще несколько режимов есть и все это налету

Так где же ваши с Фиэктрой игры? Я от вас только и слышу как удобно работать что в Юнити, что в Унреале. Ну раз удобно, значит и работать быстро, значит вы должны были давно уже управиться.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 10-08-2023 в 15:32:

Дядя Миша
Дык это. Все силы уходят на то, чтобы радоваться обилию крутых фичей. А как нарадуешься текущим - появляются новые. Когда тут игру делать?

__________________

Отправлено Дядя Миша 10-08-2023 в 17:31:

Один из наших форумчан уже третью или четвертую игру на GZDoom сделал при этом. В котором нет ни блюпринтов ни предпросмотра уровней. И даже не бегал за мной и не рассказывал как там всё круто "просто берёшь и делаешь как тебе нужно всё что угодно". А вот игру - таки сделал и не одну.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XF-Alien 10-08-2023 в 19:08:

Цитата:

Дядя Миша писал:
Так где же ваши с Фиэктрой игры? Я от вас только и слышу как удобно работать что в Юнити, что в Унреале. Ну раз удобно, значит и работать быстро, значит вы должны были давно уже управиться.

Тебе интересно было бы почитать уловный dev-log про разработку чего-то конкретного на этих движках от лица автора?

__________________
To start the match, Let's draw the sketch, Then add some magic from your heart!
Take gold and blue, Take silver too and put a sparkle in your art!
I love that dress, I love It, YES!!! I love the way It makes me feel.
I love the shoes, I love to choose, It was a dream and now It's real!

Отправлено (_-=ZhekA=-_) 10-08-2023 в 19:51:

Цитата:

XaeroX писал:
Што ж вы халфу мучили, а не перешли на анрил сразу в 1998 году?

А я тогда не знал

Цитата:

Я же уже говорил, что игра пока стоит на паузе

А так я уже два конфигуратора написал на анриле, которые уже готовы

Цитата:

Дядя Миша писал:
И даже не бегал за мной и не рассказывал как там всё круто

Я за тобой не бегаю, мне это не нужно, я тихо спокойно делаю свои проекты на анриле

Если тебе не интересно, как работается на других движках, то ок писать больше про это не буду

Отправлено Дядя Миша 10-08-2023 в 21:09:

Цитата:

XF-Alien писал:
уловный dev-log про разработку

Всё равно это никто не способен оценить кроме самого автора. А вот результат - очень даже способны. Если он есть конечно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 10-08-2023 в 22:13:

Цитата:

(_-=ZhekA=-_) писал:
Я за тобой не бегаю, мне это не нужно

Да ладно ты, не парься, это такая фигура речи у Дяди Миши

__________________

Отправлено SNMetamorph 11-08-2023 в 08:05:

Цитата:

Очень резонный вопрос. Обычно люди, которые нахваливают юнити/анрил и в особенности блендер, никогда ничего толкового на этих инструментах не делали (да и врят ли сделают). Суть вся ведь вообще не в инструментах.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено FiEctro 11-08-2023 в 08:37:

Цитата:

А где бамп? А где ротатабля

? А донат заслал? Ну сделали мы несколько ГК игр, но толку мне их вам показывать? Это совсем другой жанр и уровень отличный от кваки. Обычные мобильные дрочильни которыми завален весь гугл плей. Движков копирующих кваку десятки, и кому они нафиг нужны? Я даю тебе фидбек что вот есть такие интересные фишки которые уже существуют давным давно, не хочешь - не делай, я тебя не заставляю. Но я уже вижу как народ мучается с текущем ксашем, где нет ни профайлера, ни нормального встроенного отладчика, ни нормальных инстументов для работы с UI, компиляторы с какими то странными и нелогичными ограничениями, жуткие просадки фпс на ровном месте и многое многое другое, вот смысл делать тоже самое? Почему нельзя сразу всё учесть в новом движке? Я ж помочь хочу, а не обосрать. Ксерокс этого тоже к сожалению не понимает, и воспринимает мои фидбеки в штыки.

Отправлено (_-=ZhekA=-_) 11-08-2023 в 08:43:

Дядя Миша
SNMetamorph
Старая версия одного готовых из конфигураторов лежит тут, можно скачать и по юзать

https://hlfx.ru/forum/showthread.php?s=&threadid=5828

Цитата:

SNMetamorph писал:
Обычно люди, которые нахваливают юнити/анрил

Я ничего не нахваливаю, в анриле помимо плюсов просто херова тонна минусов, с которыми сталкиваешься только тогда, когда начитаешь конкретно в нем работать

Хотел, как лучше, а получилось, как всегда...

Отправлено Дядя Миша 11-08-2023 в 09:10:

Цитата:

FiEctro писал:
Ну сделали мы несколько ГК игр, но толку мне их вам показывать?

Стесняешься что ли?

Цитата:

FiEctro писал:
Это совсем другой жанр и уровень отличный от кваки

Разве же я требовал от вас игр, непременно похожих на кваку? Был еденичный случай, когда Pod-Stas уверенно заявил, что он ку2 портирует на юнити вообще без проблем. Я ему тогда сказал - хотя бы один уровень, но чтоб аутентично было. Нуивот - до сих пор ждём.

Цитата:

FiEctro писал:
Обычные мобильные дрочильни которыми завален весь гугл плей

Ну это то, в чём Юнити традиционно силён, да.

Цитата:

FiEctro писал:
Но я уже вижу как народ мучается с текущем ксашем

Мучаться со старым ксашем или нет - это личный выбор каждого. Я вот к примеру решил что не стоит. А они решили что стоит.

Цитата:

FiEctro писал:
Я даю тебе фидбек что вот есть такие интересные фишки которые уже существуют давным давно

Внимательно читаю и запоминаю. Но в конце каждой фразы ты непременно добавляешь "а вообще там можно сделать всё что угодно и как угодно". Теперь я понял что под словами "что угодно и как угодно" имеется в виду мобильная дрочильня. Немного конкретики не помешает.

Цитата:

FiEctro писал:
вот смысл делать тоже самое? Почему нельзя сразу всё учесть в новом движке?

Почему ты решил что я делаю тоже самое и не учитываю всё в новом движке?

Цитата:

(_-=ZhekA=-_) писал:
в анриле помимо плюсов просто херова тонна минусов, с которыми сталкиваешься только тогда, когда начитаешь конкретно в нем работать

Это с любым сложным софтом так.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 11-08-2023 в 10:18:

Цитата:

FiEctro писал:
Но я уже вижу как народ мучается с текущем ксашем

Интересно, почему тогда никто не жалуется ни мне, ни на этот форум? Ну это при том что бОльшая часть этого самого народа со мной так или иначе контактирует. Особенно хотелось бы слышать ту часть, которая реально делает много крутого уже на том, что есть вот в данный конкретный момент, но от них я тоже жалоб не слышу. Периодически они у меня задают вопросы, или подкидывают какие-то неплохие идеи, но ещё никто ни разу не жаловался.

Цитата:

FiEctro писал:
где нет ни профайлера, ни нормального встроенного отладчика

С чего это вдруг? Всё что есть для плюсов, а есть много чего, прекрасно работает. Более того, никто не привязывает к конкретным инструментам: хочешь юзай вижловый дебаггер и профайлер, хочешь Tracy/VTune. Кому что удобнее.

Цитата:

FiEctro писал:
ни нормальных инстументов для работы с UI

А это правда. И я пока не знаю, что делать с этим.

Цитата:

FiEctro писал:
жуткие просадки фпс на ровном месте

Тоже правда, но лишь отчасти. Не на ровном месте, а вполне в конкретных кейсах. И это всё тупо потому что никто еще не занимался оптимизацией, т.к. пока что других более важных дел до сих пор выше крыши, а рабочих рук не так уж много. Это не техническая проблема, а организационная.

Добавлено 11-08-2023 в 14:18:

Цитата:

Дядя Миша писал:
Мучаться со старым ксашем или нет - это личный выбор каждого. Я вот к примеру решил что не стоит. А они решили что стоит.

А знаешь почему решили? Потому что оно уже вот есть готовое. Что-то криво, чего-то пока нет, но в целом оно рабочее, и не заброшенное, и потихоньку все инструменты развиваются. Что и подтверждается такими проектами как Diffusion и HL: History of Kumertau.
Почему не взять и сделать с нуля что-то крутое, учтя прошлые ошибки? Потому что будет адски долго и вообще без гарантий того, что в итоге получится что-то юзабельное и подходящее под задачи. Одно дело просто написать минимально рабочий прототип, и совсем другое пофиксить критичные баги, учесть предложения юзеров, всё оттестировать нормально. Это тысячи человекочасов, которые надо ещё где-то взять. То есть нужно либо очень много людей, либо чтобы та часть людей которая уже включена в рабочий процесс, тратила очень много времени. Звучит как бы нереалистично в современных реалиях.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Casperx69x 11-08-2023 в 10:59:

Мимо крокодил, работая под ксашем.

Я делаю свой мод под Праймом,и ксашем который обновляют.

У ксаша есть своя аудитория, именно из игроков, и она огромная, и вкатиться туда вполне себе хороший кейс, чем очередная поделка от ноунейма на анриле/юните которого никто не знает.

Теперь почему я выбрал ксаш. Он простой. Буквально. Даже не смотря на всякие плюшки типо вьюпорта на анриле и блюпринт там, в ксаше все еще удобнее делать многие вещи, исходя из кол-ва человекочасов. Так же не смотря, на какие-то анальные ограничения, которые были введённые ради хз чего, их можно обойти, код довольно понятен даже для нуба, а уж про портирование контента я уж молчу. Именно ассеты перетягивать на ксаш под праймом, проще простого, ДАЖЕ НЕ СМОТРЯ на то, что начинал с инструментов которые работают из под консоли, без минимального интерфейса.

В данный момент у ксаша много проблем, но в сравнении с теми проблемами, что есть у других движков, это чепуха. Субъективное мнение конечно же, но оно такое уж извините. У меня очень сильно возрос аппетит, и приходилось просить пофиксить какие-то баги, лимиты, графику и прочее подтянуть, но с той скоростью с какой это делается меня устраивает. Это все еще быстрее, чем ковырять огромные движки.

Когда я перешел на ксаш, я ожидал, что комьюнити будет более сговорчивое, и поэтому зарегистрировался тут, и очень был опечален тем, что вместо того, что уже готовое решение забросили, это странно. Потратить много времени, чтоб сделать хорошую вещь, и тут же переключится на другое, оставив все в огне, но благо есть другие люди.

Отправлено Дядя Миша 11-08-2023 в 11:31:

Цитата:

SNMetamorph писал:
Интересно, почему тогда никто не жалуется ни мне, ни на этот форум?

https://hlfx.ru/forum/showthread.ph...5168#post215168
а это что?

Цитата:

SNMetamorph писал:
Это тысячи человекочасов, которые надо ещё где-то взять. То есть нужно либо очень много людей, либо чтобы та часть людей которая уже включена в рабочий процесс, тратила очень много времени. Звучит как бы нереалистично в современных реалиях.

Я понял, оригинальный Xash3D при таких рассуждениях вообще не мог появиться.

Цитата:

Casperx69x писал:
анальные ограничения, которые были введённые ради хз чего

На минуточку в 96-м году компьютеры были слабее чем сегодня. Ну то что чтобы прямо совсем слабее - на них тоже тогда виндоуз устанавливали, прямо как сегодня. Но тем не менее.

Цитата:

Casperx69x писал:
и очень был опечален тем, что вместо того, что уже готовое решение забросили, это странно

Xash3D - побочный продукт, разминка перед собственным проектом. Я сделал всё что наметил, я заложил огромную кучу решений которые можно развивать и улучшать, вокруг движка сформировалось коммунити, которому я могу со спокойной душой доверить дальнейшую судьбу проекта - разве это плохо? Или я должен как Торвальдс всю жизнь ковырять ядро одного и того же Линукса?

Цитата:

Casperx69x писал:
Потратить много времени, чтоб сделать хорошую вещь, и тут же переключится на другое, оставив все в огне

Как ни крути, но Xash3D очень сильно зависим от халфы. Это не совсем то, чего бы мне хотелось.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 11-08-2023 в 11:41:

Цитата:

Дядя Миша писал:
https://hlfx.ru/forum/showthread.ph...5168#post215168
а это что?

Так где ж тут жалоба? Человек задал вопрос и зарепортил баг.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено FiEctro 11-08-2023 в 11:44:

Цитата:

Дядя Миша писал:
Внимательно читаю и запоминаю. Но в конце каждой фразы ты непременно добавляешь "а вообще там можно сделать всё что угодно и как угодно". Теперь я понял что под словами "что угодно и как угодно" имеется в виду мобильная дрочильня. Немного конкретики не помешает.

Я не помню где такое писал, возможно я неправильно выразился. Я говорил о том что IDE Юнити и анрила очень хорошо сочетает в себе множество инструментов которые в других движках разбросаны как отдельные программы.

Насчет дрочилен, ну а что дрочильня разве не игра? Сколько дрочилен сделано на ксаше? Ксаш же портировали на андроид и сенсор поддерживает, в чем проблема то? Если тебе конкретно интересно что же делают люди на Юнити то вбей на ютубе запрос: best unity games 2023 или 2022 или какой любой другой год, там наверное раз в месяц или квартал делают подборки разных игр, от спинномозговых дрочилен до весьма серьёзных проектов. Я не понимаю почему конкретно по моим не очень то и высоким скиллам ты меришь движки. Такой подход вообще не объективен.

Цитата:

SNMetamorph писал:
Интересно, почему тогда никто не жалуется ни мне, ни на этот форум? Ну это при том что бОльшая часть этого самого народа со мной так или иначе контактирует. Особенно хотелось бы слышать ту часть, которая реально делает много крутого уже на том, что есть вот в данный конкретный момент, но от них я тоже жалоб не слышу. Периодически они у меня задают вопросы, или подкидывают какие-то неплохие идеи, но ещё никто ни разу не жаловался.

Ну вот про профайлер, фпс и лимиты мы буквально недавно обсуждали.

Цитата:

Дядя Миша писал:
Я понял, оригинальный Xash3D при таких рассуждениях вообще не мог появиться.

Ксаш не должен быть клоном Юнити я считаю, но и не должен быть устаревшим движком где всё делается через блокнотик.

Отправлено SNMetamorph 11-08-2023 в 11:55:

Цитата:

Дядя Миша писал:
Я понял, оригинальный Xash3D при таких рассуждениях вообще не мог появиться.

Так он как раз и вполне подходит под мои рассуждения.
1) Это продукт который сразу под готовую аудиторию халфомоддеров появился. Может он и не подразумевался таким, но то что он именно вот такой - это факт
2) Он в себе наследует все подходы и контент которые были созданы за всё время существования HL1
Всё то же касается и XashXT, который в себе унаследовал многое из спирита и местами из первой паранои даже.
Это совсем не то же самое, как если бы появился какой-то новый продукт в вакууме и ни с чем напрямую не связанный, и знакомый только полутора землекопам. А все ролики на YT которые имеют отношение к HL или в целом к играм Valve, собирают не миллионы, но сотни тысяч просмотров вполне себе уверенно до сих пор.

Добавлено 11-08-2023 в 15:55:

Цитата:

Дядя Миша писал:
Как ни крути, но Xash3D очень сильно зависим от халфы. Это не совсем то, чего бы мне хотелось.

Вот в этом и суть как раз. Xash3D привлёк к себе внимание именно из-за привязки в халфе.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено FiEctro 11-08-2023 в 11:57:

Цитата:

Casperx69x писал:
Теперь почему я выбрал ксаш. Он простой. Буквально.

Вот это кстати очень важный момент, но я уточню, ксаш не то чтобы проще других движков, но он имеет кучу контента под себя. Т.е. на нём можно учиться, смотреть как сделано у других и самому даже что то сделать из этого контента. Но всё же при попытке как то осовременнить движок вылезает та же болезнь которую раньше приписывали Юнити - всё надо писать самому с нуля. И если под Юнити это делать намного проще за счёт кучи встроенных функций, где всё важное уже обёрнуто, плюс отладчик уже синхронизирован с IDE. То тут тебе голые кресты с указателями, ну и отладка по хардкору, что вообще нельзя назвать ПРОСТОЙ разработкой. Я это не пишу чтобы как то принизить ксаш, нет, я просто делюсь с тем к чему я сам пришел. Я прекрасно понимаю что можно при желании потратить несколько лет и получить и на том что есть конфетку, но многих простых и очевидных вещей тебе придётся делать с 0, и хуже того лезть ещё в форматы. Например чтобы сделать какие нибудь регдоллы.

Отправлено Crystallize 11-08-2023 в 11:59:

Цитата:

Дядя Миша писал:
Xash3D - побочный продукт, разминка перед собственным проектом.

Мне показалось что человек имел в виду ксашмод, может быть в том числе просто.

Отправлено Дядя Миша 11-08-2023 в 11:59:

Цитата:

SNMetamorph писал:
Так где ж тут жалоба? Человек задал вопрос и зарепортил баг.

А багрепорт по твоему не жалоба? Это такая форма сказать "спасибо" разработчикам? Ну ок.

Цитата:

FiEctro писал:
Я говорил о том что IDE Юнити и анрила очень хорошо сочетает в себе множество инструментов которые в других движках разбросаны как отдельные программы.

Нет-нет, ты всегда говоришь, что можно дописать всё что угодно, как тебе нужно.

Цитата:

FiEctro писал:
Насчет дрочилен, ну а что дрочильня разве не игра?

Видимо ты считаешь что да, раз стесняешься показывать.

Цитата:

FiEctro писал:
но и не должен быть устаревшим движком где всё делается через блокнотик

Разумный подход - когда доступны оба варианта. И через блокнотик и через GUI.

Цитата:

SNMetamorph писал:
Это совсем не то же самое, как если бы появился какой-то новый продукт в вакууме и ни с чем напрямую не связанный

Эти движки как минимум связаны одним разработчиком. Ну и тем, собственно фактом, что на новом ксаше тоже можно будет без проблем запилить халфу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 11-08-2023 в 12:01:

Цитата:

SNMetamorph писал:
HL: History of Kumertau

Не стесняйтесь постить темы о проектах, никто бить не будет. Или будут?

Отправлено FiEctro 11-08-2023 в 12:05:

Цитата:

Дядя Миша писал:
Нет-нет, ты всегда говоришь, что можно дописать всё что угодно, как тебе нужно.

Далеко не всё, Юнити тоже имеет свои ограничения. Но это знаешь, как сравнивать размер Луны и размер Солнца. Я мог бы расписать длиннопост почему Юнити говно и я не советую его использовать, но это было бы лицемерием потому что собственно такое можно написать про любой движок. И Ксаш далеко не плохой движок, он мне нравится, но потом я из него просто вырос. Программировать под него мне не хватает знания крестов, а писать код под всякие элементарные вещи вроде физики и анимаций, надо много, надо много возиться с конвертацией и подготовкой ресурсов. Может я даже не прав в этом, может если бы была нормальная документация как на Юнити, я бы даже в сторону Юнити не посмотрел, и сейчас бы с пеной у рта доказывал всем что лучше Ксаша движка нет, что на нем можно дописать всё что угодно, как тебе нужно. А все эти Анрилы и Юнити это бесполезная развлекуха для зумерков и мобильных дрочилен.

Отправлено SNMetamorph 11-08-2023 в 12:17:

Цитата:

Crystallize писал:
Не стесняйтесь постить темы о проектах, никто бить не будет. Или будут?

На ModDB уже есть страничка, а разрабу как я понимаю просто лень еще где-то на форумах дублировать. Но я думаю лучше его самого об этом спросить.

Добавлено 11-08-2023 в 16:17:

Цитата:

FiEctro писал:
То тут тебе голые кресты с указателями, ну и отладка по хардкору, что вообще нельзя назвать ПРОСТОЙ разработкой.

Тут получается палка о двух концах: с одной стороны использование плюсов повышает порог вхождения, но с другой сильно расширяет возможности моддинга - есть примеры товарищей которые какие-то просто сумашедшие вещи делали даже в голдсорсе, хоть я и совсем не сторонник подхода пытаться что-то патчить в движке.

А по поводу голых указателей - так в плюсах, в отличие от Си, можно и не работать ручками с памятью вообще, хоть язык и даёт такую возможность. Я вообще едва ли могу вспомнить, когда мне в последний раз приходилось вручную работать с памятью. Есть куча разных контейнеров на любой вкус и задачу, а если тебе всё-таки понадобилось что-то такое, можно использовать std::shared_ptr/unique_ptr которые на себя берут ответственность деаллоцировать объект когда он больше не будет нужен. Плюс современные IDE немалую часть ошибок покажут еще даже до компиляции. Например, когда ты попытаешься из функции вернуть указатель на переменную, которая находится на стеке. Или когда пытаешься на стеке аллоцировать какой-то просто громадный массив, который может и не уместиться в стеке. Например, VS такое уже давно умеет подсвечивать. Ну и еще есть всякие статические анализаторы по типу PVS Studio и CodeQL, тоже очень многое покажут, чего ты сам мог не углядеть.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено FiEctro 11-08-2023 в 12:20:

Цитата:

SNMetamorph писал:
Тут получается палка о двух концах: с одной стороны использование плюсов повышает порог вхождения, но с другой сильно расширяет возможности моддинга - есть примеры товарищей которые какие-то просто сумашедшие вещи делали даже в голдсорсе, хоть я и совсем не сторонник подхода пытаться что-то патчить в движке.

Не всегда так. Код на крестах в игровых двикжах очень архитектурно завязан. То есть порой чтобы написать что то, тебе нужно переписать то что уже было написано ранее. В новых движках твои скрипты изолированы от основного кода, и при этом позволяют получить широкий доступ не конфликтуя уже с тем что есть.

Цитата:

SNMetamorph писал:
А по поводу голых указателей - так в плюсах, в отличие от Си, можно и не работать ручками с памятью вообще, хоть язык и даёт такую возможность. Я вообще едва ли могу вспомнить, когда мне в последний раз приходилось вручную работать с памятью. Есть куча разных контейнеров на любой вкус и задачу, а если тебе всё-таки понадобилось что-то такое, можно использовать std::shared_ptr/unique_ptr которые на себя берут ответственность деаллоцировать объект когда он больше не будет нужен. Плюс современные IDE немалую часть ошибок покажут еще даже до компиляции. Например, когда ты попытаешься из функции вернуть указатель на переменную, которая находится на стеке. Или когда пытаешься на стеке аллоцировать какой-то просто громадный массив, который может и не уместиться в стеке. Например, VS такое уже давно умеет подсвечивать. Ну и еще есть всякие статические анализаторы по типу PVS Studio и CodeQL, тоже очень многое покажут, чего ты сам мог не углядеть.

Я не спорю, но где об этом почитать в конктексте Ксаша вот? Конечно вы меня отправите как и любого новичка становиться гуру C++, где он скорее всего плюнет на всё это, и выберет что попроще. Указатели в шарпах тоже кстати есть, но ими не тычут тебе в нос, т.е. это приятное дополнение, а не стрельба из пушки по воробьям.

Отправлено Crystallize 11-08-2023 в 12:25:

Цитата:

SNMetamorph писал:
На ModDB уже есть страничка

Представь насколько мала аудитория Моддб если даже я как олдфаг туда не хожу, а бываю только на социалках и на этом форуме.

Добавлено 11-08-2023 в 19:23:

Цитата:

SNMetamorph писал:
Я вообще едва ли могу вспомнить, когда мне в последний раз приходилось вручную работать с памятью.

CBaseEntity *pGovno = UTIL_FindEntityByTargetname считается?
Начинаю понимать почему ~X~ писал такие посты

Добавлено 11-08-2023 в 19:25:

Цитата:

FiEctro писал:
Я не спорю, но где об этом почитать в конктексте Ксаша вот?

Я однажды на КСМ просил гайд по кодингу для ксашмода, но народ не понял, зачем это.

Отправлено SNMetamorph 11-08-2023 в 12:26:

Цитата:

Crystallize писал:
Представь насколько мала аудитория Моддб если даже я как олдфаг туда не хожу, а бываю только на социалках и на этом форуме.

Эт че, шутка какая-то? Покажите мне какой-нибудь сравнимый по дневной посещаемости ресурс по моддингу хл. Gamebanana, например, сильно уступает. Всякие форумы - уже тем более.
https://www.moddb.com/games/half-life/stats

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено FiEctro 11-08-2023 в 12:30:

Цитата:

SNMetamorph писал:
Эт че, шутка какая-то? Покажите мне какой-нибудь сравнимый по дневной посещаемости ресурс по моддингу хл. Gamebanana, например, сильно уступает. Всякие форумы - уже тем более.

К сожалению не шутка, сейчас все эти сайты и форумы это что то олдфаговое из нулевых. Сейчас все сидят в соцсетях, месседжерах, ютуб каналах и т.д. Спроси кого нить из матерых разрабов работающих в крупных студиях про МодДб или гейбанану (которая зачем то лезет в политику), скорее всего они пожмут плечами. Ибо эти сайты хоть и известны, но в очень узких кругах.

Отправлено SNMetamorph 11-08-2023 в 12:35:

Цитата:

Crystallize писал:
CBaseEntity *pGovno = UTIL_FindEntityByTargetname считается?
Начинаю понимать почему ~X~ писал такие посты

Так ты тут где-то аллоцируешь память? Нет. Освобождаешь? Нет. Это тупо ссылка. В плюсах для этого можно использовать как указатели, так и то что там зовётся прямо так и зовётся ссылками. Только вот в ссылку нельзя всунуть nullptr, который мог бы означать в данном контексте, что объект не был найден.

Добавлено 11-08-2023 в 16:35:

Цитата:

FiEctro писал:
Я не спорю, но где об этом почитать в конктексте Ксаша вот? Конечно вы меня отправите как и любого новичка становиться гуру C++, где он скорее всего плюнет на всё это, и выберет что попроще. Указатели в шарпах тоже кстати есть, но ими не тычут тебе в нос, т.е. это приятное дополнение, а не стрельба из пушки по воробьям.

Я согласен что документация нужна, проблема в том что её некому писать на данном этапе. Да, у меня есть определённый задел в виде сайта с документацией. И есть идеи, о чём можно написать. Но у меня тупо не хватает времени пополнять его новыми статьями. Мне в целом помогают периодически с некоторыми частями документации, но этого всё ещё мало. Это само по себе тоже довольно масштабная работа.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено FiEctro 11-08-2023 в 12:38:

Цитата:

SNMetamorph писал:
Я согласен что документация нужна, проблема в том что её некому писать на данном этапе. Да, у меня есть определённый задел в виде сайта с документацией. И есть идеи, о чём можно написать. Но у меня тупо не хватает времени пополнять его новыми статьями. Мне в целом помогают периодически с некоторыми частями документации, но этого всё ещё мало. Это само по себе тоже довольно масштабная работа.

У меня была мысль набросать хотя бы что то с помощью ChatGPT. Он довольно неплохо понимает HLSDK. Но конечно это чисто эксперимент, окончательным продуктом считать такое сложно.

По мне описывать абсолютно всё не нужно, достаточно просто сделать введение в базовую разработку. Например ввиде серии уроков как сделать платформер в стиле марио. Тут тебе и кодинг, и отладка, и работа с ресурсами и анимациями, и офомление отдельной папки мода, и может даже работа с HUD. И при этом сам проект не масштабный для новичка.

Отправлено SNMetamorph 11-08-2023 в 12:40:

Цитата:

FiEctro писал:
По мне описывать абсолютно всё не нужно, достаточно просто сделать введение в базовую разработку.

Вот такое как раз и нужно в первую очередь. А то приходят люди которые вообще не в курсе всей этой темы, спрашивают как и что делать, какие программы нужны. Вот им бы дать статью, в которой это всё расписано - но её нет. Благо хотя бы другие люди не ленятся отвечать на вопросы, за что им спасибо.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Crystallize 11-08-2023 в 12:44:

Цитата:

SNMetamorph писал:
Так ты тут где-то аллоцируешь память? Нет.

Это тоже указатель, он бывает невалиден, или бывает что исчезает при смене кадра или по выходе из функции.

Отправлено SNMetamorph 11-08-2023 в 12:46:

Цитата:

Crystallize писал:
Это тоже указатель, он бывает невалиден, или бывает что исчезает при смене кадра или по выходе из функции.

Каким образом эта функция может вернуть невалидный указатель? А если тебе ссылку надо где-то долговременно хранить, для этого есть класс EHANDLE

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 11-08-2023 в 12:55:

Цитата:

FiEctro писал:
Но это знаешь, как сравнивать размер Луны и размер Солнца.

Вот я и спрашиваю - ты за Луну, за Советскую Страну или ты за Солнце, за пузатого японца?

Цитата:

FiEctro писал:
То тут тебе голые кресты с указателями, ну и отладка по хардкору

Кстати в Шоте тоже есть указатели. Но падаёт он тихо, прямо в движковую консоль. Я ж говорил, что начинающих программистов больше всего пугает не тот факт что программа упала, а этот жуткий виндовый звук ошибки по дефолту

Добавлено 11-08-2023 в 15:55:

Цитата:

SNMetamorph писал:
Каким образом эта функция может вернуть невалидный указатель?

Например если ничего не нашлось.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XF-Alien 11-08-2023 в 19:32:

Цитата:

Casperx69x писал:
У ксаша есть своя аудитория, именно из игроков, и она огромная, и вкатиться туда вполне себе хороший кейс, чем очередная поделка от ноунейма на анриле/юните которого никто не знает.

Для нас, моддеров, "хороший кейс" это несколько десятков тысяч скачиваний от силы. Только вот для ноунейм-инди это базовый минимум, который почти наверняка может себе позволить разработчик и считается по меркам индустрии в целом - отправной точкой (для инди, разумеется). Дальше - сколько получится, в зависимости от того, насколько выстрелит игра. Есть куча примеров от одиночек/маленьких групп, которые вполне себе смогли. Иными словами, шанс вполне есть.
А вот для моддеров - это уже предельный и непреодолимый потолок, обусловленный конечностью старперов-халферов со всего мира. Есть, конечно, исключения, в виде первой Паранойи, КоФа и Свена (и еще, быть может, какого-нибудь брутала), но это <0,1% от числа всех выпущенных модов под халфу за все время.

Вообще, интересные тут мысли мелькают у вас касательно игростроя. Сравнивания всякие UE с ксашем. Вот делал-делал мод, потом взял и перетащил папку своего проекта из директории хл в директорию ксаша - все, без пяти минут инди-гейм-девелопер со стажем

Отправлено SNMetamorph 11-08-2023 в 19:56:

Цитата:

XF-Alien писал:
Только вот для ноунейм-инди это базовый минимум, который почти наверняка может себе позволить разработчик и считается по меркам индустрии в целом - отправной точкой (для инди, разумеется).

Откуда информация? Какая-то есть статистика или цифры просто с потолка взяты? Я знаю немало инди-игр, которые валяются никому нафиг не нужные в стиме (что вполне под собой имеет логичное обоснование). Сейчас поясню. Когда ты делаешь инди-игру, тебе нужно как-то выделиться и привлечь внимание среди сотен (или даже тысяч уже) точно таких же игр. Когда же ты делаешь мод либо игру под уже конкретное сформировавшееся комьюнити, проектов каких-то там, понятное дело, гораздо меньше чем инди-игр в целом, и соответственно при таком количестве уже вообще на любой проект обратят внимание как минимум. А за примером далеко идти не надо: рейтрейсинг прикрученый к HL1 на ксаше зафорсился без преувеличений на весь мир, и про него уже миллионы людей в курсе. Крупнейшие мировые околоигровые издания тоже писали про него:
https://www.pcgamer.com/ray-traced-...oks-incredible/
https://www.youtube.com/watch?v=btVbRjj9YJo
https://www.theverge.com/2023/2/22/...-nvidia-rtx-gpu
А это как бы даже не какая-то отдельная игра, а просто мод.

Добавлено 11-08-2023 в 23:56:

Цитата:

XF-Alien писал:
А вот для моддеров - это уже предельный и непреодолимый потолок, обусловленный конечностью старперов-халферов со всего мира. Есть, конечно, исключения, в виде первой Паранойи, КоФа и Свена (и еще, быть может, какого-нибудь брутала), но это <0,1% от числа всех выпущенных модов под халфу за все время.

Так и модов то настолько крупных, как те которые ты перечислил, почти что нету. Были бы - о них бы и знало больше людей.

Резюмирую: я не знаю, с чего ты вдруг решил что ситуация с инди-проектами как-то в лучшую сторону отличается от ситуации с модами. В обоих случаях тяжело привлечь внимание к проекту, но в случае с модами это чуточку проще, и я уже расписал выше, почему так.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено XF-Alien 11-08-2023 в 21:04:

Цитата:

SNMetamorph писал:
Откуда информация?

Да всего лишь-то из личного опыта. На примере Перилоса это и было явно продемонстрировано. Почти полное отсутствие пиара + игра крепкий середнячок, явно не хватающий звезд с неба. Мне, чтоб добиться подобных показателей для Дельты, пришлось куда больше трудиться и вкладываться в проект. Это еще при том, что какие-то неведомые мне ребяты (за что им ресепектище и надо им сказать спасибо в титрах новой версии..) очень постарались, форся мой мод на релизе везде и вся в рунете.

Если тебя интересуют игры-примеры то вот моя подгонка, где либо разраб-одиночка, либо очень небольшой коллектив: The Forest 1-2, Subnautica (но не уверен насколько они не/многочисленны) 7 days to die, Bright Memory, Darkwood, Melody's Escape, Industria, Nightmare of Decay, Mist Survival, Near Death. Praey for the Gods, Witch Hunt, Skinwalker Hunt (ага, привет Gua с КСМ

), Deathly Stillness, Hedon Bloodrite, ColdSide. В конце концов, игры от Носкова. И это только лишь то, во что играл лично я. Это еще без учета всякой попсы типа Gris, BattleBit Remastered и прочих Limbo с Superhot (ничего против них не имею, просто они для меня говно, я такое ни-ни).

Цитата:

SNMetamorph писал:
Я знаю немало инди-игр, которые валяются никому нафиг не нужные в стиме

Да, можно справедливо заметить, что за их спинами целая куча никому не известных трупов, но я тогда задам встречный вопрос: а много ли среди этих трупов, которые делались так же качественно и с любовью, как вышеперечисленные мной? С ужасом обнаружишь, что большинство - пиксельное говно или вообще моноцвет про летающий кубик на синем фоне, образно говоря. Хотя, и среди таких есть, кто смог, чего уж (тот же супрехот).

Цитата:

SNMetamorph писал:
Крупнейшие мировые околоигровые издания тоже писали про него:
https://www.pcgamer.com/ray-traced-...oks-incredible/

https://www.pcgamer.com/half-life-d...-in-the-making/ - ну я вон тоже есть на pcgamer. И без всяких ксашей и лучей, только что с того?

Цитата:

SNMetamorph писал:
и про него уже миллионы людей в курсе

Про N-word человека с часами тоже писали на весь мир. И про ку1 на осциллографе. Ты ведь не будешь утверждать, что делать игры для часов и осциллографов это будущее, а ПК и консоли - вчерашний день? Про лучи в хл - туда же. Медийные издания работают во многом исходя из соображений работы с рекламодателем и кликбейта. От сюда же и новости про "чувака, который провел 50 лет в игре и получил все достижения", которые тоже массово могут поститься по всему инету.

Цитата:

SNMetamorph писал:
Когда ты делаешь инди-игру

Где ознакомиться можно с твоим бэкграундом?

Цитата:

SNMetamorph писал:
Сейчас поясню.

Поясняю: кто не видит общей картины и не понимает что с чем сравнивать, того очень легко запутать фактами. Популизм так и работает. Мыслить лишь одними категориями базовой человеческой логики - очень ненадежно. Одной лишь логикой обходятся те, кто, как правило, большего позволить себе и не может. Это очень порочный и ложный круг. Исключительно не рекомендую.

Отправлено XaeroX 11-08-2023 в 21:18:

Цитата:

XF-Alien писал:
И без всяких ксашей и лучей, только что с того?

Ну как - что? О тебе теперь знают миллиарды людей. Можно греться в тёплых лучах ~~рейтрейсера~~ славы.

Цитата:

XF-Alien писал:
Медийные издания работают во многом исходя из соображений работы с рекламодателем и кликбейта.

Так а что мешает нашим ушлым авторам форков ксаша встраивать рекламу в ролики, и получать с кликбейта денюжку? Оно, может статься, намного проще, чем делать инди-игру или даже мод. Вот тебе и прямая монетизация внимания аудитории, которую можно выдавать за успехи в игрострое. Доллары-то вполне реальные капают на счёт.

Добавлено 11-08-2023 в 17:18:

Цитата:

XF-Alien писал:
Мне, чтоб добиться подобных показателей для Дельты, пришлось куда больше трудиться и вкладываться в проект

Ну справедливости ради скажем, количество человеко-часов, затраченных на Перилос, плюс нужные фичи редактора, плюс движок - это что-то запредельное. Меня до сих пор оторопь берёт, как вспомню...

Даже не верится, что мы всё это вытащили.

__________________

Отправлено (_-=ZhekA=-_) 11-08-2023 в 21:28:

Цитата:

Сам то понял, что сморозил?

Кейс из хл 1 и ксаша вообще ни где не котируется - это чисто хобби с которым на работу не берут

К самому ксашу и ДМ претензий нет! Area 51 сделана на ксаше и хлфх

Отправлено Дядя Миша 11-08-2023 в 21:33:

Цитата:

XF-Alien писал:
и прочих Limbo с Superhot (ничего против них не имею, просто они для меня говно, я такое ни-ни)

А мне Limbo понравилась. Там был такой паук, например.

Добавлено 12-08-2023 в 00:33:

Цитата:

(_-=ZhekA=-_) писал:
Кейс из хл 1 и ксаша вообще ни где не котируется - это чисто хобби с которым на работу не берут

Элбер в 4A именно так работу и получил.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 11-08-2023 в 21:46:

Цитата:

Дядя Миша писал:
Элбер в 4A именно так работу и получил.

Я UE4 начал изучать, как только он стал бесплатным и только после его освоения можно было куда-то рыпаться...

Добавлено 12-08-2023 в 00:46:

Цитата:

Дядя Миша писал:
Это с любым сложным софтом так.

Согласен

Отправлено XF-Alien 11-08-2023 в 21:48:

Цитата:

Дядя Миша писал:
Там был такой паук, например.

Я так и не прошел до конца. Видимо, вот он, откуда

Цитата:

Дядя Миша писал:
Элбер в 4A именно так работу и получил.

Рынок труда сильно меняется в ГД. Когда-то и буззер загремел туда после релиза Паранойи. Сейчас вряд ли прокатит, если кто-то хочет именно так устроится. По крайней мере в ААА.

Отправлено (_-=ZhekA=-_) 11-08-2023 в 22:00:

Дядя Миша

Если тебе действительно интересно, то я тебе могу многое рассказать о 3д максе и анриле, так как я в этих двух прогах работаю

Добавлено 12-08-2023 в 00:54:

Цитата:

XaeroX писал:
Ну справедливости ради скажем, количество человеко-часов, затраченных на Перилос, плюс нужные фичи редактора, плюс движок - это что-то запредельное. Меня до сих пор оторопь берёт, как вспомню... Даже не верится, что мы всё это вытащили.

Ох сколько я в одну мосю потратил времени на Area 51 это просто ппц...

Но это в любом случаи был опыт из которого я сделал определенные выводы

Добавлено 12-08-2023 в 01:00:

Цитата:

Дядя Миша писал:
Элбер в 4A именно так работу и получил.

Мне похрен, а ты сам-то в это веришь?

Отправлено Дядя Миша 11-08-2023 в 22:01:

Цитата:

XF-Alien писал:
Когда-то и буззер загремел туда после релиза Паранойи

Распространённый, хотя и ошибочный стереотип. В реальности же БуЗЗера взяли в крайтек за его карты для CS.

Цитата:

(_-=ZhekA=-_) писал:
Если тебе действительно интересно, то я тебе могу многое рассказать о 3д максе и анриле

Интересно но попозже, когда я приступлю к написанию редактора.

Добавлено 12-08-2023 в 01:01:

Цитата:

(_-=ZhekA=-_) писал:
Мне похрен, а ты сам-то в это веришь?

Я просто знаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 11-08-2023 в 22:10:

Цитата:

Дядя Миша писал:
В реальности же БуЗЗера взяли в крайтек за его карты для CS.

Только по-моему всё же не в Крайтек. Начинал он в какой-то мелкой конторе. А потом уже взяли в Крайтек, с его опытом в индустрии.

__________________

Отправлено Дядя Миша 12-08-2023 в 09:42:

Ну чтож, приступаю к реализации первой из озвученных задач - имплементации сетевой подсистемы. Сама по себе сеть на первый взгляд кажется довольно-таки простой задачей - тут байты переслал, там принял. Построил дельта-таблицы (отсортировал в них строчки, естественно), чтобы не пересылать лишнего, а только необходимое. Проинтерполировал данные с предидущими.
Как будто бы всё несложно и тиерично. Проблемы начинаются когда мы хотим предиктинг. Предиктинг базируется на физическом поведении объектов. Физическое поведение объектов мы сами задаём в пользовательском коде. Значит нам надо этот код либо два раза скопировать на клиент и сервер, либо как-то иначе вызвать из другого места, причём имея в виду, что на клиенте возможно будут недоступны некоторые вещи, которые есть на сервере (ну в теории), поскольку полная клиентская симуляция сервера, скорее всего просто затормозит работу движка и ничего не даст нам. Особенно в синглплеере.

Перед тем как выработать собственный подход к проблеме, давайте пробежимся по исходникам уже существующих движков и посмотрим в общих чертах, как оно реализовано там. Поскольку это не обзор на редакторы, я не буду заводить отдельные темы, а буду писать прямо сюда по мере штудирования.

Добавлено 12-08-2023 в 12:42:

Если кто-то вдруг не понял. Проблемы в первую очередь у конечных юзеров, которым при неудачной организации всего этого дела придётся физический код куда-то два раза дублировать. Вспоминайте как все ненавидели этот предиктинг оружий в халфе, как он глючил, как была мешанина из пушек с предиктингом и без. Я не хочу чтобы мы второй раз наступили на эти грабли.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 12-08-2023 в 18:35:

Обзоров пока что не будет, будут общие размышления по теме.
Итак, кроме двух классических сетевых моделей, есть так же два варианта имплементации поддержки сети:

1. Сеть как архитектура
2. Сеть как сервис

Первое - это то, что мы имели удовольствие наблюдать в трёх кваках, а так же в голдсорсе и сорсе и возможно (поскольку нет исходников) в Source2.
В чём тут смысл - сетевая архитектура буквально пронизывает весь движок и заставляет его подстраиваться под нее. Это приводит к тому, что даже в сингл-плеере мы имеем два набора энтить - клиентский и серверный, причём на полном серьезе данные передаются на виртуальный клиент через заглушку (заглушка прямо там же в коде движка, в виде обычных буфферов-массивов). Т.е. по сути выполняется никому не нужная работа.
Так же, ради предиктинга приходится дублировать код физики на клиентской части, с рядом оговорок, само собой, потому что предсказать поведение тех же монстров мы не можем. Предиктинг вообще можно рассматривать как более продвинутый вариант интерполяции, который учитывает некоторые нелинейные условия. Ну например прыжок, приседание или блокировку поезда (если мы предиктим его). Т.е. в принципе предиктинг можно заменить такой простейшей проверкой, типа испускания луча по ходу движения объекта и в 70% случаев этого окажется достаточно (в Darkplaces именно так и сделано).
Единственный плюс такого подхода - для нас олдскульщиков эта модель более привычная и совершенно чётко разделяет клиент и сервер даже если физически они находятся на одной машине. А так же даёт некоторые гарантии, что всё что работало в локальном режиме будет так же работать и по сети. Правда последнее выполняется лишь с рядом оговорок.

Вторая модель - это то, что повсеместно используется сейчас. У нас нет никакого разделения на клиентские и серверные объекты. Объект у нас всегда один. Сеть подключается только когда активен мультиплеер. Всё остальное время она не оказывает никакого влияния. И соответственно не потребляет ресурсов. Для локального игрока тоже всё прозрачно и по сети не передаётся. Для остальных - считывается состояние объекта, отсылается по сети и принимается. Ну и есть две функции исполнения физики - нормальный кадр и кадр предиктинга. Реализация физики для этих двух состояний может чуть-чуть отличаться, хотя это и необязательно. Таким образом:
1. мы не тратим ресурсы на сеть в синглплеере
2. мы не траим память на дельта-секвенции
3. нам не нужно расшаривать свой код на клиентские и серверные инстанции библиотек.

Но есть одна маленькая ложка дёгтя в этом подходе. Поскольку такой сервис не нарушает целостность архитектуры ядра, его прикручивают спустя рукава в надежде, что те, кому надо - сами всё допилят или переделают. Что мы, например, имеем удовольствие наблюдать во всяких Юнити.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 16-08-2023 в 16:45:

Вообщем, подводя итоги, что хочу сказать. Обзоры писать не буду, ибо ничего такого заслуживающего внимания найти так и не удалось.
Только общие рассуждения:

Чем меньше движок (по крайней мере в пользовательской своей части) будет выпячивать свою принадлежность к клиент-серверной архитектуре тем будет только лучше для всех. Я вам объясню принципиальную разницу в этих подходах. Те, кто привыкли кодить под халфу\кваку, знают, что вот они настроили объект и в принципе - всё. Дальше он куда-то передаётся по сети, потом рендерер его подхватывает и рисует. Повлиять на что-либо, получить какую-то обратную связь в принципе невозможно. Иметь в свойствах объекта метод Draw тем более из области фантастики. Тогда как во всех современных движках оно именно так и устроено. Объект, игровой цикл - отправка на отрисовку. Сеть в данном случае действует максимально прозрачно для всех - она по необходимости просто реплицирует объект у клиента и всё. Ну то есть понятно, что есть так же протокол соединения, но он тем более находится где-то сбоку и сами объекты никак не затрагивает.
Соответственно при такой модели есть три способа синхронизации с сервером:
1. интерполяция - если игра запущена на удалённом клиенте, физика отключается и просто ловит обновления переменных по сети.
2. Предиктинг - физика делает несколько кадров как бы в песочнице, используя для нового кадра смешанные результаты от обновлений по сети и полученных локальных вычислений. Кол-во таких кадров определяется кол-вом пришедших обновлений.
3. Полностью локальная симуляция - физика на клиенте живёт своею жизнью (но синхронно с временем сервера) и иногда мягко интерполирует значения с локальными, если они вдруг не совпадают. Т.е. грубо говоря сервер может как рассылать обновления usercmd_t для всех клиентов, так и делать полное обновление стейта. Проблема такого подхода, что возникает как бы двойной лаг, если игнорировать остальные обновления стейтов, например в целях экономии траффика. Впрочем сама модель мне вполне нравится своей гибкостью, у нее потенциально гораздо больше настроек, чем у старой.
Благодаря наличию виртуальной машины нет нужды даже вручную прописывать мета-информацию для всех полей объектов. Можно собрать списки полей в полностью автоматическом режиме. Тут тоже возможны два варианта:
1. Собираем стейты со всех полей в каждом объекте, отправляем их на клиент целиком, ориентируясь на тип переменной. Если float - передаём четыре байта, если byte - передаём один байт. Получившийся пакет сжимаем каким-нибудь простейшим архиватором, тем же LZSS. Так же заводим delta_state для каждого серверного объекта, чтобы не отправлять данные, которые не изменились. Правда тут потребуется обратная связь, скорее всего - клиент, приняв обновления, должен будет отослать на сервер подтверждения что стейт синхронизирован и только тогда кэш будет считаться валидным.
2. Для тех, у кого много свободного времени - всё как в первом варианте, но при помощи встроенных средств языка вы указываете сколько бит использовать для передачи по сети той или иной переменной и таким образом вручную оптимизируете траффик свой игры. Работа несложная, но как правило такое дико раздражает если обязательно требуется, как в той же халфе - каждый раз когда мы хотим что-то передать на клиент, приходится лезть в delta.lst и что-то там сортировать, добавлять. Никому это не нравится. Ну а когда игра полностью готова - почему бы и не оптимизировать?

Из вышесказанного, надеюсь, уже понятно, что новый ксаш будет очень сильно напоминать Unity по крайней мере той его частью с которой будут иметь дело игровые программисты. По духу, по концепции, но не по реализации!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 16-08-2023 в 21:49:

Надеюсь будет и способ по фасту вкинуть сеть в проект

Отправлено Дядя Миша 23-08-2023 в 22:55:

В новом ксаше есть любопытное ограничение архитектуры: он способен рисовать только модели и больше ничего, кроме моделей.
Ну то есть как. Он может рисовать конечно буквы в меню или отладочные линии-полигоны, но штатная отрисовка универсального конвейера заточена только и исключительно под модели. Поясню почему так получилось:
Всё дело в системе материалов. Каждый материал состоит из трёх частей.
1. базовая часть
2. опциональная часть
3. пользовательская часть
Базовая часть - это настройки по умолчанию. То что никогда не придётся прописывать пользователю для каждого материала. Они всегда есть и их всегда можно поменять, но для всей группы материалов разом.
Опциональная часть - даже не знаю, работает ли она. Никогда её не использовал, просто не было нужды.
Пользовательская часть - это собственно та часть, которую мы все привыкли видеть как описание материала. В чём же подвох, спросите вы?
Так именно в том, что базовая часть вяжется к строго определённому типу модели, а материал без базовой части существовать не может - и текстурные юниты и юниформы во время рендеринга активно обращаются к модели и берут оттуда различную информацию. В принципе можно создать такую специальную фейковую модель для короткоживущих эффектов (например партиклей) и скорее всего в дальнейшем я именно так и сделаю. Но вот для долгоживущих эффектов (лучей, декалей), этот вариант наоборот оказывается невероятно удобным.
По сути получается такая секретная модель которая внутри движка неявным образом прилинкована к энтите и в течении всего времени её жизни аккумулирует в себя декали, которые были поставлены на эту энтить. Оптимизирует их там внутри себя, собирает в батчи, ну итд.
Причём, поскольку модель является частью стандартного конвейера, то такие декали сразу из коробки получают абсолютно весь функционал обычных моделей в плане настроек системы материалов. Т.е. ситуации, когда у моделей одни настройки, а у декалей другие, более ограниченные попросту не возникнет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 24-08-2023 в 00:36:

Цитата:

Дядя Миша писал:
В новом ксаше есть любопытное ограничение архитектуры: он способен рисовать только модели и больше ничего, кроме моделей.

Нам с начала нулевых промывали мозги: браши устарели, браши это прошлый век, кубизм офигевший и так далее. На любой вопрос тогда маппер получал ответ: "сделай моделькой". Ну, собственно, вот и закономерный результат.

__________________

Отправлено Дядя Миша 24-08-2023 в 07:53:

Под моделью понимается некая структура с VBO-данными.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 24-08-2023 в 08:03:

Не очень понял. Вот OpenGL позволяет рисовать вертексы, полигоны, текстуры, линии и т.д. Имеется ввиду что такие структуры смогут существовать как отдельный объект на сцене или что?

Цитата:

XaeroX писал:
Нам с начала нулевых промывали мозги: браши устарели, браши это прошлый век, кубизм офигевший и так далее. На любой вопрос тогда маппер получал ответ: "сделай моделькой". Ну, собственно, вот и закономерный результат.

А сам то втихую на моей спонзе некоторые браши модельками и кривыми заменил

Зрада.

Отправлено Дядя Миша 24-08-2023 в 11:56:

FiEctro то отрисовка в ImmediateMode. А я про объекты, которые загружены в видеопамять и не изменяются.
Декали ведь создаются один раз и потом уже не модифицируются.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 24-08-2023 в 12:37:

Дядя Миша
А, ну примерно понял, мне казалось нечто подобное уже в ксаше есть. Декальки геометрией планируешь делать?

Отправлено Дядя Миша 24-08-2023 в 12:59:

Да, геометрией, по-старинке. К декалям-прожекторам у меня по прежнему много вопросов. Если на статику я их ещё наложу, то как быть с анимированными моделями?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 24-08-2023 в 13:18:

Цитата:

FiEctro писал:
А сам то втихую на моей спонзе некоторые браши модельками и кривыми заменил Зрада.

Я разве говорю что модели не нужны? Или может быть я на спонзе вообще всё заменил на модели? Нет вроде, только всякие мелкие вещи, которые по сути - детализация. Ты и сам почему-то голову льва в браши не перегнал. А вот мелкие колонны - поленился.
В волатильной спонзе осталось очень много брашей, если что. Но и модельки с кривыми есть, да.

__________________

Отправлено Дядя Миша 24-08-2023 в 22:21:

Декали на самом деле это тихий ужос. Это самая противоречивая вещь, которая успешно сопротивляется вообще всем оптимизациям.
Не зря я их в параное так и не доделал. Вот и сегодня - весь день обдумывал.
Ну и надумал сделать такую штуку, которая естественно не имеет аналогов.
Если получится - декалей будет унлимит. Ну не прям-прям унлимит, а где-то примерно 16 тысяч декалей на сурфейс(!!!). И тормозить всё это не будет.
Если я конечно всё правильно рассчитал.

Добавлено 25-08-2023 в 01:21:

А, да. В новом ксаше декали разделены. Если декаль полностью статичная - постеры там всякие, лужы и прочее - то её создаёт компилятор BSP.
Но вышесказанное относится к декалям, которые спавнятся во время игры - кровищща, следы от взрывов, дырки от пуль.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 25-08-2023 в 06:17:

Цитата:

XaeroX писал:
Я разве говорю что модели не нужны? Или может быть я на спонзе вообще всё заменил на модели? Нет вроде, только всякие мелкие вещи, которые по сути - детализация. Ты и сам почему-то голову льва в браши не перегнал. А вот мелкие колонны - поленился.
В волатильной спонзе осталось очень много брашей, если что. Но и модельки с кривыми есть, да.

Да ё моё, почему ты всегда такой серьёзный? Я просто по дружески пошутил.
По мне браши и модели надо использовать там где они нужны по смыслу.

Цитата:

Дядя Миша писал:
Если получится - декалей будет унлимит. Ну не прям-прям унлимит, а где-то примерно 16 тысяч декалей на сурфейс(!!!). И тормозить всё это не будет.

Типа как в Алиен шутере? Запекать в глобальную карту?

Цитата:

Дядя Миша писал:
К декалям-прожекторам у меня по прежнему много вопросов. Если на статику я их ещё наложу, то как быть с анимированными моделями?

Ну да ты прав, с большими декалями на анимированных моделях не очень хорошо получается, нужно их как то "заморозить" там где они наложились. Как это сделать технически эффективно, у меня пока мыслей нет.

Отправлено Crystallize 25-08-2023 в 07:29:

Цитата:

FiEctro писал:
Ну да ты прав, с большими декалями на анимированных моделях не очень хорошо получается, нужно их как то "заморозить" там где они наложились. Как это сделать технически эффективно, у меня пока мыслей нет.

В 1м кадре определять где-то рядом точку относительно кости и потом проецировать с этой точки как фонарик?

Отправлено ZGreen 25-08-2023 в 08:22:

В ут2004 декали-проекторы, если я не ошибаюсь. В больших количествах они некисло сажают фпс даже на компах, которые многократно превосходят системные требования игры.

Отправлено Дядя Миша 25-08-2023 в 08:23:

Цитата:

FiEctro писал:
Я просто по дружески пошутил.

После того редактирования википедии мы твои шутки больше не воспринимаем как шутки.

Цитата:

FiEctro писал:
Запекать в глобальную карту?

Не-не, это стейнмапы, это отдельная технология.

А к этим декалям-прожекторам главный вопрос еще и в том, что каждую такую декаль придётся рисовать отдельно. Нельзя нарисовать сразу все такие декали за один вызов. Потому что они тащат с собой кучу параметров, которые надо обновлять в юниформах. И это главная проблема.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 25-08-2023 в 08:53:

Цитата:

Дядя Миша писал:
После того редактирования википедии мы твои шутки больше не воспринимаем как шутки.

Вот сам небось отредактировал, и меня обвиняет.

Отправлено Дядя Миша 26-08-2023 в 20:03:

Это всё конечно пока ещё очень глючное, но просто для теста нагрузочной способности. Бинарник собран в дебаге, так бы там было за тысячу фпс.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 26-08-2023 в 20:56:

Дядя Миша
А почему со стены на стену декальки не переходят?

__________________

Отправлено Дядя Миша 26-08-2023 в 22:54:

Финальная версия

На динамическое освещение тоже реагируют.

Цитата:

XaeroX писал:
А почему со стены на стену декальки не переходят?

Декали ведь статичные, где поставили там и стоят. Может в волатиле они крадутся за изумлъонным игроком, но мне ближе классическое поведение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 26-08-2023 в 22:56:

Цитата:

Дядя Миша писал:
Может в волатиле они крадутся за изумлъонным игроком

Ну вообще-то и в халфе крадутся, и в джеке.

__________________

Отправлено Дядя Миша 26-08-2023 в 23:29:

Эти декальки используют нормаль поверхности, куда попала трасса.
Если бы вместо этого использовать в качестве нормали взгляд игрока, то была бы проекция. Ты же об этом спрашивал?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 27-08-2023 в 00:05:

Дядя Миша
Я имел в виду, что когда в халфе наносится декаль, она кладётся сразу на несколько сурфасов, например в углу - покрывает весь угол, на лестнице - кладётся и на саму ступеньку, и на её боковую часть. А у тебя - выглядит, будто декаль наносится только на один сурфас, возле которого стоит её оригин.

Добавлено 26-08-2023 в 20:05:

Вот картинка

__________________

Отправлено nemyax 27-08-2023 в 05:34:

XaeroX

Отправлено Дядя Миша 27-08-2023 в 08:30:

Я понял об чём ты говоришь, но повторюсь, используется нормаль от поверхности, которую вернула трасса. Если использовать нормаль от взгляда - получится проекция.

Впрочем код клиппинга декалей возможно будет ещё меняться.

Добавлено 27-08-2023 в 11:30:

Можно ещё сделать что: пробежаться по дереву, собрать все потенциальные сурфейсы, пробежаться по сурфейсам, из каждого треугольника посчитать нормаль, сложить все нормали и получить среднее.
В компиляторе я так и делаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 27-08-2023 в 09:51:

Ну да, нетривиальная задача, тут либо растягивать рисунок декали, либо вот такие пропуски, и то и то выглядит так себе. Видимо нужно брать нормаль не от проекции, а высчитывать какую то среднюю нормаль от поверхности. В общем хз.

Дядя Миша
А можешь визуализировать сетку твоих декалей и пофоткать с разных ракурсов? Мне всегда было интересно, как они ложатся.

Отправлено Дядя Миша 27-08-2023 в 10:12:

Разве в этой каше можно что-то разобрать?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 27-08-2023 в 11:21:

Вот единичная декаль, тут получше видно.

Добавлено 27-08-2023 в 13:16:

В принципе можно заморочиться и уничтожить смежные рёбра там где по смыслу они не нужны, но на скорость отрисовки это не влияет, а время постановки - увеличивает. Смысла нет.

Цитата:

FiEctro писал:
а высчитывать какую то среднюю нормаль от поверхности

Ну да, я про это и говорю. Компилятор bsp у меня именно этим и занимается.
В радиусе места постановки декали собирает все поверхности, берёт от них нормаль и вычисляет среднюю. И вот эта нормаль берётся как база для проекции.

Добавлено 27-08-2023 в 13:18:

По срокам и задачам напишу. Что мне ещё осталось сделать:

1. Декали на моделях (пока что только на скелетных)
2. Сохранение декалей в сейв
3. Систему партиклей (сейчас их нет вообще никаких)
4. Полная ревизия и отладка.

И будет демка. Конец септямбря ориентировочно. Но загадывать не буду.

Добавлено 27-08-2023 в 14:21:

Поскольку декали являются частью общей системы материалов, можно делать вот такие вот вещи.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 27-08-2023 в 11:28:

У тебя партикли типа плевков булсквида будут освещаться?

Отправлено Дядя Миша 27-08-2023 в 12:02:

Будут, но до партиклей я ещо не добрался же.

Добавлено 27-08-2023 в 15:02:

Кстати говоря, освещение партиклов я вам завёз ещё для ксаш-мода.
Правда только в авроре. Но они и освещались и туманились.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 27-08-2023 в 13:17:

Цитата:

Дядя Миша писал:
Вот единичная декаль, тут получше видно.

Спасибо!

Цитата:

Дядя Миша писал:
В радиусе места постановки декали собирает все поверхности, берёт от них нормаль и вычисляет среднюю. И вот эта нормаль берётся как база для проекции.

Это замечательно. Сделай ещё слои для объектов и декалей, чтобы на одни объекты они могли накладываться, а на другие нет. Очень полезная штука.

Цитата:

Дядя Миша писал:
Компилятор bsp у меня именно этим и занимается.

Кстати, соррян что отхожу от темы, но как у тебя обстоят дела с Т-джунками? Планируется какой нибудь фикс для них?

Отправлено Дядя Миша 27-08-2023 в 15:18:

Цитата:

FiEctro писал:
чтобы на одни объекты они могли накладываться, а на другие нет

Ну есть флажок nodecals, если ты об этом. А вот так чтобы слоями, ну типа в три слоя декали наложились, а на четвёртый - ну ни в какую, этого нет.

Цитата:

FiEctro писал:
как у тебя обстоят дела с Т-джунками?

Никак не обстоят. Руки не доходят их сгенерировать

Но я себя тешу надеждой что со включённым MSAA разницы не видно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 27-08-2023 в 17:06:

Цитата:

Дядя Миша писал:
Можно ещё сделать что: пробежаться по дереву, собрать все потенциальные сурфейсы, пробежаться по сурфейсам, из каждого треугольника посчитать нормаль, сложить все нормали и получить среднее.
В компиляторе я так и делаю. [/B]

Вот как раз в этом случае тебе нужна матрица смежности.

Отправлено FiEctro 28-08-2023 в 11:11:

Цитата:

Дядя Миша писал:
Ну есть флажок nodecals, если ты об этом. А вот так чтобы слоями, ну типа в три слоя декали наложились, а на четвёртый - ну ни в какую, этого нет.

Ну вот в сорсе к примеру в материале можно указать какая декаль будет накладываться, там стекло, дерево или ещё что нибудь. Но по мне это не очень удачный вариант. Надо указывать лучше сам ресурс, а не тип поверхности.

Отправлено Дядя Миша 28-08-2023 в 12:34:

Система физических материалов у меня есть. Она в пользовательском ведении, так что туда можно добавлять всё что угодно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 30-08-2023 в 13:39:

Декали готовы. И на моделях и на брашах. И они сохраняются в сейв.
И да, действительно можно накладывать без ограничений - они никогда не удаляются, только накапливаются. Впрочем потом надо будет сделать более гибкие настройки в этом плане конечно. Иногда декали надо удалять по сюжету.

Перехожу к имплементации клиентских эффектов.
У нас это темпэнтити, лучи, партиклы и трасеры.
С новой архитектурой ксаша никакие дурацкие темп-энтити мне не понадобятся. Буду использовать обычные - это намного удобнее во всех отношениях. С лучами пока всё очень туманно, никакая концепция в голове не вырисовывается. Но к счастью в Кваке таких лучей нету, а значит пока что этот вопрос можно отложить в сторону. А те лучи, которые используются в кваке сделаны из темпэнтить сегментами. Так что тут вопрос закрыт.
А вот партиклы надо сделать обязательно. Какая же игра без партиклов?
Это первый дуум ещё как-то без них мог обходиться. Но сделать партиклы с моей архитектурой движка будет не так-то просто. Рисовать партиклы через глбегин я не могу. Можно сделать через инстансы, но я с ними никогда не работал. К тому же у меня конвейер под них не настроен, а вообще инстансы будут нужны, например для отрисовки инстанс-моделей и я полагаю, эту работу имеет смысл выполнить разом для всего. Поэтому пока что мне представляется следующая схема организации партиклов:

1. как и декали, партиклы будут прикрепляться к модели. Если же прикрепления не предполагается, то будут аттачится к миру.
2. апдейт предполагает обновления всех позиций партиклей, а так же изменения их цвета, т.е. стандартная эвалюация.
3. обновлённые данные заливаются в VBO в конце кадра. Та часть партиклов, которая уже вышла из строя, просто получает нулевую прозрачность. И по этому критерию для нее перестаёт выполняться обновление. Когда все партиклы получат нулевую прозрачность, считается что парт-система выработала свой ресурс и может быть освобождена.
4. технически каждый партикл представлен в виде четырёх вертексов и шести элементов, причём во все четыре вертекса записана текущая позиция партикла, а трансформация поворота к камере выполняется на видеокарте. Да, тут есть избыточность, но во первых в одной партсистеме партиклов обычно не так уж и много (128-256 максимум), а во вторых без инстансов эту проблему всё равно не решить. Зато все партиклы, принадлежащие одному эффекту рисуются за один вызов, что тоже положительно сказывается на оптимизации.
5. Из-за предложенной схемы отрисовки оказывается возможным переиспользовать шейдер спрайтов для партиклей. А так же использовать и сами спрайты в качестве партиклей. Аналогично сделано и для декалей - шейдер мировых декалей использует шейдер для отрисовки мира. Меньше уникальных шейдеров - меньше их переключений, выше фпс. Но конечно никто не мешает написать и собственный.
6. Партиклы всегда добавляются в очередь прозрачных полигонов и их возможно отсортировать по дальности. Но только в рамках целой партсистемы,а не каждой частички. Впрочем и это неплохо, т.к. партиклы обычно вообще никто не сортирует.

Пока что так всё это вижу.

Добавлено 30-08-2023 в 16:39:

У прочитавших вышесказанное наверняка возникнет вопрос, мол почему бы и с лучами не поступить так же как с партиклами, хранить сегменты обновлять в шейдере. А потому что для лучей нужно две точки. И где брать эту вторую точку, как её корректно хранить - это больной вопрос, нарушающий всю инкапсуляцию объектов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 30-08-2023 в 18:40:

Цитата:

Дядя Миша писал:
Буду использовать обычные - это намного удобнее во всех отношениях.

Неплохо сделать возможность стаковать несколько энтитей ввиде одного объекта, чтобы не приходилось городить огромные гирлянды из объектов. Ну и конечно добавлять свой скрипт ввиде такой же энтити.

Цитата:

Дядя Миша писал:
Из-за предложенной схемы отрисовки оказывается возможным переиспользовать шейдер спрайтов для партиклей.

А если я захочу вместо спрайта модельку вставить? Мы кстати для оптимизации делали спрайт именно ввиде треугольника, а не квадрата как результат фпс в 2 раза выше

А ведь есть ещё компонент который с помощью скрипта может сам по себе какую угодно фигню из вертексов и полигонов рисовать

Цитата:

Дядя Миша писал:
У прочитавших вышесказанное наверняка возникнет вопрос, мол почему бы и с лучами не поступить так же как с партиклами, хранить сегменты обновлять в шейдере. А потому что для лучей нужно две точки. И где брать эту вторую точку, как её корректно хранить - это больной вопрос, нарушающий всю инкапсуляцию объектов.

Сначала ответь на вопрос что такое вообще партикля? Это инстансер объектов (задаёт количество и время), т.е. их спавнер, а дальше ты задаёшь уже поведение этим объектам с помощью генераторов или может даже задания им свойств обычных энтитей, почему нет?

Цитата:

Дядя Миша писал:
А потому что для лучей нужно две точки. И где брать эту вторую точку, как её корректно хранить - это больной вопрос, нарушающий всю инкапсуляцию объектов.

Для лучей не нужно 2 точки, у луча есть координата его начала и направление (по желанию ещё длинна и его субдивайд, если мы хотим например его искривлять как молнию). Но если уж точно нужно прицелиться в какой то объект, есть констрейнт LookAt.

Кстати насчёт лучей, добавь ещё нативные безъе пути, это очень удобная штука, которой как правило нет из коробки ни в одном движке. Ну может разве что в волатиле.

Цитата:

Дядя Миша писал:
5. Из-за предложенной схемы отрисовки оказывается возможным переиспользовать шейдер спрайтов для партиклей. А так же использовать и сами спрайты в качестве партиклей. Аналогично сделано и для декалей - шейдер мировых декалей использует шейдер для отрисовки мира. Меньше уникальных шейдеров - меньше их переключений, выше фпс. Но конечно никто не мешает написать и собственный.

Так а в чём проблема? Спрайт имеет свой материал, а материал может иметь какой угодно шейдер. Я никогда не понимал нафига хранить 2д графику в разных форматах? Для текстур свой формат, для UI свой, для спрайтов свой формат, для скайбоксов свой, для кого этот изврат?

В Юнити кстати есть GPU Instance для всех одинаковых материалов с одним шейдером в сцене, я не знаю как он работает, но подымает ФПС он очень хорошо, когда много объектов с одним материалом.

Цитата:

Дядя Миша писал:
Декали готовы. И на моделях и на брашах. И они сохраняются в сейв.
И да, действительно можно накладывать без ограничений - они никогда не удаляются, только накапливаются. Впрочем потом надо будет сделать более гибкие настройки в этом плане конечно. Иногда декали надо удалять по сюжету.

Круто

Не забывай что декалям можно например ещё задавать сортировку, ну например маппер налепил в одном углу кучу декалей, а ему нужно чтобы они ложились в определенном порядке друг на друга.

Отправлено Дядя Миша 30-08-2023 в 20:53:

Цитата:

FiEctro писал:
Я никогда не понимал нафига хранить 2д графику в разных форматах?

Ну вот вальвовцы тоже не понимали - нафига. В результате в халфе худ хранится в самых обычных спрайтах, а ректанглы в них люди должны вручную прописывать, руководствуясь видимо пролетарским чутьём, не иначе. Потому что в прописывании этих ректанглов лажали абсолютно все.
И я в том числе. И их ненавидели прописывать, да. Но зато всё в одном формате, как ты любишь.

Объясняю:
1. Текстура - это просто сборище пикселей и к ним идёт хидер с информацией о сжатии, а так же долготе и широте. Это не трёхмерный объект и не двухмерный объект. Это просто raw-массив.

2. Шрифты (атласы) содержат в себе текстуру и ректанглы, описывающие участки на этой текстуре, которые можно (и нужно) считать отдельными изображениями. Делается это из целей оптимизации - одну текстуру быстрее грузить, одну текстуру быстрее рисовать. А информация о регионах поможет нам быстро ориентироваться. Обычно она ассоциируется либо с индексом буквы (если это обычный шрифт), либо со специальным именем, если это шрифт картинок. Но и лайтмапы можно тоже хранить в таком вот шрифте, конечно.

3. Спрайты (ну по крайней мере в моём случае), это не просто картинка и не просто набор картинок. Это трёхмерная геометрия запечённая в GPU-friendly буфферы, информация о регионах и картинка. Под термином спрайт может скрываться всё что угодно. Там может быть классический спрайт-биллбоард, может быть импостор или моделька кустика травы.
Ну вообщем что-то такое, что имеет кастомную геометрию, но при этом не имеет коллизии. Так же на кадры спрайта можно привязать разную геометрию, по типу как body у моделей. Разница в том что такая геометрия статична лишена разных зависимостей и гораздо более оптимальна для инстансинга. Да и для темп-энтить тоже. В халфе, как ты знаешь, даже для статичной модели обязательно считаются кости, не бывает моделек без костей. Это расточительно. Вот мои спрайты в данном случае замена таким моделькам.

4. Скайбоксы. Скайбокс это кубемапа, т.е. трёхмерная текстура. Лукап в нее осуществляется вектором. Вроде бы и raw-массив, но хитрый. Опять же к геометрии никакого отношения не имеет.

Цитата:

FiEctro писал:
Мы кстати для оптимизации делали спрайт именно ввиде треугольника, а не квадрата как результат фпс в 2 раза выше

Страшно подумать, что творится с юнити, если он надорвался рисовать целых два треугольника.

Цитата:

FiEctro писал:
Для лучей не нужно 2 точки

Это смотря какие лучи. Если лазер, то да, достаточно одной точки и направления. А есть лучи, которые именно что приаттачены к двум точкам. Причём обе точки могут быть как на одной энтите, так и на разных.

Цитата:

FiEctro писал:
GPU Instance для всех одинаковых материалов с одним шейдером в сцене

А ты подумай на минуточку, почему эта штука не включена по умолчанию и навсегда.

Цитата:

FiEctro писал:
ну например маппер налепил в одном углу кучу декалей, а ему нужно чтобы они ложились в определенном порядке друг на друга.

Это статичные декали, у меня их компилятор считает и они вкомпиливаются прямо в карту. Ещё не хватало такое в рантайме делать.

Добавлено 30-08-2023 в 23:53:

Цитата:

FiEctro писал:
Я никогда не понимал нафига хранить 2д графику в разных форматах?

Так может ты поэтому до сих пор свою игру никак сделать не можешь, что кое-чего не понимаешь?

Ну да ладно. По здравом размышлении понял, что городить огород ради одних только партиклей смысла не имеет. Тут нужна большая клиентская система визуальных эффектов. Выносить это в скриптовой язык не буду - система прекрасно параметризуется, а условий там нету, равно как и каллбэков. Точнее говоря, каллбэков там можно придумать ровно два штуки - по удалении временного эффекта и по его коллизии с геометрией.
И сделать обратную связь на те же визуальные эффекты. Ну то есть мы стреляем такой специальной лучевой пушкой в стену, от нее отваливается сгусток энергии в виде шара, падает на землю, при соударении распадается на множество мелких шариков, которые плавно гаснут. Ну что-то вроде такого. Понятно, что на скриптах такое делать затратно, а каких-то сложных условий тут нет.
В принципе к чему-то аналогичному пришли и в форках кваки, в таких как даркплейс или FTE. Но честно говоря, там описание скриптов мозговзрывающее, приведу характерный пример такого скрипта для Arcane Dimensions.

C++ Source Code:

1	effect TE_GUNSHOT

count 1

3	type static // вот это тяжелое наследие из кода кваки. Таких переключателей быть вообще не должно

4	color 0x101010 0x707070 // RGBA упакованный в unsigned long. Симпатично, а главное как удобно!

5	tex 32 36 // вручную предлагается прописывать размер текстуры или я не понял

6	size 1 2 // это начальный и конечный размер, а может быть рандомный диапазон?

7	sizeincrease 2 // а это тогда что?

8	alpha 64 96 48 // альфа с тремя параметрами?

9	velocityjitter 8 8 4 // почему джиттер по трём осям но без диапазона рандомности,

10	gravity 0.01 // слава богу, хоть тут всё логично, это фактор.

Ну и вот такое вот оно там. Хрен победи как его использовать, тем более без визуального редактора.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 30-08-2023 в 23:48:

Цитата:

FiEctro писал:
Ну может разве что в волатиле.

Разумеется, в Волатиле. Там вы про них небось впервые и узнали.

Я даже вроде видео выкладывал, как монстр ходит по интерполированным путям.

Цитата:

FiEctro писал:
у луча есть координата его начала и направление

Ты когда-нибудь видел электрическую дугу? Расскажи, где у неё начало, а где направление.

__________________

Отправлено FiEctro 31-08-2023 в 06:03:

Цитата:

Дядя Миша писал:
2. Шрифты (атласы) содержат в себе текстуру и ректанглы, описывающие участки на этой текстуре, которые можно (и нужно) считать отдельными изображениями.
3. Спрайты

Так спрайты тоже можно делить на ректанглы. Даже более того можно их разбивать на сетку и привязывать её к скелету

Спрайт атласы называются

Неотъемлимый атрибут 2д игр.

А шрифты можно и даже нужно из того же ttf собирать, вон как Альбатрос делал в своём форке. Ну или в теже спрайтшиты их компилировать.

Цитата:

Дядя Миша писал:
4. Скайбоксы. Скайбокс это кубемапа, т.е. трёхмерная текстура. Лукап в нее осуществляется вектором. Вроде бы и raw-массив, но хитрый. Опять же к геометрии никакого отношения не имеет.

Это вроде больше от шейдера зависит, а не от формата, не? Да и не только кубамапы бывают, есть ещё сферомапы, есть ещё панорамы. Для каждого типа свой формат?

Цитата:

Дядя Миша писал:
Это статичные декали, у меня их компилятор считает и они вкомпиливаются прямо в карту. Ещё не хватало такое в рантайме делать.

А какая разница, если после компиляции они наложатся не в том порядке?

Цитата:

Дядя Миша писал:
А есть лучи, которые именно что приаттачены к двум точкам.

Ну так я говорю же - констрейнт Look at который задаёт направление в сторону выбранного объекта. Если нужно обрезать длинну луча то можно опять же подтянуть дистанцию между Look at объектом и целью. Вам наверное трудно понять, т.к. в вашей логике одна энтитя может делать только одну вещь.

Добавлено 31-08-2023 в 09:03:

Цитата:

XaeroX писал:
Ты когда-нибудь видел электрическую дугу? Расскажи, где у неё начало, а где направление.

Начало там где высокий потенциал, направление там где более низкое сопротивление пробития. Но если в рамках движка то это Look at, ну или по вашему поле target в парамсах энтити.

Цитата:

Дядя Миша писал:
Страшно подумать, что творится с юнити, если он надорвался рисовать целых два треугольника.

Это на 1 объект. А объектов было около 5 лямов, там была целая анимированная галактика из них

Знаю не очень оптимально делать это объектами, но как вышло. Мне интересно как ксаш вывезет 5 лямов энтитей

Отправлено Дядя Миша 31-08-2023 в 09:26:

Цитата:

FiEctro писал:
А шрифты можно и даже нужно из того же ttf собирать

Они у меня и так собираются из ttf налету.

Цитата:

FiEctro писал:
Так спрайты тоже можно делить на ректанглы

Ну они и делятся.

Цитата:

FiEctro писал:
Для каждого типа свой формат?

в DDS все.

Цитата:

FiEctro писал:
Вам наверное трудно понять, т.к. в вашей логике одна энтитя может делать только одну вещь.

По твоей логике класс векторов должен ещё уметь грузить текстуры и посылать сетевые пакеты.

Цитата:

FiEctro писал:
А объектов было около 5 лямов, там была целая анимированная галактика из них

Я думаю это не были объекты в привычном понимании.

Цитата:

FiEctro писал:
Мне интересно как ксаш вывезет 5 лямов энтитей

Никак не вывезет. И юнити бы тоже не вывез. Каждый кадр пробегаться по пяти миллионам объектов никакой движок не вывезет. Даже не сам движок, а процессор.
Впрочем - всё зависит от кол-ва операций.

Добавлено 31-08-2023 в 12:12:

А я продолжаю имплементировать аппаратно-ускоренные партиклы.
Идею чтобы выделять модель для каждой партикл-системы, я отбросил.

Когда в том же квейке происходит выстрел, то выделяется 6-12 небольших партикл-систем за кадр. Это чтожы на каждый такой выстрел аллокать модель, а через полсекунды её уничтожать? Неоптимально. Жесткая привязка партиклов к энтите по сути тоже не нужна. Единственное что партиклы наследуют от энтити - это позицию в пространстве. В теории могут и что-нибудь ещё, но это уже через шейдер. Таким образом нам достаточно создать единичную модель, некий пул партиклей. И спокойно в нём обновлять всё. Опять же, спавн одинаковых партиклей за один кадр и в одном месте вполне можно мержить на лету в единую партикл-систему.
А в конце кадра - перезаливать это в VBO.

Следующий момент - время жизни частиц довольно мало, они редко живут более одной секунды. Каждый раз физически вытирать их из памяти затратно. Равно как и менять размер VBO. Я предполагаю частицам, которые уже исчерпали свой лимит просто обнулять цвет. Если альфа равна нулю, такая частица нарисована не будет. Таким образом для каждой партикл-системы образуется некий аналог свободных частиц без физического перевыделения памяти. Для однократных эффектов это не имеет значения, но для обновляющихся, типа шлейфа за хвостом от ракеты - вполне имеет.

Это допущение основано на линейном и равноускоренном движении объектов, которые отбрасывают хвост - ракет, плевков и прочего.
При аллокации у нас уже есть актуальная скорость и следовательно точно известно кол-во партиклей, которые надо выделить для хвоста. В дальнейшем оно не меняется. Тут важно понимать, что если объект будет ускоряться, то кол-во партиклей без проблем сможет увеличиться до нужного размера, но происходить это будет крайне редко и значит не нанесёт удара по производительности.

Так же для каждой парт-системы перестраивается ббокс, чтобы мы могли эффективно её отсекать. С обычными партиклами, когда всё в куче, это сделать проблематично.

Добавлено 31-08-2023 в 12:16:

Если кто-то вдруг не понял вышенаписанного. Модель перевыделения частиц почти в точности повторяет алгоритм работы динамических массивов - память выделяется всегда только в сторону увеличения. А для уменьшения нужен отдельный явный вызов, типа compact. Но для короткоживущих частиц подобная оптимизация по памяти не нужна вообще.

Добавлено 31-08-2023 в 12:26:

Поскольку в аппаратном представлении большинства GPU-архитектур VBO Не может содержать более 65535 вертексов, следующее логичное ограничение - не более 16384 партиклей на одну систему. Это более чем за глаза достаточно, в той же кваке обычно столько партиклей выделяют вообще на всё. Если же рисовать не квад, а треугольник, то в два раза больше, но треугольник не получится подружить с атласами, вот в чём проблема.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-08-2023 в 11:13:

Цитата:

Дядя Миша писал:
Никак не вывезет. И юнити бы тоже не вывез. Каждый кадр пробегаться по пяти миллионам объектов никакой движок не вывезет. Даже не сам движок, а процессор.
Впрочем - всё зависит от кол-ва операций.

Да там простые операции, просто круговое движение. Да и фпс где то около 10-15 был, потому и экономили каждый треугольник. Потом переписали чтобы один объект был и рисовали повершинно.

Добавлено 31-08-2023 в 14:06:

Цитата:

Дядя Миша писал:
По твоей логике класс векторов должен ещё уметь грузить текстуры и посылать сетевые пакеты.

Ты просто не работал в 3д пакетах, там есть такое понятие как стек модификаторов или констрейнтов.

Например есть у тебя куб. Ты хочешь сгладить его, накидываешь первым делом модификатор субдивайд. Потом ты хочешь например просверлить в нём отверстие, накидываешь поверх модификатор булеан, потом тебе надо сделать много копий этого меша, накидываешь модификатор аррей. Энтития всё ещё одна при этом, но делает уже несколько функций. В случае с кушными энтитиями тебе надо срать кучей объектов излишне перегружая процессор и ещё при этом как то синхронизировать их координаты парент системой, ради чего так усложнять жизнь мапперам и железу?

Цитата:

Дядя Миша писал:
Если же рисовать не квад, а треугольник, то в два раза больше, но треугольник не получится подружить с атласами, вот в чём проблема.

Через шейдер можно с UV поколдовать и вписать квад внуть треугольника.

Цитата:

Дядя Миша писал:
Не может содержать более 65535 вертексов, следующее логичное ограничение - не более 16384 партиклей на одну систему.

Можно сделать слои для партикли, типа как ты режешь модель на части для .smd так же резать и партиклю, если я правильно тебя понял. Юнити вроде как сложные меши тоже разбивает на сабмеши на этапе рендера.
Что имеется ввиду под системой?

Отправлено Дядя Миша 31-08-2023 в 11:29:

Цитата:

FiEctro писал:
Да там простые операции, просто круговое движение.

Ты меня сейчас пытаешься убедить, что вы обновляли пять миллионов объектов на шарпе и это даже выдавало 15 фпс?

Цитата:

FiEctro писал:
там есть такое понятие как стек модификаторов или констрейнтов.

Ну ты не смешивай редакторы с игровым процессом. Редактор может выдавать хоть пять фпс. Неприятно но работать можно.

Цитата:

FiEctro писал:
Например есть у тебя куб. Ты хочешь сгладить его, накидываешь первым делом модификатор субдивайд. Потом ты хочешь например просверлить в нём отверстие, накидываешь поверх модификатор булеан, потом тебе надо сделать много копий этого меша, накидываешь модификатор аррей. Энтития всё ещё одна при этом, но делает уже несколько функций.

То есть ты вообще не понимаешь что такое ООП. Ну причём тут модификаторы?

Или ты собрался дырку в кубе сверлить каждый кадр во время игры?

Цитата:

FiEctro писал:
Можно сделать слои для партикли, типа как ты режешь модель на части для .smd так же резать и партиклю

Так это плавающий лимит. Его не надо преодолевать - и так неплохо.

Цитата:

FiEctro писал:
Что имеется ввиду под системой?

Один выстрел из пушки порождает кучку партиклов. Вот это одна система.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-08-2023 в 11:56:

Цитата:

Дядя Миша писал:
Ты меня сейчас пытаешься убедить, что вы обновляли пять миллионов объектов на шарпе и это даже выдавало 15 фпс?

Так шарп можно компилировать. Ну тоесть преобразовывать в C++ если это потребуется.

Цитата:

Дядя Миша писал:
Ну ты не смешивай редакторы с игровым процессом. Редактор может выдавать хоть пять фпс. Неприятно но работать можно.

Цитата:

Дядя Миша писал:
То есть ты вообще не понимаешь что такое ООП. Ну причём тут модификаторы?
Или ты собрался дырку в кубе сверлить каждый кадр во время игры?

Я просто привёл пример. Эти модификаторы для игр тяжелые, но в редакторах их смешиваниют регулярно. Почему нельзя делать тоже самое с энтитиями?

Цитата:

Дядя Миша писал:
Так это плавающий лимит. Его не надо преодолевать - и так неплохо.

Главное чтобы движок не крашился

Отправлено Дядя Миша 31-08-2023 в 12:35:

Цитата:

FiEctro писал:
Почему нельзя делать тоже самое с энтитиями?

Вот буквально вчера Чувачок про две игры спрашивал, почему одна логает, а другая нет. И ты жы ему привёл ссылку, правда сам ты её не читал, судя по всему, иначе бы заметил, что вторая игра не логает, потому что они полностью отказались от ECS.

Добавлено 31-08-2023 в 15:35:

Цитата:

FiEctro писал:
Так шарп можно компилировать. Ну тоесть преобразовывать в C++ если это потребуется.

Крайне сомнительно что шарп можно преобразовывать в С++, ты должно быть перепутал с БлюПринтами.
Но даже эта компиляция не даёт сопоставимой скорости работы.
Я прекрасно помню Paint.NET он логал как тысяча чертей.
Может конечно в 2005-м году шарп ещё не умел преобразовываться в нативный код.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-08-2023 в 19:00:

Цитата:

Дядя Миша писал:
Крайне сомнительно что шарп можно преобразовывать в С++, ты должно быть перепутал с БлюПринтами.

https://docs.unity3d.com/Manual/IL2CPP.html

Цитата:

Дядя Миша писал:
Вот буквально вчера Чувачок про две игры спрашивал, почему одна логает, а другая нет. И ты жы ему привёл ссылку, правда сам ты её не читал, судя по всему, иначе бы заметил, что вторая игра не логает, потому что они полностью отказались от ECS.

Хочешь сказать что 10 энтитей будут работать быстрее чем 1 с аналогичным функционалом?

Отправлено Дядя Миша 31-08-2023 в 20:24:

Цитата:

FiEctro писал:
Хочешь сказать что 10 энтитей будут работать быстрее чем 1 с аналогичным функционалом?

Наоборот. У энтить (игровых объектов) есть ужасная проблема. Они в принципе не оптимизируются. Придётся каждый кадр честно перебирать все и каждой вызывать метод обновления. Поэтому чем их больше - тем тормознее.

Добавлено 31-08-2023 в 23:24:

Цитата:

FiEctro писал:
https://docs.unity3d.com/Manual/IL2CPP.html

Фактически это декомпилятор, чтобы продукт его отрыжки скормить студии.
Интересные у вас в шарпе упражнения.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-09-2023 в 09:41:

Цитата:

Дядя Миша писал:
Наоборот. У энтить (игровых объектов) есть ужасная проблема. Они в принципе не оптимизируются. Придётся каждый кадр честно перебирать все и каждой вызывать метод обновления. Поэтому чем их больше - тем тормознее.

Что прямо совсем не оптимизируются? А какой способ реализации энтитей по твоему самый быстрый?

Отправлено Дядя Миша 01-09-2023 в 19:44:

Цитата:

FiEctro писал:
Что прямо совсем не оптимизируются?

Это концептуальное ограничение. Как ты предлагаешь апдейтить энтити выборочно?

Цитата:

FiEctro писал:
А какой способ реализации энтитей по твоему самый быстрый?

Чем их меньше тем лучшы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 02-09-2023 в 10:49:

Цитата:

Дядя Миша писал:
Чем их меньше тем лучшы.

Так ты говоришь что ECS это тоже медленно. Ну вообще я так подумал энтитии тоже можно каталогизировать для упрощения поиска. Есть например Инстанс энтитии которые создаются или удаляются, есть например вкомпиленные в карту которые никуда не деваются и никак не меняются, есть физические ну и т.д. и т.д. Вот например если мне надо например найти физический проп какой нибудь, зачем все не физические объекты перебирать? Может быть есть возможность сделать тег им какой нибудь?

Отправлено Crystallize 02-09-2023 в 10:56:

FiEctro Класснейм?

Отправлено FiEctro 02-09-2023 в 11:02:

Crystallize
Не обязательно. В целом и сам пользователь может выставлять различные теги для своих объектов. Зачем по лишнему пробегаться? По мне это очень удобно.

Отправлено Crystallize 02-09-2023 в 15:20:

FiEctro Что прямо настолько быстрее проверить наличие тега чем сравнить класснейм? Можно класснеймы захешировать и сверять чексуммы, если это быстрее.
Кстати я не так давно задумался, почему движки Кармака работают и сверяют голые строки вместо каких-нибудь хэшей или номеров как это делают японцы.

Отправлено Дядя Миша 02-09-2023 в 15:21:

Цитата:

FiEctro писал:
Ну вообще я так подумал энтитии тоже можно каталогизировать для упрощения поиска

В NT есть словари для мгновенного получения списка по имени, цели, имени класса, итд.

Цитата:

FiEctro писал:
есть например вкомпиленные в карту которые никуда не деваются и никак не меняются

Эти вообще не проявляют себя как энтити.

Цитата:

FiEctro писал:
Вот например если мне надо например найти физический проп какой нибудь, зачем все не физические объекты перебирать?

Боюсь ты опять не понял. Перебор не для поиска. Перебор для обновления.
Каждый кадр ты должен обновить все энтити. Даже если там ничего не поменялось, ты обязан им вызвать метод Update. Вот я о чём.
А теперь представь что энтить - миллион. Сам цикл время сожрёт, даже если фактического обновления и не будет. К слову пустой цикл на 4 миллиарда идёт около двух секунд.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-09-2023 в 11:50:

Цитата:

Дядя Миша писал:
Боюсь ты опять не понял. Перебор не для поиска. Перебор для обновления.
Каждый кадр ты должен обновить все энтити. Даже если там ничего не поменялось, ты обязан им вызвать метод Update. Вот я о чём.
А теперь представь что энтить - миллион. Сам цикл время сожрёт, даже если фактического обновления и не будет. К слову пустой цикл на 4 миллиарда идёт около двух секунд.

В Юнити есть ещё FixedUpdate, и частоту обновления ты ему можешь задать намного меньше чем общий фремрейт, так собственно вся физика работает. И в теории размазать твой миллион на несколько кадров, хотя я сам таким не занимался, но видел что то похожее в других проектах. Например некоторые при старте сцены инициализиют тяжелые скрипты по очереди (в основном актуально для Start), вместо того чтобы затолкать их сразу в 1 кадр.

Цитата:

Дядя Миша писал:
К слову пустой цикл на 4 миллиарда идёт около двух секунд.

Между миллионом и миллиардом большая разница.

P.S. Смотрел что я тебе в дискорд кидал?

Отправлено Дядя Миша 07-09-2023 в 20:34:

Цитата:

FiEctro писал:
Смотрел что я тебе в дискорд кидал?

Я дискорд посещаю пару раз в месяц. Нет ещё.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 10-09-2023 в 15:20:

Ну чтож, демка некоторым образом готова и отправлена на приватное тестирование. Если всё достаточно неплохо, то завтра выложу для подписчиков.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 10-09-2023 в 17:09:

Дядя Миша
Расскажи кратко что будет в демке. Ротатабля? Бамп? Тени?

Отправлено XaeroX 10-09-2023 в 18:41:

FiEctro
А чего бы тебе больше хотелось?

__________________

Отправлено nemyax 10-09-2023 в 18:44:

Цитата:

FiEctro писал:
Ротатабля? Бамп? Тени?

Pick any two.

Отправлено FiEctro 10-09-2023 в 19:06:

XaeroX
Неанимированного хряка

Отправлено Дядя Миша 10-09-2023 в 19:13:

FiEctro завтра большой пост накатаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 10-09-2023 в 20:18:

Дядя Миша в телеграм тоже тогда уж

Отправлено Дядя Миша 10-09-2023 в 20:31:

Crystallize в телеграме поменьше.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 24-09-2023 в 09:45:

После отпуска возвращаюсь к работе. Плагин для Джека вчерне готов, т.е. им уже можно пользоваться. Осталось сделать две вещи:

1. Спецификация формата .source - это нативный формат XashNT для хранения исходников уровней, префабов и прочего.

2. Компиляция плагина в 64-битную версию.

Потом будет большая ревизия исходников, дописание недостающих мелочей (например генерация Tangent-Space для бамп-маппинга или T-Junc полигонов), некоторые вещи ждут своего часа с 2020-го года.

Затем - создание SampleSDK, простейших примеров и возможностей.
Потом написание документации и первый релиз инструментария.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 24-09-2023 в 13:43:

Цитата:

Дядя Миша писал:
Плагин для Джека вчерне готов, т.е. им уже можно пользоваться.

То есть игры на ксаше нужно будет делать в джеке? Свой редактор писать передумал?

Отправлено XaeroX 24-09-2023 в 14:19:

(_-=ZhekA=-_)
Чем же тебя Джек не устроил?

__________________

Отправлено Дядя Миша 24-09-2023 в 14:39:

Цитата:

(_-=ZhekA=-_) писал:
То есть игры на ксаше нужно будет делать в джеке?

Ты очень невнимательно читаешь. Свой редактор запланирован на будущий год, а пока можно и в Джеке помаппить.

Набросал первичную имплементацию текстового формата для хранения уровней .source
Пример того, как он выглядит:

C++ Source Code:

1	"EntityDef"

3	"id" "324"

4	"classname" "trigger_multiple"

5	"spawnflags" "2048"

6	"angle" "270"

7	"message" "Shub-Niggurath awaits you..."

8	"sounds" "2"

9	"wait" "5"

10	"angles" "0.00 270.00 0.00"

12	"ConvexDef"

14	"id" "1246"

    "SideDef"

18	"id" "7403"

19	"material" "start/trigger"

20	"plane" "1 0 0 0"

21	"uaxis" "1 0 0"

22	"vaxis" "0 1 0"

    "SideDef"

27	"id" "7402"

28	"material" "start/trigger"

29	"plane" "0 1 0 2016"

30	"uaxis" "-1 0 0"

31	"vaxis" "0 1 0"

    "SideDef"

36	"id" "7405"

37	"material" "start/trigger"

38	"plane" "0 0 1 -312"

39	"uaxis" "0 1 0"

40	"vaxis" "-1 0 0"

    "SideDef"

45	"id" "7406"

46	"material" "start/trigger"

47	"plane" "0 0 -1 376"

48	"uaxis" "0 -1 0"

49	"vaxis" "-1 0 0"

    "SideDef"

54	"id" "7404"

55	"material" "start/trigger"

56	"plane" "0 -1 0 -2000"

57	"uaxis" "1 0 0"

58	"vaxis" "0 1 0"

    "SideDef"

63	"id" "7401"

64	"material" "start/trigger"

65	"plane" "-1 0 0 208"

66	"uaxis" "-1 0 0"

67	"vaxis" "0 1 0"

Несколько избыточно, но максимально дружелюбно для ручного редактирования и потенциально с бесконечной расширяемостью.
Формат так же позволяет хранить в нём мешы, патчи, ландшафты, любой тип исходной геометрии, вообщем. Впрочем, старый-добрый .map тоже естественно, поддерживается. Вышеприведённый формат - он скорее для будущего редактора, нежели для Джека.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 24-09-2023 в 15:29:

Цитата:

Дядя Миша писал:
"EntityDef"

Я боюсь этих ваших "Def" с непривычки. Это была какая-то непонятная фигня из 3 кваки.

Отправлено Дядя Миша 24-09-2023 в 15:45:

Crystallize ключевое звено нового формата - именованный блок фигурных скобок внутри которого находится пара ключ-значение.
Т.е. никаких больше длинных строк с неизвестным числом аргументов и кучей лишних скобок, как круглых, так и фигурных.
Чтобы было понятнее - теперь геометрия описана таким же образом, как и настройки энтити.

Добавлено 24-09-2023 в 18:40:

Конечно уровни из сталкера в такой формат сохранять не рекомендуется - он распухнет до пары гигабайт. Но это и не требуется - для хранения высокополигональной геометрии есть формат .csm

Добавлено 24-09-2023 в 18:44:

Так же хочу обратить ваше внимание - формат полностью отвязан от размера текстур. И есть возможность сохранять текстурные оси (то что приведено в примере), текстурные вектора, или даже старый способ с оффсетами и вращением - просто используя другие ключи.
Аналогично, вместо ключа "material" можно использовать ключ "texture" или даже "mipmap" для разных способов. Скорее всего в XashNT это не понадобится, но я делаю все эти форматы с дальним прицелом - на стандартизацию.

Добавлено 24-09-2023 в 18:45:

Следующая задача - ревизия интерфейсов виртуальных машин, чтобы потом можно было подключить к ним сетевой интерфейс, не ломая совместимость.
Т.е. интерфейсы которые сейчас в демке скоро станут неактуальными, но пока что это не имеет никакого значения.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 24-09-2023 в 16:02:

Цитата:

XaeroX писал:
Чем же тебя Джек не устроил?

К джеку претензий вообще нет, я просто спросил

Цитата:

Дядя Миша писал:
Ты очень невнимательно читаешь. Свой редактор запланирован на будущий год, а пока можно и в Джеке помаппить.

А ну ок, значит просто, что-то не так понял

Отправлено Crystallize 24-09-2023 в 17:31:

Цитата:

Дядя Миша писал:
Crystallize ключевое звено нового формата - именованный блок фигурных скобок внутри которого находится пара ключ-значение.

я именно про три буквы эти

Цитата:

Дядя Миша писал:
Аналогично, вместо ключа "material" можно использовать ключ "texture" или даже "mipmap" для разных способов. Скорее всего в XashNT это не понадобится, но я делаю все эти форматы с дальним прицелом - на стандартизацию.

Отсутствием мипмапов кстати можно делать переливы воды под солнцем на горизонте.

Отправлено Дядя Миша 24-09-2023 в 18:50:

Цитата:

Crystallize писал:
Отсутствием мипмапов кстати можно делать переливы воды под солнцем на горизонте

А если не очищать буффер цвета, то получится блюр.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 26-09-2023 в 10:27:

Та демка, что я выложил 11-го сентября была крайним билдом с возможностью подгружать не только виртуальные машины, но и игровые дллки (как в халфе). Самих дллок я, разумеется, не приложил, поэтому для вас разницы нет. Но в дальнейшем всё взаимодействие пользователя с движком будет только через мой собственный язык программирования Shot (ну или HeadShot), кому как больше нравится.
Про этот язык я уже писал, а кое-кто даже успел пощупать.
Вкратце для тех, кто пропустил - язык ОЧЕНЬ сильно напоминает С++, как визуально, так и по логике работы. Однако в нём устранён один из самых главных недостатков С++ - дебильная работа со строками, которая стабильно фрустирует каждое поколение начинающих программистов.
Так же присутствует мощная система отладки, брэк-поинтов и встроенный профайлер, который рисует визуальные графики нагрузки.
Из коробки поддерживается сериализация объектов, есть возможность создавать приватные объекты (в которые бакэнд совсем не сможет вмешаться, ни на чтение ни на запись).
Так же (ну пока только в теории), этот язык как бы включает в себя разнообразные достижения как низкоуровневых, так и высокоуровневых языков, позволяя портировать их исходники на Шот. В случае с С\С++ потребуются минимальные усилия, более творческий подход потребуется для таких языков, как Delphi, Java, C#, но в целом это тоже реально.

Добавлено 26-09-2023 в 13:27:

И ещё один момент: в отличие от того же QuakeC, язык не имеет какой-то явной привязки к игровому коду и без проблем может быть использован для любых задач. Так что в дальнейшем есть вероятность появления отдельной реализации самого языка, для тех, кому игры неинтересны.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 26-09-2023 в 11:16:

Цитата:

Дядя Миша писал:
Однако в нём устранён один из самых главных недостатков С++ - дебильная работа со строками, которая стабильно фрустирует каждое поколение начинающих программистов.

Вот за это большое спасибо. В c++ это реально напрягает. Порой что даже сам компилятор с ума сходит.

Цитата:

Дядя Миша писал:
Так же присутствует мощная система отладки, брэк-поинтов и встроенный профайлер, который рисует визуальные графики нагрузки.

Супер! Шикардос! Хорошие инструменты отладки это залог успеха. Надеюсь так же будут иструменты отладки и для работы с объектами, вывод их списка, поиск, чтение параметров и т.д.

Цитата:

Дядя Миша писал:
Из коробки поддерживается сериализация объектов, есть возможность создавать приватные объекты (в которые бакэнд совсем не сможет вмешаться, ни на чтение ни на запись).

Не совсем понял, а разве в c++ этого не было? Я просто не очень хорошо в крестах шарю.

Цитата:

Дядя Миша писал:
Так же (ну пока только в теории), этот язык как бы включает в себя разнообразные достижения как низкоуровневых, так и высокоуровневых языков, позволяя портировать их исходники на Шот. В случае с С\С++ потребуются минимальные усилия, более творческий подход потребуется для таких языков, как Delphi, Java, C#, но в целом это тоже реально.

Главное чтобы работу с памятью упростить. В C++ уж оно слишком формализовано, далеко не всегда такое требуется при написании игровой логики. Кстати даю подсказку, для C++ вроде как есть библиотеки которые позволяют юзать на крестах некоторые фичи из C#. Название забыл, если найду, напишу. Да думаю ты и сам такие встречал. Тоже было бы полезно включить в базовый пакет, чтобы каждый раз не писать велосипеды, вроде тех же векторов, кватернионов, листов, карутинов и т.д..

Отправлено Дядя Миша 26-09-2023 в 11:56:

Цитата:

FiEctro писал:
Надеюсь так же будут иструменты отладки и для работы с объектами, вывод их списка, поиск, чтение параметров и т.д.

Да подключить недолго, просто я пока толком не знаю, что именно вам понадобится. Потом расскажете в процессе тестирования.

Цитата:

FiEctro писал:
Не совсем понял, а разве в c++ этого не было?

Сериализации? Откуда же она возьмется изкаропки-то. Каждый сам извращается как может и мета-информацию ручками прописывает.
Это-то, собственно и бесит больше всего. Для Qt вон даже собственный компилятор изобрели, который мета-информацию сам генерирует.

А насчёт приватных объектов - не забывай что речь о виртуальной машине,а значит бакэнд может напрямую вмешиваться в состояние любого объекта и модифицировать его. Так вот у меня существует возможность создания приватных объектов. Причём приватность в данном случае - это не какой-то там флажок, они реально приватные.

Цитата:

FiEctro писал:
далеко не всегда такое требуется при написании игровой логики.

Для игровой логики всё это и не потребуется. Но вообще полноценная работа с памятью присутствует.

Цитата:

FiEctro писал:
Тоже было бы полезно включить в базовый пакет, чтобы каждый раз не писать велосипеды, вроде тех же векторов, кватернионов, листов, карутинов и т.д..

Я их уже написал, они входят в SDK.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 26-09-2023 в 13:54:

Цитата:

FiEctro писал:
Главное чтобы работу с памятью упростить. В C++ уж оно слишком формализовано, далеко не всегда такое требуется при написании игровой логики.

Играясь с врадом я сначала только мечтал анализировать строки, но в итоге выловил в памяти имена статик пропов и отсортировал те которые мне были нужны и не нужны. А вот сейчас я занимаюсь тем что наверное можно назвать машиной конечных состояний, и это реально тяжко потому что приходится мыслить строго логически как компьютер. Но тут я с трудом представляю какую подсистему ДМ мог бы написать для помощи в таких случаях.

Отправлено Дядя Миша 26-09-2023 в 18:08:

Цитата:

Crystallize писал:
но в итоге выловил в памяти имена статик пропов и отсортировал те которые мне были нужны и не нужны

Ты поосторожнее с этим. А то был у нас тут один форумчанин. Тоже строчки сортировал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 27-09-2023 в 05:58:

Цитата:

Дядя Миша писал:
Та демка, что я выложил 11-го сентября была крайним билдом с возможностью подгружать не только виртуальные машины, но и игровые дллки (как в халфе). Самих дллок я, разумеется, не приложил, поэтому для вас разницы нет. Но в дальнейшем всё взаимодействие пользователя с движком будет только через мой собственный язык программирования Shot (ну или HeadShot), кому как больше нравится.

Дал другим программистам почитать, они говорят что ты изобретаешь заново C# (и в этом нет ничего плохого, даже наоборот). Может имеет смысл его использовать за основу, а не кресты

? Каково вообще твоё мнение о шарпах?

Отправлено Дядя Миша 27-09-2023 в 06:29:

Цитата:

FiEctro писал:
они говорят что ты изобретаешь заново C#

Это потому что, они ещё не видели сам язык. Это НЕ ШАРП.
Я собственно и хотел уйти от этой порочной схемы, когда всё - объект.
Это очень сильно тормозит работу и по факту не даёт никаких преимуществ.
Моя идея заключалась в том, что С++ по своей природе очень сильно похож на скриптовой язык, особенно когда ты настроишь ему всякие операторы и методы доступа. Значит эту особенность просто надо развить и углубить, сохраняя главный принцип - вы не платите за то, чем не пользуетесь.
Что я, собственно, и сделал.
Проблема явы и шарпов в том, что там каждая переменная это по сути объект, к тому же в этих языках творится какая-то чертовщина со стеком, поэтому о приличной производительности говорить не приходится.
К тому же в природе не существует языка, с синтаксисом близким к С++, который бы позволил на себя полноценно портировать программы с Делфи.
И это тоже было частью задачи.

Занялся рефакторингом ядра движка. Эта задача ждала своего часа с сентября 2019-го года

Как вы наверное помните тогда уже во весь рост встал вопрос, что надо избавляться от дллок и переходить на скрипты. Но реализации скриптового языка на тот момент у меня не было. И я занялся другими, не менее важными задачами, такими как разработка собственного формата уровней, моделей, спрайтов, разработкой системы материалов, написание компиляторов под новые форматы. И вот теперь наконец-то возвращаюсь к исходной задаче. Когда у меня уже есть готовая демка игры, написанная полностью на скриптовом языке и оттестированая вами на предмет боле-мене правильной работы. Теперь это наконец-то стало возможным.
Как вы понимаете, ядро XashNT - это переделанный Xash3D. Всё остальное было написано с нуля, а вот ядро движка в лучших традициях Кармака,я взял от своей преведущей разработки. И соответственно там надо многое переделать. По факту от старого кода ничего не останется с течением времени. Может только какие-то внешние черты сохранятся и названия некоторых функций.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 27-09-2023 в 08:34:

Цитата:

Дядя Миша писал:
К тому же в природе не существует языка, с синтаксисом близким к С++, который бы позволил на себя полноценно портировать программы с Делфи.

Тебя спонсируют разработчики Космических рейнджеров?

Добавлено 27-09-2023 в 15:34:

Цитата:

FiEctro писал:
Дал другим программистам почитать, они говорят что ты изобретаешь заново C# (и в этом нет ничего плохого, даже наоборот). Может имеет смысл его использовать за основу, а не кресты ? Каково вообще твоё мнение о шарпах?

А можешь скопипастить что там они писали?
Вообще сейчас народ над сишарпом скорее кекает.

Отправлено Дядя Миша 27-09-2023 в 08:41:

Цитата:

Crystallize писал:
Тебя спонсируют разработчики Космических рейнджеров?

Мне хочется иметь возможность портировать интерфейс Кварка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 27-09-2023 в 09:25:

Цитата:

Crystallize писал:
А можешь скопипастить что там они писали?

Мы в дискорде обсуждали, в голосовом.

Цитата:

Crystallize писал:
Вообще сейчас народ над сишарпом скорее кекает.

А че над ним кекать? По крайней мере в отличие от ЖаваСкрипта и Питона там с типизацией всё впорядке.

Цитата:

Дядя Миша писал:
Мне хочется иметь возможность портировать интерфейс Кварка.

Это звучит как сценарий к новому фильму по мотивам Зелёного слоника

Отправлено Дядя Миша 27-09-2023 в 12:11:

Самое главное - это энтити инспектор и компас.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 27-09-2023 в 12:41:

Цитата:

FiEctro писал:
Это звучит как сценарий к новому фильму по мотивам Зелёного слоника

А что ты скриншотом хочешь сказать? Типа некрасиво? Можно подумать хаммер с большим открытым проектом выглядит как картина Васнецова? Или всех должен напугать вот этот второй ряд кнопочек который никто не юзает?

Отправлено (_-=ZhekA=-_) 27-09-2023 в 12:58:

Хотел в гугле найти скрины кварка, чтобы глянуть, что это за хрень такая и ничерта не нашел...
Видимо не очень популярный редактор

Отправлено Дядя Миша 27-09-2023 в 13:19:

Цитата:

Crystallize писал:
Или всех должен напугать вот этот второй ряд кнопочек который никто не юзает?

В том кварке, который юзал я этого ряда ещё не было. Его потом уже добавили, когда сменился разработчик. Понятное дело, что сам он в редакторе никогда не работал, вот и начал от балды городить.

Добавлено 27-09-2023 в 16:19:

Ну к слову все эти ряды кнопок без проблем вытаскиваются со своих посадочных мест и их можно вообще закрыть.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 27-09-2023 в 13:48:

Цитата:

Дядя Миша писал:
и компас.

Зачем он кстати там нужен?

Цитата:

Crystallize писал:
А что ты скриншотом хочешь сказать? Типа некрасиво? Можно подумать хаммер с большим открытым проектом выглядит как картина Васнецова? Или всех должен напугать вот этот второй ряд кнопочек который никто не юзает?

Да просто не все уже помнят как он выглядит

Даже самая древняя версия хаммера выглядит куда понятнее и интуитивнее кварка. Но соглашусь с ДМ что некоторые интересные фишки там есть. Тот же список объектов.

Отправлено Crystallize 27-09-2023 в 15:04:

Цитата:

(_-=ZhekA=-_) писал:
Хотел в гугле найти скрины кварка, чтобы глянуть, что это за хрень такая и ничерта не нашел...
Видимо не очень популярный редактор

Quake army knife пиши

Цитата:

FiEctro писал:
Даже самая древняя версия хаммера выглядит куда понятнее и интуитивнее кварка.

Наверное это иллюзия от того что сразу видишь 5 кнопок с режимами, а всё остальное в менях.

Цитата:

FiEctro писал:
Но соглашусь с ДМ что некоторые интересные фишки там есть. Тот же список объектов.

Творческий поиск удобнее в Хаммере-Джеке. Когда не знаешь чего хочется и просто накидываешь браши. Когда уже есть план и ты знаешь какие инструменты и модификаторы хочешь юзать, то удобнее Кварк. Или когда нужно что-то однообразное типа скал или улицы с бордюрами.

Отправлено FiEctro 27-09-2023 в 15:07:

Цитата:

Crystallize писал:
Творческий поиск удобнее в Хаммере-Джеке. Когда не знаешь чего хочется и просто накидываешь браши. Когда уже есть план и ты знаешь какие инструменты и модификаторы хочешь юзать, то удобнее Кварк. Или когда нужно что-то однообразное типа скал или улицы с бордюрами.

И то и другое является устаревшим анахронизмом из начала нулевых.

Отправлено Crystallize 27-09-2023 в 15:22:

FiEctro Браши-то? Ну как минимум у них нет изнаночных сторон что легче для восприятия человеком. Плюс бесшовное текстурирование по ПКМ. В 3д-пакетах есть где-нибудь такое текстурирование? Было бы очень удобно же.

Отправлено FiEctro 27-09-2023 в 15:55:

Цитата:

Crystallize писал:
FiEctro Браши-то? Ну как минимум у них нет изнаночных сторон что легче для восприятия человеком. Плюс бесшовное текстурирование по ПКМ. В 3д-пакетах есть где-нибудь такое текстурирование? Было бы очень удобно же.

Дело не в брашах, а так скажем сами подходы к интерфейсам немного изменились.

Отправлено Crystallize 27-09-2023 в 16:20:

FiEctro Когда интерфейс основан не на кнопках с подписями а на пиктограммах? Да вроде и Кварк на этом построен. Но на самом деле это плохая идея потому что документацию читать не будешь и пойдёшь за объяснениями к инфоцыганам. Красиво но для новичка неудобно.

Отправлено Дядя Миша 27-09-2023 в 18:02:

Цитата:

FiEctro писал:
Зачем он кстати там нужен?

Карту вращать. Дичайше удобно. Я постоянно им пользуюсь.

Цитата:

FiEctro писал:
Даже самая древняя версия хаммера выглядит куда понятнее и интуитивнее кварка

Уж так интуитивно выглядит постоянное переключение режимов и наобходимость постоянно нажимать Enter.

Добавлено 27-09-2023 в 21:01:

Больше всего меня бесят четыре окна в моделилках. Четыре окна это дико избыточно + они мелкие. Одно окно - недостаточно. Два окна - идеально.
Но так никто не делает.

Добавлено 27-09-2023 в 21:02:

Хотя нет, вру, в Юнити вроде видел два окна.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 27-09-2023 в 18:15:

Цитата:

Crystallize писал:
Quake army knife пиши

Один хрен нет нормальных скринов в хорошем качестве...

Отправлено FiEctro 27-09-2023 в 18:57:

Цитата:

Дядя Миша писал:
Карту вращать. Дичайше удобно. Я постоянно им пользуюсь.

Вместо камеры вращать карту 0_о?

Цитата:

Дядя Миша писал:
Больше всего меня бесят четыре окна в моделилках. Четыре окна это дико избыточно + они мелкие. Одно окно - недостаточно. Два окна - идеально.

Плюсую

Отправлено Дядя Миша 27-09-2023 в 19:03:

Цитата:

FiEctro писал:
Вместо камеры вращать карту 0_о?

В окнах с ортогональным видом - да. В трёхмерном - летаешь камерой как обычно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 27-09-2023 в 19:42:

Дядя Миша
Ну я понял, рудимент короче. Щас это просто кубик который рисуют поверх вьюпорта.

Отправлено Crystallize 27-09-2023 в 22:42:

Цитата:

Дядя Миша писал:
Уж так интуитивно выглядит постоянное переключение режимов и наобходимость постоянно нажимать Enter.

Да там режимы переключаешь раз в несколько минут, а браши просто копируются а не создаются новые.

Отправлено Дядя Миша 28-09-2023 в 06:19:

Изучил устройство сетевых подсистем в некоторых движках. Для начала - в околоклонах того же квейка. Что хочу сказать - там абсолютно везде использовано допущение, что сеть должна посылать пакеты намного реже, чем сервер выполняет кадров. Мало этого - в большинстве случаев там ещё нет и явной связи между кол-вом кадром выполненных сервром и временем для передачи очередного пакета. Сеть живёт по каким-то своим асинхронным правилам. Из-за этого обстоятельства нам приходится накапливать на клиенте кадры, пытаться всё это дело проинтерполировать или предсказывать. Структуры, нужные для интерполяции или предсказания занимают очень много места на самом деле. Да и само выполнение сетевого кода далеко не бесплатное.
Пока что навскидку наметил вот какую схему сетевой интеракции:
1. Сервер и Клиент хранят в себе состояние предидущего кадра, для каждого объекта отдельно. Хранят в виде bitstrem в raw-массиве и только для тех объектов, которым вообще требуется синхронизация. Критерии известны с незапамятных времён - у объекта должна быть модель. Разумеется можно завести какой-то флажок для форсирования отправки на клиент, ну руководствоваться одним только флажком неудобно.
2. Клиент и Сервер тикают синхронно 60 кадров в секунду. Никакого удушения и пропуска пакетов не предусмотрено. Это в свою очередь избавляет нас от необходимости заведения каких-то промежуточных структур для интерполяции значений, которые ещё надо куда-то сохранять, менять местами и выполнять кучу дополнительных действий. В норме интерполяция не нужна вообще. Я допускаю необходимость локальной интерполяции, скажем в рамках того же сервера, когда монстры делают шаг всего 10 раз в секунду, а в промежутках их позиция плавно двигается к заданной точке. Как минимум потому что между этими действиями нет реальных факторов в виде лага сетевого пакета, значит такая интерполяция будет всегда работать надёжно.
3. Несмотря на отсутствие пропуска пакетов, в дело вмешивается фактор их задержки. Если задержка менее времени кадра - менее 16 милисекунд, то всё хорошо. Нам даже не потребуется ничего предиктить.
Если же задержка выше, то клиент продолжает выполнять локальную симуляцию мира в ожидании очередного пакета. И при получении данных - просто обновляет их для клиентских объектов.
4. При таком подходе размер пакета может вырастать до приличных значений, однако не всё так плохо.
- Посылаются только переменные, отличные от ноля
- Посылаются только переменные, которые изменились с преведущего кадра
- Посылаются в виде небольшого кол-ва бит
- Если пакет достаточно большой, его можно дополнительно сжать LZSS
- Если даже такой пакет превысил MTU, его можно слать фрагментами. Фрагментация отправляет пачку пакетов за один кадр, но с этим я пока ещё толком не разобрался. UDP совершенно точно может отправлять и принимать пакеты размером до 65к чего бы мне хватило за глаза, но к сожалению в целях совместимости в большинстве случаев размер пакета ограничен прямо в настройках роутера.

Любопытно, что вышеприведённой схеме в наибольшей мере соответствует Normal Quake, который пакеты не душит, правда и предиктинга там тоже нет. Собственно уже в QuakeWorld ввели удушение пакетов и на тот момент (97-й года, диалап) это было неплохим решением. Ну а потом это удушение унаследовали все форки квейка, включая сорс и вероятно даже сорс2.
Надо будет ещё исследовать унреалы, край-энджины, сталкер.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-09-2023 в 08:03:

Цитата:

Дядя Миша писал:
- Если даже такой пакет превысил MTU, его можно слать фрагментами. Фрагментация отправляет пачку пакетов за один кадр, но с этим я пока ещё толком не разобрался. UDP совершенно точно может отправлять и принимать пакеты размером до 65к чего бы мне хватило за глаза, но к сожалению в целях совместимости в большинстве случаев размер пакета ограничен прямо в настройках роутера.

Кстати да, я тоже сталкивался с этим на Юнити, на разных провайдерах и роутерах размер пакета может отличаться. Где то он пропускает, а где то нет. Неужели нет какого то стандарта?

Кстати сейчас многие движки помимо подключеня по UDP могут ещё использовать различные веб протоколы.
https://docs.unity3d.com/ScriptRefe...WebRequest.html

Отправлено Дядя Миша 28-09-2023 в 09:32:

Цитата:

FiEctro писал:
Неужели нет какого то стандарта?

Стандарт есть, и он как раз и равен 1400 байт.
Проблема сразу с двух сторон. Этот стандарт был принят во времена диалап подключения и давно уже устарел. Но его по прежнему придерживаются по принципу "как бы чего не вышло". UDP позволяет отправлять до 65 килобайт за раз, чего достаточно для всех случаев. Умные роутеры сами фргаментируют такие пакеты на мелкие. Но даже сейчас далеко не все этим занимаются. Потому что стандарта на фрагментацию - нет.
А вторая сторона - то что 1400 байт для одного пакета никогда не хватает.
Скажем во время игры можно удерживаться в рамках такого пакета без проблем, а во время подключения - нет. Кстати в том же QuakeWorld фрагментация как раз и была во время подключения, а потом она уже была не нужна.

Цитата:

FiEctro писал:
могут ещё использовать различные веб протоколы

UDP это протокол с минимальной латентностью, в этом его смысл.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 28-09-2023 в 11:38:

Цитата:

Дядя Миша писал:
Любопытно, что вышеприведённой схеме в наибольшей мере соответствует Normal Quake, который пакеты не душит, правда и предиктинга там тоже нет. Собственно уже в QuakeWorld ввели удушение пакетов и на тот момент (97-й года, диалап) это было неплохим решением.

Там чета в мемуарах же они писали что сначала они сильно недооценили убожество телефонных линий, по факту средний пинг был выше раза в два, и т.д.

Отправлено Дядя Миша 28-09-2023 в 14:38:

Цитата:

Crystallize писал:
сначала они сильно недооценили убожество телефонных линий

Ну да, понадеялись на лучшее, ведь Америка - это великая страна, там же всё идеально и по другому быть просто не может

Ну а мне собственно осталось выполнить две глобальных, масштабных задачи:
1. Имплементация сетевой подсистемы в движке
2. Написание собственного редактора

Когда это будет сделано, можно считать что основной цикл разработки завершён и наступает время техподдержки. Буду спокойно дописывать некоторые недостающие мелочи, добавлять фичереквесты по просьбам фичекриперов, исправлять ошибки, итд.
На всё-про-всё понадобится ещё примерно год. Может быстрее управлюсь, но пока не буду загадывать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-09-2023 в 15:43:

Дядя Миша
А чем мультиплеер первой и второй кваки отличается от мультиплеера первохалфы? И что с ним сделали в сорсе?

Отправлено Дядя Миша 28-09-2023 в 16:11:

В первой кваке не было предиктинга. Она вообще не была рассчитана на игру по интернету в тогдашних условиях. Чтобы исправить это недоразумение, Кармак сделал QuakeWorld, который был заточен исключительно под мультиплеер. Халфа первоначально базировалась на исходниках кваки, не заточенной под мультиплеер - это самые первые версии. Потом появилась CS и встал вопрос о комфортной игре по интернету.
Тогда вальвовцы конкретно прокачали сетевой движок, используя наработки от QuakeWorld, Quake 2 и собственные. В результате получилась мощная сетевая подсистема. Она же изначально была использована в Сорсе, но что там потом с ней делали я уже не знаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 28-09-2023 в 22:11:

Цитата:

Дядя Миша писал:
3. Несмотря на отсутствие пропуска пакетов, в дело вмешивается фактор их задержки. Если задержка менее времени кадра - менее 16 милисекунд, то всё хорошо. Нам даже не потребуется ничего предиктить.

Предиктинг и задержки между кадрами -- вещи ортогональные. Хороший предиктинг должен "ощущаться" как локальная игра. Отличный предиктинг ещё и освобождает сервер от пересылки части данных.

Можно конечно сделать иначе и на клиенте крутить основную логику, а сервер занять только пересылкой данных между клиентами. В некоторых играх это сделано (и теперь они борются с читами).

Твоя схема синхронно отправлять 60 кадров отличается от удушения в кваке только тем, что лимит просто чуть выше. 60 кадров может не хватить клиенту, а серверу и явно сильно больше можно.

Цитата:

Дядя Миша писал:
UDP совершенно точно может отправлять и принимать пакеты размером до 65к чего бы мне хватило за глаза, но к сожалению в целях совместимости в большинстве случаев размер пакета ограничен прямо в настройках роутера.

Физически, да, 65к. Но это редкость.
Оно, в том числе ограничено не только роутером который у вас стоит дома, но и всем сетевым оборудованием, которое находится на пути. Есть такая штуковина, которая называется Path MTU Discovery, работает просто -- если пакет не пролазит, то в ответ присылается ICMP пакет с MTU. Посылать до тех пор, пока не пролезет. Работает не везде, потому что ICMP можно игнорировать.

Цитата:

FiEctro писал:
Кстати да, я тоже сталкивался с этим на Юнити, на разных провайдерах и роутерах размер пакета может отличаться. Где то он пропускает, а где то нет. Неужели нет какого то стандарта?

В том-то и дело, что он как бы есть. В RFC 791 у IPv4 минимальный размер датаграммы что-то в районе 570 байт, на практике что-то в районе 1400-1500, в какой-нибудь локалке может быть и 65к. У IPv6 таки подняли лимит до 1280, с той же оговоркой, что может быть и больше. Надо ещё не забывать что Ethernet MTU -- это 1500 байт, поэтому я мало понимаю, где Дядя Миша находит 65к.

Добавлено 29-09-2023 в 01:11:

Алсо, 2 Дядя Миша, testpacket для определения MTU был не очень хорошей идеей. Учитывая что это пакет который отправляется до поднятия нетчана, его может отправлить кто угодно. В том числе отправлять по кругу, высаживая FPS сервера в 0. В том числе отправлять с левых IP адресов. (да, это возможно, просто отправляешь сырой IP пакет с левым адресом в поле source. Некоторые провайдеры это не чинят, несмотря на то, что противодействовать этому очень легко)

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 29-09-2023 в 06:44:

Цитата:

a1batross писал:
Предиктинг и задержки между кадрами -- вещи ортогональные

Когда у тебя асинхронная петля и клиент-сервер тикают с одинаковым зазором предиктингу просто некуда вмешиваться. Такое может возникнуть при условии, что в один из кадров пакет не пришёл.

Цитата:

a1batross писал:
Отличный предиктинг ещё и освобождает сервер от пересылки части данных.

Одновременно усложняя сетевой механизм и раздувая память для хранения дельты.

Цитата:

a1batross писал:
60 кадров может не хватить клиенту, а серверу и явно сильно больше можно.

Сейчас всё работает на 60 кадров. Правда совсем без сети.

Цитата:

a1batross писал:
testpacket для определения MTU был не очень хорошей идеей

Учитывая открытые сорцы и нелюбовь к своевременному апдейту на исправленные версии, наличие сети само по себе - не очень хорошая идея.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 29-09-2023 в 09:29:

Возможно ли какое-то упрощение работы с клиент-сервером? Например я залажу в условный func_car ~~который горит в лесу~~ и в зависимости от того, от 3-го лица у меня камера или от 1-го, мне может понадобиться анимация всего персонажа или по крайней мере камеры и вьюмодели. Значит нужно снова тянуться в hud.cpp чтобы сделать мессагу и проиграть анимацию на клиенте.

Отправлено Дядя Миша 29-09-2023 в 10:08:

Цитата:

Crystallize писал:
Возможно ли какое-то упрощение работы с клиент-сервером?

Сейчас всё устроено таким образом, что на клиенте - только отрисовка худа и обработка кнопок. Ну и небольшой сетап экрана - его размер и fov.
Больше там ничего нет и не планируется. Т.е. постоянно лазить туда-сюда не придётся.

Добавлено 29-09-2023 в 13:08:

Вью-модели теперь - это самые обычные энтити, которые приаттачены к игроку. Я там в дальнейшем им добавлю фильтры, чтобы моделька от первого лица рисовалась только от первого лица и у локального клиента.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 29-09-2023 в 14:37:

Цитата:

Дядя Миша писал:
Когда у тебя асинхронная петля и клиент-сервер тикают с одинаковым зазором предиктингу просто некуда вмешиваться. Такое может возникнуть при условии, что в один из кадров пакет не пришёл.

Предиктинг исправляет проблему в основном с задержками. Нет смысла ждать пока сервер обработает +forward, если на клиенте мы можем рассчитать то же самое с минимальной погрешностью.

Без предиктинга для игрока это базовая задержка в 33 мс (отправка + получение), а она достаточно заметна, уже не говоря о задержке отображения кадра на мониторе.

Клиент так же может выставить лимит в 144 FPS, учитывая что играет он на 144 Гц мониторе. В данном случае задержка ~7мс и привязка к 60 здесь не нужна.

Цитата:

Дядя Миша писал:
Учитывая открытые сорцы и нелюбовь к своевременному апдейту на исправленные версии, наличие сети само по себе - не очень хорошая идея.

Это само собой. Я сделал механизм, который сохранял чексуммы от тестового пакета. И он у меня даже заработал, по крайней мере стало невозможно положить сервер просто отправляя по кругу запросы на тестовый пакет, но в итоге мне просто не понравилось то как я сделал.

__________________
Xash3D FWGS форк

Отправлено Crystallize 29-09-2023 в 16:50:

Цитата:

a1batross писал:
Клиент так же может выставить лимит в 144 FPS, учитывая что играет он на 144 Гц мониторе. В данном случае задержка ~7мс и привязка к 60 здесь не нужна.

Кстати а не будет ли дергания если фпс не кратный 60? Может предусмотреть вариант 72?

Добавлено 29-09-2023 в 23:49:

Цитата:

Дядя Миша писал:
Сейчас всё устроено таким образом, что на клиенте - только отрисовка худа и обработка кнопок. Ну и небольшой сетап экрана - его размер и fov.
Больше там ничего нет и не планируется. Т.е. постоянно лазить туда-сюда не придётся.

Кажется что-то такое было в клиенте ХЛ1 на релизе, а потом Вальв туда целого слона запихнули.

Добавлено 29-09-2023 в 23:50:

Так получается что концепция мессаг вообще уходит в прошлое, ну для моддера по крайней мере?

Отправлено a1batross 29-09-2023 в 17:19:

Crystallize будет, если тикать синхронно и без предиктинга.

__________________
Xash3D FWGS форк

Отправлено Дядя Миша 29-09-2023 в 18:46:

Цитата:

a1batross писал:
Нет смысла ждать пока сервер обработает +forward, если на клиенте мы можем рассчитать то же самое с минимальной погрешностью.

Ну это для игрока. А я мыслю категорией "предиктинг для всего".

Цитата:

a1batross писал:
Клиент так же может выставить лимит в 144 FPS

Петля всё равно будет 60 герц, это не регулируется.

Цитата:

Crystallize писал:
Кажется что-то такое было в клиенте ХЛ1 на релизе, а потом Вальв туда целого слона запихнули.

Оно просто не торчало наружу.

Цитата:

Crystallize писал:
Так получается что концепция мессаг вообще уходит в прошлое, ну для моддера по крайней мере?

Остались, никуда не делись. Ну как-то же параметры худа надо передать на клиент, здоровье, броньку, пушки там.

Добавлено 29-09-2023 в 21:46:

Наконец-то у меня дошли глаза просмотреть те ролики, которые скинул мне FiEctro про S&3 Box, кажется так оно называется.
Самое главное сказано в середине второго ролика - Вальв дала одному из авторов гаррис мода полные исходники второго сорса, ну или может не полные, а только SDK (остальным не дали и этого) и он на их основе замутил этот самый S&3 Box. Я ведь собственно, почему удивился? Да потому что знал, что SDK от второго сорса в общем доступе нет. И его никому не дают.
Но раз так, каким же образом, не имея исходников был сделан этот S&3Box?
А вот теперь и понятно каким.
Что тут можно сказать - чувствуется одновременно и влияние Unity и влияние Source. Но остаётся вопрос - а чем это будет лучше Unity? Ну ок, у Сорса были какие-то проблемы, он в процессе разработки утратил разделение кода на пользовательский и системный. И вот автор гаррис-мода его вернул через своё творение. Теперь все могут этим пользоваться. А Юнити наоборот подорвал доверие к своей политики. И теперь все могут перейти с Unity на этот S&3Box, и там и там - сишарп. Самое интересное в этой истории - сравнить возможности движков. Может быть Unity в подмётки не годится новому сорсу, а может быть он напротив его уделывает, просто мы привыкли что юнити это такая хрень для мобилок и не заметили как он вырос в нечто большее. Но это всё вы мне уже расскажете, когда попробуете поработать с этим S&3Box.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 29-09-2023 в 19:06:

Цитата:

Дядя Миша писал:
Клиент и Сервер тикают синхронно 60 кадров в секунду

Я помню когда тестировал билд XashNT в 2021 году, еще тогда не понял этого. Фпс около двух тысяч, а по ощущениям будто лагает. У меня моник 75 Гц, а там все как-то залочено под 60 фпс как Дядя Миша сказал тогда. С QuakeNT ситуация не изменилась. Все так же ощущается рваным на экране, хоть на 75 фпс, хоть на 1500, vsync вообще ни на что не влияет (может недоделано, я не знаю).

__________________
Мой мод на Xash

Отправлено Дядя Миша 29-09-2023 в 19:15:

Aynekko если у тебя монитор умеет выше 60 герц, то да, вероятно может быть такой эффект.
Ты с сорсом сравни, там похожая схема.

Добавлено 29-09-2023 в 22:15:

Нёмыч мне тоже возмущался, мол лагает Ксаш. Я ему говорю, взапроверь в Doom3 и в Source. Он взапроверил и признал, что там тоже самое.
Просто когда это движки от крупных компаний - воспринимается как должное. А когда от дяди Мишы - сразу предъявляют как баг.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 29-09-2023 в 19:31:

Цитата:

Дядя Миша писал:
Ты с сорсом сравни, там похожая схема.

Я день-через-день играю в хл2дм. Сразу в глаза бросилось. Там такого нет. fps_max стоит 75. Поставил 60 - и вот да, сразу вижу, что прям 1-в-1 как XashNT выглядит, такое же рваное.

__________________
Мой мод на Xash

Отправлено Дядя Миша 29-09-2023 в 19:37:

Aynekko так ты и в ксаше поставь fps_max 75. Или не помогает?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 29-09-2023 в 19:41:

Цитата:

Дядя Миша писал:
Aynekko так ты и в ксаше поставь fps_max 75. Или не помогает?

Не помогает. Как уже писал выше, 75 фпс, 1500 фпс, всинк вкл/выкл, эффект один и тот же.

Цитата:

Дядя Миша писал:
А когда от дяди Мишы - сразу предъявляют как баг.

Это не так, как минимум потому, что Xash3D такого эффекта не имеет.
А насчет XashNT у меня что тогда, в 2021 году были лаги по ощущениям, что сейчас. Ну неспроста же ж.

Я не знаю, раз у тебя там синхрон на 60 гц, могу только предположить, что экранные viewangles обновляются с этой же частотой, отсюда и лаг.

__________________
Мой мод на Xash

Отправлено Дядя Миша 29-09-2023 в 19:50:

Цитата:

Aynekko писал:
Xash3D такого эффекта не имеет

Там игровой цикл иначе устроен.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-09-2023 в 19:55:

Цитата:

Дядя Миша писал:
Нёмыч мне тоже возмущался, мол лагает Ксаш. Я ему говорю, взапроверь в Doom3 и в Source. Он взапроверил и признал, что там тоже самое.
Просто когда это движки от крупных компаний - воспринимается как должное. А когда от дяди Мишы - сразу предъявляют как баг.

Ну в первой кваке же не было такого, да и распрыжку зачем отключил? Неужели нельзя как то интерполировать?

Отправлено Дядя Миша 29-09-2023 в 20:06:

Цитата:

FiEctro писал:
Ну в первой кваке же не было такого

Откуда ты знаешь как играется первая квака на современных мониторах?
Разве что WinQuake попробовать запустить. Но оригинал перестал работать начиная с XP.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-09-2023 в 20:23:

Дядя Миша
А квейк ремастер?

Отправлено Дядя Миша 29-09-2023 в 20:37:

Я не знаю как там игровая петля устроена.
Для начала надо будет собрать статистику по этой проблеме.
Попозже запилю голосовалку в закрытой ветке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Decay 30-09-2023 в 02:24:

Цитата:

Дядя Миша писал:
Разве что WinQuake попробовать запустить. Но оригинал перестал работать начиная с XP.

А я в 2012 проходил q1 и hipnotic на win7 именно на WinQuake и вроде норм было

Добавлено 30-09-2023 в 08:58:

Но это был простой монитор acer v193

Добавлено 30-09-2023 в 09:24:

А ты говоришь именно про оригинал. Сразу не дошло

Отправлено FiEctro 30-09-2023 в 11:03:

Дядя Миша
Я не очень понимаю эту проблему, в Юнити такие глюки бывают когда ты код размещаешь в неправильные апдейты. Это косяк кода квейка, или всётаки архитектуры? Или ксаш выполняет всё разом в апдейте?

Отправлено Дядя Миша 30-09-2023 в 17:45:

Цитата:

FiEctro писал:
Это косяк кода квейка, или всётаки архитектуры

архитектуры. Но пока не понятно. Тут мы в очередной раз имеем дело с кучей противоречивых условий - по хорошему надо чтобы игра работала с частотой обновления монитора. Пока все мониторы были 60 герц, проблемы не было. Но вот нам начали выкатывать какие-то маркетологические штучки на 144 герца, на 240 герц, зачем? Я даже на CRT с частотой обновления 100 герц уже не видел никаких мерцаний, да и навряд ли глаз способен уследить. На кой нужны какие-то там 240 герц? Тем более что TFT обновляют изображение частями, у них нет мерцания, присущего CRT. Именно поэтому кстати у них долгое время частота обновления была 60 герц и глаза ни у кого не болели. Собственно, проверить экран на мерцание очень легко - наводим камеру смартфона, на CRT видим бегущие полосы. На ЖК не видим ничего. Теперь эти мониторы с нестандартной частотой стали головной болью. Потому что ни физику ни сеть нет резона обновлять чаще 60 раз в секунду. А без синхронизации с кадровой частотой монитора получаем вот такие лаги. Причём не у всех, не всегда и при разных условиях.

Цитата:

FiEctro писал:
Или ксаш выполняет всё разом в апдейте?

Ну да, всё разом. А как надо? Время идёт одинаково для всех объектов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 30-09-2023 в 17:57:

Цитата:

Дядя Миша писал:
Но вот нам начали выкатывать какие-то маркетологические штучки на 144 герца, на 240 герц, зачем?

На 144Гц даже окошки глаже таскаются

Цитата:

Дядя Миша писал:
Я даже на CRT с частотой обновления 100 герц уже не видел никаких мерцаний, да и навряд ли глаз способен уследить.

На самом деле живость картинки CRT как раз возникает от мерцаний.

Цитата:

Дядя Миша писал:
На кой нужны какие-то там 240 герц?

Глянь какой-нить боевичог с пересчётом картинки на высокий фреймрейт через Smooth Video Project.

Отправлено Aynekko 30-09-2023 в 21:37:

Цитата:

Дядя Миша писал:
какие-то маркетологические штучки на 144 герца

У меня монитор на ПК 75 гц, на ноуте 120, у брата 144. Разница между 75 и 120 огромная, на 120 в лучшую сторону. Между 144 и 120 разницы я не увидел - было так же супер-плавно. Насчет значений выше, сказать уже не могу - не видел, могу лишь предположить, что разница будет почти незаметной.

Цитата:

Дядя Миша писал:
Потому что ни физику ни сеть нет резона обновлять чаще 60 раз в секунду.

Так я не понимаю, сделай чтобы локально там все интерполировалось на тыщу фпс или сколько там пользователю надо, а по факту обновляй 60 раз.

__________________
Мой мод на Xash

Отправлено FiEctro 30-09-2023 в 21:57:

Цитата:

Дядя Миша писал:
Ну да, всё разом. А как надо? Время идёт одинаково для всех объектов.

Так у тебя физика от фпс плавать начнёт. У неё должны быть свои такты и фпс. А так же некоторые события могут выполняться до или после обновления физики. Как то глупо всё в апдейт пихать чтобы потом каждый раз мучаться как с дрожащими монстрами на платформах, но может в этом есть какие то свои приемущества? Да и дельта тайм куда делся?

В Юнити можно внедриться на любой этап пайплайна.
https://docs.unity3d.com/uploads/Ma...r_flowchart.svg

Цитата:

Дядя Миша писал:
Потому что ни физику ни сеть нет резона обновлять чаще 60 раз в секунду. А без синхронизации с кадровой частотой монитора получаем вот такие лаги. Причём не у всех, не всегда и при разных условиях.

У меня и на 60 гц тоже лаги есть, но только если фпс выше 60ти и выключен всинк.

Отправлено Дядя Миша 01-10-2023 в 06:17:

Цитата:

Aynekko писал:
Между 144 и 120 разницы я не увидел

Так я ровно про это и говорю - выше ста герц разница уже не видна.

Цитата:

Aynekko писал:
а по факту обновляй 60 раз.

Оно и обновляется по факту 60 раз. Возможно проблема в том, что 1 / 60 по нормальному не делится.

Цитата:

FiEctro писал:
Так у тебя физика от фпс плавать начнёт.

С чего бы она начнёт плавать если для физики синхронный поток на 60 кадров в секунду?

Цитата:

FiEctro писал:
А так же некоторые события могут выполняться до или после обновления физики.

Могут. И выполняются.

Цитата:

FiEctro писал:
каждый раз мучаться как с дрожащими монстрами на платформах

В QuakeNT монстры на платформах не дрожат, если ты не заметил. Можешь на e1m1 поехать вместе с солдатом вниз - дрожать он не будет и будет спокойно бегать по едущей платформе.

Цитата:

FiEctro писал:
Да и дельта тайм куда делся?

Никуда не делся.

Цитата:

FiEctro писал:
В Юнити можно внедриться на любой этап пайплайна.

Ну у меня всё же более сетевая архитектура, поэтому такого попросту нет. Да оно и не нужно. В рендеринг тем более нет смысла вмешиваться - достаточно отправить некоторые параметры в шейдер. XashNT использует полностью аппаратное ускорение. В Юнити есть партиклы? Там можно внедриться в процесс их рендеринга из C#?

У меня есть функция ServerStartFrame - вызывается до начала физики.
И функция ServerRunPhysics - вызывается для каждого объекта.
И вот в ней ты делаешь абсолютно всё что угодно. Физика полностью находится в скриптах, по крайней мере на данный момент.
Если надо передать какой-то параметр в материал - просто в самом материале пишешь обращение entity->paramname. А в объекте регистрируешь свойство с именем "event.parmname" и к этому свойству подцепляешь то что тебе нужно - переменную член класса, функцию, виртуальную функцию. И при рендеринге это свойство автоматически вызывается и передаёт в шейдер нужный параметр. При соблюдении ряда условий - что объект виден в кадре, что шейдер вообще использует этот параметр. Это гораздо удобнее, чем вручную что-то сетапить в соответствующих эвентах. Но и гораздо сложнее в реализации, нежели внутри пайплайна понаделать вызова функций в скрипты.

Добавлено 01-10-2023 в 09:17:

Вообще, каллбэки на каждом этапе конвейера - это признак очень топорной и неоптимальной архитектуры, потому что ядро оказывается плотно связано этими калбэками и начинаются разные проблемы при попытке внедрить в движок какую-то новую подсистему, например ту же поддержку сети или нормальную сериализацию. В результате при смене мажорной версии может сломаться совместимость или просто скорость работы окажется неудовлетворительной. В халфе точно также понаделали этих грёбанных каллбэков и никто с ними толком не умел работать. Зато между движком и пользовательской частью образовалась громадная куча паразитных связей.
Т.е. ты по сути хвастаешься неоптимальной слаборасширяемой архитектурой, которая видимо была принята от балды еще в середине нулевых, как наиболее влобное решение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 01-10-2023 в 07:30:

Проведи слепой тест - сделай 2 простых билда, с логикой залоченной на 60 фпс, а другой на 144 например. Назови их билд1 и билд2. Я более чем уверен, что все скажут, что 144 плавнее.

__________________
Мой мод на Xash

Отправлено Дядя Миша 01-10-2023 в 09:42:

Немножко картинок вам в ленту. Вот так выглядит визуальный профайлер игрового кода. Раздельно для серверной и клиентской части (потом ещё аналогичный сделаю для меню).
Можно посмотреть сколько в среднем опкодов виртуальная машина выполняет за кадр, а так же наглядно - в виде графика. Соответственно, если график начинает краснеть - пора оптимизировать ваш код.
Впрочем, когда я напишу JIT, лимиты на оптимизацию отодвинутся. Ну а пока - вот так.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-10-2023 в 10:28:

Всё мелкое да и данных мало.

Отправлено Дядя Миша 01-10-2023 в 10:36:

Ладно, то что напротив CPU иконка часов - это я понять могу. То что напротив памяти - изображение микросхемы в принципе тоже. Но то что напротив рендеринга нарисован не то бублик, не то дырка от него - это вот вообще взрыв мозга какой-то.

Цитата:

FiEctro писал:
Всё мелкое да и данных мало.

Это in-game статистика. Предлагаешь ей вообще весь экран покрыть?
В редакторе с окошками можно будет сделать подробнее.
Ну и да - это профайлер не всего кода, это профайлер именно скриптовых машин. Учитывая что в юнити из каждого участка ядра растёт пользовательский каллбэк конечно данных будет намного больше, а у юзера будет активнее болеть голова, как это всё разрулить и соптимизировать.

Добавлено 01-10-2023 в 13:36:

Или вот к примеру в Юнити есть статистика GC Allocated, как я понимаю Garbage Collector. У меня его нет, он просто не нужен, как я выведу по нему статистику?

Добавлено 01-10-2023 в 13:36:

Кстати вот это вот Physics.FetchResults - это чисто PhysX-овая заморочка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-10-2023 в 10:41:

Цитата:

Дядя Миша писал:
Или вот к примеру в Юнити есть статистика GC Allocated, как я понимаю Garbage Collector. У меня его нет, он просто не нужен, как я выведу по нему статистику?

Нету коллектора или графика?

К слову чисто для информации:
Есть ещё Frame debugger и Render debugger тоже очень полезные штуки.
https://docs.unity3d.com/ru/530/Man...meDebugger.html
https://docs.unity3d.com/Packages/c...bug-Window.html

Цитата:

Дядя Миша писал:
Это in-game статистика. Предлагаешь ей вообще весь экран покрыть?

Можно оставить как есть, но для больших подробностей Tab окно сделать как окно убийств и смертей в мультиплее. Когда надо игрок сам его выведет.

Цитата:

Дядя Миша писал:
Ну и да - это профайлер не всего кода, это профайлер именно скриптовых машин. Учитывая что в юнити из каждого участка ядра растёт пользовательский каллбэк конечно данных будет намного больше, а у юзера будет активнее болеть голова, как это всё разрулить и соптимизировать.

Там можно каждый скрипт отдельно просмотреть.

Цитата:

Дядя Миша писал:
Но то что напротив рендеринга нарисован не то бублик, не то дырка от него - это вот вообще взрыв мозга какой-то

Ну читать то умеешь? По мне эти иконки вообще лишние.

Цитата:

Дядя Миша писал:
В редакторе с окошками можно будет сделать подробнее.

Потому я и говорил что возможность запускать игру внутри редактора это не просто фишка от балды. Это часть отладчика, и очень важная часть. Когда ты можешь запустить игру и посмотреть в реальном времени на сцене чем занимается каждая отдельно взятая энтития.

Отправлено Дядя Миша 01-10-2023 в 10:50:

Цитата:

FiEctro писал:
Нету коллектора

Коллектора.

Цитата:

FiEctro писал:
Там можно каждый скрипт отдельно просмотреть.

А ну у меня тоже такое можно сделать. Но специально я этим заниматься не буду, только по мере возникновения потребности.
Если игра и так быстро везде работает - зачем её оптимизировать?
Только тратить время на бесполезные вещи.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-10-2023 в 10:52:

Цитата:

Дядя Миша писал:
Если игра и так быстро везде работает - зачем её оптимизировать?
Только тратить время на бесполезные вещи.

А если утечка памяти? И гарбаж коллектора нет? Нет ну я с тобой согласен, может в конктексте кваки действительно смысла никакого нет, поскольку она сама по себе маленькая и легковесная. Но вот если у тебя более сложный проект, с десятками тысяч объектов? Как ты всё это отлаживать собираешься?

Не знаю, мне кажется такой подробный отладчик в первую очередь сократил бы много времени тебе как разработчику движка. А так же помог собирать больше данных от пользователей которые жалуются что у них что то тормозит. Вспомни сколько возни было с рендером второй паранойи.

Отправлено Дядя Миша 01-10-2023 в 10:53:

Цитата:

FiEctro писал:
Когда ты можешь запустить игру и посмотреть в реальном времени на сцене чем занимается каждая отдельно взятая энтития.

Оно как правило самоочевидно и безо всякого отладчика.
Впрочем я пока ничего утверждать не буду. Инструменты должны появляться по мере возникновения потребности в них. Скажем первобытные люди уже вполне использовали камень в качестве молотка, а вот отвертки им были совершенно ни к чему.

Добавлено 01-10-2023 в 13:53:

Цитата:

FiEctro писал:
А если утечка памяти?

Невозможна by design. У меня же стековая машина. Дальше стека не утечёт.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-10-2023 в 10:59:

Цитата:

Дядя Миша писал:
Оно как правило самоочевидно и безо всякого отладчика.

Это как очевидно? Ну вот ты создаёшь в реалтайме ригидбоди, запустил игру, а его в игре нет, т.к. его под землю вытолкало, как это с ходу определишь? В реалтайм отладчике это видно с первых секунд, в ином случае придётся тратить куда больше времени.

У Годота кстати такая же фигня, при запущенной игре внутри сцены объекты все статичны, и ты нифига не видишь что происходит с ними. Это ооочень неудобно.

Цитата:

Дядя Миша писал:
Невозможна by design. У меня же стековая машина. Дальше стека не утечёт.

Вылет будет давать? Или что? Ну вот вместо ГарбажКоллектора можно статистику юзания и переполнения стека показывать. Я правда не знаю всех подробностей и насколько это актуально в твоём движке.

Цитата:

Дядя Миша писал:
Скажем первобытные люди уже вполне использовали камень в качестве молотка, а вот отвертки им были совершенно ни к чему.

Зависит опять же от сложности. Энтитии в квейке довольно простые и работают в основном в глобальном пространстве. Но вот если ты машинку например собрал, да ещё и с использованием физики? Запустил, а она вроде и едет но как то не так. Сколько тебе времени придётся потратить чтобы выяснить какой фрагмент этой сложной системы косячит?

Отправлено Дядя Миша 01-10-2023 в 11:43:

Цитата:

FiEctro писал:
а его в игре нет, т.к. его под землю вытолкало

Но почему?

Цитата:

FiEctro писал:
Вылет будет давать? Или что?

Ничего. Просто не будет утечек и можно вообще об этом не думать.
Ты же когда с халфой работал не думал об утечках.

Цитата:

FiEctro писал:
Запустил, а она вроде и едет но как то не так. Сколько тебе времени придётся потратить чтобы выяснить какой фрагмент этой сложной системы косячит?

А как мне в этом деле поможет профайлер и анализатор утечек памяти?

К тому же едет "как-то не так" это очень субъективное ощущение. Может у нее подвеска жостче чем надо или мощность мотора выставлена слабая, например. Но при чём тут тогда вообще отладка? Берёшь и играешься с параметрами.

Добавлено 01-10-2023 в 14:43:

Цитата:

FiEctro писал:
и работают в основном в глобальном пространстве.

Абсолютно все объекты в конечном счёте высчитывают своё положение в глобальном пространстве. Локальные пространства это всего лишь удобная абстракция.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-10-2023 в 12:17:

Цитата:

Дядя Миша писал:
А как мне в этом деле поможет профайлер и анализатор утечек памяти?

Не профайлер, а на сцене в реалтайме. Когда ты можешь кликнуть мышкой на объект во время игры и посмотреть что творится с его значениями и координатами.

Профайлер может помочь не только программисту, но левелдизайнеру когда он например переборщил с материалами, и хочет выяснить откуда просадки.

Цитата:

Дядя Миша писал:
Берёшь и играешься с параметрами.

Ну тоесть заниматься брутфорсом?
Каким параметрами, если где то в коде баг?

Цитата:

Дядя Миша писал:
Абсолютно все объекты в конечном счёте высчитывают своё положение в глобальном пространстве. Локальные пространства это всего лишь удобная абстракция.

Надеюсь сделаешь какие то инструменты для работы с дочерними и родительскими объектами. Чтобы не лезть в матрицы как в Годоте.

Отправлено Дядя Миша 01-10-2023 в 16:10:

Цитата:

FiEctro писал:
Когда ты можешь кликнуть мышкой на объект во время игры и посмотреть что творится с его значениями и координатами.

Это я тоже могу сделать. Но для начала надо убедиться, что в отладке такого рода вообще возникнет потребность.

Цитата:

FiEctro писал:
левелдизайнеру когда он например переборщил с материалами, и хочет выяснить откуда просадки.

r_speeds есть. Там сразу видно сколько переключений шейдера, сколько флушей и сколько треугольников. Память разумеется тоже показывает. Ну может не так красиво как в Unity. Но опять же, на моей памяти народ на всё это стабильно забивает болт.

Цитата:

FiEctro писал:
Каким параметрами, если где то в коде баг?

"Машина едет как-то не так" - это ты описал свои субъективные ощущения, например. Это необязательно баг, может настройки такие.

Цитата:

FiEctro писал:
Надеюсь сделаешь какие то инструменты для работы с дочерними и родительскими объектами

В сорсе есть такие инструменты? Я что-то не видел. И не помню, чтобы у кого-то там аттач объектов вызывал проблемы.

Добавлено 01-10-2023 в 18:50:

FiEctro ты, чем приводить в пример разные отладочные инструменты, которые красивые и наглядные, лучше расскажи реальный опыт их применения. Было ли такое, что баги ты находил именно с помощью этих самых инструментов, а не самостоятельно вспоминал где именно ты налажал.

Добавлено 01-10-2023 в 19:08:

C# абсолютно не годится для игр. Он даже для приложений особо не годится. Вспоминаем Paint.NET. Кто-то может сказать, мол, там работа с пикселями. пикселей много, вот и не справляется. Хорошо, но у меня есть софтина для внутрисхемного программирования на шарпе. Там одно небольшое окошко и несколько кнопок. Как жы люто это говно лагает. И всё время норовит зависнуть. А ведь оконному интерфейсу никто и не гарантирует мгновенно отклика. Там окошки неперерисованными могут оставаться долгое время и типа нормально. Прогресс-бары зависают, к примеру. И вот на таком языке вы собрались делать игру. Хуже СиШарпа только годотовский клон Питона под названием GDScript. Он настолько тормозной, что даже Юнити на его фоне кажется чем-то сверхбыстрым.
Эпики, устав бороться со всем этим дерьмом запилили блюпринты, которые в финале просто транслируются в обычный С++ код. Решение спорное, но по производительности наверняка лучшее. Однако у них другая проблема - разобраться в здравом уме с кодобазой анрила практически невозможно.
Уж слишком она гигантская. Многие и не пытаются - выбирают Юнити или тот же Годот. Вот такая вот диалектика. Кстати с КрайЭнджином была аналогичная шляпа - разобраться с его игровой кодобазой могут не только лишь все. И большинство предпочло не связываться.

Добавлено 01-10-2023 в 19:10:

И ещё один момент. Казалось бы в чём разница между кодобазой Анрила и Края? И там и там тёмный лес. Но у Эпиков более дружелюбное коммунити, а у Края насколько я понял было всё очень токсично.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-10-2023 в 17:39:

Цитата:

Дядя Миша писал:
Это я тоже могу сделать. Но для начала надо убедиться, что в отладке такого рода вообще возникнет потребность.

Во всех современных движках оно используется. Я это тоже использую 90% времени отладки.

Цитата:

Дядя Миша писал:
r_speeds есть. Там сразу видно сколько переключений шейдера, сколько флушей и сколько треугольников. Память разумеется тоже показывает. Ну может не так красиво как в Unity. Но опять же, на моей памяти народ на всё это стабильно забивает болт.

Окей ты видишь показания за кадр, а если тебе нужно посмотреть за период времени?

Цитата:

Дядя Миша писал:
"Машина едет как-то не так" - это ты описал свои субъективные ощущения, например. Это необязательно баг, может настройки такие.

Вот если бы ты ехал на работу, а у тебя одно из колёс проколото ты тоже считал бы это субъективными ощущениями? Ну или каждый раз ставить специальный датчик на колесо чтобы посмотреть что у тебя прокололось?

Это типичное проявление багов, особенно когда ты переносишь какой то другой код к себе в проект, физика такой системы может быть сломана абсолютно. И ты можешь либо сидеть несколько дней и отлаживать код выводя нужные фрагменты в консоль. Либо сразу щелкать их мышкой в интерфейсе.

Цитата:

Дядя Миша писал:
В сорсе есть такие инструменты? Я что-то не видел. И не помню, чтобы у кого-то там аттач объектов вызывал проблемы.

Просвещайся:
https://docs.unity3d.com/ScriptReference/Transform.html

Цитата:

А много в сорсе ты с помощью кода что то аттачил, вращал и перемещал в локальных координатах?

Цитата:

Дядя Миша писал:
FiEctro ты, чем приводить в пример разные отладочные инструменты, которые красивые и наглядные, лучше расскажи реальный опыт их применения. Было ли такое, что баги ты находил именно с помощью этих самых инструментов, а не самостоятельно вспоминал где именно ты налажал.

Да регулярно. Я тебе уже вторую страницу пишу применения. Дело не в красоте, дело в том что это:

1. Ты можешь редактировать любые параметры во время выполнения игры чтобы посмотреть как твой объект будет вести себя в тех или иных случаях. Нет нужды каждый раз перезапускать игру.
2. Очень наглядно когда ты можешь напрямую кликнуть мышкой на объект и узнать всё что с ним происходит, какой у него велосити, какой у него угол, какие значения публичных и приватных переменных, какие скрипты его меняют и т.д.
3. Фрейм дебаггер помогает при написании шейдеров и пост эффектов, когда например у тебя внезапно на ровном месте отваливаются тени, или не рисуются под прозрачным объектом.
4. Профайлер помогает найти скрипты которые жрут больше всего оперативки и ЦП, а так же что более важное какие из них дают фризы, это может быть несколько милисекунд.

Цитата:

Дядя Миша писал:
C# абсолютно не годится для игр. Он даже для приложений особо не годится. Вспоминаем Paint.NET. Кто-то может сказать, мол, там работа с пикселями. пикселей много, вот и не справляется. Хорошо, но у меня есть софтина для внутрисхемного программирования на шарпе. Там одно небольшое окошко и несколько кнопок. Как жы люто это говно лагает. И всё время норовит зависнуть. А ведь оконному интерфейсу никто и не гарантирует мгновенно отклика. Там окошки неперерисованными могут оставаться долгое время и типа нормально. Прогресс-бары зависают, к примеру. И вот на таком языке вы собрались делать игру. Хуже СиШарпа только годотовский клон Питона под названием GDScript. Он настолько тормозной, что даже Юнити на его фоне кажется чем-то сверхбыстрым.
Эпики, устав бороться со всем этим дерьмом запилили блюпринты, которые в финале просто транслируются в обычный С++ код. Решение спорное, но по производительности наверняка лучшее. Однако у них другая проблема - разобраться в здравом уме с кодобазой анрила практически невозможно.
Уж слишком она гигантская. Многие и не пытаются - выбирают Юнити или тот же Годот. Вот такая вот диалектика. Кстати с КрайЭнджином была аналогичная шляпа - разобраться с его игровой кодобазой могут не только лишь все. И большинство предпочло не связываться.

Сам Юнити и его интерфейс написан на крестах вроде как, у тебя есть исходники. А вот виртуальная машина - шарпы да.

Я охотно верю, я знаю что низкоуровневые языки всегда быстрее будут. Но дело не просто в быстроте, дело в удобстве использования всего этого. Суть движков как раз упрощать рутинные процессы. Иначе какой в них смысл? Писать свой движок поверх твоего?

Цитата:

Дядя Миша писал:
А ведь оконному интерфейсу никто и не гарантирует мгновенно отклика. Там окошки неперерисованными могут оставаться долгое время и типа нормально. Прогресс-бары зависают, к примеру. И вот на таком языке вы собрались делать игру.

Зависит от реализации. Вон есть imgui на крестах, и он не лагает, а вот как делфи библиотеки себя поведут, большой вопрос. Поскольку я уже пообмазывался виндовыми окошками в C++ и понял какое это кривущее лагучее дерьмо.

Отправлено Дядя Миша 01-10-2023 в 19:24:

Цитата:

FiEctro писал:
а если тебе нужно посмотреть за период времени?

И что ты там увидишь? Среднюю температуру по больнице?
Ты увидишь краткую историю верчения камерой. Это не статистика, а хрень какая-то.

Цитата:

FiEctro писал:
от если бы ты ехал на работу, а у тебя одно из колёс проколото ты тоже считал бы это субъективными ощущениями?

Ну вышел и визуально посмотрел. Отладчик для этого не нужен. Корочи, давай реальный пример. Потому что вот это твоё "как-то не так" это чистая субъективщина.

Цитата:

FiEctro писал:
Это типичное проявление багов, особенно когда ты переносишь какой то другой код к себе в проект, физика такой системы может быть сломана абсолютно

Т.е. отладка позволяет переносить код из одного проекта в другой? А если к примеру сам пишешь, то она не нужна?

Цитата:

FiEctro писал:
Просвещайся:
https://docs.unity3d.com/ScriptReference/Transform.html

Мой поинт в том, чтобы написать систему аттача прямо на Шоте, а не выводить интерфейсы из движка. Разумеется это будет тормозно. Но для меня это - лишний стимул оптимизировать интерпретатор, а не прятаться за убогими интерфейсами. Эпики вон в третьем анриле допрятались до того, что вообще дропнули виртуальную машину.

Цитата:

FiEctro писал:
А много в сорсе ты с помощью кода что то аттачил, вращал и перемещал в локальных координатах?

Так если это можно при создании уровня сделать, зачем в коде?

Цитата:

FiEctro писал:
Но дело не просто в быстроте, дело в удобстве использования всего этого. Суть движков как раз упрощать рутинные процессы. Иначе какой в них смысл?

Это я к тому, зачем я вообще морочился с собственным скриптовым языком когда есть всякие луа, петоны, шарпы и явы. Вот как раз по этой причине. Все эти языки категорически не годятся для игр.

Цитата:

FiEctro писал:
Вон есть imgui на крестах, и он не лагает

Тут я долго смеялся. Более лагучего дерьма чем imgui ещё поискать. Его судя по всему писали представители LGBTQ или как оно там называется.

Цитата:

FiEctro писал:
пообмазывался виндовыми окошками в C++ и понял какое это кривущее лагучее дерьмо.

Выглядит жутко, да. Кресты вообще с окошками плохо дружат. Ну оно и понятно. Когда кресты создавались никаких окошек ещё и близко не было.
А вот когда создавался Делфи - окошки уже очень даже были.
Просто Делфям плевать на собственную совместимость, в отличие от крестов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Kardini 01-10-2023 в 19:47:

Цитата:

Занимаюсь реверс инженирингом LS3D (движком Mafia: The City of Lost Heaven) в свое удовольствие. Буквально сделал себе что-то схожее для дебага через Cheat Engine, а потом и через считывание буквально в Юнити через чтение памяти. Думаю не так уж и трудно сделать.

Цитата:

FiEctro ты, чем приводить в пример разные отладочные инструменты, которые красивые и наглядные, лучше расскажи реальный опыт их применения. Было ли такое, что баги ты находил именно с помощью этих самых инструментов, а не самостоятельно вспоминал где именно ты налажал.

Могу рассказать именно Я за свой опыт. Такие отладочные инструменты прекрасны, когда ты пишешь что-то серьезное и архитектурное, но по своей природе ты не особо технарь и удерживать вообще все в своей голове вообще все, что ты пишешь не получается. Прекрасный инструмент. Кликаешь на объект. Смотришь публичные переменные, что ты себе вывел. Чаще всего, скорее в силу своих когнитивных способностях случается ситуация, что ты где-то накосячил в коде, но не фатально. Игра не крашнулась, но работает через жопу. И тут безумно помогает Инспектор Юнити.

Ставишь на паузу игру (по потребности, можно и в реальном времени влезть). Редактируешь любую переменную так как тебе вздумается. Хочешь залезть глубже? Можешь и приватные до определенной глубины глянуть и отредактировать. Эдакий хороший пинок нерабочему жигулю, в котором ты вручную рукой крутишь обороты, хех, чтоб он таки завёлся.

Это лично для меня буквально та вещь, которая разделяла движки нулевых и конца 90ых, которые ДВИЖКИ и Юнити-подобное направление уже нынешнего времени, которое началось с 2010. Потому что это попросту снижает порог вхождения и сложность разработки. Ты в дебаге можешь отредактировать любую переменную, а так же увидеть косяк в каком-нибудь буле.
Так же помогает безумно как и брейкпоинты в вижуал студии, если у тебя какие-то критические вещи случаются на уровне уже фрейма.

Цитата:

C# абсолютно не годится для игр. Он даже для приложений особо не годится.

Я бы хотел немного разграничить тут. С точки зрения быстродействия - шарпы отвратительны. Просто ужасны и фу. Как... И все интерпретируемые скриптовые языки. Unity3D решает этот вопрос преобразованием в релизной версии в C++ код посредством IL2CPP. Не особо спасает, зато от вирусописателей школьников помогает.

Однако, C# действительно неплох с точки зрения архитектуры. Почему? Да у него блин альтернатив нет. Про GDScript ты уже все сказал, а что остается? Несчастный и ужасный LUA? Или еще более жалкая JS? Господи, на его фоне Шарпы кажутся такими низкоуровневыми аристократами, способными в восхитительную абстракцию, что даже слов нет.

Плюсы всем блин хороши, но они точно не прокатят для *дизайна* игры. Писать архитектурные крутые и тяжелые компоненты - да, пожалуйста. UE буквально бьет палкой разработчиков и требуют "ВПИСЫВАЙ ВСЕ НУЖНЫЕ ПЕРЕМЕННЫЕ УЖЕ ТОЛЬКО В НАШЫ РЕАЛИЗАЦИИ". И в текущих рамках Шапры тупо находятся в проклятом лимбо. Они достаточно скриптовые и щадят пользователя от совсем уж идиотских ошибок, но при этом достаточно абстрактные, чтоб на них МОЖНО было бы писать уже какие-никакие, но архитектурные решения игры.
(Я на днях ознакомился с некоторыми реализациями GDScript. Господи, я как будто в 2006 с Game Maker и GML попал. Просто ужасно.)

Цитата:

Однако у них другая проблема - разобраться в здравом уме с кодобазой анрила практически невозможно.
Уж слишком она гигантская. Многие и не пытаются - выбирают Юнити или тот же Годот. Вот такая вот диалектика. Кстати с КрайЭнджином была аналогичная шляпа - разобраться с его игровой кодобазой могут не только лишь все. И большинство предпочло не связываться.

Современные идиомы разработки скорее четко дают понять - "разработчик НЕ ДОЛЖЕН влезать в движок". Пусть барахтается в скриптовом болоте (и ХОРОШО если тут будут шарпы. От спагеттикода блупринтов мне зябко становится). Пусть не лезет куда-то на низкоуровневые вопросы. Вопросами архитектуры и движка тип должны разбираться разработчики как раз движков, которые должны выдать удобное API, решающее многие вопросы.

Отправлено FiEctro 01-10-2023 в 19:51:

Цитата:

Дядя Миша писал:

И что ты там увидишь? Среднюю температуру по больнице?
Ты увидишь краткую историю верчения камерой. Это не статистика, а хрень какая-то.

Например минимальные и максимальные значения, ну и средние да. Этого мало?

Цитата:

Дядя Миша писал:
Ну вышел и визуально посмотрел. Отладчик для этого не нужен. Корочи, давай реальный пример. Потому что вот это твоё "как-то не так" это чистая субъективщина.

Создание и удаление объектов, изменение их свойств, динамическое перемещение их по иерархии и т.д.

Цитата:

Дядя Миша писал:
Т.е. отладка позволяет переносить код из одного проекта в другой? А если к примеру сам пишешь, то она не нужна?

Ну ты хотел пример?

Цитата:

Дядя Миша писал:
Мой поинт в том, чтобы написать систему аттача прямо на Шоте, а не выводить интерфейсы из движка. Разумеется это будет тормозно. Но для меня это - лишний стимул оптимизировать интерпретатор, а не прятаться за убогими интерфейсами. Эпики вон в третьем анриле допрятались до того, что вообще дропнули виртуальную машину.

Неудобно всё матрицами писать. А отлаживать их гемор. Это как раз пример того где у тебя вместо нужных углов может выйти какая то херня.

Цитата:

Дядя Миша писал:
Так если это можно при создании уровня сделать, зачем в коде?

А в динамике? Объекты постоянно создаются и удаляются.

Цитата:

Дядя Миша писал:
Тут я долго смеялся. Более лагучего дерьма чем imgui ещё поискать. Его судя по всему писали представители LGBTQ или как оно там называется.

Ну Валва и Рокстар его юзают. Да и вполне он на ГПУ целиком. Хотя я не вникал особо, если есть какой либо опыт, расскажи.

Отправлено Decay 01-10-2023 в 20:24:

Как Рокстар юзают imgui (видео в хорошем качестве)
https://t.me/gta6_leak_videos

Debug Menu в HL2
https://www.youtube.com/watch?v=bsARRLc6Pro
Но это не про работу с отдельными объектами

Мне нравится вот эта штука для gta. Тоже про глобальные настройки. Выглядит минималистично.
https://www.youtube.com/watch?v=036YTNSD4bw
https://github.com/aap/debugmenu

Отправлено Дядя Миша 02-10-2023 в 06:36:

Цитата:

Kardini писал:
Такие отладочные инструменты прекрасны, когда ты пишешь что-то серьезное и архитектурное, но по своей природе ты не особо технарь и удерживать вообще все в своей голове вообще все, что ты пишешь не получается

Ну может быть.

Цитата:

Kardini писал:
Редактируешь любую переменную так как тебе вздумается. Хочешь залезть глубже? Можешь и приватные до определенной глубины глянуть и отредактировать.

Но ведь косяк может быть именно в коде, а не в переменных. А код в реалтайме уже не отредактируешь.

Цитата:

Kardini писал:
C# действительно неплох с точки зрения архитектуры. Почему? Да у него блин альтернатив нет

Теперь есть. Зря я что ли целый год возился? Скоро покажу.

Цитата:

Kardini писал:
"разработчик НЕ ДОЛЖЕН влезать в движок"

С этим согласен.

Цитата:

FiEctro писал:
Например минимальные и максимальные значения, ну и средние да. Этого мало?

Для минимально-максимальных значений вовсе необязательно строить график.

Цитата:

FiEctro писал:
Объекты постоянно создаются и удаляются.

Со сложной иерархией? Приведи пример. В играх на Юнити, по крайней мере в тех, что я видел, иерархия практически не использовалась.

Цитата:

FiEctro писал:
Ну Валва и Рокстар его юзают. Да и вполне он на ГПУ целиком

В чём сложность оконного интерфейса? В том, что интерфейс физически состоит из двух независимых компонентов - ввод с HID и отрисовка на экран. Технически в игровом движке это тоже есть, вот только там ввод умещается в маленькую такую структурку, которая всегда сидит в движке, вызывается из строго определённого места и не может быть изменена.
Ну просто потому что от игрока в играх требуется не так уж и много действий - бег, прыжок, присед, атака. В окошках не так. Там каждая кнопка означает новый эвент. А более сложные элементы - целую кучу эвентов. Так вот отрисовка - отдельно, а эвенты отдельно. Идея в том, чтобы не перерисоывать элемент, который не изменился. Из-за этого код окошек при классическом построении выглядит страшно и непонятно.
Там какие-то таблицы, холдеры каллбэков и прочая чертовщинка.
imGUI действует иначе. Там всё как бы упрятано в один вызов. И этот вызов запихнут в отрисовку. Т.е. мы одновременно рисуем и тут же проверяем, не нажата ли кнопка, или может курсор мыши попал в рамку и надо к примеру вывести подсказку. Для программиста подобная огранизация очень удобна, а вот с точки зрения производительности, это удар по ней примерно в 1000х и до бесконечности. Потому что каждый новый элемент окна будет индивидуально опрашивать устройства ввода.
И перерисовываться каждый кадр. Пока у тебя 10-15 кнопок или ползунков, это вроде как незаметно. Т.е. для отладочных интерфейсов это ещё годится. Но ничего серьезного ты на этом не сделаешь. И это огромная проблема современного софта - всё такое на первый взгляд красивое, опенсорсное и даже мультиплатформенное. Вот только не масштабируется абсолютно. Но ты об этом узнаёшь, когда оно уже прикручено к твому коду намертво. Это ещё один способ как добавить тормозов в своё приложение.

Добавлено 02-10-2023 в 09:12:

Цитата:

Decay писал:
Debug Menu в HL2
https://www.youtube.com/watch?v=bsARRLc6Pro
Но это не про работу с отдельными объектами

Это просто штука для включения и выключения кваров, для тех, кто забыл их имена.

Добавлено 02-10-2023 в 09:36:

Так, ну какая картина у нас вырисовывается с игровыми движками:

1. Край после того как его выкупила Амазон практически сошёл со сцены.
А ЛумберЯрд был испохаблен людьми, которые, судя по всему не сделали ни одного движка в своей жизни, но зато начитались умных книжек, как их надо делать. Я допускаю, что его кто-то использует, но он давно не на слуху, в отличие от знаменитого предка.

2. В Юнити вероятно случилось некоторое головокружение от успехов и они решили что теперь они могут дектавадь всё что хотят и от них уже никто никуда не денется. Реакция от сообщества последовала моментально и фраера даже чуточку сдали назад. Это лишний раз доказывает, что они не ожидали подобного негатива. Не знаю, было ли это персональной инициативой Ричителло или коллективным решением, но идея была мягко говоря неудачной и нанесла удар по репутации. Это как если бы вы общались с человеком и он у вас украл какую-то мелочь, попался, извинился, вроде бы ерунда. но есть повод задуматься.

3. Эпики, видимо тоже на волне головокружения от успехов, затеяли судебную тяжбу с Эппл. Про который нам рассказывали, что у него капитализация, как у всей России, а может быть ещё больше. К тому же Эппл широко известен в широких кругах, а вот Эпики широко известны только в узких кругах. Силы были явно неравны, что в итоге привело к увольнению сотрудников, поскольку судебные издержки сожрали большую часть доходов. Я не удивлюсь, что ещё через год-два подобного противостояния Эпики окончательно обессилиют и их выкупит какой-нибудь Микрософт и заставит делать игры для икс-бокса. Ну или что-то вроде этого.

4. Годот. Ну тут всё как было грустно, так и осталось. Хоть где-то стабильность. Помню меня до глубины души поразил их пример океана с волнами, где вертексы трансформировались на GD Script. Я тогда спрашивал себя - эти парни, ну они же просто так шутят, да? Они же не всерьез? Походу они не шутили.

Так вот, к чему я всё это написал. На рынке очередные брожения, значит сейчас достаточно удобное время для входа с новым продуктом. Потому что народ в принципе готов рассматривать какую-то альтернативу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 02-10-2023 в 08:25:

Цитата:

Дядя Миша писал:
1. Край после того как его выкупила Амазон практически сошёл со сцены.
А ЛумберЯрд был испохаблен людьми, которые, судя по всему не сделали ни одного движка в своей жизни, но зато начитались умных книжек, как их надо делать. Я допускаю, что его кто-то использует, но он давно не на слуху, в отличие от знаменитого предка.

Star Citizen на нём.

Отправлено (_-=ZhekA=-_) 02-10-2023 в 10:31:

Цитата:

Kardini писал:
От спагеттикода блупринтов мне зябко становится

Да нет там никаких спагетти, можно делать макросы, функции, глобальные функции или просто коллапсить код

А нагавнокодить можно на любом языке в любом движке...

Отправлено Дядя Миша 02-10-2023 в 10:47:

Цитата:

Crystallize писал:
Star Citizen на нём.

Перед этими ребятами я снимаю шляпу. Наколядовать 1 млрд долларов донатов - куда там Блиновской.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 02-10-2023 в 11:09:

Цитата:

Дядя Миша писал:
Наколядовать 1 млрд долларов донатов

За эти донаты потом нужно будет отчитываться, хз, как они это будут делать

Отправлено FiEctro 02-10-2023 в 11:17:

Цитата:

Дядя Миша писал:
И перерисовываться каждый кадр. Пока у тебя 10-15 кнопок или ползунков, это вроде как незаметно. Т.е. для отладочных интерфейсов это ещё годится. Но ничего серьезного ты на этом не сделаешь. И это огромная проблема современного софта - всё такое на первый взгляд красивое, опенсорсное и даже мультиплатформенное. Вот только не масштабируется абсолютно. Но ты об этом узнаёшь, когда оно уже прикручено к твому коду намертво. Это ещё один способ как добавить тормозов в своё приложение.

Ну вон квака в настройках все эти шрифты и позунки в настройках рисует и ничего. А уж сколько всего в консоль строчит - сомневаюсь что виндовые интерфейсы такую частоту обновления потянут. Да и что мешает перестать перерисовывать кнопки на опенгле? Да и если у тебя куча значений обновляется в реалтайме, эти обновления особо и не помогут.

Отправлено Дядя Миша 02-10-2023 в 11:19:

Цитата:

(_-=ZhekA=-_) писал:
За эти донаты потом нужно будет отчитываться, хз, как они это будут делать

Да поди придумают что-нибудь. Например скажут, что у них сгорел весь жесткий диск со всеми наработками. Или весь офис затопило. Или провайдер облака, где хранились все наработки подвергся удару гиперзвуковой российской ракеты. Выкрутятся.

Добавлено 02-10-2023 в 14:19:

Цитата:

FiEctro писал:
Да и что мешает перестать перерисовывать кнопки на опенгле?

Я же говорю - отрисовка одновременно и проверка на нажатие кнопки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 02-10-2023 в 11:28:

Цитата:

Дядя Миша писал:
Да поди придумают что-нибудь. Например скажут, что у них сгорел весь жесткий диск со всеми наработками. Или весь офис затопило. Или провайдер облака, где хранились все наработки подвергся удару гиперзвуковой российской ракеты. Выкрутятся.

Это как история со сталкер 2 что ли, когда у них недавно сгорел офис, а в офисе был сервак со-всеми данными игры? И как следствие игру опять перенесли

Отправлено Crystallize 02-10-2023 в 12:11:

(_-=ZhekA=-_) Это как история с первохалфой когда у них взорвался сервер сорсконтроля и фрагменты кода пришлось собирать по клиентским машинам.

Отправлено Дядя Миша 02-10-2023 в 14:17:

Цитата:

(_-=ZhekA=-_) писал:
Это как история со сталкер 2 что ли, когда у них недавно сгорел офис, а в офисе был сервак со-всеми данными игры?

Типа того, да.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 02-10-2023 в 14:22:

Цитата:

Дядя Миша писал:
Петля всё равно будет 60 герц, это не регулируется.

Кстати, забыл добавить. Почему бы просто не сделать настройку для пользователей, как в ксаше имеется sv_fps. Пусть каждый ставит скорость обновления столько, сколько хочется, в своей игре.

__________________
Мой мод на Xash

Отправлено Дядя Миша 02-10-2023 в 15:21:

Такое делать нежелательно по ряду соображений. Но возможно я сделаю этот фпс регулируемым на какое-то время, чтобы найти оптимальное значение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-10-2023 в 08:32:

Не помню, писал ли я об этом здесь или в ТГ, но в рамках подготовки SDK я принял решение подключить минимальный набор того, без чего не обходится ни один современный движок, а именно:
- бамп
- спекуляр
- параллакс
- динамические тени
- пбр
Поскольку у меня мощная система описания материалов, то это не потребует вмешательства в движок и может быть реализовано прямо на уровне скриптов - достаточно блокнота для редактирования материалов и шейдеров. Разумеется в собственном редакторе будут более наглядные инструменты. Собственно, у меня оставалась пара незавершённых моментов - рассчитать Tangent-Space и сохранить делюкс-мапы. Когда я это сделал, на внедрение бампа потребовалось менее одного часа.

Это классический бамп по формуле

C++ Source Code:

max( dot( delux, normal ), 0.0 )

Как видите нижняя часть арки сильно затеняется, что в данном случае некорректно.

А это бамп с оффсетом по формуле

C++ Source Code:

max( dot( delux, normal ) * 0.5 + 0.5, 0.0 )

Т.е. именно по ней идёт затенение освещения в лайтмаппере. Это так называемый параметр softangle. Для Quake, где не было отражённого света он позволял получить более мягкое освещение, в противном случае это бы всё выглядело как третий Doom. Как видите, бамп стал менее ярко выраженным, но зато яркость арки подтянулась к изначальному порогу, заданному яркостью самой лайтмапы. Это собственно, основная проблема статичного бампа, чтобы его применение не затемнило картинку сверх меры. В данном случае это условие соблюдено. Да рельеф стал менее заметным, но по правде говоря чистый бамп никогда не давал вау-эффекта. Ему для этого как минимум требовался спекуляр.

Добавлено 04-10-2023 в 11:32:

Поскольку народ по прежнему не понимает с какой именно системой материалов он имеет дело, я поясню. То что я внедряю - это всего лишь один из примеров того как можно организовать рендеринг. Ни в коем случае не часть движка и не дефолтный пайплайн. Просто сэмпл.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 04-10-2023 в 09:01:

Это будет захардкоженный шейдер, или можно будет подключать к материалу свои шейдеры? Можно будет ли наследоваться от твоих шейдеров?

Поддержка ssbump будет? И как дела обстоят с бампом на моделях?

Цитата:

Дядя Миша писал:
- пбр

Кстати серые карты pbr можно расфасовать по RGBA каналам, так для сведений. Могу тебе покидать текстурок для теста.

Отправлено Дядя Миша 04-10-2023 в 09:52:

Цитата:

FiEctro писал:
Это будет захардкоженный шейдер, или можно будет подключать к материалу свои шейдеры?

Не просто можно, а нужно! Своих шейдеров в движке нет, только пользовательские. Какой шейдер сделаешь - так и будет. Движок не предлагает вообще ничего. Иными словами, если пользователь не создал материалов и шейдеров, движок ничего не нарисует.

Цитата:

FiEctro писал:
Можно будет ли наследоваться от твоих шейдеров?

Моих шейдеров там нет

Цитата:

FiEctro писал:
Поддержка ssbump будет?

Когда я внедрю в лайтмаппер Radiosity Normal Mapping то будет.

Цитата:

FiEctro писал:
И как дела обстоят с бампом на моделях?

Так же как и на статическом уровне. Единственная проблема - у меня нету карт нормалей для этих моделек из ремастера. Не на чем тестировать.

Цитата:

FiEctro писал:
Кстати серые карты pbr можно расфасовать по RGBA каналам, так для сведений. Могу тебе покидать текстурок для теста.

Я уже взял полный пак текстур из Q1Bers. Там же возьму из код из шейдеров. Просто для теста. Т.к. я сейчас тестирую касательное пространство в первую очередь. И надо решить проблемы с зеркальным наложением текстур. Вот это вот дерьмо:

Добавлено 04-10-2023 в 12:52:

FiEctro к тебе кстати вопрос. Насколько я понял в Unity есть четыре режима запекания лайтмап:
Single - ну тут понятно, просто яркость и цвет лайтмапы, как в халфе или кваке.
DualLightmaps - вот это вот я не понял что оно делает. Там какие-то взвешенные значения что ли. Требует твоего комментария.
DirectionalLightmapping - старая-добрая делюкс мапа
Radiosity Normal Mapping - как в Сорсе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 04-10-2023 в 11:35:

Цитата:

Дядя Миша писал:
Моих шейдеров там нет

А зря, было бы неплохо иметь стартовый пак графония, от которого можно отталкиваться и изменять. Хотя бы на уровне п2.

__________________
Мой мод на Xash

Отправлено FiEctro 04-10-2023 в 12:10:

Цитата:

Дядя Миша писал:
Single - ну тут понятно, просто яркость и цвет лайтмапы, как в халфе или кваке.

Ага, просто смешивает статичную лайтмапу с материалом.

Цитата:

Дядя Миша писал:
DualLightmaps - вот это вот я не понял что оно делает. Там какие-то взвешенные значения что ли. Требует твоего комментария.

Это как Лоды только для теней. Т.е. вблизи у тебя все тени шадоумапы, а с расстоянием у тебя для теней рисуется отдельная лайтмапа поверх. Прикольная штука.

Есть ещё такой прикол:
https://docs.unity3d.com/2019.1/Doc...RealtimeGI.html

Цитата:

Дядя Миша писал:
DirectionalLightmapping - старая-добрая делюкс мапа

Я не очень понимаю о какой делюкс мапе речь, но в целом да, эта штука позволяет расчитывать отраженный свет и направление нормалей для Енлайтена.

Цитата:

Дядя Миша писал:
Radiosity Normal Mapping - как в Сорсе.

Это из тех исходников? Ну вроде бы как да наверное. По идее оно уже совмещено с DirectionalLightmapping, его я и юзаю.

Вот тут что то есть, в том числе и ssbump.
https://github.com/Geenz/GzRNM

Вообще конечно ты можешь легко на Юнити написать свою логику лайтмап, ведь они не прибиты гвоздями к движку, это всеголишь шейдер. А вот с лайтпробами дела обстоят абсолютно иначе.

Цитата:

Дядя Миша писал:
Не просто можно, а нужно! Своих шейдеров в движке нет, только пользовательские. Какой шейдер сделаешь - так и будет. Движок не предлагает вообще ничего. Иными словами, если пользователь не создал материалов и шейдеров, движок ничего не нарисует.

В Юнити у шейдеров такой прикол, что ты можешь наследоваться от какого то другого шейдера, чтобы не писать всё заново. Это особенно видно если ты откроешь шейдеры URP и HDRP рендера.

Вот тут про графику и освещение много чего есть:
https://docs.unity3d.com/2019.1/Doc...ngOverview.html

Отправлено Дядя Миша 04-10-2023 в 15:38:

Цитата:

Aynekko писал:
А зря, было бы неплохо иметь стартовый пак графония, от которого можно отталкиваться и изменять. Хотя бы на уровне п2.

Так я его приложу в качестве SDK. Я имею в виду что там нет ни одного шейдера, который нельзя было бы полностью переписать, поскольку его бы требовал движок для нормальной работы. Вот такого нет.

Добавлено 04-10-2023 в 18:38:

Ну чтож, баг с касательным удалось побороть, заюзав NvMeshMender для его генерации и передав в вертекс все три компоненты.
Иными словами - сохранять только нормаль, тангенту и знак бинормали - хреновая идея. Может быть для персонажей это и работает, но для уровней - точно нет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 04-10-2023 в 16:08:

Цитата:

Дядя Миша писал:
Ну чтож, баг с касательным удалось побороть, заюзав NvMeshMender для его генерации и передав в вертекс все три компоненты.
Иными словами - сохранять только нормаль, тангенту и знак бинормали - хреновая идея. Может быть для персонажей это и работает, но для уровней - точно нет.

А освещение в думе можно так же профиксить?

Отправлено FiEctro 04-10-2023 в 16:47:

Цитата:

Дядя Миша писал:
Я уже взял полный пак текстур из Q1Bers.

Там разве PBR?

Отправлено Дядя Миша 04-10-2023 в 16:52:

Цитата:

Crystallize писал:
А освещение в думе можно так же профиксить?

В каком дууме?

Цитата:

FiEctro писал:
Там разве PBR?

Да.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 04-10-2023 в 17:53:

Дядя Миша в третьем конечно.

Отправлено Дядя Миша 04-10-2023 в 17:56:

Не понял.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 04-10-2023 в 18:00:

Будет ли сильно красивее в третьем думе если вместо первой формулы там в шейдерах поставить вторую?

Отправлено Decay 04-10-2023 в 18:02:

Тут есть особо навороченный дуум3, с подсветкой в темноте
https://github.com/RobertBeckebans/RBDOOM-3-BFG

Отправлено Дядя Миша 04-10-2023 в 18:15:

Цитата:

Crystallize писал:
Будет ли сильно красивее в третьем думе если вместо первой формулы там в шейдерах поставить вторую?

Аа, ты про это. Я думал про тангент-спейс. Ну помягче станет освещение, да.
Но и бамп станет менее чётким.

Decay это Роберт делал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 05-10-2023 в 10:32:

Цитата:

FiEctro писал:
Всё мелкое да и данных мало.

Напомнило то что сделал себе provod в своём рендерере с Vulkan для нашего Xash3D FWGS.
https://cdn.discordapp.com/attachme...82/IMG_4720.mov

__________________
Xash3D FWGS форк

Отправлено FiEctro 05-10-2023 в 10:57:

a1batross
Как то там всё прыгает и накладывается друг на друга у него что вообще можно разобрать?

Цитата:

Дядя Миша писал:
Так же как и на статическом уровне. Единственная проблема - у меня нету карт нормалей для этих моделек из ремастера. Не на чем тестировать.

Для теста можно и самому сгенерировать. Вот держи такая утилита есть:

https://www.youtube.com/watch?v=hHH178pgS1w
http://boundingboxsoftware.com/materialize/

Тут не только нормальки, но и PBR собрать можно.

Для ssbump можно вот это попробовать:
https://www.youtube.com/watch?v=J5cvlzjjpew
https://sourceforge.net/projects/ssbumpgenerator/

Чтобы не мучаться с поиском подходящих текстур.

Отправлено Дядя Миша 05-10-2023 в 12:12:

Цитата:

FiEctro писал:
Вот держи такая утилита есть:

Спасибо, попробую.

Цитата:

FiEctro писал:
Для ssbump можно вот это попробовать:

RNM я когда-нибудь потом запилю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 05-10-2023 в 16:20:

FiEctro там не накладывается, но прыгает. Сверху фреймтайм от двух последних кадров. Слева графики.

Причём он говорил что через квар можно выставить список метрик динамически, в зависимости от того что в данный момент нужно.

__________________
Xash3D FWGS форк

Отправлено FiEctro 05-10-2023 в 16:32:

a1batross
В любом случае выглядит как мешанина, там ещё и старый интерфейс под ним.

Отправлено a1batross 05-10-2023 в 20:45:

FiEctro какой старый? Там ничего старого нет, весь рендер вообще с нуля написан, за редкими исключениями, и то временными.

__________________
Xash3D FWGS форк

Отправлено FiEctro 05-10-2023 в 21:30:

a1batross

Почему все линуксоиды не умеют/любят UI?

Отправлено FiEctro 06-10-2023 в 09:19:

Дядя Миша
Кстати, а какой порядок каналов для нормалей у тебя? Можно в мета файле ресурса указать тип нормали?

Отправлено Дядя Миша 06-10-2023 в 09:48:

Хмм, бамп-маппинг появился на этой неделе. Я над подобными вещами просто не задумывался. Потом разберёмся.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-10-2023 в 11:06:

Дядя Миша
Как референс можешь глянуть в Юнтити при импорте ты можешь настроить метаданные для текстур и моделей. Ещё до того как она попадёт в материал и шейдер. Что позволяет быстро заменять текстуры не исправляя кучу материалов.

В Texture type задаётся к чему относить эту текстуру, к текстуре, спрайту, нормали, кубамапе, UI, лайтмапе.

https://docs.unity3d.com/2021.3/Doc...xtureTypes.html

Отправлено Дядя Миша 06-10-2023 в 16:45:

У меня мета-материалы. Можно исправить саму настройку материала, добавить туда новый функционал. Так что думаю, проблемы нет.

Ну чтож, сегодня наконец сбылась мечта идиота - попиксельные лайтстили.
Вы вероятно над этим не задумывались, но корректное смешение лайтстилей на GPU - это архисложная задача. Вот так, чтобы не разбивать батчи по сурфейсам, каждый из которых имеет свой набор лайтстилей, что в общем случае крайне негативно сказывается на производительности. К тому же лайтстили, приложенные к сурфейсу не дружат с инстанс-моделями.
И вообще стили должны быть привязаны к лайтгруппе. а лайтгруппа это виртуальное понятие, которым оперирует только лайтмаппер, движок про нее ничего не знает. То есть мало просто собрать лайтмапы в большие атласы - лайтстили сломают эту идиллию нахрен.
При том, что лайтстили сохранённые в текстуру не могут иметь интерполяцию. То есть всё это дело постоянно норовит взорваться уродливыми артефактами. Но тем не менее - у меня получилось.
Теперь лайтстили вообще никак не влияют на производительность
Ну и плавающий лимит присутствует конечно - 4 лайтстиля на лайтгруппу.
А вот лайтгруппы, товарищи юзеры вы в принципе можете регулировать самостоятельно, как раз на такой вот стрёмный случай. Ну и не только на такой. В 99% случаев компилятор прекрасно справляется сам. Но иногда ему требуется помощь. Теперь это регулируется со стороны дизайнера.

Добавлено 06-10-2023 в 19:44:

Так, ну чтожы. Пора показать некоторые достижения. Скриншоты в порядке появления эффектов:

Нет эффектов.

Хай-рез текстуры

Нормал-маппинг

Оффсет-маппинг (он же рельф-маппинг, он же параллакс)

Скриншоты имеют накопительный эффект, т.е. на каждом следующем видны предидущие фичи + новая. Обратите внимание как падает фпс.
Осталось только подключить PBR и тестирование бампа завершено.

Добавлено 06-10-2023 в 19:45:

Как и прошлые разы, напоминаю - в движок не лазаю. Все эти эффекты были подключены путём редактирования материалов и шейдеров.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 06-10-2023 в 19:04:

FiEctro это r_speeds. Его движок забирает строчкой из рендерера и как хочет, так и рисует.

__________________
Xash3D FWGS форк

Отправлено XaeroX 06-10-2023 в 19:21:

Цитата:

Дядя Миша писал:
Оффсет-маппинг (он же рельф-маппинг, он же параллакс)

Аж стены раздвигаются!

Добавлено 06-10-2023 в 15:21:

528 фпс на карте из первой кваки, и это ещё теней нет?

Однако...

__________________

Отправлено Дядя Миша 06-10-2023 в 19:33:

Ну чтоже. Могу сказать, что работа над лайтмаппером завершена.
Начал я им заниматься в июле 2020-го года и вот наконец он обзавёлся всем необходимым и превзошёл по своим возможностям абсолютно все лайтмапперы для всех движков семейства Quake и их производных.
За промышленные лайтмаперы ничего скажу - там и требования другие.
Впрочем как и за лайтмапперы того же Unity\Unreal. Будете сами сравнивать и мне рассказывать. Однако один момент всё же отмечу. Судя по всему, мой лайтмаппер - единственный, который умеет давать инстанс-моделям персональные лайтмапы. В том же юнити я поковырялся - там освещение еденичным цветом, ну как и в сталкере. Т.е. это довольно непростая в реализации фича. Более подробно распишу в документации.

То что лайтмаппер завершён ещё не означает, что я больше не буду над ним работать. Какие-то небольшие исправления, оптимизации, внедрение новых режимов запекания - это всё будет. Но фундаментальные принципы меняться уже не будут. В этом плане будет логичнее написать ещё один лайтмаппер, чем трогать этот, если вдруг возникнет такая необходимость.

Ну а поскольку теперь у меня есть стабильный референс в виде статически запечённого света - пора переходить к динамическому освещению.
Для начала разумеется сделаю обычный прямой свет. Собственно сам свет не проблема запилить уже сейчас, но нужны ещё две вещи:
1. эффективная система отсечения невидимых источников. Будет построена на уже знакомой вам технологии визлайт матрицы. Я использовал её в параное и остался доволен. Это на мой взгляд вообще единственная технология, которая позволяет в реалтайме рисовать лайты с квадратичным радиусом затухания. Я в своё время писал об этом. Пакость этих лайтов заключается в том, что отсечение их по радиусу невозможно в принципе - каждый такой лайт заведомо больше площади экрана. Т.е. все эти кластеры и отложка идут лесом. Поэтому в играх по прежнему используют либо лайтмапу либо локальные лайты, радиус которых гарантированно меньше площади экрана. А у меня есть технология как рисовать подобные лайты в реалтайме. Правда с оговоркой что лайты не должны двигаться, но ведь они и так не двигаются. А для подвижных лайтов можно юзать и линейный радиус затухания.
2. система рендеринга теней. Проблема теней в том, что для каждого источники выделяют одну теневую карту. Причём эти карты ещё и разные - где-то кубемапа для всенаправленных источников, где-то каскады, т.е. несколько теневых карт на источник, где-то одна, для проекционных.
Это очень неудобно и мешает полноценному менеджменту на GPU. Чтобы не проталкивать в параметры что-то, а решать эти задачи целиком на GPU. Я вижу это таким образом, что движок подаёт на вход рендеринга только массив с индексами лайтов, которые видны из текущей позиции взгляда, а всё остальное полностью решается в шейдере. Это наиболее гибкая и надёжная схема.
Динамическое освещение в движок планируется внедрить в течение следующей недели. Само по себе освещение делается легко - это немного кода в шейдере. Главная сложность - это бакэнд, обеспечение. То самое, на которое я убил почти три года и мне даже нечего было вам показать в плане скриншотов. Ну зато теперь любая задачка решается в рекордные сроки. Реалтайм радиосити займусь уже в следующем году.

Добавлено 06-10-2023 в 22:33:

Цитата:

XaeroX писал:
Аж стены раздвигаются!

Экспериментатор движений вверх-вниз видит простор там где мне видна стена!

Цитата:

XaeroX писал:
528 фпс на карте из первой кваки, и это ещё теней нет?

Так этот параллакс ещё и считается самым оптимизированным. Хотя я и не сравнивал. А тени-то чего тормозить будут? Я не собираюсь их вычислять каждый кадр, 60 раз в секунду за глаза достаточно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 06-10-2023 в 20:18:

Цитата:

Дядя Миша писал:
А тени-то чего тормозить будут?

Проходы же.

Добавлено 06-10-2023 в 16:18:

Цитата:

Дядя Миша писал:
60 раз в секунду за глаза достаточно.

Мне кажется, будут заметны дёргания. Или ты их как-то хитро блендить между кадрами будешь?

__________________

Отправлено Дядя Миша 06-10-2023 в 20:23:

Закэширую в атлас. Сервер тикает 60 раз в секунду, значит положение теней просто не изменится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 06-10-2023 в 20:26:

Цитата:

Дядя Миша писал:
значит положение теней просто не изменится.

А как же лерпинг?

__________________

Отправлено Дядя Миша 06-10-2023 в 20:28:

Да нет у меня неко-кова лерпинга. Лерпинг - это когда 20/60. А когда 60/60 - что лерпить-то?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-10-2023 в 20:36:

Цитата:

Дядя Миша писал:
Так, ну чтожы. Пора показать некоторые достижения. Скриншоты в порядке появления эффектов:

Здорово! Чуть позже распишу. Но пока я заметил что у тебя лума текстура на фонариках сломалась.

Цитата:

Дядя Миша писал:
Оффсет-маппинг (он же рельф-маппинг, он же параллакс)

Я помню была ещё версия этого шейдера где на рельефе тени рисовались.

Отправлено XaeroX 06-10-2023 в 20:49:

Цитата:

Дядя Миша писал:
А когда 60/60 - что лерпить-то?

60/60 означает, что движения будут рывками, что будет восприниматься игроком как дёргания. В идеале рендерер не должен производить два одинаковых кадра ни при каких условиях.

__________________

Отправлено FiEctro 06-10-2023 в 20:51:

Ну да привязка к герцовке 60Гц плохая идея. На мониторах с более высокой герцовкой будут плохие вещи происходить.

Цитата:

Дядя Миша писал:
Так этот параллакс ещё и считается самым оптимизированным.

Мне кстати такая идея пришла, а что если его только вблизи рисовать? Вдалеке его всеравно не видно.
Может быстрее будет?

Отправлено Дядя Миша 06-10-2023 в 21:37:

Цитата:

FiEctro писал:
Но пока я заметил что у тебя лума текстура на фонариках сломалась.

Хай-рез текстурки предполагают наличие хайрез лумы. В данном случае её не доложили.

Добавлено 07-10-2023 в 00:37:

Цитата:

FiEctro писал:
Мне кстати такая идея пришла, а что если его только вблизи рисовать?

Ты будешь смеяться, но он именно так и устроен.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 06-10-2023 в 22:05:

Цитата:

Дядя Миша писал:

А тени-то чего тормозить будут? Я не собираюсь их вычислять каждый кадр, 60 раз в секунду за глаза достаточно.

Зря.

впрочем, на общем фоне текущих лагов заметно не будет, если ничего так и не изменится - если вся картинка 60 фпс, то да, смысла нет.

Цитата:

FiEctro писал:
Ну да привязка к герцовке 60Гц плохая идея. На мониторах с более высокой герцовкой будут плохие вещи происходить.

Они уже происходят и я уже писал об этом.

__________________
Мой мод на Xash

Отправлено Дядя Миша 07-10-2023 в 06:56:

Пока нет сетевой подсистемы - бессмысленно что-либо менять в этой конструкции.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 07-10-2023 в 08:04:

Цитата:

Дядя Миша писал:
Оффсет-маппинг (он же рельф-маппинг, он же параллакс)

Последний скрин в сравнений с предыдущем выглядит ппц, как странно, особенно, когда все разьезжается в разные стороны...

А если его не сравнивать, а просто смотреть, то норм

Отправлено Дядя Миша 07-10-2023 в 08:05:

Параллакс вы сможете подключить какой угодно, я просто взял для теста то, что было под рукою. В игре он вроде норм смотрится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-10-2023 в 08:08:

Мне параллакс нравится. Когда будет ssbump у него появятся тени, и будет ещё лучше

Цитата:

(_-=ZhekA=-_) писал:
Последний скрин в сравнений с предыдущем выглядит ппц, как странно, особенно, когда все разьезжается в разные стороны...

Ну главное чтобы они не разъезжались в зависимости от угла взгляда

И такое я видел.

Цитата:

FiEctro писал:
Я помню была ещё версия этого шейдера где на рельефе тени рисовались.

Нашел:
https://stackoverflow.com/questions...x-occlusion-map

Отправлено Дядя Миша 07-10-2023 в 08:24:

FiEctro у этого паралалкса тоже есть само-затенение, чуть позже подключу. Но для SS-бампа не требуется карта высот для получения теней.
Там дополнительная информация уже запечена лайтмаппером.
Но в сущности плюс-минус то на то и выходит.

Цитата:

FiEctro писал:
Ну главное чтобы они не разъезжались в зависимости от угла взгляда

Я скоро выложу обновлённую демку. Вроде бы не разъезжаются.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-10-2023 в 08:39:

Дядя Миша
Ещё такой вопрос чисто теоретический, не совсем относящийся к ксашу. Скажи а возможно ли как то фейково сглаживать стенсильные тени? Я когда экспериментировать с альфа клипом, пробовал отобразить тона точками. Возможно что то подобное использовать для стенсильных теней? Вроде как и у шадоумап что то подобное я наблюдал.

Отправлено Дядя Миша 07-10-2023 в 08:49:

Попробую попытаться переформулировать идеологию движка простым и понятным языком. Я когда начинаю говорить о возможностях систем, народ как правило не воспринимает - они такого никогда не видели, сравнивать не с чем, поэтому непонятно.
Вот смотрите, за что мы любим старые движки? Потому что там всё просто, раз-раз, накидал уровни, собрал и игра готова. Минимум посторонних действий.
За что мы любим новые движки? Как говорят сами их пользователи - потому что на них можно сделать вообще всё что угодно! На практике чаще всего получается, что это "всё что угодно" требует гораздо больше усилий от разработчика, но приятное чувство полной свободы при этом никуда не исчезает.
Особняком стоят те же продукты от Valve - Source, Source 2. Это в некотором роде, то что я ориентируюсь, но не в плане наследования идеологии, а просто исходя из факта, что Source внутри это всё тот же квейк, пусть и переписанный десятки раз. Сама идеология осталась прежней - Хаммер, брашы, консольные утилиты для компиляции. И очень многие высказываются про него в положительном ключе, мол с удовольствием перешли бы на Source 2, да Valve его толком не даёт народу. То есть даёт, но не только лишь всем и с рядом оговорок. Опять таки, у Вальвы там дллки на С++, адов код, в котором попробуй ещё разберись. Но в целом этот подход народу нравится. При условии что его не будут заставлять абсолютно всё делать брашами и при условии, что другие примитивы не будут иметь каких-то ограничений, как было в той же Халфе. Модельку вставить вроде бы можно, да только ни нормального освещения, ни нормальной коллизии с ней уже не получить. И это конечно была трагедия.
Так вот XashNT пытается одновременно исправить недостатки всех существующих подходов, сохранив главное достоинство - простоту разработки. Он не будет перекладывать чисто внутренние проблемы на юзера, только лишь потому что кто-то поленился всё это грамотно организовать. Ваша игра тормозит? Ну вот вам отладчик - сидите и разбирайтесь где там у вас тормозит. В квейке никакого профайлера не было, но при этом и ситуации с тормозами тоже не возникало, например.
Опять же эти сторонние лайтмаперы и прочие утилиты - потребность во всём этом возникает далеко не от хорошей жизни, а потому что нативное толком не справляется. Т.е. вся эта свобода - выбор между сортами говна.
Сказанное конечно не исключает появления сторонних утилит для XashNT, но как и в случае с движками того же Квейка они будут появляться уже после его выхода и ориентироваться на то, чтобы быть как минимум не хуже нативных тулзов.
Примерно так.

Добавлено 07-10-2023 в 11:49:

Цитата:

FiEctro писал:
Скажи а возможно ли как то фейково сглаживать стенсильные тени?

Я со стенсильными тенями никогда не работал, да и не планирую, если честно. Так что ничего сказать не могу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-10-2023 в 09:00:

Цитата:

Дядя Миша писал:
Ну чтож, сегодня наконец сбылась мечта идиота - попиксельные лайтстили.
Вы вероятно над этим не задумывались, но корректное смешение лайтстилей на GPU - это архисложная задача. Вот так, чтобы не разбивать батчи по сурфейсам, каждый из которых имеет свой набор лайтстилей, что в общем случае крайне негативно сказывается на производительности. К тому же лайтстили, приложенные к сурфейсу не дружат с инстанс-моделями.
И вообще стили должны быть привязаны к лайтгруппе. а лайтгруппа это виртуальное понятие, которым оперирует только лайтмаппер, движок про нее ничего не знает. То есть мало просто собрать лайтмапы в большие атласы - лайтстили сломают эту идиллию нахрен.
При том, что лайтстили сохранённые в текстуру не могут иметь интерполяцию. То есть всё это дело постоянно норовит взорваться уродливыми артефактами. Но тем не менее - у меня получилось.
Теперь лайтстили вообще никак не влияют на производительность
Ну и плавающий лимит присутствует конечно - 4 лайтстиля на лайтгруппу.
А вот лайтгруппы, товарищи юзеры вы в принципе можете регулировать самостоятельно, как раз на такой вот стрёмный случай. Ну и не только на такой. В 99% случаев компилятор прекрасно справляется сам. Но иногда ему требуется помощь. Теперь это регулируется со стороны дизайнера.

Никто и не заметил, а это очень важная вещь. Спасибо. Хотя сами лайтстили будут не очень актуальны когда появятся нормальные динамические источники с радиосити.

Цитата:

Дядя Миша писал:
1. эффективная система отсечения невидимых источников. Будет построена на уже знакомой вам технологии визлайт матрицы. Я использовал её в параное и остался доволен. Это на мой взгляд вообще единственная технология, которая позволяет в реалтайме рисовать лайты с квадратичным радиусом затухания. Я в своё время писал об этом. Пакость этих лайтов заключается в том, что отсечение их по радиусу невозможно в принципе - каждый такой лайт заведомо больше площади экрана. Т.е. все эти кластеры и отложка идут лесом. Поэтому в играх по прежнему используют либо лайтмапу либо локальные лайты, радиус которых гарантированно меньше площади экрана. А у меня есть технология как рисовать подобные лайты в реалтайме. Правда с оговоркой что лайты не должны двигаться, но ведь они и так не двигаются. А для подвижных лайтов можно юзать и линейный радиус затухания.

Это здорово, вообще хотелось чтобы режимов затухания было как можно больше, что бы позволяло максимально приблизится к такому освещению которое хочет художник. Например сорсовскому. Ну это скорее к лайтмапперу относится.

Цитата:

Дядя Миша писал:
2. система рендеринга теней. Проблема теней в том, что для каждого источники выделяют одну теневую карту. Причём эти карты ещё и разные - где-то кубемапа для всенаправленных источников, где-то каскады, т.е. несколько теневых карт на источник, где-то одна, для проекционных.
Это очень неудобно и мешает полноценному менеджменту на GPU. Чтобы не проталкивать в параметры что-то, а решать эти задачи целиком на GPU. Я вижу это таким образом, что движок подаёт на вход рендеринга только массив с индексами лайтов, которые видны из текущей позиции взгляда, а всё остальное полностью решается в шейдере. Это наиболее гибкая и надёжная схема.
Динамическое освещение в движок планируется внедрить в течение следующей недели. Само по себе освещение делается легко - это немного кода в шейдере. Главная сложность - это бакэнд, обеспечение. То самое, на которое я убил почти три года и мне даже нечего было вам показать в плане скриншотов. Ну зато теперь любая задачка решается в рекордные сроки. Реалтайм радиосити займусь уже в следующем году.

Ну вот Юнити попытались решить этот момент ограничив колиество поинтов с тенями плавающим лимитом, а остальные рисовать повертексно. Вышло честно говоря не очень, однако в некоторых случаях это можно использовать. Но так идея такой оптимизации интересная, но думаю её реализацию можно сделать и получше, как говорил наш Илья - надо подумать.

Добавлено 07-10-2023 в 12:00:

Цитата:

Дядя Миша писал:
Попробую попытаться переформулировать идеологию движка простым и понятным языком. Я когда начинаю говорить о возможностях систем, народ как правило не воспринимает - они такого никогда не видели, сравнивать не с чем, поэтому непонятно.
Вот смотрите, за что мы любим старые движки? Потому что там всё просто, раз-раз, накидал уровни, собрал и игра готова. Минимум посторонних действий.
За что мы любим новые движки? Как говорят сами их пользователи - потому что на них можно сделать вообще всё что угодно! На практике чаще всего получается, что это "всё что угодно" требует гораздо больше усилий от разработчика, но приятное чувство полной свободы при этом никуда не исчезает.

Я бы переформулировал так:
Старые движки легче освоить потому что использующиеся там технологии примитивны, и их рендер не требует от художника вывозить реалистичную картинку. Да и тамошние инструменты и лимиты вынуждают идти на большое количество компромисов. Однако это даёт некий побочный эффект - тебе не нужно много контента, не нужно рисовать PBR, нормал мапы, не нужно делать хайполи модели с лодами. Плюс там есть уже множество захардкоженых игровых объектов которые тебе не надо писать самому, но если тебе нужно сделать игру в другом жанре, тебе придётся разгребать чужой код что отнимет уйму времени.

В новых движках лимиты отодвинуты, технологий больше, и более удобные инструменты, но тут сам уже рендер диктует некий минимальный порог для художника. Поскольку сделать первую кваку с такой же графикой можно и на пятом анриле, но вот сделать хорошую графику можно только на новом движке с удобными инструментами. Есть некая особенность современных движков вроде Юнити или Анрила которая рассматривается сторонниками старой школы как большой минус - это модульность. Т.е. изначально движок не привязан ни к камому жанру, а значит он практически не имеет никаких игровых компонентов вроде всяких дверей, платформ, плеер контроллера из коробки. Это всё надо накатывать ассетами, либо писать самому.

Я не просто тебе скинул S&Box т.к. его идеология по сути пытается соединить эти 2 школы. Это движок старой школы - Сорс2 но с инструментами и технологиями движков новой школы. Мне кажется ксашу этот концепт подошел бы ещё больше, поскольку ты не ограничен валвовскими форматами.

Отправлено (_-=ZhekA=-_) 07-10-2023 в 09:08:

Цитата:

Дядя Миша писал:
Попробую попытаться переформулировать идеологию движка простым и понятным языком.

А с какими новыми или старыми движками ксаш может конкурировать? Юнити, уе4 \ уе5?

Ксаш можно будет использовать в архитектурной визуализации, чтобы получать на выходе фотореалистичную картинку, как например в уе5?

Насколько сложно сделать аналог блюпринтов аля уе5, но для своего языка и планируется ли это?

В ксаше вся игровая логика будет, как в хл или уже как в новых движках, когда у тебя только двиг, а все, что тебе нужно пишешь сам?

Добавлено 07-10-2023 в 12:08:

Цитата:

FiEctro писал:
Я не просто тебе скинул S&Box т.к. его идеология по сути пытается соединить эти 2 школы. Это движок старой школы - Сорс2 но с инструментами и технологиями движков новой школы. Мне кажется ксашу этот концепт подошел бы ещё больше, поскольку ты не ограничен валвовскими форматами.

А скинь сюда, интересно глянуть )

Отправлено FiEctro 07-10-2023 в 09:08:

Цитата:

(_-=ZhekA=-_) писал:
А с какими новыми или старыми движками ксаш может конкурировать? Юнити, уе4 \ уе5?

Я считаю у ксаша должна быть своя ниша. Идти на сознательную конкуренцию с китами при том на начальном этапе, сомнительная идея.

Цитата:

(_-=ZhekA=-_) писал:
Ксаш можно будет использовать в архитектурной визуализации, чтобы получать на выходе фотореалистичную картинку, как например в уе5?

А смысл? Когда 3д макс и блендер с этим справляются куда лучше?

Цитата:

(_-=ZhekA=-_) писал:
Насколько сложно сделать аналог блюпринтов аля уе5, но для своего языка и планируется ли это?

Блюпринты зло. Но в качестве дополнения, почему бы и нет. Но упаси господи делать их основными.

Отправлено Дядя Миша 07-10-2023 в 09:13:

Цитата:

FiEctro писал:
Хотя сами лайтстили будут не очень актуальны когда появятся нормальные динамические источники с радиосити.

Актуальность в наличии выбора в первую очередь.

Цитата:

FiEctro писал:
вообще хотелось чтобы режимов затухания было как можно больше

Режимы затухания не захардкодены а задаются формулами, которые дизайнер самостоятельно прописывать в makebsp.def. Он есть в той демке, можешь открыть и поизучать. Там можно симулировать поведение практически любых лайтов, по крайней мере в пространстве наследия Quake.
И эти же параметры автоматически попадают в шейдер, т.е. динамический свет будет использовать те же самые формулы.

Цитата:

FiEctro писал:
как говорил наш Илья - надо подумать.

А кто это?

Цитата:

FiEctro писал:
Т.е. изначально движок не привязан ни к камому жанру

Жанр наполовину обусловлен сетевой подсистемой. С рендером проще - уж если он рисует опенворлд до горизонта то и со стратегиями-рпг как-нибудь справится. А вот сеть накладывает массу ограничений. Синхронизирующие пакеты могут быть разного размера и разной скорости обновления, причём это напрямую связано с жанром. Но пока сети нет, я ничего не могу сказать.

Цитата:

FiEctro писал:
значит он практически не имеет никаких игровых компонентов вроде всяких дверей, платформ, плеер контроллера из коробки

Это ложное рассуждение. На той же кваки и гонки делали и шахматы и даже тетрис. Но из коробки там был пример как сделать шутер.
То есть вопрос даже не в том, должн ли идти ротатабли в комплекте. Понятно, что они будут реализованы в пользовательском коде, а не внутри самого движка. Вопрос в том, что авторы движка не удосужились сделать хорошие полноценные демо во всех жанрах. И это проблема.
Вот Юнити выкатили деревню викингов свою. Ну и какая польза юзерам от этой демки? Да никакой абсолютно. Геймплея там нет, это просто статичная сцена. Чему она может научить? Ничему. Её делали с одной лишь целью - смотрите наш движок тянет не только 2д платформеры.
Т.е. выпендрёж обычный. Но да, там есть ротатабли - целых две штуки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 07-10-2023 в 09:16:

Цитата:

FiEctro писал:
Блюпринты зло.

В чем конкретное зло? Если эпики все это дело довели до совершенства и на принтах онли можно сделать любую игру

Отправлено Дядя Миша 07-10-2023 в 09:20:

Цитата:

(_-=ZhekA=-_) писал:
А с какими новыми или старыми движками ксаш может конкурировать? Юнити, уе4 \ уе5?

Последнее слово за пользователями, очевидно. Если юзеры бросают один движок и переходят на другой, можно сказать, что последний составил конкуренцию первому. Т.е. это в первую очередь человеческий фактор, а не технические особенности.

Цитата:

Когда я раздуплюсь с реалтайм радиосити можно будет вернуться к этому вопросу. Но не ранее.

Цитата:

Можно все эти спиритовские логические энтити рассматривать как прототипы будущих блюпринтов на самом деле и вернуться к этой идее снова. Посмотрим.

Цитата:

(_-=ZhekA=-_) писал:
В ксаше вся игровая логика будет, как в хл или уже как в новых движках, когда у тебя только двиг, а все, что тебе нужно пишешь сам?

Будут исчерпывающие примеры, представляющие собой законченные библиотеки. Но не на С++, а на собственном языке. Народ очень не любит писать такие вещи с нуля - это слишком большой объем работы и вероятность налажать кратно вырастает.

Цитата:

FiEctro писал:
Я считаю у ксаша должна быть своя ниша.

Так нишу и определят пользователи.

Цитата:

FiEctro писал:
Блюпринты зло.

Но почему?

Добавлено 07-10-2023 в 12:19:

Цитата:

Дядя Миша писал:
по крайней мере в пространстве наследия Quake

Вот щас обязательно найдутся те, кто поймет эту фразу неправильно.
Пространство наследия Quake - это и халфа и сорс и второй сорс и старый ксаш и параноя и каллофдутие и еще хренова куча движков, даже срузис и унреал в некотором смысле.
Вот что точно не имеет отношения к этому наследию, так это Юнити.

Добавлено 07-10-2023 в 12:20:

И Юниджин ещё.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-10-2023 в 09:24:

Цитата:

Дядя Миша писал:
Это ложное рассуждение. На той же кваки и гонки делали и шахматы и даже тетрис. Но из коробки там был пример как сделать шутер.
То есть вопрос даже не в том, должн ли идти ротатабли в комплекте. Понятно, что они будут реализованы в пользовательском коде, а не внутри самого движка. Вопрос в том, что авторы движка не удосужились сделать хорошие полноценные демо во всех жанрах. И это проблема.
Вот Юнити выкатили деревню викингов свою. Ну и какая польза юзерам от этой демки? Да никакой абсолютно. Геймплея там нет, это просто статичная сцена. Чему она может научить? Ничему. Её делали с одной лишь целью - смотрите наш движок тянет не только 2д платформеры.
Т.е. выпендрёж обычный. Но да, там есть ротатабли - целых две штуки.

На Юнити был сетевой шутан в качестве демки. Я тебе его кидал. Но как я и говорил - он идёт отдельным модулем, как и викинги.

Цитата:

Дядя Миша писал:
Жанр наполовину обусловлен сетевой подсистемой. С рендером проще - уж если он рисует опенворлд до горизонта то и со стратегиями-рпг как-нибудь справится. А вот сеть накладывает массу ограничений. Синхронизирующие пакеты могут быть разного размера и разной скорости обновления, причём это напрямую связано с жанром. Но пока сети нет, я ничего не могу сказать.

Это ты правильно подметил. Сетевая подсистема должна быть очень гибкой, чтобы подходить под разные жанры. И обеспечивать пользователю доступ к низкоуровневой её части, для кастомизации под себя. Расскажи об этом подробнее если не сложно.

Цитата:

(_-=ZhekA=-_) писал:
В чем конкретное зло? Если эпики все это дело довели до совершенства и на принтах онли можно сделать любую игру

Блю принты разработаны для прототипирования, а не программирования крупных проектов. Это как сравнивать Ардуино с полноценным ПК.

Цитата:

Дядя Миша писал:
Можно все эти спиритовские логические энтити рассматривать как прототипы будущих блюпринтов на самом деле и вернуться к этой идее снова. Посмотрим.

Что то подобное можно использовать вместо энтитей. Где каждая энтития будет просто нодой.

Цитата:

Дядя Миша писал:
А кто это?

https://hlfx.ru/forum/member.php?ac...nfo&userid=3672

Отправлено (_-=ZhekA=-_) 07-10-2023 в 09:26:

Цитата:

Дядя Миша писал:
Народ очень не любит писать такие вещи с нуля - это слишком большой объем работы и вероятность налажать кратно вырастает.

Когда уе4 стал бесплатным и я его начал изучать, то очень сильно удивился и расстроился, когда понял, что в нем нет уже готовых энтить, как в хл1 и всю игровую логику нужно писать с нуля самому и если бы не блюпринты, то 90% что я бы на это дело тупо забил

Отправлено Дядя Миша 07-10-2023 в 09:29:

Цитата:

FiEctro писал:
Расскажи об этом подробнее если не сложно.

Мне надо погрузиться для начала. Я сейчас работаю над освещением. Как доберусь по плану - напишу.

Цитата:

FiEctro писал:
https://hlfx.ru/forum/member.php?ac...nfo&userid=3672

Написано, что он не работает, а пытается вести бизнес. Кто-нибудь расскажите ему, что в бизнесе работать надо ещё больше, чем на дядю.
А то так и будет складывать углы Эйлера и сортировать строчки в delta.lst.

Добавлено 07-10-2023 в 12:29:

Цитата:

(_-=ZhekA=-_) писал:
если бы не блюпринты, то 90% что я бы на это дело тупо забил

Я очень сильно сомневаюсь что у тебя хватило бы терпения реализовать ВСЮ игровую логику той же халфы на блюпринтах. Или скажем полноценную физику игрока на них же. Вся эта каша со стрелочками с определённого момента запутывает ещё сильнее чем обычный код.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 07-10-2023 в 09:39:

Цитата:

FiEctro писал:
Блю принты разработаны для прототипирования, а не программирования крупных проектов. Это как сравнивать Ардуино с полноценным ПК.

Расскажи это эпикам и они будут громко смеяться...

Это утверждение давно уже в прошлом

Я на принтах уже 3 проги сделал

Добавлено 07-10-2023 в 12:39:

Цитата:

Дядя Миша писал:
Я очень сильно сомневаюсь что у тебя хватило бы терпения реализовать ВСЮ игровую логику той же халфы на блюпринтах

В хл нет погоды, нет рюкзака, систем скилов и прочих современных плюшек ) А то, что там есть это все реализовать вообще не сложно

Цитата:

Дядя Миша писал:
Или скажем полноценную физику игрока на них же.

Это на принтах делать не нужно, так как компонент с физикой игрока есть в самом движке и его нужно просто добавить, а если нужно что-то подправить, то можно и принтами )

Отправлено FiEctro 07-10-2023 в 10:02:

Цитата:

Дядя Миша писал:
Вот что точно не имеет отношения к этому наследию, так это Юнити.

Я тебе кидал демку где один человек вставил имплементацию БСП и ку2 физики в Юнити. В очень сыром виде, но тем не менее, работать со всем форматами второй кваки как делают это движки Кармака можно и на Юнити. Другой вопрос, а какой смысл всего этого?

Цитата:

(_-=ZhekA=-_) писал:
Расскажи это эпикам и они будут громко смеяться...
Это утверждение давно уже в прошлом Я на принтах уже 3 проги сделал

Я не спорю, можно и из зубочисток дом построить. Однако никто почему то программы на блюпринтах анрила особо не строит. Но в рамках самого анрила я ничего против не имею, думаю оно так и задумано.

Отправлено Дядя Миша 07-10-2023 в 10:06:

Цитата:

(_-=ZhekA=-_) писал:
Я на принтах уже 3 проги сделал

Конфигуратор лифта, мы видели. Однако утверждение "вообще всё" подразумевает, что на блюпринтах можно написать ещё один Unreal 5.
А это, как ты понимаешь, невозможно.

Цитата:

(_-=ZhekA=-_) писал:
А то, что там есть это все реализовать вообще не сложно

Но проверять это утверждение ты разумеется не будешь

Цитата:

(_-=ZhekA=-_) писал:
Это на принтах делать не нужно, так как компонент с физикой игрока есть в самом движке и его нужно просто добавить

Вот о чём речь. Чтобы юзер на принтах мог сделать "вообще всё", добрые дяди сперва написали десятки мегабайт кода на С++. Я в принципе не против такого подхода, но он как видим порождает иллюзии.

Цитата:

FiEctro писал:
Я тебе кидал демку где один человек вставил имплементацию БСП и ку2 физики в Юнити

Я про идеологию, вокруг которой строился весь проект.

Если кто-то там загрузил уровни от кваки, движок от этого не поменяется.
Равно как и если я сделаю импортер уровней от Юнити, это не будет означать что я проникся его идеологией.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 07-10-2023 в 10:35:

Цитата:

Дядя Миша писал:
Однако утверждение "вообще всё" подразумевает, что на блюпринтах можно написать ещё один Unreal 5.
А это, как ты понимаешь, невозможно.

Я имел ввиду, что любую ИГРОВУЮ логику, которая может понадобиться пользователю, например, смена погоды, рюкзак, рототабли, ИИ, интерфейс для всего этого и много чего еще )

Цитата:

Дядя Миша писал:
Но проверять это утверждение ты разумеется не будешь

А че тут проверять-то, если это уже есть в маркетплейсе на принтах и на плюсах на выбор, качаешь с торрента и юзаешь, если нужно

Отправлено Crystallize 07-10-2023 в 11:26:

Как выглядят 3-5 страниц кода реализованные на блюпринтах? С предохранением от вылетов на случай ненайденных энтить и соотв непроинициализированных векторов?

Цитата:

Лума-текстуры сломались.
И толстоту бампа надо бы сбавить раза в два а то похоже на комнату с мягкими стенами.

Цитата:

Дядя Миша писал:
Так этот параллакс ещё и считается самым оптимизированным. Хотя я и не сравнивал. А тени-то чего тормозить будут? Я не собираюсь их вычислять каждый кадр, 60 раз в секунду за глаза достаточно.

Сделай себе тестовый опенворлд с кубиками и с машинкой которая едет на скорости 2000 юнитов. Или игроку эту скорость выстави. И посмотри будут ли глючить тени, например тень от машинки. Потому что на такой скорости шаг отставания теней сравним с размерами игрока. И начиная с 75 герц это должно быть заметно.

Добавлено 07-10-2023 в 18:22:

Цитата:

Может быть проблема с конверсией сантиметров в юниты. Маппить в таких условиях будет туго. Ну если только на Кварк переходить или заводить кастомный юнит в Джеке.

Отправлено Дядя Миша 07-10-2023 в 11:32:

Цитата:

Crystallize писал:
Лума-текстуры сломались.

Как выяснилась - эмиссия имплементирована прямо в PBR-мапы.

Цитата:

Crystallize писал:
машинкой которая едет на скорости 2000 юнитов

Я боюсь ты не понимаешь, что физика в любом случае будет выполняться 60 раз в секунду. Даже если речь идёт о сторонних физических движках.
А если физика не обновляется чаще - откуда взяться новым данным?

Цитата:

Crystallize писал:
Может быть проблема с конверсией сантиметров в юниты

Это при условии, что к юнитам есть некоторая привязка. Обычно это константы размеров, высоты взгляда, размер мира.

Добавил PBR.

Чтож его все так любят выкручивать, чтобы блестело...

Добавлено 07-10-2023 в 14:32:

И удалил тени с диффузки

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 07-10-2023 в 11:37:

Цитата:

Crystallize писал:
С предохранением от вылетов на случай ненайденных энтить и соотв непроинициализированных векторов?

В анриле нет энтить, что сам себе наговнокодил, то и будет

Цитата:

Crystallize писал:
Как выглядят 3-5 страниц кода реализованные на блюпринтах?

А кто ж его там знает, как оно там

Главное, что работает

Цитата:

Crystallize писал:
Маппить в таких условиях будет туго.

Если двиг использовать для архитектурной визуализации, то никто точно маппить не будет, моделинг онли из макса\блендера

Отправлено SNMetamorph 07-10-2023 в 12:33:

Цитата:

Дядя Миша писал:
Добавил PBR.

Получается, у тебя для него освещение в HDR запечено? Потому что в LDR от него нет совершенно никакого смысл

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Crystallize 07-10-2023 в 12:50:

Цитата:

(_-=ZhekA=-_) писал:
В анриле нет энтить, что сам себе наговнокодил, то и будет

Дело не в этом, свои энтити тоже нужно программно искать на карте и не всегда они там есть.

Цитата:

(_-=ZhekA=-_) писал:
А кто ж его там знает, как оно там Главное, что работает

Так ты должен знать как оно там. Иначе ты все вместе не состыкуешь.
Вопрос был о том, насколько это будет похоже на свалку. А если все красиво расположить, уместится ли на мониторе 1080р.

Цитата:

(_-=ZhekA=-_) писал:
Если двиг использовать для архитектурной визуализации, то никто точно маппить не будет, моделинг онли из макса\блендера

Модельки нужно будет располагать друг относительно друга на конкретном расстоянии.

Добавлено 07-10-2023 в 19:50:

Цитата:

Дядя Миша писал:
И удалил тени с диффузки

Как? Неужели текстуру перерисовывал?

Отправлено (_-=ZhekA=-_) 07-10-2023 в 13:14:

Crystallize
Я тебя вообще не понимаю...

Цитата:

Crystallize писал:
Так ты должен знать как оно там. Иначе ты все вместе не состыкуешь.

Зачем мне это знать? При сборке проекта двиг сам все сделает, как ему нужно

Отправлено ZGreen 07-10-2023 в 13:17:

Зачем юниты конвертировать в сантиметры для рендера? Ну возьми пропорцию юнит=миллиметр и делай себе архитектуру. Это же не для игры.

Отправлено Crystallize 07-10-2023 в 13:23:

(_-=ZhekA=-_) я про геймплей а не про графику если что

Отправлено FiEctro 07-10-2023 в 13:34:

Цитата:

Crystallize писал:
Лума-текстуры сломались.

ДМ уже писал что их нет в HD паке.

Цитата:

Crystallize писал:
И толстоту бампа надо бы сбавить раза в два а то похоже на комнату с мягкими стенами.

Да вроде обычный, пускай будет побольше диапазон уж лучше потом в материале смягчить.

Цитата:

Crystallize писал:
Может быть проблема с конверсией сантиметров в юниты. Маппить в таких условиях будет туго. Ну если только на Кварк переходить или заводить кастомный юнит в Джеке.

В Блендере изначально всё в метрической системе. Эти Юниты, Футы, Дюймы оставьте англосаксам

Цитата:

Дядя Миша писал:
Чтож его все так любят выкручивать, чтобы блестело...

Металл же

Цитата:

Дядя Миша писал:
И удалил тени с диффузки

Что за тени? Эмбиент Оклюжен маску?

Цитата:

Дядя Миша писал:
лайтмаппер в HDR-режим

Кстати, а возможно в перспективе добавить сорсовский HDR?

Отправлено Дядя Миша 07-10-2023 в 13:40:

Цитата:

SNMetamorph писал:
Получается, у тебя для него освещение в HDR запечено?

Нет, в LDR. Но я могу переключить лайтмаппер в HDR-режим. Правда от смысла от этого всё равно не прибавится. Для HDR надо рендерить в FBO с флоатами, для начала. Т.е. прочекать весь конйевер. А у меня, напоминаю, была задача построить правильный касательный базис.

Цитата:

Crystallize писал:
Как? Неужели текстуру перерисовывал?

Нет, в шейдере. Вон даже фпс чуть-чуть упал.

Цитата:

FiEctro писал:
ДМ уже писал что их нет в HD паке.

Как оказалось они находятся прямо внутри PBR текстуры - вон на последних скринах лума сама-собой починилась.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 07-10-2023 в 13:46:

Цитата:

ZGreen писал:
Зачем юниты конвертировать в сантиметры для рендера? Ну возьми пропорцию юнит=миллиметр и делай себе архитектуру. Это же не для игры.

Я предполагал что модельки зданий будут импортироваться со скейлом 1 м=40юнитов, но по-твоему тоже можно. Правда восьмеричная сетка в редакторе все равно будет путать.

Отправлено Дядя Миша 07-10-2023 в 13:52:

С системой счисления ставить вопрос надо, когда я начну работу над редактором. Джек позволяет только в юнитах работать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 07-10-2023 в 18:00:

Соответствия между юнитами и реальными единицами вроде бы имеют значение только при использовании инструментов архитектурного освещения. А так-то совершенно по барабану, к чему ваша левая пятка захотела приравнять юнит.

Отправлено Дядя Миша 07-10-2023 в 21:32:

Цитата:

nemyax писал:
к чему ваша левая пятка захотела приравнять юнит

Не всё так просто. Если юнит считать метром, то получается у нас игрок - 72 метра в высоту, прямо как в одноимённом фильме.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 07-10-2023 в 21:40:

Тогда у него двери 96 метров в высоту и вообще он великан в стране великанов. Пока ты не начнёшь симулировать водичку, например, он с тем же успехом может быть лилипутом в стране лилипутов. Разницы ты не заметишь.

Отправлено Дядя Миша 07-10-2023 в 21:44:

Цитата:

nemyax писал:
Тогда у него двери 96 метров в высоту

Да, но смысл то в том, чтобы привязываться к реальным размерам, а не переименовывать милицию.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-10-2023 в 22:05:

Цитата:

nemyax писал:
Тогда у него двери 96 метров в высоту и вообще он великан в стране великанов. Пока ты не начнёшь симулировать водичку, например, он с тем же успехом может быть лилипутом в стране лилипутов. Разницы ты не заметишь.

Цитата:

Дядя Миша писал:
Не всё так просто. Если юнит считать метром, то получается у нас игрок - 72 метра в высоту, прямо как в одноимённом фильме.

Так вон пишут 1 метр = 40 юнитов

Отправлено Дядя Миша 08-10-2023 в 07:11:

C++ Source Code:

1	// meters to inches

2	#define METERS_PER_INCH 0.0254

3	#define METER2INCH( x ) ( x * ( 1.0 / METERS_PER_INCH ))

4	#define INCH2METER( x ) ( x * ( METERS_PER_INCH / 1.0 ))

напоминаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 08-10-2023 в 11:29:

Дядя Миша
Так, а причем тут дюймы, когда речь о метрах и юнитах?

Отправлено Дядя Миша 08-10-2023 в 11:42:

При том, что юнит это и есть дюйм. Я же сталкеровские карты перегонял из метров в юниты, используя размер дйюма. Всё идеально совпало.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 08-10-2023 в 11:55:

Дядя Миша
Хм, и правда 1 метр это 39,3701 дюймов. Почти не отличается от того что писали выше. Тогда в чём проблема? Формулы перевода метров в дюймы и дюймы в метры у тебя уже есть.

Отправлено Дядя Миша 08-10-2023 в 12:34:

Так я же выше написал - надо все сорцы прочекать на предмет констант.
Чтобы в коде их движка их не было.
Опять же, можно определять систему прямо в настройках карты - новый формат исходников такое вполне позволяет. Потом постепенно и для моделей что-то аналогичное сделаю. Впрочем есть и ещё одна проблема - дюймы некритично переводятся в тексели. Один тексель = 1 юнит. Это удобно. С метрами так не получится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 11-10-2023 в 19:09:

Ничего не пишу, но это не значит что новостей нет. Работаю над динамической системой освещения. Всмысле полностью динамической.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 11-10-2023 в 19:23:

Цитата:

Дядя Миша писал:
То что лайтмаппер завершён ещё не означает, что я больше не буду над ним работать. Какие-то небольшие исправления, оптимизации, внедрение новых режимов запекания - это всё будет. Но фундаментальные принципы меняться уже не будут. В этом плане будет логичнее написать ещё один лайтмаппер, чем трогать этот, если вдруг возникнет такая необходимость.

У Психопата в лайтбейкере есть любопытная фича когда освещение от неба учитывает яркость конкретных пикселей скайбокса. Ты мог бы у себя такое реализовать? Для статики.

Отправлено Дядя Миша 11-10-2023 в 19:33:

Эта фича была ещё в q3map2. Ни разу не видел чтобы это было хоть сколько-нибудь заметно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-10-2023 в 19:47:

Цитата:

Дядя Миша писал:
Эта фича была ещё в q3map2. Ни разу не видел чтобы это было хоть сколько-нибудь заметно.

В затененных местах заметно.

Цитата:

Дядя Миша писал:
Ничего не пишу, но это не значит что новостей нет. Работаю над динамической системой освещения. Всмысле полностью динамической.

Выкладывай прогресс хотя бы в закрытую ветку. Хотя бы текстом.

Отправлено Дядя Миша 11-10-2023 в 20:54:

Прогресс, когда уже есть что показать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 12-10-2023 в 02:53:

Цитата:

Дядя Миша писал:
Эта фича была ещё в q3map2. Ни разу не видел чтобы это было хоть сколько-нибудь заметно.

https://old.reddit.com/r/HalfLife/c...r_bright_spots/
Меня однажды задолбало что в ХЛ2 такие яркие облака которые ничего не освещают и я наделал фейковых солнц там где пол-неба светится. Получился подсвеченный треугольник на пол-стены.

Отправлено FiEctro 12-10-2023 в 05:57:

Crystallize
Потому что солнышко это прямое освещение, а свет от облаков - индирект. Никак ты его лампочками не имитируешь, разве что эмиссивными текстурами что раздует тебе время компиляции. Так же эта фишка очень полезна когда у тебя динамическая смена дня и ночи.

Отправлено Crystallize 12-10-2023 в 06:44:

FiEctro Скайбокс это набор точек вообщето. Потому и сымитировалось, я считаю - весьма симпатично.

Отправлено FiEctro 12-10-2023 в 07:24:

Crystallize
Да фигня, от такого способа будут тени там где их не должно быть. А если каждое солнышко будет рисовать шадоумапу то вообще жопа. Всё это работает только на очень низкочастотной лайтмапе как на скриншоте.

Цитата:

Дядя Миша писал:
Прогресс, когда уже есть что показать.

Вытянутые источники, ареалайты и проекторы планируются?

Отправлено Crystallize 12-10-2023 в 07:35:

FiEctro Так мне и нужно для статики.

Отправлено Дядя Миша 12-10-2023 в 07:37:

Насчёт вытянутых не думал. Остальное да.

Добавлено 12-10-2023 в 10:37:

Crystallize так а где твой эффект от пикселей скайбокса?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-10-2023 в 08:59:

Дядя Миша
Я так понял он имеет ввиду чтобы цвет и яркость неба вносили вклад в индирект освещения.

Отправлено Decay 12-10-2023 в 09:03:

Что-то вроде _diffuse_light

Отправлено Дядя Миша 12-10-2023 в 09:25:

Диффуз лайт у меня поддерживается, если что.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-10-2023 в 10:17:

Дядя Миша
Дифуз лайт это просто равномерный цвет. А это что то вроде умножение на цвет лучей индеректа неба на одну из сторон кубамапы цвета.
Например если луч идёт с севера от неба, то к нему добавляется цвет кубамапы неба с той же стороны откуда идёт этот луч. Можешь в Юнити глянуть как эта фишка работает. Она кстати и для динамических объектов тоже там работает.

Это полезно если небо неравномерно освещено в разных частях, к примеру закат, одним дифузом ты его уже не выровняешь.

Вот у Скаржа ещё был пример хороший:
https://gamebanana.com/mods/92240

правда я не знаю как он это у себя имитировал.

Отправлено Decay 12-10-2023 в 10:17:

Цитата:

FiEctro писал:
правда я не знаю как он это у себя имитировал.

(надеюсь он не против)

code:
{
"origin" "520 -264 504"
"_light" "255 255 255 700"
"style" "0"
"_fade" "1.0"
"_falloff" "0"
"angles" "-55 240 0"
"_diffuse_light" "0 0 0 0"
"classname" "light_environment"
}
{
"origin" "521 -265 520"
"_light" "0 0 0 0"
"style" "0"
"_fade" "1.0"
"_falloff" "0"
"angles" "90 240 0"
"_diffuse_light" "64 121 255 900"
"classname" "light_environment"
}
{
"_fake" "1"
"origin" "525 -232 504"
"angles" "-55 240 0"
"_light" "255 255 255 100"
"classname" "light_environment"
}

Отправлено Дядя Миша 12-10-2023 в 10:36:

Через diffuse_light и имитировал же.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-10-2023 в 10:39:

Дядя Миша
Дифузлайт даёт только один цвет, там у него три солнышка

Ну если ты сторонник таких костылей, то наверное ок...

Отправлено Crystallize 12-10-2023 в 10:41:

Цитата:

Дядя Миша писал:
Crystallize так а где твой эффект от пикселей скайбокса?

Отправлено Дядя Миша 12-10-2023 в 11:22:

Цитата:

FiEctro писал:
Ну если ты сторонник таких костылей, то наверное ок...

Так можно подумать рассеяние дневного света по полусфере как-то иначе делают. Только там не три солнышка, а 196.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-10-2023 в 11:24:

Ну вон в Юнити и одного достаточно, и для динамики работает

Отправлено Дядя Миша 12-10-2023 в 11:34:

Я рад за него.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Decay 12-10-2023 в 13:32:

Цитата:

Decay писал:
"_fake" "1"

А третье солнце это вообще info_sunlight перед компиляцией, специальное уточнение для освещения моделей

Отправлено Дядя Миша 12-10-2023 в 14:54:

Внедрил систему полностью динамического освещения. Пока что - без теней, только свет, тени это отдельная сложная тема, на неё сейчас просто нет времени, по плану идут совсем другие вещи. Но зато это освещение обладает высокой нагрузочной способностью. Как вы знаете в квейках обычно делают релайт, потому что нарисовать эту кучу лампочек в кадре очень затруднительно с приемлимым фпс. В XashNT это не составляет проблемы.
Слева статичное освещение (лайтмапа), справа полностью динамическое.

Добавлено 12-10-2023 в 17:54:

Перед выходом SDK надо сделать ещё три вещи:
1. то что я делал с освещением оформить в очередную демку и выложить вам напотестить.
2. набросать SampleSDK (игрок, ротатабля).
3. обновить документацию.

И наконец-то можно будет всё это пощупать извнутри, так сказать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-10-2023 в 15:18:

Дядя Миша
Для директ лайтов выглядит огонь Интересно потянет ли пентиум такое, хотя бы в 10фпс

Цитата:

Дядя Миша писал:
эту кучу лампочек в кадре очень затруднительно с приемлимым фпс.

Ну можно делать "допущения" как ты говорил мне. Например не все лампочки могут двигаться, и не всем лампочкам нужны тени. Правда в кваковских картах сложно будет без релайта это сделать. В этом и минус кармаковских карт, в том что освещение настроить можно только до компиляции геометрии. А так бы, можно было настраивать свет и объекты уже после компиляции.

Отправлено Дядя Миша 12-10-2023 в 15:48:

Цитата:

FiEctro писал:
Например не все лампочки могут двигаться, и не всем лампочкам нужны тени

Тени нужны всем лампочкам, а вот перерисовывать тени каждый кадр действительно излишне.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 12-10-2023 в 15:48:

Дядя Миша А ты юзаешь для динамики вот эти долбанутые квейковские формулы затухания и прочего?

Отправлено Дядя Миша 12-10-2023 в 16:03:

Цитата:

FiEctro писал:
в том что освещение настроить можно только до компиляции геометрии.

Нет, почему же. Настроил лайты, запустил компилятор с -onlyents.
Но это скорее обусловлено наличием лайтмапы. Сами лампочки на геометрию никак не влияют. Это скорее геометрия влияет на них - проверяется случай, если лампочка вдруг погрузилась в стену.
В кваке такое бывало иногда.

Добавлено 12-10-2023 в 18:54:

Цитата:

Crystallize писал:
А ты юзаешь для динамики вот эти долбанутые квейковские формулы затухания и прочего?

Я юзаю универсальную абстрактную формулу, которую задали в makebsp.def.
Т.е. как лампочки там настроены - то и попадает в динамику.
Впрочем это всё в шейдере, никто не запрещает отредатировать как угодно.

Добавлено 12-10-2023 в 18:55:

Цитата:

FiEctro писал:
Интересно потянет ли пентиум такое, хотя бы в 10фпс

Первый точно непотянет.

Добавлено 12-10-2023 в 18:59:

Ну да ладно, демку я вам выложу поиграетесь и сами всё увидите.
Возвращаемся к SDK.
SDK планируется две штуки. Первый - SampleSDK простейший, для понимания принципов. Абстрактный пример. Его я выложу вместе с первым релизом SDK.
И будет ещё BaseSDK, в котором будут энтити из XashXT, чтобы вы могли без проблем портировать свою игру. Этот будет делаться неспешно и обновляться тоже. Там слишком много кода.

Добавлено 12-10-2023 в 19:03:

SampleSDK будет для тех, кто привык писать вообще всё сам. Увидел пример, о, ротатабля, отлично! Много ли надо для счастья?

Добавлено 12-10-2023 в 19:03:

Лично у меня список щастья сформировался такой:
1. Бамп
2. Тени
3. Ротатабля
4. Шареная палитра

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-10-2023 в 16:39:

Цитата:

Дядя Миша писал:

Лично у меня список щастья сформировался такой:
1. Бамп
2. Тени
3. Ротатабля
4. Шареная палитра

А скайбокс то будет? Или только кваковское небо?

Отправлено Дядя Миша 12-10-2023 в 17:31:

Это настраивается пользователем. Можно загрузить и менять небо по команде с игрового кода. Т.е. движок в это не лезет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 12-10-2023 в 17:39:

А будет сглаживание TBN как у берсеркера в форке ку2?

Отправлено Aynekko 12-10-2023 в 18:25:

Цитата:

Дядя Миша писал:
перерисовывать тени каждый кадр действительно излишне.

Я надеюсь, это будет настраиваться? Не хотелось бы смотреть в 144 фпс на заторможенные 60 фпс тени.

__________________
Мой мод на Xash

Отправлено Дядя Миша 12-10-2023 в 19:34:

Цитата:

Crystallize писал:
А будет сглаживание TBN как у берсеркера в форке ку2?

Сглаживаются нормали, а по сглаженным нормалям уже генерируется сглаженный TBN. А сглаживание нормалей либо задаётся в makebsp.def, либо на карту ставится модель, где нормали уже сглажены в редакторе как надо.

Цитата:

Aynekko писал:
Я надеюсь, это будет настраиваться? Не хотелось бы смотреть в 144 фпс на заторможенные 60 фпс тени.

Я уже устал объяснять, что настраивается абсолютно всё. Как если бы у вас были исходники движка, но при этом приходилось писать в сотни раз меньше кода.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-10-2023 в 21:04:

Цитата:

Дядя Миша писал:
Сглаживаются нормали, а по сглаженным нормалям уже генерируется сглаженный TBN. А сглаживание нормалей либо задаётся в makebsp.def, либо на карту ставится модель, где нормали уже сглажены в редакторе как надо.

В сорсе вроде можно было сглаживать нормали на брашах
https://developer.valvesoftware.com...moothing_groups

и ещё настраивать скейл лайтмапы отдельно от текстуры.

Отправлено FiEctro 13-10-2023 в 06:55:

Цитата:

Дядя Миша писал:
Возвращаемся к SDK.

Кстати, а что с моделями? Если я захочу подгрузить модельки и собрать их с лайтмапой, что надо делать? Причем модельки могут быть весьма полигональными (около 50-100к трисов на модель) благо пока только статичные.
Я думаю одну сценку тебе портировать. Но боюсь твой движок набухнет от лимитов

Ну и да, сделай пожалуйста тени от солнышка, они будут нужны.

Отправлено Дядя Миша 13-10-2023 в 07:05:

Цитата:

FiEctro писал:
В сорсе вроде можно было сглаживать нормали на брашах

Можно. У меня тоже можно. Правда к сожалению пока только два кейса - настройка глобальная или настройка в материале. Либо моделька в которой нормали уже заранее сглажены как угодно. И тогда ставишь флажок - нормали не трогать.

Цитата:

FiEctro писал:
Если я захочу подгрузить модельки и собрать их с лайтмапой, что надо делать?

Ну перво-наперво надо сделать скайбокс. Без скайбокса не будет неба и не будет замкнутости уровня и солнце не будет светить. В этот скайбокс ставишь env_model или env_static - смотря как настроить энтить в makebsp.def, можешь создать новую, не принципиально.
Ну в принципе и всё.

Цитата:

FiEctro писал:
Причем модельки могут быть весьма полигональными (около 50-100к трисов на модель).

Весьма полигональные - это от двух миллионов и выше.
Да соберётся и лайтмапа тоже будет. И радиосити будет.

Добавлено 13-10-2023 в 10:05:

Цитата:

FiEctro писал:
и ещё настраивать скейл лайтмапы отдельно от текстуры.

В материале тоже можно такое, да. Причём скейл может быть даже меньше единицы, хотя это баловство. Уже на еденице тени чёткие как волюмы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 13-10-2023 в 07:20:

Цитата:

Дядя Миша писал:
Весьма полигональные - это от двух миллионов и выше.

Что это за моделька такая на 2 ляма? 0_о
Какая-нибудь елка, где каждая иголочка замоделена? )

Отправлено FiEctro 13-10-2023 в 07:30:

Цитата:

(_-=ZhekA=-_) писал:
Что это за моделька такая на 2 ляма? 0_о

Ландшафты некоторые так делают. Не очень оптимально в отличие от дисплейсмента, но больший контроль для художника. Например в нём дыры можно делать.

Цитата:

Дядя Миша писал:
Весьма полигональные - это от двух миллионов и выше.
Да соберётся и лайтмапа тоже будет. И радиосити будет.

Движок такое потянет? Модели резать не придётся? И что с разрешением текстур у таких моделей?

Отправлено (_-=ZhekA=-_) 13-10-2023 в 07:32:

Цитата:

FiEctro писал:
Ландшафты некоторые так делают. Не очень оптимально в отличие от дисплейсмента, но больший контроль для художника. Например в нём дыры можно делать.

2 ляма это очень много даже для ландшафта...

Отправлено FiEctro 13-10-2023 в 07:38:

(_-=ZhekA=-_)
В современном геймдеве регулярно срут моделями с говняной сеткой. И ландшафты это ещё самый невинный пример такой сетки. А мне просто лень делать ретопологию, и хочется поскорее перенести несколько моделей чтобы затестить.

Отправлено (_-=ZhekA=-_) 13-10-2023 в 07:55:

Цитата:

FiEctro писал:
А мне просто лень делать ретопологию, и хочется поскорее перенести несколько моделей чтобы затестить.

Для теста это понятно, там вообще похрен, а для релиза уже нужно делать по нормальному

Отправлено FiEctro 13-10-2023 в 08:00:

Цитата:

(_-=ZhekA=-_) писал:
а для релиза уже нужно делать по нормальному

Как говорил один известный в узких кругах геймдиз - нормально делай, нормально будет.

Отправлено Дядя Миша 13-10-2023 в 08:02:

Цитата:

(_-=ZhekA=-_) писал:
Что это за моделька такая на 2 ляма? 0_о

ну например - уровень моделькой.

Цитата:

FiEctro писал:
Движок такое потянет?

Всё зависит от суммарного полигонажа в кадре. Я ориентировался на пять миллионов полигонов, как достаточную величину для игр, типа сталкера.
Конечно, если натыкать тысячу ёлок и в каждой по два ляма - будет медленно.
В старой демке за январь 2022-го года была тестовая карта с Alyx где суммарно было 10 миллионов полигонов.

Цитата:

FiEctro писал:
Модели резать не придётся?

Зачем резать модели? Компилятор их сам порежет, как ему надо, сгруппирует по видимости, по материалам, по лайтмапе.

Цитата:

FiEctro писал:
И что с разрешением текстур у таких моделей?

А что с ним?

Цитата:

(_-=ZhekA=-_) писал:
2 ляма это очень много даже для ландшафта

Впервые вижу чтобы ты сказал слово "много". Обычно тебе всё мало да мало.

Добавлено 13-10-2023 в 11:02:

Цитата:

FiEctro писал:
нормально делай, нормально будет

Правильно говорил.

Добавлено 13-10-2023 в 11:02:

Цитата:

FiEctro писал:
и хочется поскорее перенести несколько моделей чтобы затестить.

Ну допустим ты затестил, тебе понравилось и чтожы? Бросишь всё и перейдешь на новый ксаш?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-10-2023 в 08:06:

Цитата:

Дядя Миша писал:
Ну допустим ты затестил, тебе понравилось и чтожы? Бросишь всё и перейдешь на новый ксаш?

Если он будет удовлетворять определенным моим потребностям. Я конечно не буду тебя ими особо грузить и заниматься фичекриперством. Но постараюсь дать любую информацию в силу своих возможностей. А там сам решай, надо оно или нет.

Отправлено Дядя Миша 13-10-2023 в 08:19:

Цитата:

FiEctro писал:
Если он будет удовлетворять определенным моим потребностям

Огласите весь список, пожалуйста

А я скажу, что уже есть, что планируется, а что нет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 13-10-2023 в 08:29:

Цитата:

Дядя Миша писал:
Впервые вижу чтобы ты сказал слово "много". Обычно тебе всё мало да мало.

Все приходит с опытом

Отправлено Crystallize 13-10-2023 в 09:00:

Цитата:

(_-=ZhekA=-_) писал:
Какая-нибудь елка, где каждая иголочка замоделена? )

Кстати именно так ёлки в Князе сделаны. По иголочке.

Отправлено FiEctro 13-10-2023 в 09:06:

Цитата:

Дядя Миша писал:
Огласите весь список, пожалуйста
А я скажу, что уже есть, что планируется, а что нет.

На самом деле у меня больше требований к инструментам нежели к движку.

И так редактор:

1. Должна быть какая то глобальная UI оболочка для IDE. Которая уже включает в себя разные инструменты. Если нужна помощь с UI - обращайся я наверстаю.

Другими словами ты запускаешь Editor.exe и у тебя все инструменты под руками, компиляторы, редактор карт, редактор кода, импортёр ресурсов, дебаггер и т.д.

2. Второй очень важный пункт, я бы даже сказал приоритетный - возможность как в Юнити запускать игру из редактора и синхронно отслеживать состояние объектов внутри самого редактора. Т.е. например игрок прошел 10 метров по карте внутри самой игры, и в редакторе он сделал тоже самое, проиграл все соответствующие анимации и т.д.

И наоборот если я пододвину игрока на 20 метров в редакторе, его автоматически пододвинет в том же направлении в игре.

3. Так же важно в том же редакторе была возможность отслеживать публичные и приватные значения объектов в реальном времени. Например я кодом заспавнил ящик, а в игре его нет. Ткнул на него в списке объектов и узнал его координаты. Ткнул ещё раз, камеру во вьюпорте к нему переместило.

Это касается не только игрок и его трансформов, а всех значений торчащих из скриптов. Так же очень желательно чтобы была возможность навесить несколько скриптов на один объект.

Т.е. теперь у нас вместо fgd парсятся просто переменные public или private прямо из скрипта подключенного к этому объекту. А энтития по сути и есть этот скрипт. Например func_door.шота

4. Профайлер менее в приоретете, но тоже очень желателен, не столько внутри игры, сколько в самом редакторе.

5. Менеджер ресурсов - возможность вставлять, удалять, перемещать, копировать, переименовывать файлы внутри самого редактора, а не в проводнике винды. Так же по возможности сделать превьюшки для моделей, материалов, текстур. Возможность там же выставить метаданные этому ресурсу и просмотреть его в обход всяких сторонних утилит прямо в редакторе.

6. Разделение ресурсов на исходник и формат движка. Т.е. у меня лежит например текстура wall.png, я открываю её в фотошопе, редактирую, сохраняю. А редактор тут же обновляет её, и пересохраняет для себя например в .dds.

7. Возможность навешивать объекты на кости скелета моделей.

8. Какой то простой редактор для вёрстки UI внутри игры и выводом эвентов чтобы их обрабатывать скриптом.

9. Аниматор который позволяет задать условия выполнения анимаций, скорости и смешивания их, и вывести в эвенты чтобы не писать каждый раз кодом новую систему (тут может быть непонятно, я чуть позже объясню).

10. Шейп кеи для моделей (морфинг).

11. Конфигуратор при старте редактора. Кнопка создать проект и в какую папку. Ну и список проектов. Запускаешь и у тебя уже всё настроено, не надо прописывать всякие идиотские гейм листы, фгд и пути к игре. Всё правильно сконфигурировано ещё при создании проекта.

Теперь по движку:

1. БСПшная физика хорошо синхронизированная с каким нить физическим движком аля физикс или ньютон. Всякие ригидбоди, колайдеры, трассы объёмными фигурами, физические материалы (статическое и динамическое трение), какой нить базовый плеер контроллер совместимый с ригидбодями, платформами, водичной, лесенками и т.д. Короче что то вроде того что в сорсе.

2. Навигационная сетка для NPC способная учитывать динамичиеские изменения (чтобы npc не шёл в закрытую дверь бесконечно)

3. Сейв реестор и плавные переходы между уровнями как в хл. Возможна поддержка асинхронной загрузки карт, когда ты можешь загрузить 2 бсп с объектами на одну сцену и плавно сменять их без экрана загрузки.

4. Максимальная гибкость в плане шейдеров. Чтобы можно было каждому материалу задать свой шейдер. А так же наследоваться уже от уже существующих.

5. Прозрачные текстуры с нормальной сортировкой, и адекватными тенями от них (что кстати не вывозит Юнити)

6. Красивый лайтмаппер и система динамического освещения (радиосити, тени, вот это всё).

7. Кубамапы, лайтпробы, зеркала, простенькая но красивая водичка, пбр.

8. Какую нить простенькую систему для пост эффектов с возможностью её переключать из скрипта во время игры

9. Динамическое небо с солнышком и облачками (можно спионерить из Юнити)

Это конечно самое базовое, хотя и без некоторых из этих пунктов тоже жить можно. Но я старался опираться на то что у тебя уже есть в планах, и тем вещам которые мне показались очень удобными в других движках (не только в Юнити, но и в Анриле, и Унигине).

Отправлено Дядя Миша 13-10-2023 в 09:54:

Цитата:

FiEctro писал:
Должна быть какая то глобальная UI оболочка для IDE. Которая уже включает в себя разные инструменты

Это само-собой. Я предполагаю сделать как глобальную оболочку, объединяющую разные инструменты, так и маленькие вспомогательные утилиты, которые смогут работать изолированно - например модельвьювер и менеджер архивов.

Цитата:

FiEctro писал:
все инструменты под руками, компиляторы, редактор карт, редактор кода, импортёр ресурсов, дебаггер и т.д.

Примерно так, да.

Цитата:

FiEctro писал:
возможность как в Юнити запускать игру из редактора и синхронно отслеживать состояние объектов внутри самого редактора

Сделать можно, но будет тормозить и какое при этом будет освещение...

Цитата:

FiEctro писал:
была возможность отслеживать публичные и приватные значения объектов в реальном времени

Вот это вообще не понял. Если мыслить концепциями той же халфы или сорса, какие там были публичные и приватные значения? Однако ящики спавнились исправно.

Цитата:

FiEctro писал:
Т.е. теперь у нас вместо fgd парсятся просто переменные public или private прямо из скрипта подключенного к этому объекту.

Ну может не совсем прямо так, может будет промежуточный кэш с автобилдом fgd-подобного файла, но да. Вручную туда вносить ничего не потребуется. Этот момент, я к слову могу попробовать сделать даже для Джека. Но не сейчас.

Цитата:

FiEctro писал:
А редактор тут же обновляет её, и пересохраняет для себя например в .dds.

Я предлагаю немного иную схему. Текстуры хранятся в исходниках, а потом перед релизом массово конвертируются в тот же DDS.

Цитата:

FiEctro писал:
Возможность навешивать объекты на кости скелета моделей.

На аттачменты же.

Цитата:

FiEctro писал:
Какой то простой редактор для вёрстки UI внутри игры и выводом эвентов чтобы их обрабатывать скриптом.

Базового UI нет. Может кто-нибудь создаст? Прямо на Шоте со скриптами.
Пока что я пишу для каждой игры свой собственный UI, не сказать, чтобы это прям было так сложно.

Цитата:

FiEctro писал:
Аниматор который позволяет задать условия выполнения анимаций, скорости и смешивания их, и вывести в эвенты чтобы не писать каждый раз кодом новую систему

Это всё только предстоит сделать, причём на Шоте. Я не знаю как лучше, поэтому не стал делать никакой базовой системы пока что.

Цитата:

FiEctro писал:
Шейп кеи для моделей (морфинг).

Так это больше к редактору моделей относится чем к движку. К блендеру, например.

Цитата:

FiEctro писал:
Запускаешь и у тебя уже всё настроено, не надо прописывать всякие идиотские гейм листы, фгд и пути к игре

Это да.

Цитата:

FiEctro писал:
БСПшная физика хорошо синхронизированная с каким нить физическим движком аля физикс или ньютон

Нет, физика своя. Никаких нутонов. К тому же предполагается, что физику пользователи сами пишут прямо на Шоте - это гораздо удобнее, чем объяснять тому же физиксу что ты от него хочешь (а он сопротивляется).

Цитата:

FiEctro писал:
Навигационная сетка для NPC способная учитывать динамичиеские изменения

Есть статичная сетка, есть возможность работать без сетки (как сейчас это делает QuakeNT), ну и совмещённый подход - по статичной геометрии через предрассчитанную сетку, а закрытые двери - в коде.

Цитата:

FiEctro писал:
Сейв реестор и плавные переходы между уровнями как в хл.

Уже есть. Правда пока толком не тестировалось - квака для этого не годится.

Цитата:

FiEctro писал:
Возможна поддержка асинхронной загрузки карт, когда ты можешь загрузить 2 бсп с объектами на одну сцену и плавно сменять их без экрана загрузки.

В принципе движок такое позволяет, но я пока толком не тестировал. Там есть одно важное ограничение - мир должен находится всегда с индексом 0. Не то чтобы это было критично, но надо продумать концепцию. А так уровней можно загружать сколько угодно, но они же сольются в единое пространство, и имена целей начнут мешать друг-другу. Навскидку.

Цитата:

FiEctro писал:
Максимальная гибкость в плане шейдеров. Чтобы можно было каждому материалу задать свой шейдер. А так же наследоваться уже от уже существующих.

Это есть. Но особо подчеркну, что все "уже существующие" материалы ты создаёшь сам. Нет материалов, которые требуются движку для работы и без которых он не может работать. Если удалить все материалы, движок просто не будет ничего рисовать.

Цитата:

FiEctro писал:
Прозрачные текстуры с нормальной сортировкой, и адекватными тенями от них

Сортировка есть, но её нормальность дело такое. Ты пойми что эта задача неразрешима в принципе, даже через OIT. Про тени пока ничего не скажу.

Цитата:

FiEctro писал:
Красивый лайтмаппер и система динамического освещения (радиосити, тени, вот это всё).

Лайтмаппер есть, реалтайм радиосити в будущем.

Цитата:

FiEctro писал:
Кубамапы, лайтпробы, зеркала

Нету, но потом добавлю бакэндом в материалы.

Цитата:

FiEctro писал:
Какую нить простенькую систему для пост эффектов с возможностью её переключать из скрипта во время игры

Это да, в планах. Сейчас нет вообще ничего подобного.
Ну если не считать постэффектами фейд экрана или его окрашивание в какой-то цвет.

Цитата:

FiEctro писал:
Динамическое небо с солнышком и облачками (можно спионерить из Юнити)

Это вы сами создаёте через Шот и систему материалов, я в это не лезу.

В движке абстрактный пайплайн, он почти ничего не знает и не вмешивается. Всё через data-driven материалы.
Там грубо говоря абстрактный цикл отрисовки батчей.

Добавлено 13-10-2023 в 12:54:

Перечитал написанное и вот что заметил. Ты мыслишь в рамках парадигмы движков, где почти всё намертво запилено в ядро и наружу торчат интерфейсы. Ксаш в этом плане предлагает иной подход - абсолютно всё можно написать самостоятельно. Однако он никого не заставляет это делать - рабочие SDK будут написаны мной лично. Но это всё будет в пользовательском ведении с возможностью отредактировать как угодно, снести полностью и написать своё. Движок содержит только абстракции, которые никогда не меняются и не требуют вмешательства.
Скажем детектор коллизий - это абстракция, куда пользователь не полезет никогда. Ну потому что принцип коллизии не предполагает каких-то там вариантов вообще. Тела не должны проваливаться, вот и всё.
А вот физическое поведение при столкновении может быть каким угодно.
Поэтому физика написана на Шоте, а не встроена куда поглубже.
Чтобы вы могли создавать новые типы физической симуляции или редактировать старые. Ну конечно какие-то тяжёлые симуляции, типа rigidbody я вынесу в ядро, но опять же - это будет абстракция без настроек, которая не меняется, т.к. потребности в том нет.

С профайлером пока не знаю. Помоему и так очевидно, что и когда будет тормозить - физика и поиск пути. Заспавнил сотни твёрдых тел - вот они и тормозят. Зачем тебе профайлер чтобы в этом убедиться?
Добавил в шейдеры бамп и параллакс - фпс упал. ну понятно что теперь выросла нагрузка на рендеринг. Опять же, что тебе скажет профайлер?

Может быть конечно в юнити тормозить начинают абсолютно неочвидные вещи, ну скажем заспавнил один ящик, а он как начал тормозить непонятно почему. Тогда да.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 13-10-2023 в 10:07:

Цитата:

Дядя Миша писал:
Помоему и так очевидно, что и когда будет тормозить - физика и поиск пути.

Совсем не очевидно рядовому юзеру.

Отправлено FiEctro 13-10-2023 в 10:15:

Цитата:

Дядя Миша писал:
Базового UI нет. Может кто-нибудь создаст? Прямо на Шоте со скриптами.
Пока что я пишу для каждой игры свой собственный UI, не сказать, чтобы это прям было так сложно.

Я могу попробовать наверстать тебе редактор, естественно если ты меня проконсультируешь по некоторым вещам. Но это будет только пустая оболочка, без логики. Естественно прежде я накидаю тебе макет, согласуем, а потому уже будем переносить на шоту.

Редактор UI по сути просто генерирует шота код, и отображает эти объекты на экране. Ну как html редактор в ворде.

Отправлено (_-=ZhekA=-_) 13-10-2023 в 10:17:

Цитата:

Дядя Миша писал:
Вот это вообще не понял. Если мыслить концепциями той же халфы или сорса, какие там были публичные и приватные значения? Однако ящики спавнились исправно.

Что-то типа этого )

https://drive.google.com/file/d/1kf...iS6j/view?t=16s

Отправлено ZGreen 13-10-2023 в 10:18:

Рядовые юзеры сели в ряд, ксаш скачали и давай рядовые игры пилить. Серьезно?

Отправлено FiEctro 13-10-2023 в 10:34:

Цитата:

Дядя Миша писал:
Сделать можно, но будет тормозить и какое при этом будет освещение...

Можно сделать галочку отключающую освещение, если уж совсем не удобно. Это куда лучше чем разрабатывать игру вообще вслепую.

Или сделать по другому. Запускать игру прямо внутри редактора, но со всеми гизмо и инпутами из редактора. А так же возможностью перейти во фри камеру. Тогда не надо будет 2 раза рендерить одно и тоже.

Цитата:

ZGreen писал:
Рядовые юзеры сели в ряд, ксаш скачали и давай рядовые игры пилить. Серьезно?

Тут кстати у Ксаша может быть хороший туз в рукаве. Это контент для голдсорса и сорса, который можно конвертировать в новый Ксаш. Как ДМ конвертировал первую кваку.

Добавлено 13-10-2023 в 13:34:

Цитата:

Дядя Миша писал:
Перечитал написанное и вот что заметил. Ты мыслишь в рамках парадигмы движков, где почти всё намертво запилено в ядро и наружу торчат интерфейсы. Ксаш в этом плане предлагает иной подход - абсолютно всё можно написать самостоятельно. Однако он никого не заставляет это делать - рабочие SDK будут написаны мной лично. Но это всё будет в пользовательском ведении с возможностью отредактировать как угодно, снести полностью и написать своё. Движок содержит только абстракции, которые никогда не меняются и не требуют вмешательства.
Скажем детектор коллизий - это абстракция, куда пользователь не полезет никогда. Ну потому что принцип коллизии не предполагает каких-то там вариантов вообще. Тела не должны проваливаться, вот и всё.
А вот физическое поведение при столкновении может быть каким угодно.
Поэтому физика написана на Шоте, а не встроена куда поглубже.
Чтобы вы могли создавать новые типы физической симуляции или редактировать старые. Ну конечно какие-то тяжёлые симуляции, типа rigidbody я вынесу в ядро, но опять же - это будет абстракция без настроек, которая не меняется, т.к. потребности в том нет.

Это старая парадигма Юнити когда всё закрыто. Сейчас они делают примерно так же, вырезают все фичи из движка, и делают их ввиде пользовательских открытых ассетов. К слову внутри редактора Юнити ты можешь написать свой редактор Юнити. Интерфейс там такой же модульный как окна в блендере.

Но речь не об этом, я про то чтобы была среда разработки с которой можно начать уже делать игру, а не писать самому среду разработки с нуля.

Отправлено Дядя Миша 13-10-2023 в 10:40:

Цитата:

ZGreen писал:
Рядовые юзеры сели в ряд, ксаш скачали и давай рядовые игры пилить. Серьезно?

А как надо?

Цитата:

FiEctro писал:
Сейчас они делают примерно так же, вырезают все фичи из движка, и делают их ввиде пользовательских открытых ассетов. К слову внутри редактора Юнити ты можешь написать свой редактор Юнити. Интерфейс там такой же модульный как окна в блендере.

Ну зашибись, зашли к нам на форум, прочитали и украли идею.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 13-10-2023 в 10:49:

Цитата:

Crystallize писал:
Кстати именно так ёлки в Князе сделаны. По иголочке.

Что за князь?

Отправлено Дядя Миша 13-10-2023 в 10:51:

Князь - это рок-группа такая, форк Короля и Шута.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-10-2023 в 10:55:

Цитата:

Дядя Миша писал:
Ну зашибись, зашли к нам на форум, прочитали и украли идею.

Не волнуйся, с одной концепции на другую они врядли быстро пересядут. К тому же сейчас у них вообще другие проблемы. Да и сомневаюсь что они ту же физику будут открывать. Да и что нам мешает подсматривать кое какие идеи у новых движков?

Хороший редактор это как упаковка, если потенциальный юзверь качает твой движок, запускает и не знает че с ним делать дальше, это беда.

Отправлено (_-=ZhekA=-_) 13-10-2023 в 11:03:

Цитата:

FiEctro писал:
Хороший редактор это как упаковка, если потенциальный юзверь качает твой движок, запускает и не знает че с ним делать дальше, это беда.

Ты, как будто скачал юнити - открыл и полетел создавать игру без уроков и туторов...

Отправлено FiEctro 13-10-2023 в 11:06:

Цитата:

(_-=ZhekA=-_) писал:
Ты, как будто скачал юнити - открыл и полетел создавать игру без уроков и туторов...

Ну во всяком случае я полетал по сценам, посмотрел как сделаны другие демки, позапускал их прямо внутри редактора и уже сформировал своё мнение о возможностях движка. А потом да, туторы.

А вот уже после Юнити я на Анрил и Унигине перескочил вообще без туторов. Там вся логика в интерфейсе схожая и это очень круто. Только потом когда начал ловить подводные камни пошёл в гугл.

Отправлено (_-=ZhekA=-_) 13-10-2023 в 11:17:

Цитата:

FiEctro писал:
Ну во всяком случае я полетал по сценам, посмотрел как сделаны другие демки, позапускал их прямо внутри редактора и уже сформировал своё мнение о возможностях движка. А потом да, туторы.

Кстати, да. Должны быть примеры, демки, которые запустил по юзал и оценил возможности движка \ фич, и чем их больше тем лучше

Я думаю, что демки и примеры играют большую роль при выборе движка

Отправлено Crystallize 13-10-2023 в 11:42:

Цитата:

(_-=ZhekA=-_) писал:
Что за князь?

Легенды Лесной Страны, русский клон Диабло.

Добавлено 13-10-2023 в 18:42:

Цитата:

ZGreen писал:
Рядовые юзеры сели в ряд, ксаш скачали и давай рядовые игры пилить. Серьезно?

Юзеру, т.е. человеку без опыта написания движков.

Отправлено FiEctro 13-10-2023 в 11:45:

Цитата:

(_-=ZhekA=-_) писал:
Кстати, да. Должны быть примеры, демки, которые запустил по юзал и оценил возможности движка \ фич, и чем их больше тем лучше Я думаю, что демки и примеры играют большую роль при выборе движка

Ты бы и другие пользователи тоже написали свои списки. Я думаю ДМ будет полезно в целом знать что люди ожидают от абстрактного игрового движка. Да и в целом самому интересно что Анрильщики ставят для себя в приоритет кроме графики.

Отправлено (_-=ZhekA=-_) 13-10-2023 в 12:12:

Цитата:

FiEctro писал:
Да и в целом самому интересно что Анрильщики ставят для себя в приоритет кроме графики.

Мне в анриле нравится, что он модульный ( состоит из плагинов ) и почти все не нужное можно отключить нахрен )

Блюпринты, конечно же

Сам едитор очень удобный и полностью кастомизируемый под себя

Что все в одном едиторе

Вся графика, физика есть из коробки, включил, что нужно и вася кот

Эпики предоставляют много примеров и демок для изучения

Собственный маркетплейс )

Сборка проекта под мобилку в пару кликов мыши

Ну, это если так на вскидку

Отправлено XaeroX 13-10-2023 в 12:29:

Цитата:

(_-=ZhekA=-_) писал:
Сам едитор очень удобный

Мне редактор анрила на всю жизнь запомнился тем, что там по хоткею Ctrl+S вместо сохранения создавался браш. Может, они что-то и поменяли впоследствии. Но первое впечатление - оно же самое важное.

__________________

Отправлено FiEctro 13-10-2023 в 12:36:

XaeroX
Кстати интересно тоже твоё мнение. Какими критериями ты руководствовался когда писал Волатилу и инструменты к ней?

Цитата:

(_-=ZhekA=-_) писал:
Сам едитор очень удобный и полностью кастомизируемый под себя

Объясни хоть чем он удобный, мы же не экстрасенсы. И поменьше смайликов если можно.

Отправлено (_-=ZhekA=-_) 13-10-2023 в 12:43:

Цитата:

FiEctro писал:
Объясни хоть чем он удобный, мы же не экстрасенсы.

Как я тебе это обьясню? Он для меня удобный, мне комфортно в нем работать, все на своих местах и ничего не бесит, а кому-то вообще может не зайти

Цитата:

FiEctro писал:
И поменьше смайликов если можно.

А чем тебе смайлы не угодили?

Отправлено ZGreen 13-10-2023 в 12:47:

Если мы говорим про четвертый и, наверное, пятый анрылы то там редактор и правда классный, въехать в базовый функционал сходу вышло, новый хаммер примерно по тем же принципам построен. А вот анрилед, который был с 2004 ут, я открыл, карту подправил, поплакал немного и закрыл. Субъективно, конечно.

Отправлено (_-=ZhekA=-_) 13-10-2023 в 13:02:

Цитата:

Crystallize писал:
Легенды Лесной Страны, русский клон Диабло.

В то время эта игра, как-то прошла мимо меня

Цитата:

ZGreen писал:
Если мы говорим про четвертый и, наверное, пятый анрылы

Ну, да именно про новые )

Цитата:

FiEctro писал:
Объясни хоть чем он удобный

Ну, вот один из примеров - легкий профайлинг значение переменной в пару кликов )

https://drive.google.com/file/d/1kf...iS6j/view?t=16s

Отправлено FiEctro 13-10-2023 в 13:03:

Цитата:

Вот есть у тебя код который например смещает объект по оси X на указанное пользователем значение. X это публичная переменная. Но там внутри например есть ещё оффсет O к примеру который умножает твоё значение допустим на 0.1, вот он приватный, его значение пользователь может подсмотреть в редакторе, но не может ручками отредактировать. А публичный и посмотреть и отредактировать прямо во время игры можно.

Естественно он не показывает вообще все не публичные переменные, а только те которые сериализует пользователь.

Цитата:

Дядя Миша писал:
В принципе движок такое позволяет, но я пока толком не тестировал. Там есть одно важное ограничение - мир должен находится всегда с индексом 0. Не то чтобы это было критично, но надо продумать концепцию. А так уровней можно загружать сколько угодно, но они же сольются в единое пространство, и имена целей начнут мешать друг-другу. Навскидку.

Очевидно что БСПшка сама по себе родительский объект - префаб. И имя этой БСПшки в целом можно плюсовать к дублирующимся именам. Но имей ввиду что как раз по этому поиск по имени вообще плохая идея и от неё всюду отказываются. У объектов на сцене должны быть свои уникальные идентификаторы и теги на которые ссылаются таргетнеймы. А так же поиск по чилдренам и парентам. Тогда ничего путаться не будет, даже если ты сто раз свой объект переименуешь.

Отправлено XaeroX 13-10-2023 в 13:09:

Цитата:

FiEctro писал:
Какими критериями ты руководствовался когда писал Волатилу и инструменты к ней?

Критерий очень простой - в движке должно присутствовать всё необходимое для разработки Perilous Warp и впоследствии Option Implicit. Документация на уровне "чтобы не забыть важные моменты" (хотя если что я всегда могу заглянуть в код и освежить память, конечно). Ну и хорошая интеграция с Джеком.
Ну ещё я посоветовался с народом на форуме по некоторым ключевым моментам, например, какие должны быть названия у энтитей, или нужен ли func_rotating из коробки. Это на случай, если кто-то потом захочет примкнуть к нашей команде.
Мне было проще - Волатила делалась по сути для одного разработчика, под нужды конкретных игр сейчас и в будущем. Несмотря на то, что разработка Option Implicit начнётся не ранее чем через 10-15 лет, я уже примерно знаю что там будет. Здесь же мы говорим про публичные продукты, которые к тому же должны давать большую гибкость, т.к. проекты на них заранее не известны.

__________________

Отправлено Дядя Миша 13-10-2023 в 13:22:

Цитата:

(_-=ZhekA=-_) писал:
Я думаю, что демки и примеры играют большую роль при выборе движка

Разумеется. Чем больше контента от авторов, тем легче соориентироваться.

Цитата:

FiEctro писал:
Я думаю ДМ будет полезно в целом знать что люди ожидают от абстрактного игрового движка

https://hlfx.ru/forum/showthread.ph...6236#post216236
Обещал расписать через пару часов - до сих пор жду.

Цитата:

(_-=ZhekA=-_) писал:
Мне в анриле нравится, что он модульный ( состоит из плагинов ) и почти все не нужное можно отключить нахрен )

Это как винда. Там тоже после установки почти всё надо выключить нахрен.

Добавлено 13-10-2023 в 16:22:

Цитата:

FiEctro писал:
Вот есть у тебя код который например смещает объект по оси X на указанное пользователем значение. X это публичная переменная. Но там внутри например есть ещё оффсет O к примеру который умножает твоё значение допустим на 0.1

Ужос какой

Ты же видел энтити в кваках халфах. Там нигде нет такого "сместить объект по оси X на указанное пользователем значение". Разумеется такой объект можно сделать, но какой в этом смысл? Вот у тебя место старта игрока, вот монстр, вот аптечка, вот триггеры. Где в этой схеме специальный код, который смещает объект по оси Х на указанное пользователем значение и главное зачем?
Даже тетрис делать удобнее, создав для фигурок абстрактную физику, а не двигая каждую фигурку на определённое число юнитов.

Цитата:

FiEctro писал:
Но имей ввиду что как раз по этому поиск по имени вообще плохая идея и от неё всюду отказываются

Глупость какая. А чегож код тогда не пишут, записывая вместо имён переменных специальные тэги? Когда у тебя имя ты можешь легко даже в блокноте посмотреть что к чему. Когда у тебя тэг, ты без редактора не разберёшься. А редактор платный. Ну и приехали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-10-2023 в 13:25:

Цитата:

Дядя Миша писал:
https://hlfx.ru/forum/showthread.ph...6236#post216236
Обещал расписать через пару часов - до сих пор жду.

Окей попинаю

Цитата:

Дядя Миша писал:
Ужос какой
Ты же видел энтити в кваках халфах. Там нигде нет такого "сместить объект по оси X на указанное пользователем значение". Разумеется такой объект можно сделать, но какой в этом смысл? Вот у тебя место старта игрока, вот монстр, вот аптечка, вот триггеры. Где в этой схеме специальный код, который смещает объект по оси Х на указанное пользователем значение и главное зачем?
Даже тетрис делать удобнее, создав для фигурок абстрактную физику, а не двигая каждую фигурку на определённое число юнитов.

Оно есть в коде. Я просто привёл пример сериализованых в интерфейс приватных и публичных переменных. Такой объект ничем не отличается от твоих аптечек и монстров кроме внутренней логики. Но тут речь была не о логике, а о переменных.

Цитата:

Дядя Миша писал:
Глупость какая. А чегож код тогда не пишут, записывая вместо имён переменных специальные тэги? Когда у тебя имя ты можешь легко даже в блокноте посмотреть что к чему. Когда у тебя тэг, ты без редактора не разберёшься. А редактор платный. Ну и приехали.

В коде у тебя используются неймспейсы чтобы ничего не конфликтовало это теже самые теги. И ничего - разбираются как то. Причём тут платный редактор я вообще не понял, блокнот в винде бесплатный.

Отправлено (_-=ZhekA=-_) 13-10-2023 в 13:29:

Цитата:

Дядя Миша писал:
Это как винда. Там тоже после установки почти всё надо выключить нахрен.

Один раз отключил и все, а можно вообще ничего не трогать и будет норм )

Отправлено Дядя Миша 13-10-2023 в 13:35:

Цитата:

FiEctro писал:
Такой объект ничем не отличается от твоих аптечек и монстров кроме внутренней логики.

Не помню чтобы мне хоть раз понадобилось смотреть внутренние стейты аптечек. Опять же, если у тебя объект подчиняется физическим законам, то ты уже не видишь что там физикс с ним делает, ты видишь только конечный результат его работы.

Цитата:

FiEctro писал:
В коде у тебя неймспейсы это теже теги

Неймпсейс в читабельном виде. А ты говоришь там вместо имён давно MD5 чексуммы или что-то вроде этого.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-10-2023 в 13:38:

Цитата:

Дядя Миша писал:
Неймпсейс в читабельном виде. А ты говоришь там вместо имён давно MD5 чексуммы или что-то вроде этого.

Ну так у тебя прописано в коде:

public GameObject koshka;

Вот koshka это и есть имя твоей переменной. А в редакторе уже просто дрегднропом кидаешь твой объект в поле koshka и он записывает в него чексумму.

Цитата:

Дядя Миша писал:
Не помню чтобы мне хоть раз понадобилось смотреть внутренние стейты аптечек. Опять же, если у тебя объект подчиняется физическим законам, то ты уже не видишь что там физикс с ним делает, ты видишь только конечный результат его работы.

А если эта аптечка даёт разное ХП в зависимости от того какой бонус ты взял

? Нет ну ты конечно можешь написать Debug.Log(hp); Но как много таких параметров ты можешь вытащить в консоль? И какое мессево это будет? Если например у тебя 100 аптечек?

Отправлено Дядя Миша 13-10-2023 в 13:52:

Цитата:

FiEctro писал:
А если эта аптечка даёт разное ХП в зависимости от того какой бонус ты взял

Как правило такие аптечки визуально отличаются.

Цитата:

FiEctro писал:
public GameObject koshka;

Прям вот так и прописано? И что это значит?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Decay 13-10-2023 в 14:11:

По поводу вывода информации — в GTA III была такая вещь в отладочном скрипте (17:35)
https://youtu.be/tpP4kKCeNew?t=1055

А в source есть такая энтити point_message, мы могли наблюдать их в большом количестве на картах в HL2 Beta. Такие записки, что в конкретном месте нужно будет сделать.

Предполагаю что была бы возможность делать такой привязанный текст, там уже каждый решал бы, как это использовать.
А может в уже имеющейся системе пользователю реально смастерить такое?

Отправлено FiEctro 13-10-2023 в 14:46:

Цитата:

Дядя Миша писал:
Прям вот так и прописано? И что это значит?

Ну вместо koshka может быть любое называние переменной. Это означает что в UI редактора в объекте на котором весит твой скрипт создастся поле koshka куда ты мышкой можешь засунуть любой объект, ну или выбрать из выпадающего списка.
И никакое fgd тут не нужно.

Допустим у тебя вместо кошки написано:
public GameObject targetname;

В инспекторе ты положил свой объект в поле targetname.
Теперь ты из этого скрипта где объявлен public GameObject targetname; можешь обращаться к нему, например к тем же трансформам.

targetname.transform.position.x += 1;

И соответственно это сместит при выполнении скрипта объект цель на 1 метр по оси X.

Или наоборот ты хочешь узнать его координаты:

Vector3 targetcords = targetname.transform.position;

А внутри сцены например будет записано:
obj:12:1
{
component = myscript.shot;
{
targetname = obj23:5:3;
}
}
где к примеру obj:12:1 и obj23:5:3; могут быть позицией в иерархии, но не обязательно. Любые метаданные. Естественно если пользователь перемещает объекты в иерархии то ссылка тоже обновляется редактором автоматически.

Отправлено Дядя Миша 13-10-2023 в 14:46:

А если я ещё одну кошку хочу поставить на уровень. Мне надо создать объект с именем koshka2 ?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-10-2023 в 14:50:

Цитата:

Дядя Миша писал:
А если я ещё одну кошку хочу поставить на уровень. Мне надо создать объект с именем koshka2 ?

Нет. Эти объекты могут быть с одним именем но с разными метаданными.

Т.е. если ты продублируешь твой объект с тем же самым скриптом ты уже в поле targetname можешь вписать другой объект или тот же самый, при том исходный объект не сломается и будет функционировать так же как и раньше. В итоге у тебя будет 2 объекта кошки со своими разными параметрами.

Отправлено Дядя Миша 13-10-2023 в 15:10:

Цитата:

FiEctro писал:
с одним именем но с разными метаданными

А где хранятся метаданные?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-10-2023 в 15:52:

Цитата:

Дядя Миша писал:
А где хранятся метаданные?

Там же где и объекты. Внутри сцены, префабов и бандлов. А энтития это просто компонент (скрипт) привязываемый к объекту. У тебя же есть викинги демка, запусти редактор да посмотри как всё устроено.

Отправлено Дядя Миша 13-10-2023 в 16:27:

Нет, я её сразу же удалил. Да и что там на тех викингах смотреть? Там игрок и две ротатабли.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-10-2023 в 17:41:

C++ Source Code:

1	using UnityEngine;

3	public class ObjectCopier : MonoBehaviour

5	public GameObject objectToCopy; // Указать объект, который вы хотите скопировать

7	void Start()

9	if (objectToCopy != null)

11	for (int i = 0; i < 10; i++) // Создать 10 копий объекта

13	Vector3 spawnPosition = new Vector3(i * 10f, 0f, 0f); // Смещаем каждую копию на 10 единиц по оси X

14	GameObject copiedObject = Instantiate(objectToCopy, spawnPosition, Quaternion.identity);

15	// Quaternion.identity означает, что копии будут иметь тот же поворот, что и оригинал

    else

20	Debug.LogError("Объект для копирования не указан!");

Вот пример в Юнити когда мы берём скриптом какой нибудь объект и копируем его со смещением.

Отправлено Дядя Миша 13-10-2023 в 18:51:

Фигово, что в шарпе, там где по смыслу достаточно функции приходится городить класс.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-10-2023 в 19:24:

Дядя Миша
А у тебя энтитя это метод?

Отправлено Дядя Миша 13-10-2023 в 19:28:

Нет, класс. Да скоро сам увидишь всё.
Просто то что ты привёл - явно не требует никаких классов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-10-2023 в 19:30:

Дядя Миша
Ну я просто шаблон привёл тебе. Такие скрипты и использует Юнити вместо энтитей. Наполнение может быть разным. Например туда можно засунуть игрока или генерацию уровня аля майныч.

Ну вот что то более приближенное к жизни:
https://github.com/atil/fpscontroll...psController.cs

Энтития игрока.

Отправлено Дядя Миша 13-10-2023 в 20:03:

И что каждый раз писать [SerializeField] вот это?

А это ещё что такое - #region Drag Drop?

Меня к слову здорово разраждает вот эта необходимость напротив каждой переменной писать private или public. Да возможно секции выглядят не так красиво, как модификаторы, но вопрос удобства же. Явно что тот, кто это придумал, сам писать на языке не планировал. Другим подляну сделал.
Ничем другим это объяснить невозможно. Да и Степанов, который динамический массив зачем-то вектором обозвал, тоже свинью подложил.

У меня это всё устроено не так. Есть класс. Он не наследуется ни от чего. Но тем не менее неявным образом связан с движком. Это поведение легко отменить перегрузив оператор new. Например для объектов, в которые движок лезть не должен - элементы меню или худа. Или какие-то вспомогательные объекты, которые не являются частью игры.
Поскольку объект ни от чего не наследуется, встаёт вопрос, а как же движок с ним общается? Очень просто - нужные переменные подключаются к свойствам (properties) с особым именем. Свойства в шоте имеют имена заключенные в двойные кавычки, благодаря чему и становится возможным объявлять имена, недопустимые с точки зрения синтаксиса самого языка.
При этом, разумеется внутри программы обратится к таким свойствам невозможно (да и не нужно) - это метки для бакэнда.
Приведу примеры:
"event.origin" - сюда мы цепляет ссылку на позицию объекта
"event.transform" - а здесь ссылка на матрицу объекта

В принципе таковых полей не очень много - до десятка. Движку это не особенно нужно. Аналогичным образом передаются и свойства в материалы. Разумеется свойства можно использовать и внутри кода, это просто удобный механизм для разных нужд.
Сериализация устроена наоборот - по умолчанию сохраняется вообще всё. Иногда что-то сохранять не требуется - напротив такой переменной прописывается _declspec( "transient" ) но это редкость.
Публичные поля (те, которые приходят из настроек энтити) описываются свойствами "field.origin" "field.angles" итд. Т.е. только то, что мы хотим загружать. В каком-то смысле соответствует вот этим твоим "Public Header" или что-то вроде. Но повторюсь - легально движок вообще не лезет в переменные ни под каким предлогом (хотя без проблем и может). Только через свойства, обозначенные пользователем.
Для отладки бакэнд может вторгаться в любые зоны объекта, но только непосредственно по команде пользователя. Это чисто отладочный режим.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-10-2023 в 20:18:

Цитата:

Дядя Миша писал:
И что каждый раз писать [SerializeField] вот это?

Это если ты хочешь вывести значения приватной переменной в инспектор. А так то оно действительно не будет иметь смысла. Если переменная публик то никаких [SerializeField] писать не надо.

Цитата:

Дядя Миша писал:
А это ещё что такое - #region Drag Drop?

Это приколы новых вижуал студий, к Юнити не имеет отношения. Типа чтобы свернуть блок кода можно было, либо для поиска.

Цитата:

Дядя Миша писал:
"event.origin" - сюда мы цепляет ссылку на позицию объекта
"event.transform" - а здесь ссылка на матрицу объекта

Непонятно, откуда у эвента оригин и трансформы?

Отправлено Дядя Миша 13-10-2023 в 20:22:

Это просто неймспейс так называется - event.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-10-2023 в 20:35:

Я так понял первое с чего нужно писать СДК это с редактора кода с подсказками

Цитата:

Дядя Миша писал:
Да и Степанов, который динамический массив зачем-то вектором обозвал, тоже свинью подложил.

А это кто и где?

Отправлено Дядя Миша 13-10-2023 в 20:36:

Цитата:

FiEctro писал:
А это кто и где?

Автор STL.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 14-10-2023 в 09:14:

Вышло обновление QuakeNT, подробности в телеграм-канале.
Приступаю к созданию SampleSDK. Тут ещё вот какой момент - с удалением дллки на С++ из движка, мне стало не под чем тестировать статичную геометрию. Ну то есть можно под библиотекой кваки, но это неудобно, она будет спамить ошибками. А вот SampleSDK для таких целей отлично подойдет. Что именно в него будет включено - вопрос открытый.

Пока что я вижу эту следующим образом:

1. Минимальный худ, который показывает кол-во здоровья
2. Минимальное меню с тремя пунктами - New Game, Settings, Quit.
В настройках смена режима разрешения и яркости.
3. Код перемещения игрока
4. итем_аптечка
5. триггер
6. дверь

Монстров вставлять не планирую пока что. Вроде как в сэмплах от тех же Юнити-Унреала их тоже нету.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 14-10-2023 в 09:54:

Цитата:

Дядя Миша писал:
2. Минимальное меню с тремя пунктами - New Game, Settings, Quit.
В настройках смена режима разрешения и яркости.

А как же Save \ Load game и настройки графики?

Цитата:

Дядя Миша писал:
5. триггер

И еще триггер, который отнимает и добавляет здоровье, чисто для примера.
Так же можно добавить разные кнопки, которые включают свет \ двери, например )

Цитата:

Дядя Миша писал:
Монстров вставлять не планирую пока что. Вроде как в сэмплах от тех же Юнити-Унреала их тоже нету.

Смотря какие примеры есть и с монстрами и с оружием )

Отправлено Дядя Миша 14-10-2023 в 10:03:

Цитата:

(_-=ZhekA=-_) писал:
А как же Save \ Load game и настройки графики?

Можно и это. Я ж говорю - предлагайте.

Добавлено 14-10-2023 в 13:03:

Но без фанатизма. Ибо каждое предложение потенциально отодвигает выход SDK во времени.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 14-10-2023 в 10:17:

Цитата:

Дядя Миша писал:
Но без фанатизма. Ибо каждое предложение потенциально отодвигает выход SDK во времени.

Ну, тогда сделай, что хотел и выпусти пока так, а потом со-временем дополняй и все

А публичные релизы то вообще буду?

Отправлено Дядя Миша 14-10-2023 в 10:27:

Цитата:

(_-=ZhekA=-_) писал:
А публичные релизы то вообще буду?

Пока ничего определённого сказать не могу. Если и будут, то весьма нескоро.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 15-10-2023 в 10:28:

В кваке был такой удивительный баг, когда некоторые дохлые монстры на опускающейся платформе вдруг начинали двигаться нетолько вниз (вслед за платформой) но и куда-то резко вбок.
При том, что не все были этому подвержены, но в игровых ситуациях встречались именно те, которые ехали. Например в конце e1m3 вы подымаетесь на лифте и есть вероятность, что убитые демоны на нём же и останутся. И когда лифт начнёт опускаться вниз, эти самые демоны куда-то поедут влево, вправо~~, в потолок~~. Причём в разные стороны.
А разгадка проста - демоны прыгают через velocity. Дохлый монстр получает флаг FL_ONGROUND, но его велосити - не обнуляется. А платформа обнуляет FL_ONGROUND и монстр в полном соответствии с остатками энергии прыжка начинает ехать не только вниз, но и туда, куда он прыгал.
Исправить этот баг очень легко - достаточно обновить pev->velocity в функции MonsterKilled.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 15-10-2023 в 13:42:

Цитата:

Aynekko писал:
Я надеюсь, это будет настраиваться? Не хотелось бы смотреть в 144 фпс на заторможенные 60 фпс тени.

Так у тебя не будет реальных 144фпс, геометрия будет обновляться в 60 фпс.

Отправлено Aynekko 15-10-2023 в 15:01:

Цитата:

Crystallize писал:
геометрия будет обновляться в 60 фпс.

По этому поводу я писал выше
https://hlfx.ru/forum/showthread.ph...6497#post216497
Ну это плохое решение.

__________________
Мой мод на Xash

Отправлено Crystallize 15-10-2023 в 15:25:

Aynekko Ну NT всё ещё предназначается для начинающего разработчика, а ~~дедушка старый~~ ему всё равно.

Отправлено Aynekko 15-10-2023 в 15:30:

Не вижу связи с "начинающим разработчиком" и 60 фпс

__________________
Мой мод на Xash

Отправлено Дядя Миша 15-10-2023 в 16:01:

Пока нет сети, организацию игровой петли трогать не буду.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 15-10-2023 в 17:48:

Цитата:

Aynekko писал:
Не вижу связи с "начинающим разработчиком" и 60 фпс

Начинающему хотя бы код заставить работать и контента понакидать, все эти высокие фреймрейты-это уже что-то элитарное.

Отправлено ZGreen 15-10-2023 в 18:06:

Правда там написано то, что я прочитываю? Элитарные фреймрейты?

Отправлено Aynekko 15-10-2023 в 19:08:

Цитата:

Crystallize писал:
все эти высокие фреймрейты-это уже что-то элитарное

Я понимаю, что ты имеешь в виду, но морока с объектами, кодом и прочим, и визуальное восприятие, это как бы разные вещи.

__________________
Мой мод на Xash

Отправлено MrThomasCooper 16-10-2023 в 15:24:

Дядя Миша а в каком состоянии находится твой конвертор уровней из сталкера? А то тут обнаружилась неплохая локация для стресс-теста.
https://ap-pro.ru/forums/topic/4023-zhivaya-zona-obt/

Отправлено Дядя Миша 16-10-2023 в 15:55:

Цитата:

MrThomasCooper писал:
а в каком состоянии находится твой конвертор уровней из сталкера?

В исправном. Я его даже научил конвертить турбо-мега-большие уровни из Alone In Winter или как там она называется.

Цитата:

MrThomasCooper писал:
А то тут обнаружилась неплохая локация для стресс-теста.

Не, памяти на лайтмапы не хватит. OpenXRay-то 64-х битный.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 17-10-2023 в 10:14:

Вот кстати какая мысль ещё мне пришла в голову. Для тех у кого логает там где логать не должно - попробуйте поиграться с кваром gl_finish.

Добавлено 17-10-2023 в 12:54:

И ещё. Попробуйте gl_vsync -1
Не один, а именно минус один.

Добавлено 17-10-2023 в 13:14:

Я тут разгребаю код инициализации OpenGL-подсистемы, там очень много залежей накопилось ещё с конца нулевых. Так что может и уйдут ваши лаги.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ZGreen 17-10-2023 в 12:05:

То есть что это получается? Я зря трес компьютор?

Отправлено Дядя Миша 17-10-2023 в 12:10:

Цитата:

ZGreen писал:
Я зря трес компьютор?

смотрит на часы
ПАКА НЭИЗВЭСТНО!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 17-10-2023 в 12:38:

Цитата:

Дядя Миша писал:
попробуйте поиграться с кваром gl_finish.

Цитата:

Дядя Миша писал:
И ещё. Попробуйте gl_vsync -1
Не один, а именно минус один.

Объясни хоть что это значит?

Отправлено Дядя Миша 17-10-2023 в 14:03:

Ну вы же жалуетесь на лаги неодолимые. Я и предлагаю поиграцца.
Может поможет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-10-2023 в 06:11:

Цитата:

Дядя Миша писал:
Вот кстати какая мысль ещё мне пришла в голову. Для тех у кого логает там где логать не должно - попробуйте поиграться с кваром gl_finish.

И ещё. Попробуйте gl_vsync -1
Не один, а именно минус один.

Я тут разгребаю код инициализации OpenGL-подсистемы, там очень много залежей накопилось ещё с конца нулевых. Так что может и уйдут ваши лаги.

Мне никак не помогло. gl_vsync -1 ограничивает фпс до 60 что не имеет смысла в этом контексте, а gl_finish ничего не делает.

Отправлено Дядя Миша 21-10-2023 в 09:55:

Сделал большую ревизию для кода создания OpenGL окна и обработчика движения мышы. Код там не менялся со времён Xash3D, был бардак какой-то непонятный. Куча ненужного устаревшего кода, который вообще непонятно как работал. В связи с этим также изменились скриптовые API, стали более целостными, поэтому демки, которые выкладывал уже несовместимы с будущей версией - каллбэки поменялись. Ну ничего, каллбэков немного, и я не планирую их всё время трогать, это просто сейчас идёт процесс окончательного устаканивания. А вот новые API, доступные из скриптового языка будут добавляться новые, на совместимость это никак не повлияет.
К тому же в движке есть встроенное средство тестирования функций и интерфейсов, позволяет убедиться что это всё есть в наличии, прежде чем вызвать.
SampleSDK для начала будет совсем простейший, но даже в таком варианте он содержит порядочно кода.
Меню состоит из двух подменю:
1. Подменю выбора карт для запуска
2. Подменю смены разрешения экрана
3. Кнопка выхода из игры (в Unity как мы помним по дефолту не было даже этой кнопки).
Клиентская часть обрабатывает нажатые игроком кнопки и отсылает их биты на сервер, а так же считает ректангл вьюпорта и fov игрока.
Серверная часть содержит в себе ворлдспаун, объект игрока и точку его старта.
В принципе этого достаточно, чтобы бегать и летать по статичной геометрии, например по картам из того же сталкера.
И достаточно для изучения кода, чтобы сформировать минимальное представление о том, как это всё работает. В таком виде оно и будет выложено для первого знакомства. Дальше возможны варианты - либо я сам добавлю туда для примера двери-аптечки, пушку в руках, либо вы прекрасно справитесь и без меня с этим. В любом случае SampleSDK для каких-то серьезных задач не предназначен, это просто минималка для запуска. Для разработки игр будет написан BaseSDK с объектами из XashXT, ну я уже говорил об этом.
Так же вам будут доступны исходники Квейк-Римейка да и любой другой из игр, которые я впоследствии планирую портировать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-10-2023 в 10:57:

Дядя Миша
Насколько Шота будет совместим с современными вижуал студиями и будет ли файл проекта для более удобной работы с проектом? Ибо писать код в блокноте врядли кто то захочет, особенно новички.

Отправлено Дядя Миша 21-10-2023 в 12:22:

Я никогда не работал в современных визуал-студиях, ничего не могу сказать.
Но там же вроде бы теперь есть возможность подключения плагинов, для поддержки разных специфических вещей? К примеру я слышал вроде бы есть плагин для написания GLSL.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-10-2023 в 12:36:

Дядя Миша
Да есть, но их написание тоже требует определенной компетенции. Как минимум очень хорошего знания твоего языка. А уж парсить свои собственные файлы проекта это вообще кошмар. Уж лучше использовать то что есть, и при возможности немного подправить чем изобретать велосипед с нуля, а потом ещё как то и всё это поддерживать.

Лучше всего рекомендую ознакомиться с VS Code он более легковесный чем студия, кроссплатформенный и более дружелюбный к плагинам, и полностью бесплатный. Правда с WinXP могут быть проблемы, как вариант можно попробовать эту старую версию (https://code.visualstudio.com/updates/v1_14) но я хз заведётся или нет, я не проверял.

https://ru.wikipedia.org/wiki/Visual_Studio_Code

Отправлено Дядя Миша 21-10-2023 в 14:03:

Цитата:

FiEctro писал:
Как минимум очень хорошего знания твоего языка

Ты намекаешь что я свой язык знаю не очень хорошо?

Цитата:

FiEctro писал:
Правда с WinXP могут быть проблемы

Я уйду с XP как только будет готов редактор. Я там реализую всё то, чего мне собствено и нужно для работы.

Добавлено 21-10-2023 в 16:51:

А вот скажите товарищи, такой вопрос. Вас же не смутит, что в SampleSDK будет довольно много кода и файлов?
Не так чтобы один файл на три строчки, хелловорлд.

Скажем игровой код будет килобайт 100 весить суммарно в разных файлах.
Я бы конечно мог это всё максимально ужать, чтобы пример вообще невозможно было расширять и переиспользовать, но не думаю, что это хорошая затея.

Добавлено 21-10-2023 в 16:51:

Или как лучше сделать?

Добавлено 21-10-2023 в 17:03:

Давайте я вам озвучу свои планы, касательно того, что именно я планирую написать\портировать на Шот из игрового кода. Не в порядке приоритетов, а просто, как вспомню~~так вздрогну~~.

Quake 1 - собственно уже портирован. Осталось только отшлифовать.
Quake 2 - скорее всего уже в этом году.
BaseSDK - некий собирательный образ из энтить халфы, ксаш-мода и паранои. Базовый SDK для XashNT на основе которого можно делать ваши игры, добавляя недостающее. Ориентировочно зима2023 - весна2024.
Doom - помните я говорил что римейк Doom доделаю на XashNT? Ну там немного работы, по большей части надо просто портировать порт.
MIR - используя BaseSDK
Paranoia - используя BaseSDK
Paranoia 2:Savior - используя BaseSDK

Это из того, что запланировано точно. Теперь из вероятного-частичного.
Quake3 - скорее всего без ботов или боты не будут на 100% себя вести как в оригинале.
Unreal Tournament 99 - это моя личная хотелка, которую или за меня сделает кто-нибудь ещё или я доберусь до нее на пенсии.
Half-Life 2 - ну тут может Crystallize займется, как я понял ему интересно.

Очень может быть что для вероятного я вообще никакой код писать не буду, а ограничусь только написанием экспортёров в форматы, понятные новому Ксашу. Но вот то что выше - это включено в roadmap.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-10-2023 в 14:30:

Цитата:

Дядя Миша писал:
Ты намекаешь что я свой язык знаю не очень хорошо?

Ну если ты сам сделаешь плагин то ни на что не намекаю. А вот если его будут пытаться делать другие люди может получиться сломанный телефон.

Цитата:

Дядя Миша писал:
Я уйду с XP как только будет готов редактор. Я там реализую всё то, чего мне собствено и нужно для работы.

Ну ты попробуй ту версию что я скинул, может ничего и не придётся.

Цитата:

Дядя Миша писал:
Скажем игровой код будет килобайт 100 весить суммарно в разных файлах.
Я бы конечно мог это всё максимально ужать, чтобы пример вообще невозможно было расширять и переиспользовать, но не думаю, что это хорошая затея.

Я думаю его просто по папкам надо расфасовать, у пользователя в проекте это папка Assets, для редактора скрипты в папке Editor, для бекенда Library. Ну тоесть всё максимально модульное. Плюс если ты всё удалишь кроме папки Assets то движок тебе всё восстановит в проекте. Это нужно на случай если там что то сломалось или повредилось.

Ты можешь где то внутри движка сделать что то вроде ToolAssets.pak куда ложить файлы необходимые для работы СДК, но при создании проекта его просто распаковывать в папку с проектом. Почему сразу не подгружать из архива спросишь ты? Да малоли может кто то свою версию захочет сделать

Цитата:

Дядя Миша писал:
Давайте я вам озвучу свои планы, касательно того, что именно я планирую написать\портировать на Шот из игрового кода. Не в порядке приоритетов, а просто, как вспомнютак вздрогну.

Это уже не актуально, к тому же всё однотипное кроме разве что СДК и Паранойи, и с натяжкой хл2. А что можно протестировать на первой кваке или первом дууме? Да и моддеры этих игр врядли пересядут, ибо им важна кроссплатформенность и опенсорц.

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

Отправлено Дядя Миша 21-10-2023 в 14:57:

Актуально - не актуально, вопрос так не стоит. Сейчас идёт активное бета-тестирование платформы и лучше всего это делать на готовых и хорошо изученных ресурсах.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 21-10-2023 в 15:08:

А что можно протестировать в первом дууме? Спрайтовых монстров?
Мне кажется логичнее брать игры где есть материалы.

Отправлено Crystallize 21-10-2023 в 15:18:

Цитата:

Дядя Миша писал:
Half-Life 2 - ну тут может Crystallize займется, как я понял ему интересно.

Код адаптировать? Перегонять те же модельки из вальвовских форматов?

Отправлено Дядя Миша 21-10-2023 в 15:37:

Цитата:

FiEctro писал:
А что можно протестировать в первом дууме? Спрайтовых монстров?

Например да.

Цитата:

FiEctro писал:
Мне кажется логичнее брать игры где есть материалы.

Для тестирования материалов хватит ворлдспауна и игрока, т.е. SampleSDK.

Цитата:

Crystallize писал:
Код адаптировать?

Ага.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 22-10-2023 в 09:19:

Цитата:

Дядя Миша писал:
Quake 1 - собственно уже портирован. Осталось только отшлифовать.
Quake 2 - скорее всего уже в этом году.
BaseSDK - некий собирательный образ из энтить халфы, ксаш-мода и паранои. Базовый SDK для XashNT на основе которого можно делать ваши игры, добавляя недостающее. Ориентировочно зима2023 - весна2024.
Doom - помните я говорил что римейк Doom доделаю на XashNT? Ну там немного работы, по большей части надо просто портировать порт.
MIR - используя BaseSDK
Paranoia - используя BaseSDK
Paranoia 2:Savior - используя BaseSDK

Возьми, какую-нибудь одну игру, например, Paranoia - доведи ее до ума и сделай, чтобы она идеально работала на твоем новом движке + добавь в нее все современные плюшки, чтобы все это вместе смотрелось и будет все ок ) Зачем тратить кучу времени на почти одно и тоже, портируя все эти игры?

Добавлено 22-10-2023 в 12:19:

Цитата:

FiEctro писал:
Ибо писать код в блокноте врядли кто то захочет, особенно новички.

Если я не ошибаюсь, то в джеке был редактор шейдеров для волатилы, и нечто подобное можно сделать в редакторе, которые будет для ксаша. Для шейдеров и для кода, чтобы для тупых показывал, где ошибка и возможные варианты исправления, ну и чтобы, когда нажал кнопочку на скомпилировать \ сохранить и этот код \ шейдер, то был сразу виден результат во вьюпорте

Отправлено Дядя Миша 22-10-2023 в 09:29:

Цитата:

(_-=ZhekA=-_) писал:
Возьми, какую-нибудь одну игру, например, Paranoia - доведи ее до ума и сделай

Само-собой.

Цитата:

(_-=ZhekA=-_) писал:
Зачем тратить кучу времени на почти одно и тоже, портируя все эти игры?

Тестирование различных подсистем и ситуаций.

Цитата:

(_-=ZhekA=-_) писал:
в джеке был редактор шейдеров для волатилы

Он только кутришные шейдеры поддерживает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 22-10-2023 в 09:43:

Цитата:

Дядя Миша писал:
Тестирование различных подсистем и ситуаций.

Игры, которые ты перечислил они плюс-минус одинаковые, я бы не стал тратить на это тонну времени

Цитата:

Дядя Миша писал:
Он только кутришные шейдеры поддерживает.

Я имел ввиду, чтобы ты потом сделал нечто похожее, но только уже для своего движка и своего языка программирования )

Отправлено Crystallize 22-10-2023 в 09:56:

Цитата:

Дядя Миша писал:
Half-Life 2 - ну тут может Crystallize займется, как я понял ему интересно.

Ты на меня не рассчитывай. Я сейчас насилу отвлекся от сорса, время тратишь а игру не полюбишь все равно.
Мне было интересно стиль поменять, но это более чем наполовину работа с текстурами и немного с освещением. И когда ты с текстурами снуло кликаешь на ползунки и смотришь на результат от фильтра то это можно считать за отдых. А когда ты над кодом воображаешь что он делает это работа.

Отправлено Дядя Миша 22-10-2023 в 11:19:

Цитата:

(_-=ZhekA=-_) писал:
которые ты перечислил они плюс-минус одинаковые

Долго объяснять.

Цитата:

(_-=ZhekA=-_) писал:
Я имел ввиду, чтобы ты потом сделал нечто похожее

У меня есть имплементация кутришных шейдеров, написанная на моём языке материалов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 24-10-2023 в 08:15:

Цитата:

Дядя Миша писал:
написанная на моём языке материалов.

По мне материалам вообще никакой язык не нужен, только имя шейдера, пути к текстурам и значения переменных из того же шейдера ну и возможно какие то флаги управляющие прозрачностью и освещением (хотя возможно это тоже регулируется в шейдере).

Отправлено Дядя Миша 24-10-2023 в 10:18:

Цитата:

FiEctro писал:
По мне материалам вообще никакой язык не нужен

Ошибаешься. Есть вещи, которые из шейдера недоступны, их надо сетапить где-то ещё. Например в материале. Но таких настроек может скопиться довольно и много и каждый раз прописывать их неудобно. Тут-то на помощь и приходит язык системы материалов - мы целую кучу настроек прячем под ключевое слово и в дальнейшем в материале используем это ключевое слово.
Причём ключевые слова задаются самим пользователем и могут скрывать за собой всё что угодно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 24-10-2023 в 12:39:

Цитата:

Насколько сильно у тебя привязка к жанру фпс? Тут нужны какие-то заготовки других жанров типа машинок из Диффужена или корабликов из Тириана.

Отправлено FiEctro 24-10-2023 в 13:13:

Цитата:

Crystallize писал:
Тут нужны какие-то заготовки других жанров типа машинок из Диффужена или корабликов из Тириана.

Это больше к физике вопрос. Вообще написание контроллера машинок как и контроллера игрока задача нетривиальная требующего небольшого исследования.

Цитата:

Дядя Миша писал:
Ошибаешься. Есть вещи, которые из шейдера недоступны, их надо сетапить где-то ещё. Например в материале. Но таких настроек может скопиться довольно и много и каждый раз прописывать их неудобно. Тут-то на помощь и приходит язык системы материалов - мы целую кучу настроек прячем под ключевое слово и в дальнейшем в материале используем это ключевое слово.
Причём ключевые слова задаются самим пользователем и могут скрывать за собой всё что угодно.

Посмотрел материалы в кваке. Ну я примерно понял, ты и физику и анимации туда вынести хочешь. Странное решение но почему бы и нет?

Отправлено Crystallize 24-10-2023 в 13:57:

FiEctro машинки то уже есть, дальше вопрос доброй воли их автора.

Отправлено FiEctro 24-10-2023 в 16:18:

Цитата:

Crystallize писал:
дальше вопрос доброй воли их автора

Здесь вопрос, а щупал ли ты их сам? Порой то что выглядит хорошо на видео может работать только на видео, а на твоих реальных тестах давать плохие результаты. Я потому Юнити и выбрал, потому что прежде чем своё что то писать, можно посмотреть что сделали другие, причём не один и не два варианта.

Отправлено Crystallize 24-10-2023 в 18:16:

Цитата:

FiEctro писал:
Порой то что выглядит хорошо на видео может работать только на видео, а на твоих реальных тестах давать плохие результаты.

Типа лучше хороший образ шутан-онли движка чем плохой имидж движка "для всего"? Ну может ты и прав.

Отправлено FiEctro 24-10-2023 в 19:24:

Crystallize
Я говорю о том что нужно исходить из собственных задач и инструмента который ты выбрал. Вот сделает ДМ СДК тогда можно будет посмотреть, а возможно впринципе туда какие машинки вставить?

Отправлено Дядя Миша 24-10-2023 в 19:40:

Цитата:

Crystallize писал:
Насколько сильно у тебя привязка к жанру фпс?

Технически у самого ядра привязки нет. Всё упирается в сеть. А сети пока что нет.

Цитата:

Не всё сразу.

Цитата:

FiEctro писал:
Ну я примерно понял, ты и физику и анимации туда вынести хочешь

Вообще-то нет

Современный движок работает на стыке двух вычислительных юнитов: CPU и GPU. Обычно проблемы возникают при передаче данных. Вот мои материалы и решают эту проблему.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 27-10-2023 в 14:08:

Так, ну чтожы. Скоро (на след. неделе) выложу ещё одну демку.
Потом ревизия документации и наконец-то первый SDK.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 27-10-2023 в 21:30:

Дядя Миша
Ждём

Отправлено Дядя Миша 29-10-2023 в 14:51:

Как бы странно это ни звучало, но в настоящее время мне по духу ближе всего стала именно идеология Юнити - если конечно избавить её от проклятия third party в немыслимых количествах. Кризис амазоновцы затерзали насмерть, Унреал превратился в какого-то монстра, с которым никто не знает как управляться в одиночку.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-10-2023 в 19:38:

Цитата:

Дядя Миша писал:
но в настоящее время мне по духу ближе всего стала именно идеология Юнити

А как ты её понял?

Отправлено Дядя Миша 29-10-2023 в 20:00:

Всё в одном + скриптовой язык.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 30-10-2023 в 02:55:

Цитата:

Дядя Миша писал:
Возможно кто-то не в курсе, но портировать Delphi на C++ в ряде случаев - нерешаемая задача. Заодно, у тех, кто внимательно следит за моими "невероятными приключениями", наверняка встал вопрос - отчего же я не взял уже портированую библиотеку VCL, для C++ Builder. Ведь разработчики Delphi выпускали и такой продукт тоже и там VCL тоже была. Так вот если внимательно изучить рантайм, то вы увидите, что там VCL присутствует в своём оригинальном виде, т.е. по прежнему на языке Delphi. Никто и никогда не портировал её на С++, в нём отсутствует ряд возможностей, которые она активно использует. В частности там нет свойств и нет виртуальных конструкторов.

Впечатление, что Делфи это по секрету самый замечательный язык, просто его преимущества были не видны людям из-за нескольких досадных недостатков.

Отправлено FiEctro 30-10-2023 в 05:58:

Crystallize
На Делфи просто было много прикольных библиотек. А так язык, как язык.

Отправлено (_-=ZhekA=-_) 30-10-2023 в 06:41:

Цитата:

Дядя Миша писал:
Как бы странно это ни звучало, но в настоящее время мне по духу ближе всего стала именно идеология Юнити - если конечно избавить её от проклятия third party в немыслимых количествах. Кризис амазоновцы затерзали насмерть, Унреал превратился в какого-то монстра, с которым никто не знает как управляться в одиночку.

Принципиальная разница между анрилом и инити в том, что в анлиле для работы уже все есть из коробки в том числе графика и физика, а в юнити нужно все это прикручивать самостоятельно, что не удобно для начинающих.

Отправлено FiEctro 30-10-2023 в 07:59:

Цитата:

(_-=ZhekA=-_) писал:
а в юнити нужно все это прикручивать самостоятельно

В Юнити физика из коробки, HDRP и URP рендеры с графоном тоже из коробки, но всё модульное. И при старте проекта даётся самый минимум чтобы не распухал твой проект. Однако ты без проблем можешь обмазываться ассетами. В целом Анрил и Юнити сейчас очень похожи, и я бы не сказал что их подход к разработке сильно различается.

Отправлено (_-=ZhekA=-_) 30-10-2023 в 08:04:

Цитата:

FiEctro писал:
В Юнити физика из коробки, HDRP и URP рендеры с графоном тоже из коробки, но всё модульное. И при старте проекта даётся самый минимум чтобы не распухал твой проект. Однако ты без проблем можешь обмазываться ассетами. В целом Анрил и Юнити сейчас очень похожи, и я бы не сказал что их подход к разработке сильно различается.

А насколько сложно в юнити включать \ выключать эти модули?
Просто раньше насколько я помню в юнити была с этим проблема и то, что из коробки ничего толком не было, сейчас я так понимаю с этим все норм?

Отправлено FiEctro 30-10-2023 в 08:07:

Цитата:

А насколько сложно в юнити включать \ выключать эти модули?

Нажатием кнопки.
https://docs.unity3d.com/Manual/upm-ui.html

Но в Годоте мне больше эта система нравится, там можно просто указать ссылку на гитхаб.

Отправлено (_-=ZhekA=-_) 30-10-2023 в 09:55:

Цитата:

FiEctro писал:
Но в Годоте мне больше эта система нравится, там можно просто указать ссылку на гитхаб.

А если работаешь оффлайн, то как быть?

Отправлено FiEctro 30-10-2023 в 10:14:

(_-=ZhekA=-_)
Так же как в Анриле, некоторые пакеты можно ставить оффлайн

Отправлено Дядя Миша 30-10-2023 в 10:23:

Пакеты это тупиковый путь. Посмотрите во что они превратили линукс, ад зависимостей, всё глючит, конфликтует и занимает чёртову уйму места.
И если пакеты начнут перестрелку друг с другом вы никак это не отладите и не почините и даже не поймете что вообще происходит.
Мне это напоминает китайскую технику слепленную из всякого мусора, в 90-е такую продавали. Я резко против такого.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 30-10-2023 в 10:26:

Цитата:

Дядя Миша писал:
если пакеты начнут перестрелку друг с другом вы никак это не отладите и не почините и даже не поймете что вообще происходит.

Так там неймспейсы разные

Да и сами пакеты не лезут в движок, это просто теже самые пользовательские скрипты.

Отправлено (_-=ZhekA=-_) 30-10-2023 в 10:57:

Цитата:

FiEctro писал:
Так же как в Анриле, некоторые пакеты можно ставить оффлайн

Я хз, что такое пакеты... В анриле плагины, которые можно вкл или выкл в меню

Отправлено Дядя Миша 30-10-2023 в 11:26:

FiEctro вот они между собой и будут конфликтовать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 30-10-2023 в 11:30:

Дядя Миша
А каким образом они могут конфликтовать?

Цитата:

(_-=ZhekA=-_) писал:
Я хз, что такое пакеты... В анриле плагины, которые можно вкл или выкл в меню

Названий много, смысл один и тот же.

Отправлено Дядя Миша 30-10-2023 в 12:41:

Всё что делалось разными людьми - обязательно будет конфликтовать между собой, закон природы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 30-10-2023 в 13:12:

Цитата:

FiEctro писал:
Так там неймспейсы разные

А прогеры это соблюдают?

Отправлено FiEctro 30-10-2023 в 13:42:

Дядя Миша
Ну вот моды в халф лайфе конфликтуют между собой? Пакеты работают примерно так же, только локально.

Цитата:

Crystallize писал:
А прогеры это соблюдают?

Обычно да, но если даже и нет, чего там сложного эти неймспейсы прописать? К тому же у самого пакета может быть вагон метаданных с указанием прав доступа. Это скорее вопрос проработанности виртуальной машины. Глупая виртуалка конечно всё в один стакан засунет.

Я видал не мало проектов на Юнити и сам немного удивлён как она может справляться просто с титаническим количество ассетов и рекламных СДК которые по идее должны уже давным давно конфликтовать друг с другом поскольку функционал у них примерно тот же.

Отправлено Дядя Миша 30-10-2023 в 15:23:

Цитата:

FiEctro писал:
Ну вот моды в халф лайфе конфликтуют между собой?

Но моды не используются ВМЕСТЕ. Они используются ПО ОЧЕРЕДИ.
А твои пакеты именно что вместе используются.

Цитата:

FiEctro писал:
и сам немного удивлён как она может справляться просто с титаническим количество ассетов и рекламных СДК

Ну вот ты к примеру подключишь одновременно пять разных плеер-контроллеров и, так сказать, что? Они все будут одновременно контролировать игрока?

Добавлено 30-10-2023 в 18:21:

Я могу ещё понять, если принято какое-то соглашение об универсальных интерфейсах ввода-вывода и на этой вот базе и построены все ассеты.
Скажем есть ассет аптечка, у которой есть эвент OnTouch и эвент AddHealth.
Ну и все объекты по очереди могут вызвать оба этих эвента или их проигноировать. В противном же случае твоя аптечка должна что-то модифицировать в классе игрока напрямую, про который она ничего не знает. В старом ксаше, да и в спирите можно с натяжкой назвать такой абстракцией систему ввода-вывода и префиксов, где на каждый префикс можно было повесить какое-то действие, но это было совершенно неинтуитивно. В хл2 чуть получше с этим, но опять же - кол-во событий может сильно различаться. В принципе это всё реализуется на Шоте, если продумать концепцию. А концепцию лучше продумывать для абстрактного SDK, а не для уже существующего набора энтить.

Добавлено 30-10-2023 в 18:23:

Да и если честно - вот этот сам механизм, когда ассет добавляется нажатием одной кнопки меня весьма напрягает. Потому что рано или поздно ты вот так вирус туда добавишь или ещё что похуже.

Добавлено 30-10-2023 в 18:23:

И в принципе подобный подход обесценивает продумывание логики игры. Некоторым кажется, что достаточно накидать ассетов и готово. А потом удивляемся, чего всё глючит, тормозит и в текстурах застревает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 30-10-2023 в 16:22:

Цитата:

Дядя Миша писал:
Но моды не используются ВМЕСТЕ. Они используются ПО ОЧЕРЕДИ.

А вот моды на Морровинд использовались одновременно. И они друг с другом конфликтовали, из-за чего их либо нельзя было использовать вместе, либо один переписывать, либо найти для своей полусотни модов порядок загрузки который исключал конфликты. Но нормального средства установить порядок загрузки модов в ванильной игре не было предусмотрено. Игра загружала моды в порядке их создания, по дате изменения файла-модуля, один мод-один файл. Поэтому была сделана специальная утилита, которая позволяла напрямую прописать файлу мода любую произвольную дату и время создания.

Отправлено FiEctro 30-10-2023 в 16:51:

Цитата:

Дядя Миша писал:
Ну вот ты к примеру подключишь одновременно пять разных плеер-контроллеров и, так сказать, что? Они все будут одновременно контролировать игрока?

Да, выглядеть это будет плохо, но они будут пытаться его контролировать.

Более того я сам писал как то такую систему состоящую из нескольких плеер контроллеров, где надо было менять физику и управление игрока радикально.

Цитата:

Дядя Миша писал:
Я могу ещё понять, если принято какое-то соглашение об универсальных интерфейсах ввода-вывода и на этой вот базе и построены все ассеты.
Скажем есть ассет аптечка, у которой есть эвент OnTouch и эвент AddHealth.
Ну и все объекты по очереди могут вызвать оба этих эвента или их проигноировать. В противном же случае твоя аптечка должна что-то модифицировать в классе игрока напрямую, про который она ничего не знает.

Да ты прав, так оно и будет работать, потому что это по концепции Юнити - говнокод (это не я придумал, другие Юнити программисты мне так сказали). Нельзя напрямую в коде прописывать эвенты. Они назначаются на сцене или префабе если тебе его надо использовать многократно. Тоже самое с аниматором в котором настраивается логика анимаций без кода, а ты уже скриптом даёшь команды аниматору. И из этого так же вытекает что поиск по имени тоже плохая идея. Вот потому у тебя всё и будет ломаться.

По твоей логике с таким же успехом ты мог бы прописывать свой адрес почты в прошивке биоса.

Цитата:

Дядя Миша писал:
Да и если честно - вот этот сам механизм, когда ассет добавляется нажатием одной кнопки меня весьма напрягает. Потому что рано или поздно ты вот так вирус туда добавишь или ещё что похуже.

Ты и без ассетов раньше вирусы подхватывал, не выдумывай глупости. За всё время пользованием Юнити и Годотом я ни одного вируса не поймал, хотя сомнительной херни качал много. А вот когда скачал ксашевкий студиомдл с какого то ноунеймовского сайта у меня сдох блокнот и сломался проводник. Так что вирусы это вообще не показатель, ими можно заразить всё что угодно.

Цитата:

Дядя Миша писал:
И в принципе подобный подход обесценивает продумывание логики игры. Некоторым кажется, что достаточно накидать ассетов и готово. А потом удивляемся, чего всё глючит, тормозит и в текстурах застревает.

Ты просто перекладываешь проблему архитектуры с плеч разработчика на плечи юзера. Почему сразу нельзя задать правила чтобы всё максимально совместимо было? Можно просто пообсуждать как лучше это сделать, и подсмотреть как в других движках.

Отправлено Дядя Миша 30-10-2023 в 18:44:

Цитата:

Crystallize писал:
А вот моды на Морровинд использовались одновременно. И они друг с другом конфликтовали

А вот в UT'99 были мутаторы. И они друг с другом не конфликтовали. Потому что их делала одна команда, которая протестировала их работу во всех вариациях. Чего нельзя сказать про моды от сторонних разработчиков.

Цитата:

FiEctro писал:
Ты и без ассетов раньше вирусы подхватывал, не выдумывай глупости

Я напоминаю одно время тут стабильно выкладывали демки на Юнити полные вирусов. Уж не из-за ассетов ли? Я даже удивлялся, годами вирусов не цепляешь, скачал демку и пошло-поехало.

Цитата:

FiEctro писал:
Так что вирусы это вообще не показатель, ими можно заразить всё что угодно.

Есть механизмы, удобные для заражения в первую очередь.

Цитата:

FiEctro писал:
Почему сразу нельзя задать правила чтобы всё максимально совместимо было?

Потому что ты эти правила ещё пересмотришь стопитцот раз помере возникновения потребностей. Стандарта-то нет. Да его и не может быть, т.к. каждая игра требует чего-то особенного.
Стандарт ещё можно разработать для игр с чётко определённым жанром, типа того же квейка: аптечки, пушки - подбираем, монстров - убиваем, кнопки - нажимаем, двери - открываем.
Но скажем уже для сталкера всё это пойдет лесом, т.к. там сложная нелинейная система с глобальными переменными. Убил кого-то не того - к тебе в целом немного отношение ухудшилось.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 30-10-2023 в 19:57:

Цитата:

Дядя Миша писал:
Я напоминаю одно время тут стабильно выкладывали демки на Юнити полные вирусов. Уж не из-за ассетов ли? Я даже удивлялся, годами вирусов не цепляешь, скачал демку и пошло-поехало.

Сам подумай, ассет это шарп скрипт. Как шарпами другие экзешники заразить? Эта просто какая то сторонняя дрянь была которая прописывалась на все подряд экзешники.

Цитата:

Дядя Миша писал:
Стандарт ещё можно разработать для игр с чётко определённым жанром, типа того же квейка: аптечки, пушки - подбираем, монстров - убиваем, кнопки - нажимаем, двери - открываем.

Стандарт это пайплайн. Написал скрипт -> указал ему права -> повесил его на объект -> задал ссылки и константы в интерфейсе скрипта -> оформил префаб. Всё, можешь делать хоть 1000 аптечек в разных жанрах с разным кодом. Потому что аптечка это абстрактный класс, а не прибитый ~~евентами~~ гвоздями хардкод который надо переписывать только потому что поменяли модельку.

Отправлено (_-=ZhekA=-_) 30-10-2023 в 20:07:

Цитата:

FiEctro писал:
Сам подумай, ассет это шарп скрипт. Как шарпами другие экзешники заразить? Эта просто какая то сторонняя дрянь была которая прописывалась на все подряд экзешники.

Стандарт это пайплайн. Написал скрипт -> указал ему права -> повесил его на объект -> задал ссылки и константы в интерфейсе скрипта -> оформил префаб. Всё, можешь делать хоть 1000 аптечек в разных жанрах с разным кодом. Потому что аптечка это абстрактный класс, а не прибитый ~~евентами~~ гвоздями хардкод который надо переписывать только потому что поменяли модельку.

Прям одна аптечка на все случаи жизни, а что если рюкзак, навыки, что тоже подойдет?

Отправлено Дядя Миша 30-10-2023 в 20:24:

Цитата:

FiEctro писал:
Как шарпами другие экзешники заразить?

Ты вспоминай что вирусы через VB-Script как-то распространялись долгое время. Напакостить-то разными способами можно.

Цитата:

FiEctro писал:
Написал скрипт -> указал ему права -> повесил его на объект -> задал ссылки и константы в интерфейсе скрипта -> оформил префаб

Это уже ближе к Doom3 который кстати и является родоначальником такого подхода. У меня проще устроено, как и в самой кваке - есть набор характеристик, класснейм и всё это прибито гвоздями к инстансу скрипта.
Можно конечно и усложнить, но без своего редактора пока не хочу всё это трогать.

Цитата:

(_-=ZhekA=-_) писал:
а что если рюкзак

Рюкзак это отдельная концепция. Тебе надо как минимум оформить хранилище предметов в классе игрока. И написать визуалиатор, который их будет показывать. Обычные аптечки всего этого лишены.

Добавлено 30-10-2023 в 23:24:

Вот для примера такой def файл из Doom3 для зомби.
Здесь есть сразу несколько сущностей:
def-файл который я приложил
скриптовой код на doomscript
абстрактный код монстров в игровой библиотеке
настройки монстра на конкретной карте

собственно мне не нравится здесь то, что эти настройки привязаны к абстрактному файлу, а не к модели. Ведь именно модель и определяет поведение монстра. Куда логичнее вшить все настройки в саму модель, а на скриптовом языке написать data-driven код монстра. Собсно всё. Моделлер делает новую модельку, там же указывает основные параметры.
Подменяем модельку - получаем нового монстра. При этом в коде можно вообще не соображать. Пока так вижу это всё.
Хотя предложенная модель никоим образом не называется как единственная.
Она в любом случае будет не в движке, а в скриптах.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-10-2023 в 06:13:

Цитата:

Дядя Миша писал:
собственно мне не нравится здесь то, что эти настройки привязаны к абстрактному файлу, а не к модели. Ведь именно модель и определяет поведение монстра.

Это будет работать только в одном конкретном случае - когда у тебя одна модель на все объекты такого типа. А если тебе нужен монстр с той же моделью но другими параметрами? Или другой моделью от другого монстра? Опять всё поломается. Т.е. левелдизайнер меняет модельку и с ней слетают все её свойства, тому приходится дергать моделера чтобы тот внёс правки...
А если у тебя например есть модель ящика раскиданная по всей карте в количестве 100 штук, а тебе надо запечь на все ящики лайтмапу, ты каждый ящик будешь делать отдельным файлом?

Нет, всётаки префабы лучше, может они выглядят не так красиво, но твой подход опять отходит от идеологии "всё в одном" и вынуждает делать какие то кастомные редакторы со своими объектами и скриптами. Не удобно это ниразу вообще, да и такие инструменты ещё нужно писать и отлаживать...

В модель можно вшивать только какие то общие вещи, например коллайдеры или шейпкеи, который в большинстве случаев будут одинаковыми.
И то желательно чтобы они импортировались как префаб, чтобы пользователь в случае чего мог подогнать их под себя без пересборки модели. Бывают случаи например когда нужно удалить какую то кость в реальном времени.

А вот евенты, аттачменты и анимации модели совсем не принадлежат и могут многократно раз меняться. Ты даже не представляешь как часто нам приходилось вешать скелет от одной модели на другую и подгонять его.

Отправлено Дядя Миша 31-10-2023 в 06:45:

Цитата:

FiEctro писал:
А если тебе нужен монстр с той же моделью но другими параметрами?

Приведи пример такого монстра. Какие именно параметры у него будут другими?

Цитата:

FiEctro писал:
левелдизайнер меняет модельку и с ней слетают все её свойства

Почему слетают? Применяются свойства новой модели. В той же халфе, например, как ты помнишь, скорость монстров определялась скоростью их анимации и это было очень удобно. Опять таки в анимациях прописаны эвенты, в новом ксаше эвенты могут вызывать скриптовые функции с параметрами. Вот и получается, что одна анимация наносит один урон игроку, а другая - другой. Там же можно спавнить всякие фаерболы и прочее. А где ещё ты собрался это прописывать? В настройках объекта чтоли? Это куда логичнее именно в анимации, чтобы сразу в модельвьвювере увидеть что происходит. И таких параметров довольно много.

Цитата:

FiEctro писал:
А если у тебя например есть модель ящика раскиданная по всей карте в количестве 100 штук, а тебе надо запечь на все ящики лайтмапу, ты каждый ящик будешь делать отдельным файлом?

Вообще не понял какая тут связь.

Цитата:

FiEctro писал:
Нет, всётаки префабы лучше, может они выглядят не так красиво

Так я не против префабов. Пусть будут.

Цитата:

FiEctro писал:
Бывают случаи например когда нужно удалить какую то кость в реальном времени.

Не было таких случаев. Да и нельзя кости удалять.

Цитата:

FiEctro писал:
пользователь в случае чего мог подогнать их под себя без пересборки модели

Так пользователь большинство этих параметров и вовсе не трогает никогда.

Цитата:

FiEctro писал:
А вот евенты, аттачменты и анимации модели совсем не принадлежат

эвенты принадлежат именно конкретной анимации. Если это анимация урона - значит эвенты наносят урон. Если это анимация выстрела, значит пускаем пулю и создаём маззлфлэш. Какие тут ещё могут быть варианты?
Аттачменты принадлежат скелету.
Банк анимаций - это просто для того, чтобы не приходилось заново эти анимации делать для каждой новой модельки.
Тебя видимо смущают некие константы в эвентах? Ну так это могут быть факторы, а не конечные значения. В анимации сильного удара - один фактор, в анимации слабого - другой. А конкретное значение уже меняется от монстра к монстру. Просто есть вещи которые нельзя переиспользовать ни в каком другом контексте. Если у тебя есть анимация ходьбы ты не сможешь её использовать в качестве анимации покоя.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 31-10-2023 в 08:10:

Цитата:

Дядя Миша писал:
Не было таких случаев. Да и нельзя кости удалять.

Насчет обычных костей я хз, а вот виртуальные кости можно создавать и удалять в реалтайме

Отправлено FiEctro 31-10-2023 в 08:31:

Цитата:

Дядя Миша писал:
Приведи пример такого монстра. Какие именно параметры у него будут другими?

Анимации, эвенты, аттачменты. Например у одного монстра одна пушка, у второго другая и в другой руке, а у третьего вообще на каске. Ну вот тебе как программисту, удобно пересобирать модель каждый раз когда ты хочешь поменять какую то константу?

Цитата:

Дядя Миша писал:
Почему слетают? Применяются свойства новой модели.

Когда они меняются, разве не слетают?

Цитата:

Дядя Миша писал:
В той же халфе, например, как ты помнишь, скорость монстров определялась скоростью их анимации и это было очень удобно.

Рут моушен да, в Юнити он тоже есть. Если честно я так и не разобрался как с ним работать, результат выходил всегда кривым и забагованым, слишком много возни с ним особенно когда используешь ИК.

Цитата:

Дядя Миша писал:
Вообще не понял какая тут связь.

Связь в том что одна и та же модель на сцене может использоваться с разным контекстом.

Цитата:

Дядя Миша писал:
Не было таких случаев. Да и нельзя кости удалять.

Ты просто с ними не сталкивался.

Цитата:

Дядя Миша писал:
Так пользователь большинство этих параметров и вовсе не трогает никогда.

Кости в Юнити это такие же объекты как и лампочки и всё остальное. Как управлять ими решает скрипт Аниматора или пользователя. Так же на них навешиваются констрейнты и скрипты, например копи ротейшен, физическая ротатабля или вигл боунсы, а так же колайдеры для физики. Ничего не мешает тебе отсоединить отдельную кость и привязать её к другому объекту на сцене. Я похожим способом софтбоди (такие жележки) и вириовки физические делал. И для этого не приходилось писать код вообще.

Какие костыли нужно писать чтобы это реализовать с изолированным скелетом я даже представить не могу.

Цитата:

Дядя Миша писал:
эвенты принадлежат именно конкретной анимации. Если это анимация урона - значит эвенты наносят урон. Если это анимация выстрела, значит пускаем пулю и создаём маззлфлэш. Какие тут ещё могут быть варианты?
Аттачменты принадлежат скелету.
Банк анимаций - это просто для того, чтобы не приходилось заново эти анимации делать для каждой новой модельки.
Тебя видимо смущают некие константы в эвентах? Ну так это могут быть факторы, а не конечные значения. В анимации сильного удара - один фактор, в анимации слабого - другой. А конкретное значение уже меняется от монстра к монстру. Просто есть вещи которые нельзя переиспользовать ни в каком другом контексте. Если у тебя есть анимация ходьбы ты не сможешь её использовать в качестве анимации покоя.

В целом согласен. Что евенты это часть анимаций, да это верно, но анимации не всегда могут быть частью модели. Иногда это может быть голый скелет который ретаргетится на скелет другой модели. А вот уже какой модели выполнять какие анимации решает скрипт Аниматора. Не все программисты и гейм дизайнеры могут смыслить в моделинге настолько хорошо чтобы сделать это ручками в 3д пакете.

Отправлено Дядя Миша 31-10-2023 в 12:40:

Цитата:

FiEctro писал:
Например у одного монстра одна пушка, у второго другая и в другой руке

И что? Руки-то не меняются. А пушки цепляются к конкретным аттачментам в самой модели\либо к частичной иерархии костей. Оно и в халфе так было.

Цитата:

FiEctro писал:
Связь в том что одна и та же модель на сцене может использоваться с разным контекстом.

Естественно может.

Цитата:

FiEctro писал:
Ты просто с ними не сталкивался.

Гланды через задницу мне действительно удалять не приходилось.

Цитата:

FiEctro писал:
Кости в Юнити это такие же объекты как и лампочки и всё остальное

Это тоже пришло из третьего дуума. Мне это не очень нравится, т.к. тормозно. Должен быть какой-то компромисс в контролировании костей.

Цитата:

FiEctro писал:
Ничего не мешает тебе отсоединить отдельную кость

Я понял, ты точки привязки называешь костями.

Цитата:

FiEctro писал:
но анимации не всегда могут быть частью модели

Ну и что? Эвент-то всегда на одном и том же кадре должен проигрываться. Если у тебя анимация выстрела - значит на кадре выстрела проигрывается эвент. Если анимация ходьбы - есть кадр где нога заведомо стоит на земле - там вызывается эвент инверсной кинематики.
Тут без вариантов, независимо от того, какую модель ты используешь.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-10-2023 в 13:03:

Цитата:

Дядя Миша писал:
Должен быть какой-то компромисс в контролировании костей.

Ну можно наверное сделать какой то объект боне контроллера который с определённым весом мог управлять костью/группой костей или наоборот к ней липнуть. Это уже своё что то надо придумывать. В любом случае это удобнее зашитых аттачментов.

Цитата:

Дядя Миша писал:
И что? Руки-то не меняются. А пушки цепляются к конкретным аттачментам в самой модели\либо к частичной иерархии костей. Оно и в халфе так было.

При этом тебе надо пересобирать модель каждый раз когда хочешь что то прицепить к ней в новом месте. А если модель не твоя то пойти сосать лапу..

Цитата:

Дядя Миша писал:
Это тоже пришло из третьего дуума.

Не знаю как в третьем думе, возможно Юнитевцы там всё и подсмотрели.

Цитата:

Дядя Миша писал:
Гланды через задницу мне действительно удалять не приходилось.

Как я говорил кость это такой же объект с иерархией. И если можно создавать и удалять объекты то почему в твоей логике невозможно это делать с костями? Ты наверное просто никогда не работал с ИК скелетами в которых мусорных костей может быть довольно много.

Отправлено Дядя Миша 31-10-2023 в 15:50:

потому что кости принадлежат:
1. одному объекту
2. одной модели
Тут нарушение целостности, когда несколько объектов пытаются контролировать одну модель. Такого быть просто не должно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-10-2023 в 16:56:

Цитата:

Дядя Миша писал:
потому что кости принадлежат:
1. одному объекту
2. одной модели
Тут нарушение целостности, когда несколько объектов пытаются контролировать одну модель. Такого быть просто не должно.

Другими словами иерархия объектов. Ладно надеюсь мне удалось донести какие возможности хотелось использовать для работы с костями

, а реализация конечно может быть и другая.

Отправлено Дядя Миша 31-10-2023 в 17:54:

дело в том, что прописывать аттачменты в коде - это такой возврат к первому квейку, где все смещения были жестко захардкодены.
И наоборот - халфа с её аттачментами в модельках воспринималась как глотк свежего воздуха. Ну хорошо, возьми этот s&3box и изучи вопрос - как там сделано. И напиши отличия от юнити - удобно\неудобно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-10-2023 в 18:13:

Цитата:

Дядя Миша писал:
дело в том, что прописывать аттачменты в коде - это такой возврат к первому квейку, где все смещения были жестко захардкодены.

Я не говорил прописывать аттачменты в коде. Это просто дочерний объект в иерархии кости внутри префаба.

Вот у тебя есть объект АК-47. Ты хочешь прикрепить его к руке, и просто переводишь этот объект мышкой из родителя ворлдспавна в родитель кость руки прямо на сцене или префабе. Всё просто без кода, перекомпиляции модели и прочего говна.

Не ну если эти аттачменты можно будет редактировать внутри редактора сцены, и сохранять в модель, почему бы и нет? Тоже вариант. Однако всеравно редактируя общую модель ты ломаешь совместимость с другими проектами где она была настроена под старые аттачменты. Хз по мне это не очень хорошая идея хранить их в модели.

Отправлено nemyax 31-10-2023 в 18:20:

FiEctro
Ты редактор скелетов просишь?

Отправлено FiEctro 31-10-2023 в 18:22:

Цитата:

nemyax писал:
FiEctro
Ты редактор скелетов просишь?

Это не отдельный редактор. Юнити вставляет скелет как префаб где каждая кость как отдельная энтития. Логично что такой скелет можно сконфигурировать в каждом префабе под свои нужды не затрагивая саму модель и не ломая совместимость с другими сценами.

В Анриле так же:

https://docs.unrealengine.com/5.0/Images/animating-characters-and-objects/SkeletalMeshAnimation/Persona/skeleton-editor/SkeletonEditorOverview.png

Отправлено nemyax 31-10-2023 в 18:28:

То есть по сути ты просишь надстройку с констрейнтами. Если без перекомпиляции модели.

Отправлено FiEctro 31-10-2023 в 18:30:

nemyax
Констрейнты юзеры могут и сами писать. Главное это доступ ко скелету и возможность управлять его костями не затрагивая саму модель.

Вот тут например посмотрите как это работает.

Отправлено Дядя Миша 31-10-2023 в 18:42:

Цитата:

FiEctro писал:
Юнити вставляет скелет как префаб где каждая кость как отдельная энтития

Вот это-то мне и непонятно. В моём представлении каждый объект либо имеет одну модель, либо не имеет её вовсе. А тут получается куча энтить контролирует одну модельку. Скорее всего это какой-то слой абстракции, т.е. объект реально один, а внутри него - подъобъекты, которые и контролируют кости. Я ведь делал нечто подобное ещё на старом ксаше - там были веровки где каждая кость такой веровки контролировалась отдельным контроллером, но все эти контроллеры были частью одной энтити. Такое сделать без проблем можно. Но это будет такой специфичный класс, рассчитаный на модели со скелетами, что очевидно.

Цитата:

FiEctro писал:
Вот у тебя есть объект АК-47. Ты хочешь прикрепить его к руке, и просто переводишь этот объект мышкой из родителя ворлдспавна в родитель кость руки прямо на сцене или префабе

Видишь ли какое дело. Прикрепить автомат простым перетягиванием в какую-то иерархию не получится. Это годится только для простых объектов, типа спышки выстрела, где тебе надо просто обозначить позицию. А для оружия, тебе надо как минимум, чтобы оно "срослось" с основной анимацией, значит там будет кусочек скелета от родителя, и вот эти два скелета ты и будешь мержить. Такое было ещё в первой халфе, игроки так свои пушки держали. Но глупо надеяться, что ты просто пристикнешь автомат к какой-то кости и он у тебя всегда будет правильно развернут во всех анимациях.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-10-2023 в 18:52:

Цитата:

Дядя Миша писал:
Видишь ли какое дело. Прикрепить автомат простым перетягиванием в какую-то иерархию не получится. Это годится только для простых объектов, типа спышки выстрела, где тебе надо просто обозначить позицию. А для оружия, тебе надо как минимум, чтобы оно "срослось" с основной анимацией, значит там будет кусочек скелета от родителя, и вот эти два скелета ты и будешь мержить. Такое было ещё в первой халфе, игроки так свои пушки держали. Но глупо надеяться, что ты просто пристикнешь автомат к какой-то кости и он у тебя всегда будет правильно развернут во всех анимациях.

Почему же? Твой автомат с анимацией будет просто копировать перемещение родительской кости, а значит анимация будет работать корректно. А вот если у пушки есть рутовая кость которая мешает это сделать, вот тут как раз в помощь и приходит возможность удалять лишние кости в префабе.

Цитата:

Дядя Миша писал:
Вот это-то мне и непонятно. В моём представлении каждый объект либо имеет одну модель, либо не имеет её вовсе. А тут получается куча энтить контролирует одну модельку. Скорее всего это какой-то слой абстракции, т.е. объект реально один, а внутри него - подъобъекты, которые и контролируют кости. Я ведь делал нечто подобное ещё на старом ксаше - там были веровки где каждая кость такой веровки контролировалась отдельным контроллером, но все эти контроллеры были частью одной энтити. Такое сделать без проблем можно. Но это будет такой специфичный класс, рассчитаный на модели со скелетами, что очевидно.

Вот представь хаммер или кварк. Представь кучу лампочек не в плане что они светятся, а как любой другой точечной энтити на сцене. Всё это объединено в префаб и каждая лампочка имеет название своей кости.

Есть env_model который загружает модель как статичную, а вот внутри неё ты можешь указать рутовую лампочку, он ищет похожие имена и позволяет привязать веса модели к твоим лампочкам которые ты можешь двигать в кварке при условии что они имеют такие же имена что и оригинальные кости, а так же являются дочерними.

Потом опять же в рутовом объекте подгружатся класс Аниматор которому указывается путь к анимации и он уже двигает твои лампочки как надо. При этом ничего тебе не мешает подгрузить на этот же скелет уже второй аниматор и например плавно смешивать 2 анимации.

При этом лампочка это всё тот же точечный игровой объект, с которым можно делать всё что угодно: создавать/удалять/редактировать/делать префабы/делать его физическим и.д.

Посмотри видео что я скинул, хотя бы перемоткой, сразу поймешь о чём я.

Отправлено Дядя Миша 31-10-2023 в 19:17:

Цитата:

FiEctro писал:
При этом ничего тебе не мешает подгрузить на этот же скелет уже второй аниматор и например плавно смешивать 2 анимации.

Проблема в том, что мне вообще не надо подгружать никаких-таких аниматоров, чтобы смешивать сколько угодно анимаций.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-10-2023 в 19:23:

Дядя Миша
Это понятно, вот только поменяешь модельку и всё сломается. Я просто доношу общую идею. Может придумаешь и более удачную реализацию. То что префабы дают большую гибкость и совместимость чем вшитые в модель аттачменты.

Отправлено Дядя Миша 31-10-2023 в 19:26:

Слушай, ну в халфе модельку меняли, разве что-то ломалось? Наоборот получался новый монстр.

Добавлено 31-10-2023 в 22:26:

Цитата:

FiEctro писал:
То что префабы дают большую гибкость чем вшитые в модель аттачменты.

А ты представь, что модель со вшитыми аттачментами - это и есть префаб.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-10-2023 в 19:28:

Цитата:

Дядя Миша писал:
Слушай, ну в халфе модельку меняли, разве что-то ломалось? Наоборот получался новый монстр.

Ну если они условно идентичные наверное это будет работать. Но как часто такое встретишь? Вот ты идёшь качаешь модельку с инета, а у неё только голый скелет и всё. Что ты с ней дальше будешь делать?

Цитата:

Дядя Миша писал:
А ты представь, что модель со вшитыми аттачментами - это и есть префаб.

Да не вопрос. Главное чтобы к костям был доступ со сцены и можно было делать свои префабы не создавая дубликатов этой модели. Вот например твоя реализация тоже очень близко к этой концепции:

Цитата:

Дядя Миша писал:

Я ведь делал нечто подобное ещё на старом ксаше - там были веровки где каждая кость такой веровки контролировалась отдельным контроллером, но все эти контроллеры были частью одной энтити. Такое сделать без проблем можно. Но это будет такой специфичный класс, рассчитаный на модели со скелетами, что очевидно.

Я же не навязываю тебе конкретную реализацию, просто объясняю функционал.

Отправлено Дядя Миша 31-10-2023 в 20:04:

Цитата:

FiEctro писал:
Вот ты идёшь качаешь модельку с инета, а у неё только голый скелет и всё

Если всё с инета качать, это не игра получится, а чёрт знает что такое.
Я такие игры не понимаю. Это ладно, ещё текстуры можно отовсюду надёргать и использовать готовый движок. Но чтобы модели из интернетов качать? И не меблю-диваны там всякие, а персонажей!
Ведь игра это и есть персонажы, а ты предлагаешь их из интернета накачать?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-10-2023 в 20:32:

Цитата:

Дядя Миша писал:
Если всё с инета качать, это не игра получится, а чёрт знает что такое.
Я такие игры не понимаю. Это ладно, ещё текстуры можно отовсюду надёргать и использовать готовый движок. Но чтобы модели из интернетов качать? И не меблю-диваны там всякие, а персонажей!
Ведь игра это и есть персонажы, а ты предлагаешь их из интернета накачать?

Ну вот скажы ты в моды на халфу играл? Там почти в каждом половина моделей с интернета, хоть и переработанные под халфу, либо с других модов и игр. Если человек например хочет программировать в твоём движке хочет научиться, зачем его нагружать сразу ещё и моделингом?

Отправлено Дядя Миша 31-10-2023 в 20:42:

Так то не игра, а мод, баловство всякое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 01-11-2023 в 03:51:

Дядя Миша На движках серии квейка разница между модом и новой игрой довольно условная.

Отправлено FiEctro 01-11-2023 в 05:53:

Цитата:

Дядя Миша писал:
Так то не игра, а мод, баловство всякое.

В Паранойе 2 тоже вроде как монстров из других игр надёргали, не

Отправлено Дядя Миша 01-11-2023 в 05:59:

Цитата:

Crystallize писал:
На движках серии квейка разница между модом и новой игрой довольно условная.

Есть тотальные конверсии.

Цитата:

FiEctro писал:
В Паранойе 2 тоже вроде как монстров из других игр надёргали, не

Надо Элбера спрашивать, я в таком не шарю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-11-2023 в 13:02:

Цитата:

Дядя Миша писал:
Надо Элбера спрашивать, я в таком не шарю.

Кстати, а где он?

Отправлено MrThomasCooper 01-11-2023 в 19:41:

Дядя Миша кстати, где-то тут шла речь про плагин для блендера. Не планируешь включить в сдк?

Отправлено Дядя Миша 01-11-2023 в 20:15:

Есть плагин для импорта-экспорта в CSM, не за моим авторством.
Думаю его включить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 04-11-2023 в 17:15:

Ну чтож, работаю над документацией. Это двухсторонний процесс, т.к. я исправляю и саму документацию и параллельно удаляю то, что было создано но так и не пригодилось\утратило актуальность. Т.е. навожу ревизию.
А так же занимаюсь любимым занятием всех форкеров - переименовываю все папки, файлы, расширения и прочее. Папку sound в папку audio, условно говоря. Удивительное дело. Мне это занятие весьма нравилось в 2008-м, а сейчас с трудом себя заставляю.

Добавлено 04-11-2023 в 20:15:

Взглянул наконец на эту сталкеровскую чудо-карту, Живая Зона или как-то так она там называется. Ну это сразу не вариант. Там одна только геометрия больше гигабайта весит. Я её даже сдекомпилить не смогу на 32-х битах-то.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-11-2023 в 10:19:

Для тех, кто любит читать документацию и внимательно изучил документацию от прошлых выпусков, скорее всего возникнут вопросы, почему часть параметров, которая уже тогда была помечена как неиспользуемая, наконец-то исчезла, а часть - так и осталась висеть.
Я удаляю те или иные параметры, когда им появляется уже готовая новая система, которая не предполагает использование этих устаревших параметров. А если пока что никакой системы написано не было, то эти устаревшие параметры так и продолжают висеть. Использовать их невозможно, но и удалять я их пока не спешу. Речь о системе материалов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-11-2023 в 10:46:

Цитата:

Дядя Миша писал:
Взглянул наконец на эту сталкеровскую чудо-карту, Живая Зона или как-то так она там называется. Ну это сразу не вариант. Там одна только геометрия больше гигабайта весит. Я её даже сдекомпилить не смогу на 32-х битах-то.

Давай я помогу. Только распиши что делать надо

Со сталкером никогда не работал.

Отправлено Дядя Миша 05-11-2023 в 13:14:

Так тулзы для декомпиляции 32-х битные. Впрочем, насколько я понял, эту локацию никто не может разобрать даже нативными инструментами для сталкера. Да и смысла в этом никакого. У меня на видеокарте 1 гиг памяти всего.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 05-11-2023 в 14:37:

Дядя Миша
Кстати, а в ксаше будут разные современные плюшки, например, RTX или DLSS ?

Отправлено FiEctro 05-11-2023 в 15:02:

Цитата:

(_-=ZhekA=-_) писал:
Кстати, а в ксаше будут разные современные плюшки, например, RTX или DLSS ?

Для этого вулкан надо прикручивать. Да и видеокарты у ДМа нет нужной.
Впрочем к старому ксашу РТХ то прикрутили, пускай и костылями. Так что может найдутся энтузиасты.

Отправлено Дядя Миша 05-11-2023 в 15:27:

Цитата:

(_-=ZhekA=-_) писал:
Кстати, а в ксаше будут разные современные плюшки, например, RTX или DLSS ?

Пока что не думал об этом. Сначала весь базовый функционал, редактор опять же. А потом удовольствия. Но вообще странно, что эти лучи на OpenGL не работают.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-11-2023 в 15:44:

Цитата:

Дядя Миша писал:
Но вообще странно, что эти лучи на OpenGL не работают.

Через CUDA вроде можно, но будут ли работать именно RTX ядра неизвестно. Впрочем на форумах Нвидии пишут что можно выполнять трассировку на вулкане и передавать на отрисовку в OGL. Короче костылями всё можно.

Но лучше наверное использовать рендер чисто на вулкане для трассировки, благо такой проект на ксаш пилится, надеюсь его не забросят, можно и на новый двиг портировать эти наработки.

Отправлено (_-=ZhekA=-_) 05-11-2023 в 19:24:

Цитата:

FiEctro писал:
Для этого вулкан надо прикручивать.

Можно и ДХ12 обойтись

Отправлено Дядя Миша 05-11-2023 в 21:24:

Работаю над документацией. Исправляю, дополняю. Потом ещё придётся гайд по языку писать, хотя бы самый минимальный. Потому что предполагается что пользователи знакомы с С++ и немного в него умеют.
Впрочем - тут в сущности как в халфе. Мы его SDK редактировали вообще не зная никакого С++, просто делая по аналогии и ведь даже что-то получалось. Просто нам тогда Халфа немало палок в колёса навставляла, т.к. вальвовцы там целую кучу мин оставили. Ну а тут, понятно, виртуальная машина, думаю особых проблем не возникнет. Опять же, от вас будет обратная связь, по итогам которой я постараюсь внести в документацию самое неочевидное. Но скажу честно - как правило все эти объекты игровые пишут даже толком не зная языка и ничего, оно даже работает.

Потом, когда управлюсь с документацией, поставлю новую студию, надо попробовать собрать тулзы-плагины в 64 бита, посмотрим что из этого получится. Потом закрытое бета-тестирование SDK будет.
Ну и потом уже официальная версия. Я уже как-то привык к этому ритму, чтобы всё по десять раз заранее проверить, а не как тогда с параноей было - выложили и у половины форумчан незавелось, да чего за примером далеко ходить, вон у Жэки не завелось, я тогда чуть сума не сошёл. Почти неделю починяли.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-11-2023 в 07:28:

Цитата:

Дядя Миша писал:
Работаю над документацией. Исправляю, дополняю. Потом ещё придётся гайд по языку писать, хотя бы самый минимальный. Потому что предполагается что пользователи знакомы с С++ и немного в него умеют.

Это правильно

Цитата:

Дядя Миша писал:
Впрочем - тут в сущности как в халфе. Мы его SDK редактировали вообще не зная никакого С++, просто делая по аналогии и ведь даже что-то получалось.

Самое мерзкое в ХЛСДК то чтобы добавить какую ту фишку в халфе, её надо было прописать в разных местах. Те же пушки например прописывались и на клиенте и на сервере и ещё во всяких мелких файлах. Вот это нифига не интуитивно, не гибко и не удобно в принципе. Хорошо когда пользовательский код отделён от базового и новичкам не надо его разгребать, искать в каком месте его иницилизировать.

А вот примеры могут быть да, но лучше что отдельно от чистого проекта.

Цитата:

(_-=ZhekA=-_) писал:
Можно и ДХ12 обойтись

Вопрос совместимости шейдеров. Непонятно как ДМовский GLSL будет совместим с другими АПИ. В Юнити там свой CG/HLSL подобный язык который собирается под любой АПИ. Но конечно очень хотелось чтобы в будущем ксаш дружил с другими АПИшками, т.к. меня берёт сомнение что вслед за Эппл и Майкрософт в новых виндовсах откажется от поддержки OGL. Всётаки какой нить Вулкан хотя бы в зачаточном состоянии (абы заводилось) неплохо бы было иметь под крылом. Почему Вулкан, а не директ? Всё просто, вулкан кроссплатформенный, да и идеалогически ближе к GL/GLSL, плюс дружит со всеми новомодными фишками вроде RTX и DLSS. Но конечно не на данном этапе

Цитата:

Дядя Миша писал:
Я уже как-то привык к этому ритму, чтобы всё по десять раз заранее проверить, а не как тогда с параноей было - выложили и у половины форумчан незавелось, да чего за примером далеко ходить, вон у Жэки не завелось, я тогда чуть сума не сошёл. Почти неделю починяли.

Не завелось это не страшно, страшно когда забивают на баг репорты

Отправлено (_-=ZhekA=-_) 07-11-2023 в 07:31:

Цитата:

Дядя Миша писал:
а не как тогда с параноей было - выложили и у половины форумчан незавелось, да чего за примером далеко ходить, вон у Жэки не завелось, я тогда чуть сума не сошёл. Почти неделю починяли.

Около двух недель пытались решить все проблемы, если я не ошибаюсь.
На старте такого конечно быть не должно

Отправлено Дядя Миша 07-11-2023 в 07:56:

Цитата:

FiEctro писал:
чтобы добавить какую ту фишку в халфе, её надо было прописать в разных местах

Да, согласен.

Добавлено 07-11-2023 в 10:56:

Цитата:

FiEctro писал:
вслед за Эппл и Майкрософт в новых виндовсах откажется от поддержки OGL.

Билли грозился выкинуть поддержку OGL начиная с 95-й винды.
Но по факту эта поддержка появляется с драйверами на видеокарту, от микрософта тут ничего не зависит. Вот когда нвидия перестанет включать поддержку GL на новых карточках, точнее когда эти самые новые карточки перестанут поддерживать GL - вот тогда уже можно будет напрячься.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-11-2023 в 08:02:

Цитата:

Дядя Миша писал:
Вот когда нвидия перестанет включать поддержку GL на новых карточках, точнее когда эти самые новые карточки перестанут поддерживать GL - вот тогда уже можно будет напрячься.

Лучше заранее подготовить почву чтобы всю архитектуру перепахивать не пришлось. Я говорю - в зачаточном состоянии. Но не сейчас, тут с тобой согласен.

Отправлено Дядя Миша 07-11-2023 в 10:12:

Архитектура более чем подготовлена ко всему. Я над этой архитектурой не один год размышлял.

Offtop. Поиграл наконец в эту карту Сталкер Живая Зона.
Грузилось ужастно долго, ппц просто. Минут наверное 10 грузилось. Я честно говоря думал - вылетит. У меня на видеокарте один гигабайт памяти всего, кстати надо будет обновить видеокарту, взять хотя бы гигов на шесть.
Но как ни странно - загрузилось и заработало. Если ходить по окраинам карты, то в целом не тормозит даже, под сотку фпс выдаёт, но в центре где много домов, много геометрии, там до нуля падает и ничего не сделаешь.
Решение - смотреть себе под ноги и напевать песню.

Корочи на этой карте, представьте себе расположилось минимум 20 локаций, причём как из оригинального сталкера, так и новых. И все вместе они образуют закрытый город Припять. Правда ЧАЭС на этой локации нет, ну то как бы и фиг с ней. И знаете, ведь вполне неплохой городок - небольшие микрораёны, поликлиника, магазины, дома быта, рынки, ЖД-станция - ну вообщем всё что нужно для жизни. Хорошее дело такие вот городки, жаль что после развала СССР они превратились в депрессивные.
Или вот как в случае с Припяти - из-за аварии.

Теперь, собственно, немного технических данных:
1. На этой карте 86 лайтмап 1024х1024, как я понял там содержится только тень от солнца и ничего более. В любом случае на таких вот размерах уровней использовать лайтмапы не вариант.

2. Сам уровень весит на удивление мало, если взять без AI-сетки, лайтмап и упрощённой геометрии (я так до сих пор и не понял зачем она нужна), то всего-навсего 2.5 гигабайта, из них 1.25 гигабайта колоизация, 1.15 гигабайт видимая геометрия. Вот это кстати не понял, почему колоизация весит больше чем видимая геометрия. Такого быть ну точно не должно.

3. Лайтмапы эти весят 178 мегабайт. Ну в принципе терпимо, для такой карты-то.

4. Уровень сохранён в самый-пресамый обычный сталкеровский формат.
Это означает, что он целиком уместился в разрешение флоата. Уж не знаю сколько там квадратных километров, но бегать я по нему реально заманался. А я ведь толком и не глянул ничего, всё на бегу, носом в пол.

5. При попытке разобрать карту на запчасти декомпилятор ожидаемо вылетел с нехваткой памяти, ну оно и неудивительно.

На мой взгляд наполнить такую локацию геймплеем будет крайне непросто. А если и получится, то играть на ней можно будет неделями, причём большая часть времени уйдет просто на нарезание кругов. Вы учтите, что тут фактически закрытый город целиком уместился, люди ИРЛ годами в таком жили не покидая его. И ничего - не тянуло их куда-то.
На мой взгляд куда лучше взять вот такую локацию типа небольшого города и максимально наполнить её событиями. Чем делать тупые игры про космос, где ты большую часть времени летишь в грёбанной пустоте.
То есть если бы допустим на эту локацию со временем завезли геймплей - я бы с удовольствием вспоиграл. Впрочем думаю, что так оно и будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-11-2023 в 10:19:

Цитата:

Дядя Миша писал:
1. На этой карте 86 лайтмап 1024х1024, как я понял там содержится только тень от солнца и ничего более. В любом случае на таких вот размерах уровней использовать лайтмапы не вариант.

Цитата:

Дядя Миша писал:
3. Лайтмапы эти весят 178 мегабайт. Ну в принципе терпимо, для такой карты-то.

Так нормально с лайтмапами вышло, довольно немного весят, почему не вариант? Да ещё весь городище в гиг видеопамяти уместился. Красотища.

Отправлено Дядя Миша 07-11-2023 в 10:49:

Цитата:

FiEctro писал:
Да ещё весь городище в гиг видеопамяти уместился.

32 байта на вертекс как раз - позиция - 12 байт, UV текстуры\лайтмапы - 8 байт, TBN 9 байт и ещё три резервных байта на всякий случай.

Цитата:

FiEctro писал:
Так нормально с лайтмапами вышло, довольно немного весят

В ксаше бы они побольше весили - там же ещё несжимаемые карты лайтстилей. Хотя они не на каждую страницу спавнятся, могут и полностью отсутствовать.

Добавлено 07-11-2023 в 13:49:

А в сталкере нет никаких карт лайтстилей - там гвоздями всё прибито, то самое допущение - в этой странице рассеяный свет от солнца, в этой странице тень от солнца, в этой странице всё остальное освещение.
Понятное дело, что такая репрезентация только для аутдора и подходит.
Впрочем я посмотрю, может быть сделаю нечто вроде референсного стиля, когда каждая страница жестко может быть назначена на определённый стиль. Это несложно, но в рамках конкретной игры может оказаться полезным как раз для экономии видеопамяти. Главное что система в принципе гибкая и позволяет всякое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-11-2023 в 11:28:

Цитата:

Дядя Миша писал:
В ксаше бы они побольше весили - там же ещё несжимаемые карты лайтстилей. Хотя они не на каждую страницу спавнятся, могут и полностью отсутствовать.

Так, а почему в dds не схоронить развертку?

Отправлено Дядя Миша 07-11-2023 в 11:41:

Потому что там индексы лайтстилей, их нельзя сжимать с потерями.
Но можно сделать единую конфигурацию лайтстилей на все страницы - как в сталкере. Отключаемую разумеется. Тогда вся эта информация просто не понадобится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 10-11-2023 в 20:23:

Ну чтож, дописываю документацию по языку. Потом надо будет собрать плагин для джека в 64 бита и приступим к закрытому тестированию.

Добавлено 10-11-2023 в 23:23:

Закрытое тестирование - это совсем закрытое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 11-11-2023 в 16:26:

Основная документация по языку готова. Осталось написать ещё два приложения к документации.

Добавлено 11-11-2023 в 19:23:

Чтож, работы по написанию документации завершены. Разумеется она неполная, разумеется она будет в дальнейшем меняться, улучшаться и уточняться. Но она хотя бы есть. А ведь могло бы и вовсе никакой не быть, особенно в случае, когда продукт является opensource и его автор предполагает, что люди будут в нём разбираться, просто читая исходный код.

Добавлено 11-11-2023 в 19:26:

Пока что по документации не получено обратной связи в телеграм-канал ничего писать не буду, это ориентировочно воскресенье-понедельник.
Мне так же требуется произвести некоторые исправления и улучшения в утилитах конвертации и собрать плагин для джека в 64-бита.
И начнётся первичный закрытый процесс бета-тестирования SDK.
По его завершению будет опубликован SDK для официальных бета-тестеров.
К концу следующей недели ориентировочно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-11-2023 в 17:08:

Дядя Миша
Супер, ждём

Отправлено Дядя Миша 12-11-2023 в 15:57:

Сделал ревизию QuakeNT. Дописал недостающих монстров из платных эпизодов, прописал им эффекты, исправил кое-какие багги, в частности игрок не всегда хотел выныривать из воды.

Добавлено 12-11-2023 в 18:55:

Оформил движок в виде исполняемого файла. Это самое надёжное - можно быть уверенным, что такой движок запустится всегда. Соответственно, пользовательский запуск движка выглядит теперь примерно следующим образом:

C++ Source Code:

1	int APIENTRY WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow )

3	char cmdline[1024];

5	// generate final commandline

6	strncpy( cmdline, "bin\\xashnt_core32.exe -game quake ", sizeof( cmdline ) - 1 );

7	strncat( cmdline, lpCmdLine, sizeof( cmdline ) - 1 );

9	// run engine

10	return WinExec( cmdline, SW_SHOW );

1. Устанавливаем путь до исполняемого файла и добавляем обязательный параметр -game
2. добавляем пользовательские параметры командной строки
3. Запуск.

Вместо WinExec предпочительнее использовать CreateProcess, но здесь реально без разницы.

Добавлено 12-11-2023 в 18:57:

Так же обращаю ваше внимание на тот занятный факт, что теперь лаунчеры можно называть зарезервированными именами, небоясь что умный драйвер нвидии обрежет часть расширений, ну или еще какую пакость придумает.

Разумеется вы без проблем можете писать свои собственные лаунчеры, например на СиШарпе. Или на Делфи. Вообщем больше не стоит задача подгрузки некоей дллки, т.е. по силам даже самому начинающему программисту.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 12-11-2023 в 16:20:

Цитата:

Дядя Миша писал:
Сделал ревизию QuakeNT. Дописал недостающих монстров из платных эпизодов, прописал им эффекты, исправил кое-какие багги, в частности игрок не всегда хотел выныривать из воды.

Ты сделал чтобы при стрейфе не увеличивалась скорость?

Отправлено Дядя Миша 12-11-2023 в 17:27:

Это квар cl_sidespeed регулирует

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-11-2023 в 17:31:

Дядя Миша
Как работать с Дельтой в твоём движке? Есть ли аналог Start/FixedUpdate/Update/LateUpdate? Покажи примеры.

Отправлено Дядя Миша 12-11-2023 в 17:57:

Цитата:

FiEctro писал:
Как работать с Дельтой в твоём движке?

с какой дельтой? С delta.lst? Не трогать ни в коем случае, она еле держится, вот-вот отвалится.

Цитата:

FiEctro писал:
Есть ли аналог Start/FixedUpdate/Update/LateUpdate? Покажи примеры.

Нет, ничего такого нету. Есть Spawn, Precache, Activate и RunPhysics.
Но ты можешь их переименовать в Start\Update, если тебе так привычнее.
Это некритично.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-11-2023 в 18:03:

Цитата:

Дядя Миша писал:
с какой дельтой? С delta.lst? Не трогать ни в коем случае, она еле держится, вот-вот отвалится.

Дельта тайм.
Такая штука, чтобы события от фпс не зависили:

C++ Source Code:

transform.position += m_Velocity * Time.deltaTime;

Цитата:

Дядя Миша писал:
Нет, ничего такого нету. Есть Spawn, Precache, Activate и RunPhysics.

А зачем их было переименовывать? Вот и как теперь понять что где? В каком порядке они выполняются?

Отправлено Crystallize 12-11-2023 в 18:09:

Цитата:

FiEctro писал:
Дельта тайм.
Такая штука, чтобы события от фпс не зависили:

В халфе это зовется фреймтайм, я думал ты знаешь.

Отправлено FiEctro 12-11-2023 в 18:23:

Цитата:

Crystallize писал:
В халфе это зовется фреймтайм, я думал ты знаешь.

Всё что я знал с ХЛСДК я уже давно успешно позабыл. Да и не сказать что я там многого знал.

Отправлено Дядя Миша 12-11-2023 в 20:03:

Цитата:

FiEctro писал:
А зачем их было переименовывать?

Твой вопрос предполагает, будто бы я украл Юнити и всё там переименовал, чтобы никто не догадался.

Цитата:

FiEctro писал:
В каком порядке они выполняются?

Там всё видно прямо в скриптовом языке, в отличие от того же Юнити.
Ты же их сам и вызываешь.

Добавлено 12-11-2023 в 23:03:

Есть глобальные экспортные функции и они вызывают всё

C++ Source Code:

1	void EXPORT ServerActivate( void )

3	progs->ServerActivate();

6	void EXPORT ServerDeactivate( void )

8	progs->ServerDeactivate();

11	void EXPORT ServerStartFrame( void )

13	progs->ServerStartFrame();

16	void EXPORT ServerRunPhysics( int e )

18	progs->RunPhysicsForObject( e );

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-11-2023 в 20:23:

Цитата:

Дядя Миша писал:
Твой вопрос предполагает, будто бы я украл Юнити и всё там переименовал, чтобы никто не догадался.

А вдруг

? Впрочем в этом нет ничего плохого.

Цитата:

Дядя Миша писал:
Есть глобальные экспортные функции и они вызывают всё

Спасибо так понятнее.

Отправлено Дядя Миша 12-11-2023 в 20:49:

Движок не имеет права просматривать\вызывать ничего, пока пользователь ему явно это не разрешит. Т.е. скриптовая машина движком управляет, а не наоборот.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 14-11-2023 в 08:18:

Редкие кадры. Наверное всем интересно, что же там в сталкере за нормалки такие с диффузией ошибки, почему их так корёжит и нужны ли они вообще?
Ну вот вам два скриншота - первый без коррекции ошибок, а второй с коррекцией.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 14-11-2023 в 09:39:

А что он корректирует? Ещё у тебя у нормалей зелёный канал инвертирован.

Отправлено Дядя Миша 14-11-2023 в 11:37:

Цитата:

FiEctro писал:
А что он корректирует?

А ты между двумя картинками быстро попереключайся и все вопросы отпадут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 14-11-2023 в 12:23:

Дядя Миша
Я так и не понял, это артефакты сжатия dds?

Отправлено Дядя Миша 14-11-2023 в 12:52:

Ну да

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 14-11-2023 в 13:17:

А, ну в Юнити такой же есть. Хорошая штука.

Отправлено Дядя Миша 14-11-2023 в 20:24:

Что-то мне подсказывает, что это DXT-компрессор был калечный в те далёкие времена. Ну не должно быть таких артфактов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 14-11-2023 в 21:38:

При портировании ксашмода на NT ты учтешь замеченные баги? Например те что были исправлены в прайме? Или те что Айнекко нашел когда спецназ гоняет не с тем оружием которое выставлено?

Отправлено FiEctro 15-11-2023 в 05:52:

Crystallize
NT движок куда более масштабнее чем ксашмод.

Отправлено Дядя Миша 15-11-2023 в 06:29:

Цитата:

Crystallize писал:
Например те что были исправлены в прайме?

А что там в прайме было исправлено? Половину исправлений я же им и подсказал в своё время, но то что было сделано за последний год - я уже не участвовал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 15-11-2023 в 08:56:

В первую очередь в ксашмоде нужно исправить секвенции игрока - дерганье модели от третьего лица и так далее. Там что-то с гейтсеквенциями.
Я все жду того самого обновления ксашмода, который вроде как обещался (?) и надеюсь что там это профиксят.
Предвосхищая вопрос "что же вы сами за столько времени это не пофиксили", ну, копанием в коде ксашмода активно занимаюсь только я, а в прайме код рендера уже весь из паранои - и там SNMetamorph сейчас занимается конкретно графикой и вроде как залез в physx.
Мне в студиомодельрендере касаемо игрока не получается разобраться, а больше и некому.

__________________
Мой мод на Xash

Отправлено Дядя Миша 15-11-2023 в 09:10:

Я от своих слов не отказываюсь, но сроки пока называть не буду.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 15-11-2023 в 11:39:

Цитата:

Дядя Миша писал:
А что там в прайме было исправлено? Половину исправлений я же им и подсказал в своё время, но то что было сделано за последний год - я уже не участвовал.

Я знаю что своё ты всегда исправишь, но я имел в виду именно перенести те фиксы что успели раскопать без тебя.

Отправлено Дядя Миша 15-11-2023 в 11:52:

Цитата:

Crystallize писал:
перенести те фиксы что успели раскопать без тебя

Они не имели привычку писать в комментариях "Спасибо дядя Мише, за то что указал на баг". Откуда ты знаешь, что они раскопали без меня, а что с моей помощью?

Обсуждение тех или иных багфиксов велось в телеге приватно.

Добавлено 15-11-2023 в 14:52:

Скрытый текст:

Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 15-11-2023 в 13:44:

Цитата:

Aynekko писал:
В первую очередь в ксашмоде нужно исправить секвенции игрока - дерганье модели от третьего лица и так далее. Там что-то с гейтсеквенциями.
Я все жду того самого обновления ксашмода, который вроде как обещался (?) и надеюсь что там это профиксят.
Предвосхищая вопрос "что же вы сами за столько времени это не пофиксили", ну, копанием в коде ксашмода активно занимаюсь только я, а в прайме код рендера уже весь из паранои - и там SNMetamorph сейчас занимается конкретно графикой и вроде как залез в physx.
Мне в студиомодельрендере касаемо игрока не получается разобраться, а больше и некому.

Не надо пока бежать впереди паровоза. Подождите пока NT СДК выйдет и стабилизируется, появятся новые утилиты и т.д.

Отправлено Дядя Миша 15-11-2023 в 13:58:

Товарищи, вы ещё учитывайте, что обновление старого ксаша будет так или иначе привязано к новому. Чтобы в старом ксаше появились некоторые возможности нового - в частности поддержка формата .csm.
Это хороший формат и я его буду всячески рекомендовать для использования.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 15-11-2023 в 14:34:

Цитата:

Дядя Миша писал:
Они не имели привычку писать в комментариях "Спасибо дядя Мише, за то что указал на баг". Откуда ты знаешь, что они раскопали без меня, а что с моей помощью?

А просто по дате фикса это нельзя однозначно отделить? Был конкретный момент когда ты перестал им помогать?

Отправлено Дядя Миша 15-11-2023 в 14:45:

Цитата:

Crystallize писал:
А просто по дате фикса это нельзя однозначно отделить?

Разумеется нельзя.

Цитата:

Crystallize писал:
Был конкретный момент когда ты перестал им помогать?

Они спрашивали - я отвечал. Постепенно они набрались опыта и теперь неплохо справляются сами.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 15-11-2023 в 21:26:

Цитата:

Дядя Миша писал:
вы ещё учитывайте, что обновление старого ксаша будет так или иначе привязано к новому

Это очень радует, хотелось бы, чтобы ксашмод обновлялся параллельно XashNT. Лукавить не буду, тут чисто мой шкурный интерес, т.к. у меня на нем весь мод базируется и переезжать я никуда не буду (даже на прайм).

Цитата:

FiEctro писал:
Подождите пока NT СДК выйдет и стабилизируется, появятся новые утилиты

Так а NT тут причем? Речь про ксашмод. По опыту скажу, что иногда полезно переключаться между проектами.

Цитата:

Crystallize писал:
Был конкретный момент когда ты перестал им помогать?

Мои проблемы с ксашмодом имели полярный характер. Либо "я могу это сам сделать" (поэтому спрашивать не надо), либо "там полная ж..., а у Дяди Миши нет времени". Другого не дано

__________________
Мой мод на Xash

Отправлено Дядя Миша 16-11-2023 в 06:25:

Цитата:

Aynekko писал:
По опыту скажу, что иногда полезно переключаться между проектами.

Да давайте, я сейчас что-то там в ксаш-мод прикручу, а потом оно в родительском проекте поменяется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 16-11-2023 в 06:25:

Цитата:

Aynekko писал:
Это очень радует, хотелось бы, чтобы ксашмод обновлялся параллельно XashNT. Лукавить не буду, тут чисто мой шкурный интерес, т.к. у меня на нем весь мод базируется и переезжать я никуда не буду (даже на прайм).

Так сам же пишешь у вас своя ветка есть с уже пофикшенными багами. Зачем дёргать ДМ?

Отправлено Aynekko 16-11-2023 в 08:14:

Цитата:

FiEctro писал:
Так сам же пишешь у вас своя ветка есть с уже пофикшенными багами. Зачем дёргать ДМ?

У вас - это у кого? У меня свой форк (заточенный конкретно под мод), у прайма свой (причем там клиент по большей части параноя 2, а сервер ксашмодовский).
Есть баги, которые я не в силах пофиксить из-за недостаточных знаний/умений, а SNMetamorph занят другим и ему не до этого. Мне больше не к кому идти.

__________________
Мой мод на Xash

Отправлено SNMetamorph 16-11-2023 в 22:03:

Цитата:

Дядя Миша писал:
в частности поддержка формата .csm.

Так что он в итоге умеет вообще? Когда я последний раз о нём слышал, он кроме хранения геометрии + кастомной даты никаких функций больше не предоставлял.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 17-11-2023 в 07:34:

Хранит статичную геометрию - позицию вертекса, нормаль, цвет и два UV-канала, для текстуры и лайтмапы. Компилятор уровней, загружая эту модель дополннительно её обрабатывает - генерирует развертку лайтмапы.

Цитата:

SNMetamorph писал:
кроме хранения геометрии + кастомной даты никаких функций больше не предоставлял.

А какие функции он по твоему должен ещё предоставлять?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 17-11-2023 в 07:35:

Цитата:

Дядя Миша писал:
Хранит статичную геометрию - позицию вертекса, нормаль, цвет и два UV-канала, для текстуры и лайтмапы. Компилятор уровней, загружая эту модель дополннительно её обрабатывает - генерирует развертку лайтмапы.

Кстати, а что с порталами? У меня была такая мысль, а что если разбивать основной уровень изначально на несколько сеток? Возможно это как то автоматизировать? Для брашей можно сделать какой нить VisGroup по аналогии с обычными группами в хаммере. А компилятор просто будет записывать кто кого видит, а кого нет.

Тогда и детайлы делать не нужно.

Отправлено ZGreen 17-11-2023 в 08:08:

Компилятор виз изобретен заново. А вообще интересное стремление работу компьютера перекладывать на человека. Хотя надо-то наоборот. Каждый раз в этом контексте вспоминаю свое стремление подрисовать лайтмЭпы в фотошопе.

Отправлено FiEctro 17-11-2023 в 08:57:

Цитата:

ZGreen писал:
Компилятор виз изобретен заново. А вообще интересное стремление работу компьютера перекладывать на человека. Хотя надо-то наоборот. Каждый раз в этом контексте вспоминаю свое стремление подрисовать лайтмЭпы в фотошопе.

На больших картах с большой детализацией врядли кармаковский виз будет работать эффективно, тоже касается и лайтмап в том виде в котором они хранятся в БСП. Оно больше было заточено под софтварный рендер. Да и не надо лукавить, всякие хинты и порталы тоже надо расставлять в первой и второй халфе, просто все кладут на это болт.

ДМ рассказал что можно определять детайлы по разделению их от общей сетки, а я предложил дальнейшее развитие.

Отправлено Дядя Миша 17-11-2023 в 10:27:

Цитата:

FiEctro писал:
Для брашей можно сделать какой нить VisGroup по аналогии с обычными группами в хаммере

Уже сделано. Правда он пока используется для принудительного разбиения лайтмап чтобы она сама на себя не замкнулась. Это довольно редкая ситуация, но встречается. Например в кваке на e1m1, там где этот спуск с кнопками. Лайтмапа на дорожке замыкается сама на себя, я попытался всё это автоматически разрулить, но в итоге ерунда получилась. То есть разрулить то конечно возможно и даже надёжно, но лайтмапа начнёт слишком часто прерываться, эта штука перестраховывается. Будет больше швов. Хотя по логике эти швы там где они в принципе и должны быть, но всё равно не слишком красиво - ведь их может не быть совсем.

Цитата:

FiEctro писал:
а что если разбивать основной уровень изначально на несколько сеток?

Если ты лепишь домики на ландшафт, то технически ты уже разбил уровень на сетки. Каждый домик - это сектор. Остаётся только в оконные и дверные проёмы поставить портал-браш. Что собственно и было сделано в сталкере.
Но там тему недокрутили до конца, у них же нет BSP-дерева.
Нам просто надо проанализировать эти домики и пометить structural-поверхности. И пропустить их в дерево. Ну и собственно всё, дальше дерево строится, как будто мы имели дело с обычными брашами, корректно домики попадают в дерево и их внутренности образуют новый сектор. Весь вопрос только в том, как отделить структурные полигоны от детальных и не пропустить часть структурных. Простой пример - стены у домика однозначно станут структурными полигонами, но есть ещё к примеру поколодники, которые должны вровень выпирать, а это, сами понимаете, не такое простое дело.
Если поколодник не попадёт в структурные брашы, то внутренность домика не станет герметичной и новый сектор не образуется.
Конечно когда для ксаша будут делать полностью новые уровни, то структурную геометрию могут явно отделить в новую группу и пометить её - это проще и надежнее. Но и автоматические детекторы тоже должны присутствовать. Чтобы был выбор.
К примеру вы в курсе, что компилятор у меня автоматически определяет какие полигоны осветить повертексно, а на какие наложить лайтмапу?
Нет, ему можно это явно указать, но он умеет и сам. Все сталкеровские карты скопилены именно с автоматическим определением повертексное\лайтмапа, можете включить показ лайтмапы и убедиться что механизм отлично справляется. А ведь это гораздо сложнее чем отдуплить структурные поверхности от детальных.

Цитата:

FiEctro писал:
На больших картах с большой детализацией врядли кармаковский виз будет работать эффективно

На аутдор-сценах никто виз и не использует. Порталы + HOM, иначе никак.
Причём я планирую HOM-геометрию тоже генерировать автоматически, это не так уж и сложно.

Добавлено 17-11-2023 в 13:12:

FiEctro я твою картинку не понял. Каким образом у тебя Сетка 1 попадает во фрустум и не рисуется при этом?
И где в таком случае порталы? То что сетки друг с другом соприкасаются не значит ничего. Равно как и форма сектора может быть произвольной, втч и вогнутой, это ни на что не влияет.

Добавлено 17-11-2023 в 13:20:

Вот картинку нарисовал, чтобы лучше понимали как устроена портально-пассажная система в XashNT.

Зелёная точка - игрок, жёлтые линии - фрустум, красные полоски - порталы.
Игрок видит сектор1 (потому что он сам находится в нём), сектор 2, сквозь портал, а вот сектор 3 - не видит, потому что портал между вторым и третьим сектором во фрустум не попал.
В той же кваке виз работал иначе. Там угол обзора брался равным 180 градусов, т.е. из первого сектора третий было видно ВСЕГДА.
Ну а в ксаше даже второй сектор может исчезнуть из поля видимости, если игрок отвернётся.

Добавлено 17-11-2023 в 13:22:

Важно понимать, что сектор это полувиртуальное понятие, он как бы не существует в реальности. От него остаётся только уникальный номер, а других характеристик он не имеет. Но зато и батчи геометрии знают, к какому сектору они принадлежат и порталы это тоже знают.
А большего и не требуется.

Добавлено 17-11-2023 в 13:23:

Ну и да - вся геометрия рубится по порталу, если в материале не включён запрет на это дело. Абсолютно вся - колоизационная, брашы, мешы, патчи, ландшафты, дисплейсменты.

Добавлено 17-11-2023 в 13:27:

Цитата:

Дядя Миша писал:
На аутдор-сценах никто виз и не использует

Тут требуется пояснение. В XashNT на данный момент отсечение геометрии это фрустум + порталы, в дальнейшем добавится ещё HOM.
Иными словами вот те уровни квейка - они все вручную портализованы.
Причём там как получается - если портал поставить прямо внутрь двери, то дверь его подхватывает и начинает открывать и закрывать вместе с собой.
Но можно и без дверей ставить, просто в дверных проёмах.
Я бы с удовольствием эти порталы расставил автоматически, но пока не могу подобрать необходимые допущения, это ведь далеко не так просто, как кажется. Когда у меня будет собственный редактор и я смогу визуализировать свои эксперименты (да, вся автоматика, которая есть сейчас была сделана вслепую, просто вследствии чёткого понимания, как это будет работать), то смогу сделать гораздо более впечатляющие анализаторы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 17-11-2023 в 10:45:

Цитата:

Дядя Миша писал:
А какие функции он по твоему должен ещё предоставлять?

Ну как минимум анимации хотя бы. Или под статику и динамику разные форматы?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено FiEctro 17-11-2023 в 11:36:

Цитата:

Дядя Миша писал:
FiEctro я твою картинку не понял. Каким образом у тебя Сетка 1 попадает во фрустум и не рисуется при этом?
И где в таком случае порталы? То что сетки друг с другом соприкасаются не значит ничего. Равно как и форма сектора может быть произвольной, втч и вогнутой, это ни на что не влияет.

В целом наверное да, немного неправильно. Но идея не в фрустуме. А в том чтобы разбивать основной меш на сегменты ещё на этапе создания карты.

Цитата:

Дядя Миша писал:

Уже сделано. Правда он пока используется для принудительного разбиения лайтмап чтобы она сама на себя не замкнулась. Это довольно редкая ситуация, но встречается.

Это как? Когда её в кольцо запирает и начинает выпучивать как потолки на спонзе?

Цитата:

Дядя Миша писал:
То есть разрулить то конечно возможно и даже надёжно, но лайтмапа начнёт слишком часто прерываться, эта штука перестраховывается. Будет больше швов.

В сети есть бесплатные разворачивальщики - Xatlas например. Кармаковская система больше под софтварный рендер заточена, не факт что она вообще способна работать без разбиения всего и вся. Хотя у Xatlas тоже иногда бывают свои причуды если ему битую геометрию скормить.

Цитата:

Дядя Миша писал:
Если ты лепишь домики на ландшафт, то технически ты уже разбил уровень на сетки. Каждый домик - это сектор. Остаётся только в оконные и дверные проёмы поставить портал-браш. Что собственно и было сделано в сталкере.
Но там тему недокрутили до конца, у них же нет BSP-дерева.
Нам просто надо проанализировать эти домики и пометить structural-поверхности. И пропустить их в дерево. Ну и собственно всё, дальше дерево строится, как будто мы имели дело с обычными брашами, корректно домики попадают в дерево и их внутренности образуют новый сектор. Весь вопрос только в том, как отделить структурные полигоны от детальных и не пропустить часть структурных. Простой пример - стены у домика однозначно станут структурными полигонами, но есть ещё к примеру поколодники, которые должны вровень выпирать, а это, сами понимаете, не такое простое дело.
Если поколодник не попадёт в структурные брашы, то внутренность домика не станет герметичной и новый сектор не образуется.
Конечно когда для ксаша будут делать полностью новые уровни, то структурную геометрию могут явно отделить в новую группу и пометить её - это проще и надежнее. Но и автоматические детекторы тоже должны присутствовать. Чтобы был выбор.

Если домик модель, врядли кто то будет делать его единым мешем, во всяком случае стен со стульями. Подоконник ещё могут, но это просто коробка которая ни на что особо не влияет.

Цитата:

Дядя Миша писал:
К примеру вы в курсе, что компилятор у меня автоматически определяет какие полигоны осветить повертексно, а на какие наложить лайтмапу?
Нет, ему можно это явно указать, но он умеет и сам. Все сталкеровские карты скопилены именно с автоматическим определением повертексное\лайтмапа, можете включить показ лайтмапы и убедиться что механизм отлично справляется. А ведь это гораздо сложнее чем отдуплить структурные поверхности от детальных.

Это вообще не понял. Помню ты говорил что в повертексном освещении никакого смысла вообще нет.

Цитата:

SNMetamorph писал:
Ну как минимум анимации хотя бы. Или под статику и динамику разные форматы?

Ну да, по идее карты лучше хранить как Static mesh. А вот загружать как раз файлы сцен где могут быть эти статик меши в любом количестве, а так же всякие объекты и скрипты. Ведь на одной сцене может быть не одна "БСПшка", а несколько. К тому же это позволяет грузить карты асинхронно т.е. бесшовно. А в случае подгрузки "БСПшек" друг в друга получим рекурсию.

Цитата:

Дядя Миша писал:
На аутдор-сценах никто виз и не использует. Порталы + HOM, иначе никак.
Причём я планирую HOM-геометрию тоже генерировать автоматически, это не так уж и сложно.

Посмотри каналы и дорогу в хл2. Там довольно интересный подход к оптимизации оутдуров. Да и потом оутдур это не обязательно коробка, он может быть буквой Г, П и всех видов фигур из тетриса, или вообще змейкой. Да ещё и по любой оси.

Цитата:

Дядя Миша писал:
Причём там как получается - если портал поставить прямо внутрь двери, то дверь его подхватывает и начинает открывать и закрывать вместе с собой.

А как это работает?

Добавлено 17-11-2023 в 14:36:

Цитата:

Дядя Миша писал:
Причём там как получается - если портал поставить прямо внутрь двери, то дверь его подхватывает и начинает открывать и закрывать вместе с собой.
Но можно и без дверей ставить, просто в дверных проёмах.

Я не совсем понимаю как определяет Vis видимость. Но предположим можно было бы сделать таким образом - Вот у нас есть 1 полигон в секторе1 у него есть нормаль которая смотрит в сторону сектора 2, и собственно из этого полигона кидается трейс который пытается обнаружить полигоны в секторе 2 нормаль которых смотрит в его сторону, если таких нет то переходим к следующему полигону сектора 1 который так же перебирает все полигоны сектора 2. И вот если хоть один из полигонов увидит полигон из другого сектора, и между ними нет препятствий ввиде других полигонов из нашего сектора или какого либо другого, то помечаем их как видимые. Если нет, то нет. Конечно это слишком упрощённый и неэффективный вариант, но думаю смысл ты поймёшь. Самое забавное что замкнутость уровня в таком случае не нужна.

Отправлено ZGreen 17-11-2023 в 11:45:

Вот и виз с трейсами подъехал.

Цитата:

FiEctro писал:
Кармаковская система больше под софтварный рендер заточена

Особенно лайтмапы из ку3 под софтварный рендер заточены, которого в игре и нет вовсе.

Отправлено FiEctro 17-11-2023 в 11:50:

Цитата:

ZGreen писал:
Вот и виз с трейсами подъехал.

Я как раз и пытаюсь опираться на имеющиеся системы.
Собственно как то так я понимаю работу VIS:

Только тут ни порталы, ни замкнутые системы не нужны получается?

Цитата:

ZGreen писал:
Особенно лайтмапы из ку3 под софтварный рендер заточены, которого в игре и нет вовсе.

Под ку3 не маппал, так что не знаю как там. Но вполне допускаю что какое либо наследие могло там быть.

Отправлено Crystallize 17-11-2023 в 12:13:

Порталы в окнах домика это я так понял совсем не то что функ-порталы в ксашмоде?

Можешь показать сравнение одинаковой геометрии с тру-индиректом из HL против индиректа по полусфере из NT?

Цитата:

FiEctro писал:
Да и не надо лукавить, всякие хинты и порталы тоже надо расставлять в первой и второй халфе, просто все кладут на это болт.

В халфе пространство нормально визилось автоматически, хинты нужны были для коррекции каких-то хитрых случаев и для ускорения виза (или это миф, я забыл). А в новом ксаше не поставишь портал-вообще ничего не отвизится.

Добавлено 17-11-2023 в 19:13:

Цитата:

А почему условие нельзя сделать

Отправлено FiEctro 17-11-2023 в 12:14:

Цитата:

Crystallize писал:
В халфе пространство нормально визилось автоматически, хинты нужны были для коррекции каких-то хитрых случаев и для ускорения виза (или это миф, я забыл). А в новом ксаше не поставишь портал-вообще ничего не отвизится.

Там и аутдуров больших не было.

Отправлено ZGreen 17-11-2023 в 12:32:

Ёмое, какие-то полигоны друг друга проверяют, что такое я прочитываю?

Отправлено Crystallize 17-11-2023 в 14:14:

Цитата:

FiEctro писал:
Там и аутдуров больших не было.

В аутдорах всё равно не поможет ничего, ну разве что это будут какие-то каньоны как в Кризисе, которые тоже можно перегородить хинтом или ареапорталом.

Добавлено 17-11-2023 в 21:14:

ZGreen Может это дырки?

Отправлено FiEctro 17-11-2023 в 14:30:

Цитата:

ZGreen писал:
Ёмое, какие-то полигоны друг друга проверяют, что такое я прочитываю?

Сетка проверяет видимость другой сетки.

Отправлено Дядя Миша 17-11-2023 в 15:17:

Цитата:

SNMetamorph писал:
Ну как минимум анимации хотя бы

Есть же smd, чем он плох?

Цитата:

FiEctro писал:
разбивать основной меш на сегменты ещё на этапе создания карты.

На какие сегменты?

Цитата:

FiEctro писал:
Это как? Когда её в кольцо запирает и начинает выпучивать как потолки на спонзе?

чего-чего? Заврапленная лайтмапа начинает рисовать свет, там где по смыслу должна быть тень.

Цитата:

FiEctro писал:
Кармаковская система больше под софтварный рендер заточена

Объясни, с чего ты взял, что у меня там Кармаковская система?

Цитата:

FiEctro писал:
Помню ты говорил что в повертексном освещении никакого смысла вообще нет.

Есть, если площадь полигонов меньше одного люкселя и объект замкнутый. Лайтмапа на таких не очень смотрится.

Цитата:

FiEctro писал:
Да и потом оутдур это не обязательно коробка, он может быть буквой Г, П и всех видов фигур из тетриса, или вообще змейкой.

Аутдор буквой Г - это коридор, которому верх покрасили в небо. Делается не от хорошей жизни, а потому что честный аутдор движок не тянет.

Цитата:

FiEctro писал:
А как это работает?

Так я же только что объяснил - ставишь портал так, чтобы его браш задевал или даже попал внутрь браша\модели двери. И тогда дверь может его контролировать.

Цитата:

FiEctro писал:
Я не совсем понимаю как определяет Vis видимость

У меня сейчас не очень много времени, но я году в 21-м писал про это очень подробно в этой же теме, надо только найти. Поэтому тезисно:
1. пространство разбивается деревом.
2. у каждого лифа есть поверхности.
3. там где поверхностей нет - спавнятся порталы между двумя лифами.
4. для оптимизации можно объединять лифы в кластеры по некоторым признакам (ку2, ку3). Но можно оставить как есть (ку1).
5. Дальше запускаем портал-флоу. Это очень простая операция, берём портал и проверяем из него видимость другого портала, считая что у нас параллельное зрение (или FOV 180, если кому-то непонятно). Но! Каждый пройденный насквозь портал отсекает часть нашего зрения, потому через 4-5 проходов видимость прервётся так или иначе, за углом очередного коридора. Корочи смысл тот же - секторы-порталы, только в роли секторов - лифы. Лифов дохрена, получается комбинаторный взрыв, поэтому виз так долго и считает. Ну зато ничего вручную расставлять и то не надо.

Цитата:

FiEctro писал:
Конечно это слишком упрощённый и неэффективный вариант

Это то что каждому приходит первым делом в голову и не годится ни для какого реального применения на практике.

Цитата:

FiEctro писал:
Только тут ни порталы, ни замкнутые системы не нужны получается?

Портальный рендеринг основан на допущениях, допущения, это великая вещь, которая позволяет создавать вещи, кажущиеся невозможными. Так вот допущения у нас в следующем - из любого сектора бывают выходы ТОЛЬКО ПОРТАЛЫ. Никаких случайных дыр там нет и быть не может. И вот используя это обстоятельство, мы просто-напросто берём и проверяем видно ли из окна одного портала - другой портал.
Эта операция занимает сотые доли микросекунды и всегда абсолютно надёжна. Но нужен препроцессинг, которого сейчас все боятся.

Добавлено 17-11-2023 в 18:16:

Цитата:

Crystallize писал:
против индиректа по полусфере из NT?

По полусфере это не индирект как таковой, а атмосферное рассеяние света.
Эта штука например не может осветить нижнюю часть листьев на деревьях.
Но зато, будучи рассчитанной один раз годится для всего дневного цикла, это весьма удобно, поэтому такую лайтмапу юзают в динамических рендерах.

Цитата:

Crystallize писал:
А в новом ксаше не поставишь портал-вообще ничего не отвизится.

Но хотя бы откуллится.

Цитата:

Crystallize писал:
А почему условие нельзя сделать

Условие - не ставить портал внутрь двери. Никто же не заставляет.

Добавлено 17-11-2023 в 18:17:

Цитата:

Crystallize писал:
В аутдорах всё равно не поможет ничего

Ну HOM поможет, но так. Если хоть что-то друг-друга загораживает.
А если вот прямо ровная плоскость и на ней тысячи ёлок, то да, жопа.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 17-11-2023 в 17:36:

Цитата:

Дядя Миша писал:
Условие - не ставить портал внутрь двери. Никто же не заставляет.

А ты сделай if в коде двери. Или в коде мовевитча.

Добавлено 18-11-2023 в 00:36:

Цитата:

Дядя Миша писал:
Ну HOM поможет, но так. Если хоть что-то друг-друга загораживает.
А если вот прямо ровная плоскость и на ней тысячи ёлок, то да, жопа.

А если перевести оценку видимости с 0-1 на 10-15 градаций? Если виз распухает то увеличить размер лифов.

Отправлено Aynekko 17-11-2023 в 17:41:

В xash3d/ксашмоде очень кстати не хватает такой оптимизации, что при закрытой двери отсекалось бы все то, что за ней. Понятно, что двери могут быть и прозрачные, но допустим даже если по флагу "отсекать видимость".

__________________
Мой мод на Xash

Отправлено ZGreen 17-11-2023 в 17:47:

В хл2, если кто помнит, ареапорталы даже в выбитых окнах работали -- просто изображение в них заблюривалось и портал закрывался.

Отправлено Дядя Миша 17-11-2023 в 18:24:

Цитата:

Crystallize писал:
А ты сделай if в коде двери.

Сами сделаете, если так хочется.

Цитата:

Crystallize писал:
А если перевести оценку видимости с 0-1 на 10-15 градаций?

Чего-чего?

Цитата:

Aynekko писал:
В xash3d/ксашмоде очень кстати не хватает такой оптимизации, что при закрытой двери отсекалось бы все то, что за ней

Формат уровней не позволяет же.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ZGreen 17-11-2023 в 20:09:

Цитата:

Дядя Миша писал:
Чего-чего?

От "отчетливо видно", до "почти не видно", наверное.

Отправлено Дядя Миша 17-11-2023 в 21:31:

Отсекать одни ёлки другими бессмысленно - эта операция займет больше времени чем их отрисовка. Вот если скажем гора, а за ней ёлки - тут у нас сплошной профит получается.

Добавлено 18-11-2023 в 00:31:

Поэтому только туман + дальняя плоскость.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Aynekko 18-11-2023 в 06:36:

А можно, например, сделать такую оптимизацию?
Например, сначала у нас рисуются браши, потом модели. Есть чистое поле. Стоит брашевая стена, непрозрачная, пусть даже func_wall (видимость не отсекает). Но модели за этой стеной все равно рисуются, хотя игрок их не видит. Нельзя как-то сравнить масштабы стены и глубину, делать нужные проверки и вообще не вызывать рендер этих моделей?

__________________
Мой мод на Xash

Отправлено Дядя Миша 18-11-2023 в 07:46:

Цитата:

Aynekko писал:
Нельзя как-то сравнить масштабы стены и глубину, делать нужные проверки и вообще не вызывать рендер этих моделей?

Это и есть HOM - софтварная растеризация в маленький буффер глубины для окклюзии.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ZGreen 18-11-2023 в 07:49:

Мне кажется, на производительность в контексте Ксаша больше повлияет склеивание нескольких моделей в одну, чем такие вычисления. Учитывая, что моделька проверяется на видимость по своему оригину, то как быть в твоем случае, если стенка перекрывает оригин модели, скажем, опоры ЛЭП?

Отправлено Aynekko 18-11-2023 в 08:15:

Цитата:

ZGreen писал:
на производительность в контексте Ксаша больше повлияет склеивание нескольких моделей в одну

Тут подтверждаю. Я изначально на outdoor-карте делал горы из отдельных камушков, каждый из которых был энтитей, их там могло быть штук 50-70 в кадре. Потом, спасибо Психопату за замечательную прогу, я смог перекомпилить bsp в модель (выделив нужные камушки и поместив их в отдельную карту) и таким образом поставил их одной энтитей, тем самым нехило подняв фпс - рисовалось-то за один вызов.
Но такое можно сделать далеко не всегда, все не объединишь.

__________________
Мой мод на Xash

Отправлено ZGreen 18-11-2023 в 08:20:

Ну так на то и дан разработчику живой ум, чтобы эту задачу решать в жестких рамках.

Отправлено Aynekko 18-11-2023 в 08:34:

Цитата:

ZGreen писал:
Учитывая, что моделька проверяется на видимость по своему оригину, то как быть в твоем случае, если стенка перекрывает оригин модели, скажем, опоры ЛЭП?

Забыл отписать.
Нет, я предполагал, что это не так работает. Вот скажем есть квадратная стена.
Пусть она совпадает с нашим условием, что она полностью непрозрачная. Мы ее проецируем на экранные координаты и каким-то образом обозначаем ее дистанцию от экрана.
Далее рисуем модели. Точно также проецируем ббокс (а не оригин) модели на экран, проверяем дальность видимости. Если модель за стеной и ббокс вписан в наш некий "бокс окклюзии", то рендер модели даже не будем вызывать, не тратя время ни на gl-функции, ни тем более на шейдер.

__________________
Мой мод на Xash

Отправлено FiEctro 18-11-2023 в 11:25:

Цитата:

ZGreen писал:
Учитывая, что моделька проверяется на видимость по своему оригину

Кстати по мне это самое тупое что можно только использовать в этом случае. Уж лучше тогда по хитбоксу.

Отправлено Дядя Миша 18-11-2023 в 15:24:

Цитата:

Aynekko писал:
Пусть она совпадает с нашим условием, что она полностью непрозрачная. Мы ее проецируем на экранные координаты и каким-то образом обозначаем ее дистанцию от экрана.

и вот у нас получилась программная растеризация в буффер глубины для окклюзии.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 19-11-2023 в 09:41:

Цитата:

Aynekko писал:
А можно, например, сделать такую оптимизацию?
Например, сначала у нас рисуются браши, потом модели. Есть чистое поле. Стоит брашевая стена, непрозрачная, пусть даже func_wall (видимость не отсекает). Но модели за этой стеной все равно рисуются, хотя игрок их не видит. Нельзя как-то сравнить масштабы стены и глубину, делать нужные проверки и вообще не вызывать рендер этих моделей?

То что ты описал, называется occlusion culling, и там есть несколько разных подходов для него. Вообще не сильное, но вполне ощутимое ускорение в такой ситуации может дать банальный depth pre-pass, особенно если шейдеры какие-то тяжелые.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 01-12-2023 в 12:43:

Чтож, SDK выложен, миграция на новый форум продолжается, но эта тема ещё не потеряла своей актуальности. Она будет закрыта по достижению 256-страниц. Сейчас мы на 224-й странице.
Вторая часть блога разработчика выйдет уже на новом форуме.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 01-12-2023 в 12:48:

Дядя Миша
Обнови первый пост что ты мигрировал на новый ресурс. А то малоли найдутся ещё слоупоки которые всё пропустили.

Отправлено Дядя Миша 01-12-2023 в 12:49:

F.A.Q. обновил, естественно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 01-12-2023 в 21:06:

А что за новый форум?

Отправлено Cybermax 02-12-2023 в 00:55:

(_-=ZhekA=-_) https://t.me/xashnt/102

__________________
ㅤ

Отправлено Decay 02-12-2023 в 10:35:

Дядя Миша, ты писал в закрытой ветке в уже закрытой теме, что в гта могли текстуры загрузиться, а коллизия нет, и игрок проваливался. За всю жизнь не помню такого даже в самых старых III и VC. А вот наоборот, когда текстуры не догрузились — да, это всем известные удары самолета об невидимые столбы и деревья например
https://www.youtube.com/watch?v=gvFcg_Rc8_I
https://www.youtube.com/watch?v=tSGuWyxRhBc

Отправлено FiEctro 02-12-2023 в 10:40:

Забавно что в старых ГТА можно провалиться уже на загруженных локациях

Отправлено Дядя Миша 02-12-2023 в 10:41:

Decay зайди пожалуйста в закрытую ветку и следуй инструкциям.

Цитата:

Decay писал:
А вот наоборот, когда текстуры не догрузились — да

Ну может напутал, давно дело было.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 02-12-2023 в 10:46:

Decay я помню такое. Но и текстуры в таких случаях успевали загрузить только один из самых мутных мипов.

Отправлено Camblu_Buildovich 04-12-2023 в 07:23:

Дядь Миш, А можно ли и куда-нибудь на рдаче сохранить первоначальные логин-пасс на новый форум?

__________________

Цитата:

КСМ это форум украинских нацистов и в администрации нет адекватов.

Отправлено Дядя Миша 04-12-2023 в 08:29:

Camblu_Buildovich в телеграме есть, ссылка на телегу у меня в подписи.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Camblu_Buildovich 08-12-2023 в 18:08:

А форум бесшовной реальности надолго прилег?

__________________

Цитата:

КСМ это форум украинских нацистов и в администрации нет адекватов.

Отправлено Дядя Миша 08-12-2023 в 20:41:

Работы ведутся, может быть недоступен, да.
Уже работает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 14-12-2023 в 04:27:

Можно ли считать переезд на другой форум концом эпохи xash.ru? Как раньше считали переезд на КСМ?

Отправлено Дядя Миша 14-12-2023 в 06:34:

Ещё 32 страницы нам тут флудить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 14-12-2023 в 14:29:

Crystallize
Дык эпоха xash.ru закончилась ещё с момента потери домена.
А для конца эпохи hlfx.ru нужно чтобы я на какой-то другой форум переехал. А мне некуда.

__________________

Отправлено Дядя Миша 16-12-2023 в 14:18:

А вот скажите мне товарищи - часто ли используется эта схема огранизации файловой системы, как это было принято у Кармака и впоследствии перешло на первую халфу?
Я имею в виду базовая папка с игрой а к ней можно подключать папку мода, из которой доступны все ресурсы. Это вообще ещё актуально?
Скажем в Юнити или UE такое практикуют? Как вы это видите?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 16-12-2023 в 15:03:

Цитата:

Дядя Миша писал:
А вот скажите мне товарищи - часто ли используется эта схема огранизации файловой системы, как это было принято у Кармака и впоследствии перешло на первую халфу?
Я имею в виду базовая папка с игрой а к ней можно подключать папку мода, из которой доступны все ресурсы. Это вообще ещё актуально?
Скажем в Юнити или UE такое практикуют? Как вы это видите?

Юнити и Анрил вроде как по мне не практикуют такого. Разве что только бандлы. По мне идея наследоваться от какого то мода, вполне удачная и прикольная чтобы не ломать оригинальные файлы.

Отправлено Дядя Миша 16-12-2023 в 16:24:

Да, но народ же кушать не может, "у меня игра, у меня игра, не какой-то там мод!".

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Cybermax 16-12-2023 в 17:59:

Цитата:

Crystallize писал:
xash.ru

Если бы спросили меня, но меня никто не спрашивал, то если и делать отдельный форум для Ксаш, то на https://xash3d.ru/doku.php.

Добавлено 16-12-2023 в 20:59:

Цитата:

FiEctro писал:
Юнити и Анрил вроде как по мне не практикуют такого. Разве что только бандлы. По мне идея наследоваться от какого то мода, вполне удачная и прикольная чтобы не ломать оригинальные файлы.

Логичная и удобная схема. Про мод а не игра, всем плевавть будет. Те кто хотят будут делать.

__________________
ㅤ

Отправлено FiEctro 16-12-2023 в 18:40:

Цитата:

Дядя Миша писал:
Да, но народ же кушать не может, "у меня игра, у меня игра, не какой-то там мод!".

Народ хотел автоматизацию и удобные инструменты. А не кваку.

Отправлено (_-=ZhekA=-_) 18-12-2023 в 07:24:

Цитата:

Дядя Миша писал:
Скажем в Юнити или UE такое практикуют? Как вы это видите?

Сходу я не смог разобраться, как в UE делать моды или DLC, а конкретно во-все это вникать у меня пока нет желания

Добавлено 18-12-2023 в 10:24:

Цитата:

FiEctro писал:
Народ хотел автоматизацию и удобные инструменты. А не кваку.

В каком году народ все это хотел?

Отправлено Дядя Миша 18-12-2023 в 09:11:

Цитата:

FiEctro писал:
Народ хотел автоматизацию и удобные инструменты

Что именно народ хотел - дело тёмное. Одни хотели одно, другие, соответственно, другое. Третьи хотели одного, но согласились с тем, что им дали. А четвертые что ни дай - обратно недовольны, таких меньшинство, но пару человек я знаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 18-12-2023 в 14:53:

Цитата:

FiEctro писал:
Народ хотел автоматизацию и удобные инструменты. А не кваку.

Не забываем что в квейке были всякие энтити чтобы собак можно было в космос запускать.

Отправлено FiEctro 18-12-2023 в 16:44:

Crystallize
Энтити это теже блюпринты просто неудобные и без нормальной визуализации.

Отправлено Crystallize 18-12-2023 в 17:24:

FiEctro блин я всё время забываю что все скрипты уже написаны за меня и их только скачать.

Отправлено Дядя Миша 18-12-2023 в 18:46:

Цитата:

FiEctro писал:
Энтити это теже блюпринты просто неудобные и без нормальной визуализации.

Наоборот. Блюпринты - это избыточная визуализация. Визуальный мусор.
Я ставлю на уровень монстра и мне плевать как он там внутри устроен.
Главное чтобы он делал то, что я хочу.

Добавлено 18-12-2023 в 21:46:

Тем временем я восстановил работоспособность демок Quake3 и XreaL.
Мог бы выложить, но сперва хочется написать для них хотя бы минимальный код - ротатабли, лаунч-пады, двери. Такие заготовки будут народу гораздо интереснее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 18-12-2023 в 19:25:

Цитата:

Дядя Миша писал:
Наоборот. Блюпринты - это избыточная визуализация. Визуальный мусор.

Смысл у них примерно один и тот же, есть инпут и отпут и функционал. Но всё же визуализация энтитей нод бы была бы нагляднее чем просто имена в настройках энтитей которые ведут хрен знает куда. Вот представь у тебя есть 2 экрана сцена и нодовый эдитор. Нажимаешь на энтитию на сцене и он выделяет твою ноду на втором экране и показывает сразу куда и что подключено. И наоборот вместо того чтобы искать энтитию на сцене, особенно если она огромная ты можешь найти её на 2д доске как ноду, а чтобы переключиться на неё на сцене, нажать ПКМ -> Go to entity. Главное что видно все связи будет.

Таким образом на энтитиях уже можно было бы реально сложную логику делать, а главное наглядно, а не заниматься вслепую доктортрессизмом.

Цитата:

Дядя Миша писал:
Мог бы выложить, но сперва хочется написать для них хотя бы минимальный код - ротатабли, лаунч-пады, двери. Такие заготовки будут народу гораздо интереснее.

Ротатабли и двери конечно хорошо, но логика и трансформы лучше.

Отправлено XaeroX 18-12-2023 в 20:22:

Цитата:

FiEctro писал:
Таким образом на энтитиях уже можно было бы реально сложную логику делать

Зачем делать сложную логику на энтитях, если можно написать скрипты?
Я думал, поколение любителей блоков и стрелочек вымерло вместе с Game maker, году в 2005м

Или тут подход "everything old is new again"?

__________________

Отправлено Дядя Миша 18-12-2023 в 20:38:

Цитата:

FiEctro писал:
Вот представь у тебя есть 2 экрана сцена и нодовый эдитор. Нажимаешь на энтитию на сцене и он выделяет твою ноду на втором экране и показывает сразу куда и что подключено. И наоборот вместо того чтобы искать энтитию на сцене, особенно если она огромная ты можешь найти её на 2д доске как ноду, а чтобы переключиться на неё на сцене, нажать ПКМ -> Go to entity. Главное что видно все связи будет.

Это и есть доктортрессизм, только в современной обвертке.

Добавлено 18-12-2023 в 23:38:

Мне особенно нравится когда поведение монстра настраивают через ноды сцены или что-то в этом роде. Как будто все самые поганые практики из программирования собрали вместе и засунули в игровые движки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 18-12-2023 в 20:58:

Цитата:

XaeroX писал:
Зачем делать сложную логику на энтитях, если можно написать скрипты?
Я думал, поколение любителей блоков и стрелочек вымерло вместе с Game maker, году в 2005м
Или тут подход "everything old is new again"?

Не знаю, ДМ говорит что энтитии лучше.

Цитата:

Дядя Миша писал:
Мне особенно нравится когда поведение монстра настраивают через ноды сцены или что-то в этом роде. Как будто все самые поганые практики из программирования собрали вместе и засунули в игровые движки.

Возможно потому что это быстрее и это могут делать люди особо не знакомые с программированием. Хардкодить всё прибивать гвоздями ещё более поганая практика.

Отправлено Дядя Миша 18-12-2023 в 21:10:

Цитата:

FiEctro писал:
Возможно потому что это быстрее и это могут делать люди особо не знакомые с программированием

Низкий порог входа как правило гарантирует отвратительный результат или вообще его отсутствие. То вот да, вроде бы и модель на карту поставилась и скрипт написался, который дверь открывает. Но между этой дверью и реальной игрой ровно такая же пропасть, которая была бы с высоким порогом входа.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 18-12-2023 в 21:53:

Цитата:

Дядя Миша писал:
Но между этой дверью и реальной игрой ровно такая же пропасть, которая была бы с высоким порогом входа.

Ну так в этом и заключается мастерство написания движков для разработчиков. Чтобы как раз убрать всю рутину без потери основого функционала. Иначе бы каждый писал свой движок на С++ или ассемблере.

Отправлено XaeroX 19-12-2023 в 00:02:

Цитата:

FiEctro писал:
Иначе бы каждый писал свой движок на С++ или ассемблере.

Да писать можно хоть на питоне (игровую логику, в смысле). Мне другое интересно - как ДЕБАЖЫТЬ эти ваши стрелочки и блоки? Ну представь классическую ситуацию - всё сделано совершенно правильно, а включаешь - не работает. Куда ставить брейкпоинты, куда втыкать принт-стейтменты?

__________________

Отправлено Дядя Миша 19-12-2023 в 05:24:

FiEctro есть три подхода к разработке игры:
1. дизайнер расставляет объекты и связывает их событиями.
2. дизайнер расставляет ноды и пытается через эти ноды заставить объекты что-то делать
3. дизайнер углубляется в код и понимает, что кодить куда интереснее, чем расставлять объекты. С этого момента он уже потерян для мира как дизайнер.
На первом подходе сделана куча игр и модов. Второй подход - это то, чем вы занимаетесь на Юнити, без особенных успехов. Движение есть, а результата нет. Третий подход как правило ведёт в никуда. Но есть исключения.

Добавлено 19-12-2023 в 08:24:

Цитата:

XaeroX писал:
Мне другое интересно - как ДЕБАЖЫТЬ эти ваши стрелочки и блоки?

Добавляешь рядом отдельный блок дебага, связываешь стрелочкой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 19-12-2023 в 06:09:

Цитата:

XaeroX писал:
Мне другое интересно - как ДЕБАЖЫТЬ эти ваши стрелочки и блоки?

Очень просто ) в логике, которую ты делал ставишь где-нибудь бреакпоинт или несколько и запускаешь проект, как только доходит до этого места, где стоит бреакпоинт, то тебя автоматом перебрасывает к этому месту и там можно в динамике смотреть значение переменных и куда идет или не идет логика дальше, ну и сразу можно понять почему именно, так как все наглядно и в динамике ) Это один из вариантов )

Добавлено 19-12-2023 в 08:50:

FiEctro
Ладно я работаю в UE и делаю все на принтах, но ты то сидишь на юнити и от тебя непривычно слышать, как ты топишь за принты или, что-то похожее

Добавлено 19-12-2023 в 09:09:

Цитата:

Дядя Миша писал:
Наоборот. Блюпринты - это избыточная визуализация. Визуальный мусор.

Для всех все по разному, для кого-то писать код в блокноте или студии это мусор из, каких-то непонятных символов и букв, а есть и те, вроде тебя, для которых принты это какая-то визуальная хрень ) Хотя смысл у этих двух разных подходов абсолютно один и тот же, как бы это не отрицал

Цитата:

Дядя Миша писал:
Я ставлю на уровень монстра и мне плевать как он там внутри устроен.
Главное чтобы он делал то, что я хочу.

И на принтах так же, ты же на уровень ставишь монстра, а не код\принты ) А если тебе нужно в этом монстре, что-то изменить ты его отрываешь в студии или блюпринт редакторе и правишь, что нужно

Или вообще можно править его настройки в динамике, если они конечно у меня есть )

Отправлено Дядя Миша 19-12-2023 в 06:57:

Цитата:

(_-=ZhekA=-_) писал:
для кого-то писать код в блокноте или студии это мусор из, каких-то непонятных символов и букв

Как же ты это сообщение набирал из непонятных символов и букв? Вот представь, что на форуме можно было бы общаться исключительно блоками со стрелочками. И там в каждом блоке смайлик или анимированная картинка.

Цитата:

(_-=ZhekA=-_) писал:
Хотя смысл у этих двух разных подходов абсолютно один и тот же

Смысл одинаковый, а плотность информации разная. В этом-то и всё дело.
У принтов ужасающе низкая плотность информации.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 19-12-2023 в 07:23:

Цитата:

Дядя Миша писал:
Как же ты это сообщение набирал из непонятных символов и букв? Вот представь, что на форуме можно было бы общаться исключительно блоками со стрелочками. И там в каждом блоке смайлик или анимированная картинка.

Ну, ты прям очень сильно утрируешь

Цитата:

Дядя Миша писал:
Смысл одинаковый, а плотность информации разная. В этом-то и всё дело.
У принтов ужасающе низкая плотность информации.

Если ты считаешь, что кодить нужно только в студии или блокноте это не говорит о том, что это так же правильно\удобно для других

Если смыл одинаковый, то каждый выбирает то, что ему больше нравиться или удобнее. И вот как раз анрил дает такую прекрасную возможность, для тебя плюсы, а для меня принты, а еще все это можно комбинировать )

Отправлено Crystallize 19-12-2023 в 10:03:

Цитата:

Я упорно держался за энтити (ну Tactical Espionage Action же смог!) до пока не выяснил что время реакции энтитей имеет плавающую погрешность что-то около 0.1с. Таким образом Фрименом бегать ещё куда ни шло, но построить на них динамичный геймплей невозможно. Надо сказать что к переломному моменту я дошёл до спавна дамми-модельки на долю секунды чтобы игрок если увидит её мог судить о направлении своего движения (стрейфы были разбиндены).

Хотя блюпринты должны работать по-другому, блюпринты же не обязательно физически пихать на карту как все энтити хл.

Отправлено Дядя Миша 19-12-2023 в 11:01:

Цитата:

Crystallize писал:
до пока не выяснил что время реакции энтитей имеет плавающую погрешность что-то около 0.1с.

Ты что-то совсем не то выяснил. Это не время реакции всех энтить, а время обновления цикла, которое обычно ставят в раёне 0.1
Но никто не мешает поставить там 0 и получить мгновенную реакцию.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-12-2023 в 11:36:

Цитата:

Дядя Миша писал:
1. дизайнер расставляет объекты и связывает их событиями.
2. дизайнер расставляет ноды и пытается через эти ноды заставить объекты что-то делать
3. дизайнер углубляется в код и понимает, что кодить куда интереснее, чем расставлять объекты. С этого момента он уже потерян для мира как дизайнер.
На первом подходе сделана куча игр и модов. Второй подход - это то, чем вы занимаетесь на Юнити, без особенных успехов. Движение есть, а результата нет. Третий подход как правило ведёт в никуда. Но есть исключения.

Ты меня не понял, сами энтитии уже можно рассматривать как ноды даже те что в халфе и кваке

просто без нормальной визуализации.

Цитата:

(_-=ZhekA=-_) писал:
Ладно я работаю в UE и делаю все на принтах, но ты то сидишь на юнити и от тебя непривычно слышать, как ты топишь за принты или, что-то похожее

Ну как бы на Юнити есть куча плагинов с нодами. Да и Анрил я тоже ковырял. Не топлю я за ноды, просто забавно как ДМ пишет что ноды говно, а энтити классные, хотя это по своей сути одно и тоже.

Но в защиту ДМ могу сказать что чистый код действительно приятнее макарон. Но это именно что код, а не местная логика.

Отправлено (_-=ZhekA=-_) 19-12-2023 в 11:50:

Цитата:

FiEctro писал:
Но в защиту ДМ могу сказать что чистый код действительно приятнее макарон.

Можно большой код делить на функции\макросы\компоненты по смыслу и нет никаких макарон... К слову в студии тоже можно наговнять так, что хрен потом там, кто-то разберется

Отправлено Дядя Миша 19-12-2023 в 11:55:

Цитата:

FiEctro писал:
сами энтитии уже можно рассматривать как ноды даже те что в халфе и кваке

С натяжкой можно, но это разные концепции всё же.

Цитата:

FiEctro писал:
просто без нормальной визуализации

Ну вот ты поставил на карту монстра. Что ты там собрался визуализировать?
Состояние его AI-машины? Так в сорсе есть и такая визуализация. Однако нодов там нет.

Цитата:

FiEctro писал:
ноды говно, а энтити классные, хотя это по своей сути одно и тоже.

Это разные концепции.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 19-12-2023 в 14:09:

Цитата:

Дядя Миша писал:
Ты что-то совсем не то выяснил. Это не время реакции всех энтить, а время обновления цикла, которое обычно ставят в раёне 0.1
Но никто не мешает поставить там 0 и получить мгновенную реакцию.

Ты ж говорил что меньше 0.1с чревато глюками.
Так или иначе я ставил разное и какого-то очевидно и выгодно выделяющегося варианта не нашёл. Реакция идет с задержкой и сильно плавает от случая к случаю.

Отправлено XaeroX 19-12-2023 в 14:33:

Цитата:

(_-=ZhekA=-_) писал:
ну и сразу можно понять почему именно

Сразу видно - ничего серьёзного ты в жизни не дебажыл

__________________

Отправлено Дядя Миша 19-12-2023 в 14:45:

Цитата:

Crystallize писал:
Ты ж говорил что меньше 0.1с чревато глюками.

Ты сохранил точную цитату?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 19-12-2023 в 16:38:

Цитата:

Дядя Миша писал:
Это разные концепции.

Скорее разные этапы эволюции.

Отправлено Дядя Миша 19-12-2023 в 19:08:

Мода по кругу идёт. Завтра твои ноды объявят deprecated, что ты будешь делать?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 19-12-2023 в 19:34:

Цитата:

XaeroX писал:
Сразу видно - ничего серьёзного ты в жизни не дебажыл

Я еще только учусь

Цитата:

Дядя Миша писал:
Мода по кругу идёт. Завтра твои ноды объявят deprecated, что ты будешь делать?

А никто и не говорил, что они популярны, просто их юзают те, для кого это удобно

Их не уберут, так как на них примерно больше половины маркетплейса завязано )

Отправлено Дядя Миша 19-12-2023 в 20:30:

Deprecated - это нежелательный к использованию. Не уберут конечно, но новое поколение начнут учить чему-то другому.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Camblu_Buildovich 20-12-2023 в 09:24:

Цитата:

Дядя Миша писал:
Завтра твои ноды объявят deprecated, что ты будешь делать?

~~модами~~ ассетами допилят. Напоминаю, что для той же юнити первые ноды начали пилить васяны из ассет стора, причем - глянь дату оригинального релиза. В 2014-м я лично ковырял плеймэйкер и эту дичь. Правда, оно у меня не особо работало, из-за несоответствия версий api - пираты на cgpersia не зарелизили их под мою, более новую версию юнити.
УЕ тоже шел к нодам еще с третьей версии. А сейчас актуальная - пятерка.
А учитывая, что еще к UDK, который был без ассет стора и открытых исходников - еще в том, малом комьюнити - легко делали "ассеты"/"плагины" для, например, подключения питонов и луа, или диалоговых систем с sql строками, для новых версий это будет несложно. К сожалению, ссылок за давностью лет уже не доставлю. Но они были, верьте мне

Пару лет назад видел шейдер для псевдо-пбр, например.

Так что твоя позиция лично мне видится как "не читал, но осуждаю".

__________________

Цитата:

КСМ это форум украинских нацистов и в администрации нет адекватов.

Отправлено FiEctro 20-12-2023 в 10:21:

Цитата:

Дядя Миша писал:
Мода по кругу идёт. Завтра твои ноды объявят deprecated, что ты будешь делать?

Энтитии уже давно объявили и тебе это не особо мешает.

Цитата:

Camblu_Buildovich писала:
Напоминаю, что для той же юнити первые ноды начали пилить васяны из ассет стора,

Самое лучшее васянское изобретение это ноды для шейдеров. Никто из художников толком не знает как их правильно писать. А вот заготовками нодами можно накидать довольно крутые вещи за очень короткое время.

https://acegikmo.com/shaderforge/images/web/screenshots/sf_ss_mainpage_a.jpg

Отправлено Camblu_Buildovich 20-12-2023 в 10:31:

Цитата:

FiEctro писал:
Никто из шейдерописателей толком не знает как правильно писать шейдеры

Пофиксил, не благодари.

В уе мне больше всего понравился именно mateditor. Да, с ним иногда надо пострадать, но есть же документация с базовыми примерами, от которой легко оттолкнуться. А с этим шейдерфоржем я справиться не смог, что во времена 5.x, что пару лет назад.

Цитата:

FiEctro писал:
Никто из художников толком не знает как их правильно писать

А причина одна - ~~безблагодатность~~ отсутствие вменяемой документации по этому вашему шейдерфоржу.

__________________

Цитата:

КСМ это форум украинских нацистов и в администрации нет адекватов.

Отправлено FiEctro 20-12-2023 в 10:34:

Цитата:

Camblu_Buildovich писала:
А с этим шейдерфоржем я справиться не смог, что во времена 5.x, что пару лет назад.

Ну незнаю. Есть же справка:
https://www.acegikmo.com/shaderforge/nodes/

Одна из самых лучших, что я встречал.

Отправлено Camblu_Buildovich 20-12-2023 в 10:56:

Цитата:

FiEctro писал:
Одна из самых лучших, что я встречал.

Не нашел там прям наглядных примеров для самых маленьких.
https://docs.unrealengine.com/udk/T...lsTutorial.html
https://docs.unrealengine.com/udk/T...rialBasics.html
https://docs.unrealengine.com/udk/T...alExamples.html
https://docs.unrealengine.com/udk/T...Compendium.html
Да, в уе3 доках оно разделено на несколько страниц. Зато всё прям наглядно, с конь-кретными примерами. У шейдерфоржа же 1 большая страница с суховатым описанием нод без особых примеров. Вот к каким нодам можно подключать какой-нибудь Biangent direction?
А в доках по уе3 я перехожу к какому-нибудь https://docs.unrealengine.com/udk/T...jectOrientation и сразу вижу, как и к чему его можно крепить, чтоб не поломать материал

Чет мы уже в конь-кретный офтоп полезли, тема-то о Хаше.

__________________

Цитата:

КСМ это форум украинских нацистов и в администрации нет адекватов.

Отправлено FiEctro 20-12-2023 в 11:09:

Цитата:

Camblu_Buildovich писала:
Не нашел там прям наглядных примеров для самых маленьких.

Меня берёт сомнение что ты вообще её читал, ибо всё там есть если зайти на сайт.
https://www.neatcorporation.com/Pro...ickStart-en.pdf

Наглядными примерами завален весь гугл. Да и выше я скинул скриншот тоже с официального сайта.

https://80.lv/articles/prototyping-with-shader-forge/

Отправлено Camblu_Buildovich 20-12-2023 в 12:24:

Цитата:

FiEctro писал:
Меня берёт сомнение что ты вообще её читал, ибо всё там есть если зайти на сайт

Ну я просмотрел то, что ты мне скинул. Даже, на всякий, жамкнул еще раз на ссылку "documentation", чтобы убедиться, что

Цитата:

Camblu_Buildovich писала:
У шейдерфоржа же 1 большая страница с суховатым описанием нод без особых примеров

Пдф да, не увидел. Спасибо.

Цитата:

FiEctro писал:
Наглядными примерами завален весь гугл

Цитата:

FiEctro писал:
Никто из художников толком не знает как их правильно писать

Сомнительные примеры, получается. Разработчики-то точно должны знать, как их писать. А примеров на офсайте - с гулькин нос. Может в справке юнити побольше? Я просто уже не помню за давностью.

__________________

Цитата:

КСМ это форум украинских нацистов и в администрации нет адекватов.

Отправлено FiEctro 20-12-2023 в 14:24:

Цитата:

Camblu_Buildovich писала:
Сомнительные примеры, получается. Разработчики-то точно должны знать, как их писать. А примеров на офсайте - с гулькин нос. Может в справке юнити побольше? Я просто уже не помню за давностью.

Не сильно отличается от того что ты скинул. Но да у Эпиков буков побольше. А суть примерно та же. Шейдерфордж это чисто пользовательский продукт который к Юнитеху не имеет никакого отношения. Уже потом они подсмотрели и сделали свой Шейдерграф уже официальный, но к сожалению так и не отладили нормально.

P.S. Мне подсказали откуда ДМ вычитал что ноды это плохо

https://camo.githubusercontent.com/3689373b81b26569777fb6228627edf883b039097a322a4a7a32ef5f61866d99/68747470733a2f2f662e636c6f75642e6769746875622e636f6d2f6173736574732f333234373638382f39393133392f34396239633932632d363734382d313165322d383064392d3131656231393936363635392e6a7067

Отправлено XaeroX 20-12-2023 в 14:28:

Цитата:

FiEctro писал:
Мне подсказали откуда ДМ вычитал что ноды это плохо

"AI Disabled" намного лучше, да.

__________________

Отправлено Дядя Миша 20-12-2023 в 19:42:

Нет, вопросов не надо задавать. Лучше самостоятельно задумайтесь.
А ещё лучше - посмотрите фильм целиком.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 21-12-2023 в 20:26:

Вообщем товарищи для корректной работы инстансов, они же детайлы, они же MU-модели, придётся ещё раз сломать совместимость формата уровней.
Я какое-то время полагал, что достаточно достроить в движке эту подсистему, но нет. Там всё придётся переписать. Впрочем от вас потребуется только пересобрать потом уровни заново.

Добавлено 21-12-2023 в 23:26:

Вот тогда и на сталкере будет нормальный фпс, кстати.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Camblu_Buildovich 22-12-2023 в 17:00:

Цитата:

Дядя Миша писал:
Вот тогда и на сталкере будет нормальный фпс, кстати.

И и на амуде со штеудом?

__________________

Цитата:

КСМ это форум украинских нацистов и в администрации нет адекватов.

Отправлено Дядя Миша 22-12-2023 в 18:36:

Хочется надеяться

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 27-12-2023 в 19:52:

Вообщем минимальная версия OpenGL для запуска XashNT - это версия 3.2
Но судя по тому, что ни у кого проблем не возникло - у всех железо удовлетворяет этому требованию.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 27-12-2023 в 20:49:

Дядя Миша
Это какому гефорсу соответствует? 8800?

__________________

Отправлено Дядя Миша 27-12-2023 в 21:32:

Вообщем, начиная с Intel HD Graphics 2012-го года выпуска, восьмая серия жирафов и Radeon HD 2000 и выше.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 29-12-2023 в 21:08:

Вообшем учитывая устройство современного конвейера GPU вооруженного ксашевской системой материалов и организацией конвейера рендеринга в движке можно с уверенностью сказать - движок за тормоза более не отвечает. Только пользователь. Какую геометрию скормит, какие шейдеры напишет - так и будет тормозить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 29-12-2023 в 22:31:

Цитата:

Дядя Миша писал:
Какую геометрию скормит, какие шейдеры напишет - так и будет тормозить.

Это удивительно всеобъемлющее утверждение: трудно найти движок, в отношении которого оно несправедливо. Ну то есть когда движок тормозит одинаково вне зависимости от скормленной ему геометрии и шейдеров.

__________________

Отправлено Дядя Миша 30-12-2023 в 07:44:

Ну как же: Unreal 5. Карту-коробку создал, а там уже 30 фпс почему-то.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 30-12-2023 в 10:57:

Цитата:

XaeroX писал:
Это удивительно всеобъемлющее утверждение: трудно найти движок, в отношении которого оно несправедливо. Ну то есть когда движок тормозит одинаково вне зависимости от скормленной ему геометрии и шейдеров.

Да больше бомбит от корявых дров Интела и Амуде. Что у одних работает, то у других вызывает дикие тормоза в 3 фпс, отваливающиеся текстуры, вылеты и т.п. Вероятно эти экземпляры имеют не полную поддержку GL 3.2 и самое печальное что нет особо никаких средств для отладки таких вещей в Ксаше, ну то есть как нет, есть - идти в блокнотик и построчно включать шейдер пока не найдёшь проблемную строку. ДМ говорит что с этим поделать ничего нельзя, т.к. все приколы происходят на стороне драйвера. При том что тот же Сталкер на директе работает везде одинаково, во всяком случае на том железе где GLSL вёл себя нестабильно.

Цитата:

Дядя Миша писал:
Ну как же: Unreal 5. Карту-коробку создал, а там уже 30 фпс почему-то.

Я давно говорю - тяжелые шейдеры зло. Темболее с циклами и ифами всякими. А учитывая сколько технологий только одного GI поддерживает анрил, там наверное не шейдеры, а треш, угар и содомия.

Отправлено Дядя Миша 30-12-2023 в 14:01:

Цитата:

FiEctro писал:
Вероятно эти экземпляры имеют не полную поддержку GL 3.2

Наоборот. В GL начиная с версии 3.2 появилось такое понятие как Core-профиль. Объясню почему. Начиная с 8 версии жирафов поменялась архитектура конвейера GPU. Раньше это был фиксированный конвейер с возможностью программирования. Поэтому он отлично справлялся с отрисовкой через те же глБегины. Главное чтобы шейдеры были простые.
Начиная с Core-профиля 3.2 сделали версию, которая не тянет за собой никакой груз совместимости, не добавляет в шейдер никакие встроенные юниформы и собственный код, эмулирующий фиксированный функционал.
И вот нормально реализовать профиль совместимости - т.е. классический GL, на котором сейчас и работает Ксаш, смогла только NVidia. Поэтому на ней обычно у всех всё прекрасно работает. Остальные запилили core-профиль, а профиль совместимости - по остаточному принципу. Поэтому там получаются такие забавные коллизии - у Интола в профиле совместимости нет встроенных юниформов gl_ModelViewProjectionMatrix - ну потому что их нет в Core-профиле. Или что-то валится прям в жосткую эмуляцию.
Т.е. когда я перейду на Core-профиль в Ксаше большая часть проблем исчезнет автоматически. Ну это уже в следующем году.
Тем более что движок изначально писался про свежие версии GL, но там остались какие-то куски кода, в основном отладочные для вывода сообщений например. Постепенно я всё это переделаю, там не особо много кода.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 30-12-2023 в 14:30:

Цитата:

FiEctro писал:
Да больше бомбит от корявых дров Интела и Амуде

Они уже 20 лет такие, пора бы и привыкнуть.
Помнится, ещё автор Тринити на это отвечал - мой мод не работает на вашей видеокарте? Попросите маму с папой купить нормальный жыфорс. За точность цитаты не ручаюсь, но смысл был такой.

__________________

Отправлено Дядя Миша 30-12-2023 в 14:54:

И кстати восьмая серия жифорсов - последняя векторная специализированная архитектура конвейеров. В следующем поколении уже пошли юниформ блоки с плавающей точкой, без чёткого деления на растр-вектор. Отчего стало возможным тут же реализовать Куду. Что и было с успехом проделато.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 30-12-2023 в 15:01:

Цитата:

Дядя Миша писал:
Отчего стало возможным тут же реализовать Куду. Что и было с успехом проделато.

CUDA прекрасно бегала на 8800, собственно это мой первый и единственный опыт с ней, где я придумал алгоритм расчёта поверхности, доступной молекулам воды, который в 14 раз быстрее тривиальной версии на CPU.

__________________

Отправлено Дядя Миша 30-12-2023 в 15:27:

Ну чтож, реорганизация формата уровней для ускорения работы инстансов успешно завершена:

Карта, прямо скажу, не особо подходящяя для таких тестов, но времени это всё тестировать на картах Сталкера у меня уже не было.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 30-12-2023 в 19:16:

Цитата:

Дядя Миша писал:
Ну как же: Unreal 5. Карту-коробку создал, а там уже 30 фпс почему-то.

Ну, так ты это в настройки зайди, отключи люмен, виртуальные тени и включи ДХ11 на SM5 и будет у тебя не 30 на 120

Отправлено FiEctro 30-12-2023 в 20:57:

Цитата:

Дядя Миша писал:
Ну чтож, реорганизация формата уровней для ускорения работы инстансов успешно завершена:

Трава у тебя сильно фпс просаживает? Расскажи в чём оптимизация инстансов заключается. Кстати, а материалы тоже инстансятся?

Отправлено Дядя Миша 30-12-2023 в 21:17:

Цитата:

(_-=ZhekA=-_) писал:
отключи люмен, виртуальные тени

Разве виртуальные тени не повышают фпс наборот? Для чего они вообще нужны? Мне казалось это оптимизация такая.

Добавлено 31-12-2023 в 00:14:

Цитата:

FiEctro писал:
Что то трава у тебя сильно фпс просаживает

Не трава а чудовищный убершейдер, который включает в себя все возможные вариации конвейера Ку3.

Цитата:

FiEctro писал:
Расскажи в чём оптимизация инстансов заключается

Раньше инстансы группировались по моделям и каждая модель потенциально могла содержать несколько разных материалов - это приводило к рестарту конвейера. Сейчас они сгруппированы в пространстве по материалу и лайтмапе. Т.е. за один вызов выводится сразу около тысячи кустов.

Цитата:

FiEctro писал:
Кстати, а материалы тоже инстансятся?

Всмысле?

Добавлено 31-12-2023 в 00:17:

Цитата:

FiEctro писал:
Отредактировано FiEctro сегодня в 00:11

Ты меня газлайтишь. Отвечаю на одно сообщение, запостил - уже поменялось. Пишешь "где бамп?", я отвечаю, глядь а в твоем посте уже вопрос "где тени?".

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 30-12-2023 в 21:20:

Цитата:

Дядя Миша писал:
Ты меня газлайтишь. Отвечаю на одно сообщение, запостил - уже поменялось. Пишешь "где бамп?", я отвечаю, глядь а в твоем посте уже вопрос "где тени?".

Я подумал у тебя на скриншотах "до" и "после", потом дошло что они все после. Потому и отредактировал.

Цитата:

Дядя Миша писал:
Всмысле?

Ну вот есть например дерево tree.mdl ты ставишь его на карту 1 раз, у тебя для этого материала добавляется 1 проход. Ставишь 2 таких дерева с одинаковым, у тебя уже 2 прохода, а с ГПУ инстансингом будет 1 проход. У тебя я так понял Дипами называются. Я так понял это:

Цитата:

Дядя Миша писал:
Раньше инстансы группировались по моделям и каждая модель потенциально могла содержать несколько разных материалов - это приводило к рестарту конвейера. Сейчас они сгруппированы в пространстве по материалу и лайтмапе. Т.е. за один вызов выводится сразу около тысячи кустов.

оно и есть?

Отправлено Дядя Миша 30-12-2023 в 21:34:

Цитата:

FiEctro писал:
У тебя я так понял Дипами называются

DIP это термин из DirectX, сокращение от Draw Indexed Primitive.
Поскольку сейчас везде именно так и рисуют, его уместно использовать.

Цитата:

FiEctro писал:
Ставишь 2 таких дерева с одинаковым, у тебя уже 2 прохода

Потому что трансформация сбрасывает конвейер. А инстансинг хранит позицию-углы-скейл в текстуре и читает её прямо в вертексном шейдере.
И можно нарисовать несколько тысяч одинаковых моделей за один вызов.
Что, собственно и отражено в статистике - всего 27 дипов.
А проход - это другое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 31-12-2023 в 07:56:

Цитата:

FiEctro писал:
У тебя я так понял Дипами называются.

Ты не читал разборы рендеров сталкера, обливиона, флэтаута на геймдев.ру?

Цитата:

Дядя Миша писал:
Что, собственно и отражено в статистике - всего 27 дипов.

А сколько дипов тут было бы до переписывания кода инстансов?

Отправлено Дядя Миша 31-12-2023 в 08:47:

Цитата:

Crystallize писал:
А сколько дипов тут было бы до переписывания кода инстансов?

Колво-инстансов * кол-во материалов. Но там были и другие проблемы, в частности я сделал, чтобы трава освещалась одним люкселем, иначе никаких лайтмап на нее не напасёшься. А так одна страница 1024х1024 = миллион травинок можно осветить. Опять же были ограничения по памяти, к тому же копии инстансов сохранялись в массив с моделями, рядом с дверями и лифтами. А в новом ксаше есть небольшая архитектурная проблемка - он дико долго грузит уровень, если этих самых встроенных моделей слишком много. Так что теперь и скорость загрузки уровней вырастет. Сплошные плюсы. Минус только один - я формат уровней поломал, придётся всё заново перекомпилить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-12-2023 в 09:46:

Цитата:

Дядя Миша писал:
А в новом ксаше есть небольшая архитектурная проблемка - он дико долго грузит уровень, если этих самых встроенных моделей слишком много.

Я тоже пришёл к тому что траву надо делать большими кусками. Отдельно возиться с каждым кустиком слишком накладно.

Отправлено Дядя Миша 31-12-2023 в 10:15:

Инстансы на данный момент превратились в прозрачную для пользователя систему. Он просто ставит кучу одинаковых объектов на уровень и не задумывается над тем, как именно движок будет их рисовать. Но в возможностях при этом не теряет ничего.

Добавлено 31-12-2023 в 13:15:

Единственный момент - для инстансов качство лайтмапы автоматически ухудшается вдвое, а то никаких страниц не напасёшься. Но как правило этого никто не замечает + легко отключить в дальнейшем.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 31-12-2023 в 10:44:

Цитата:

Дядя Миша писал:
для инстансов качство лайтмапы автоматически ухудшается вдвое, а то никаких страниц не напасёшься.

Я думаю эту опцию стоит вынести в настройки компилятора, а там пользователь пускай сам решает, хватит ему страниц или нет. Мне кажется когда будет 64битный компилятор эта проблема отпадёт сама собой.
Да и зачем траве лайтмапа? Чем повертексное освещение не подходит? Более тяжелое?

Отправлено Дядя Миша 31-12-2023 в 11:43:

Для травы даже повертесное избыточно.

Добавлено 31-12-2023 в 14:43:

А оно там есть как раз потому что система не знает, какую модель поставили на уровень

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-01-2024 в 07:14:

На фоне постов ДМ в телеге, мне стало интересно, а насколько хорошая идея мержить созданную траву в более крупные кластеры? Ну тоесть изначально это мешб 1 кустика = 1 объект, а мы например делаем 100 мешб в 1 сетку = 1 объект? Или это разрушит инстансинг? Ещё я провёл некоторые тесты и понял что такие меши весят многовато, вес кластера обжшки могут доходить до 2х гигов (это где то 250тыс кустов по примерно 48 вертексов), но благо движок не хранит их в таком виде.

Отправлено Дядя Миша 12-01-2024 в 07:27:

Цитата:

FiEctro писал:
а мы например делаем 100 мешб в 1 сетку = 1 объект?

Инстансинг так и работает, только мы не делаем 100 копий кустов, а просто храним их позиции, масштаб и угол поворота.
Опытным путём удалось выяснить что наиболее комфортный размер кластера 256х256. Его и фрустум хорошо отсекает и кустов при большой плотности может много поместится.

Цитата:

FiEctro писал:
и понял что такие меши весят многовато

В этом и смысл инстансинга - храним исходный куст + его трансформации.
Тогда твои 250 тысяч кустов весят всего-навсего 6 мегабайт (а можно и меньше, но смысла нет).

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-01-2024 в 07:33:

Цитата:

Дядя Миша писал:
Его и фрустум хорошо отсекает и кустов при большой плотности может много поместится.

Ну вот меня это больше всего удивило, почему ты написал что плотность нельзя регулировать? Какие там ограничения? Хотя это помогло бы сделать траву более плотной перед игроком и более редкой вдали. Потому что сейчас это больше похоже на отдельные кустики.

Цитата:

Дядя Миша писал:
В этом и смысл инстансинга - храним исходный куст + его трансформации.
Тогда твои 250 тысяч кустов весят всего-навсего 6 мегабайт (а можно и меньше, но смысла нет).

А где оно хранится? В видимопамяти или в ОЗУ? Хоть и инстансинг, но вершины есть вершины, им нужно куда то записать хотя бы позицию. И что то я сомневаюсь что получится 6 мегабайт всего. Я просто тоже попытался траву сделать на Юнити, и в целом вышло всё ок, кустиков ну очень много и они покрывают поле равномерно, но вес кластеров довольно большой получился. И это довольно жирная трава адаптированная под вершинный шейдер. Если отдельные кусты просто плоскими треугольниками рисовать, то можно увеличить количество кустиков в несколько раз.

Отправлено Дядя Миша 12-01-2024 в 09:09:

Цитата:

FiEctro писал:
почему ты написал что плотность нельзя регулировать?

Плотность регулировать нельзя в принципе. Потому что позиции кустов запечены в карту. Как ты собрался регулировать?
На моей памяти единственная игра где можно было регулировать плотность кустов, это вот как раз-таки сталкер. Потому что там трава хранится в особенном сжатом формате, там по сути даже не позиции, а градиент позиций с какими-то вероятностями. Этот формат позволяет очень плотно упаковать данные с растительностью за счёт расстановки травы в реальном времени.
Иными словами - каждый кустик ищет место пересечения с геометрией и ставится на её поверхность. Поэтому когда ты в сталкере резко башкой крутишь он всегда зависает и лагает, потому что эти грёбанные кусты делают Drop To Floor. И чем больше этих кустов - тем сильнее лагает. Но зато плотность можно регулировать, да.
В теории можно сделать регулировку плотности. например выбрасывая каждый второй куст, но на практике это будет отвратительно выглядеть скорее всего.

Цитата:

FiEctro писал:
А где оно хранится?

В видеопамяти, в текстурках. Но можно в ОЗУ продублировать для всяких отладочных нужд.

Цитата:

FiEctro писал:
Хоть и инстансинг, но вершины есть вершины, им нужно куда то записать хотя бы позицию

То есть ты само слово "инстансинг" не понимаешь вообще. Потому что в нём как раз и суть - чтобы никуда не записывать никакие вершины, а хранить один куст в локальном пространстве. А позицию, поворот и масштаб читать в вертексном шейдере прямо из текстуры, налету конструировать матрицу и применять её к вертексу. Точнее ко всем вертексам куста. Это быстро, вершинные шейдеры почти никогда не забирают более 10% от общей производительности.

Цитата:

FiEctro писал:
Я просто тоже попытался траву сделать на Юнити, и в целом вышло всё ок, кустиков ну очень много и они покрывают поле равномерно, но вес кластеров довольно большой получился

Ну что в Юнити нет инстансинга? Или ты сидишь на какой-то версии 3.0 может быть? В жизнь не поверю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-01-2024 в 09:21:

Цитата:

Дядя Миша писал:
Ну что в Юнити нет инстансинга? Или ты сидишь на какой-то версии 3.0 может быть? В жизнь не поверю.

Да всё есть, причём тут инстансинг. Мой вопрос был в другом. Ладно я тебя понял.

Цитата:

Дядя Миша писал:
Плотность регулировать нельзя в принципе. Потому что позиции кустов запечены в карту. Как ты собрался регулировать?

Можно кластер разбить на несколько объектов которые находятся в одном месте. Эдакий своеобразный LOD.

Отправлено Дядя Миша 12-01-2024 в 10:06:

Цитата:

FiEctro писал:
Можно кластер разбить на несколько объектов которые находятся в одном месте

Всмысле - разбить кластер? Кластер это объединение. Если разбить кластер, то его не будет.

Добавлено 12-01-2024 в 13:06:

По нанитам кратенько распишу общую информацию, в чём заключалась проблема и как Эпики попытались её решить.

1. Начиная с какого-то момента стало ясно, что единственный оставшийся способ улучшить визуальную составляющую игры - это тупое увеличение кол-ва полигонов в кадре. Параметрические методы - не справляются. Не делает особой погоды ни бамп-маппинг, ни параллакс, ни труформ, ни даже хвалёная тесселяция. Потому что они в лучшем случае могут прорисовать только микрорельеф поверхности. Какие-то ребрышки, зубчики, впадины, вообщем всё то, что как-бы выступает над поверхностью. Но уже даже какую-нибудь шерсть или ворс таким образом сделать проблематично, не говоря уже о более сложных формах микрорельефа. К тому же он может быть весьма неравномерным и попросту не описываемым одним измерением - той самой картой высот. Самый простой способ - наращивать поликаунт не канает. Разберёмся почему.
2. начиная с какого-то момент увеличение кол-ва полигонов в кадре перестаёт влиять на визуальное восприятие. Вы это и сами могли видеть в демках тесселяции, когда ползунок крутишь и где-то начиная с середины значений форма объекта практически не меняется, но зато если подлететь камерой чуть ли в упор - проступают новые детали. Для параметрических методов проблемы не существовало - карта высот одномерная и прекрасно даунскейлится, а трилинейная фильтрация позволяет аккуратно смешивать разные слои мипов без видимых артефактов перехода. Эта технология с незапамятных времен поддерживается на аппаратном уровне и практически бесплатная на сегодняшний момент. Именно поэтому Крайтеки до последнего так цеплялись за свой SSPOM, который почти как тесселяция, но в несколько раз быстрее. С реальными треугольниками начинаются проблемы. Если камера достаточно далеко, то размер треугольника - меньше пикселя. Он скорее всего будет просто отброшен после растеризации или в процессе.
Но время на растеризацию будет потрачено. Получается идиотская ситуация - видеокарта рендерит 5-10 миллионов полигонов, которые почти не вносят вклад в картинку, вся энергия уходит на нагрев окружающей среды. Ну или в худшем случае это даёт мельтешение какое-то в местах скопления таких вот треугольников.
3. Поэтому стояло две задачи касаетельно вывода такой геометрии:
- научить видеокарту эффективно отсекать такие мини-треугольники, чтобы процесс их вывода не влиял на производительность.
- сделать особый формат хранения данных с лодами, которые можно сэмплировать по типу трилинейной фильтрации, т.е. смешивая разные части лодов бесшовно. Там где камера близко - выводим максимальный по качеству лод, там где далеко - аккуратно смешиваем с менее детальным.
Вероятно так же стояла задача как сгенерировать эти лоды, но я этого уже не касаюсь. То ли руками, то ли автоматически, наверное в документации по UE5 об этом написано. Собственно именно эти задачи Nanite и решает.
Весь процессинг такой геометрии технически устроен на вычислительных шейдерах, что в свою очередь налагает на эти мешы массу ограничений в плане их рендеринга и трансформации. Поэтому я и говорю, что без аппаратной поддержки подобных мешей это сейчас такой костыль и достаточно сырая технология. А внедрение аппаратной поддержки в свою очередь может её как-то улучшить в виде снятия ограничений, наложенных программной реализацией конвейера на текущий момент.
4. Эти самые наниты даже не смотря на эффективные способы квантизации пространства весят чертовски много. КМК даже слишком избыточно.
Ну тут непонятно, то ли при меньшем поликаунте они выглядят как говно, то ли народ просто ещё на научился делать не слишком полигональные наниты, которые мало весят. Тут вопрос открытый. Но из-за их чудовищного веса они никогда не умещаются целиком в видеопамяти и их приходится стримить. А стриминг это главный удар по производительности - тут даже SSD не всегда справляется. Вот это главный момент, который они недокрутили ящитаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-01-2024 в 12:11:

Цитата:

Дядя Миша писал:
Всмысле - разбить кластер? Кластер это объединение. Если разбить кластер, то его не будет.

Вот смотри у нас на квадрате 256х256 дюймов есть 8 кустиков. Мы можем объединить их в 1 сетку разом. А можем объединить например в 3 сетки на том же месте по 5, 2, 1 кустика. Когнечно у нас будет теперь 3 объекта вместо 1, но зато мы можем теперь менять их плотность. А поскольку общее число кластеров небольшое, то особого влияния на производительность это не должно давать, скорее наоборот мы можем рисовать возле игрока более плотную траву, а подальше менее плотную. Это просто сырой концепт, возможно ты знаешь как сделать это более оптимально.

Я пока просто рассуждаю. Ну или совсем безумная идея сдвигать полигоны далеко за пределы фрустума прибавляя к вертикальной координате значения из перлин ноиза, а почему нет

Цитата:

Дядя Миша писал:
Ну тут непонятно, то ли при меньшем поликаунте они выглядят как говно, то ли народ просто ещё на научился делать не слишком полигональные наниты, которые мало весят. Тут вопрос открытый. Но из-за их чудовищного веса они никогда не умещаются целиком в видеопамяти и их приходится стримить.

Оптимизация моделей это просто очень долго и дорого. Другое дело наговнять в каком то Збраше и вставить в игру. Помнится как ты топил что художники в гробу вертели крутить материалы, так вот они ещё и в гробу вертели оптимизировать сетки, и развёртки. Им слепи и вставь. И пока вы думаете как уместить плоскость в 4 точки, они уже вовсю лепют уровни в VR из маршевых кубов (которые кстати тоже всегда замкнутые и имеют объём как и браши), а так же сканируют окружающие их деревья и камушки на свой iPad (облако точек).

Так же всякие тесселяции, параллаксы и рельефы стрёмно выглядят на углах и стыках, а так же при некоторых углах обзора, что ну очень не нравится многим художникам. Потому они и любят делать всё полигонами, пока видюха это позволяет...

Добавлено 12-01-2024 в 15:11:

Цитата:

Дядя Миша писал:
наниты даже не смотря на эффективные способы квантизации пространства весят чертовски много. КМК даже слишком избыточно.

В этом и состоял мой вопрос, а ты переключился на инстансы. Ну это наверное многое зависит от самого формата и насколько хорошо он жмётся и расжимается. Тот же obj например занимает места на диске неприлично много, но в архиве он может быть в разы меньше.

Отправлено Дядя Миша 12-01-2024 в 13:08:

Цитата:

FiEctro писал:
А поскольку общее число кластеров небольшое

Ну как небольшое. Два-три десятка тысяч, если самих кустов около миллиона.

Цитата:

FiEctro писал:
Ну или совсем безумная идея сдвигать полигоны далеко за пределы фрустума

Пусть безумная идея - вы не рубайте сгоряча!

Цитата:

FiEctro писал:
вовсю лепют уровни в VR из маршевых кубов

А почему именно в VR?

Цитата:

FiEctro писал:
Так же всякие тесселяции, параллаксы и рельефы стрёмно выглядят на углах и стыках

Лучше всего параллакс смотрится на деревьях - там же нет стыков.

Цитата:

FiEctro писал:
В этом и состоял мой вопрос, а ты переключился на инстансы

Какой вопрос?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-01-2024 в 13:39:

Цитата:

Дядя Миша писал:
А почему именно в VR?

Вот если бы ты работал на стройке тебе бы было удобно пользоваться одной рукой? Вот так же и в ВР, больше контроля чем мышкой. И я не агитирую идти покупать ВР шлем, просто демонстрирую как быстро наши с тобой представления о моделировании и левелдизайне устаревают. А ведь совсем недавно многие вещи хардкодили прямо на ассемблере

Так что из виртуального леса можешь построить себе виртуальный дом

Цитата:

Дядя Миша писал:
Какой вопрос?

Главный вопрос жизни, вселенной и вообще

Отправлено Дядя Миша 12-01-2024 в 15:05:

FiEctro почему именно такое странное сочетание - кубы в VR, я это хотел узнать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 12-01-2024 в 15:23:

Цитата:

Дядя Миша писал:
FiEctro почему именно такое странное сочетание - кубы в VR, я это хотел узнать.

Потому что это лепка. А лепку проще описать кубами, особенно маршевыми при достаточной плотности сетки можно получать меши практически идентичные обычным. Хотя на видео похоже обычные меши.

https://en.wikipedia.org/wiki/Marching_cubes

Вот тут ближе о чем я говорю:

Так же маршевыми кубами можно делать CSG операции как в Ред Фрекшене

Отправлено Дядя Миша 12-01-2024 в 21:52:

Цитата:

FiEctro писал:
Так же маршевыми кубами можно делать CSG операции

как и любым солидным объектом, тащем-то. Ты ведь никогда не задумывался что означает эта аббревиатура? Constructive Solid Geometry.

Цитата:

FiEctro писал:
Потому что это лепка.

Здание так лепить странно, персонажей - не всегда удобно. Скульптинг известен давно, но не особо прижился.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 13-01-2024 в 08:44:

Цитата:

Дядя Миша писал:
Скульптинг известен давно, но не особо прижился.

Скульптинг выстрелил году в 2004 и прижился будьте-нате.

Отправлено FiEctro 13-01-2024 в 13:37:

Цитата:

Дядя Миша писал:
Здание так лепить странно, персонажей - не всегда удобно. Скульптинг известен давно, но не особо прижился.

Ну как бы лепят ещё со времён третьего дуума, и ничего. Вот дома как ты говоришь лепить хоть и странно, но получаются они намного интереснее чем офигевший кубизм из брашей. Поскольку там делать высокую детализацию намного проще ну и плотность сетки позволяет. Впрочем если посмотришь предыдущее видео создание обычных плейнов тоже допускается.

Цитата:

Дядя Миша писал:
как и любым солидным объектом, тащем-то. Ты ведь никогда не задумывался что означает эта аббревиатура? Constructive Solid Geometry.

Безусловно, вот только как этот солидный объект описать так чтобы он был похож на последствия разрушений?

Отправлено Дядя Миша 13-01-2024 в 13:59:

Не понял насчёт разрушений. Каких разрушений?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 13-01-2024 в 15:59:

Дядя Миша
как в ред фрекшене, ты же помнишь игру такую?

Отправлено FiEctro 28-01-2024 в 10:31:

https://assetstore.unity.com/packag...oject-pro-87744

Думаю будет интересно - реалтаймовое построение навмеша.

Отправлено Дядя Миша 28-01-2024 в 11:32:

Для статичного уровня используется предрассчитанный патч в который вносятся поправки с учётом положения динамических тел.
Кстати-кстати. По идее я уже в сл. месяце буду как раз решать эту задачу и задействовать встроенные механизмы навигации.

Добавлено 28-01-2024 в 14:29:

Цитата:

FiEctro писал:
реалтаймовое построение навмеша

Да где же?

Там даже в названии видео написано A-Star. Не поглазам?

Добавлено 28-01-2024 в 14:30:

Кстати локальные навмеши (которые часть бмодели) ксаш тоже поддерживает

Добавлено 28-01-2024 в 14:32:

Вообще мне весьма не нравится что из всех вариантов поиска пути остался только A*. Никакой альтернативы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-01-2024 в 11:45:

Цитата:

Дядя Миша писал:
Да где же? Там даже в названии видео написано A-Star. Не поглазам?

Опять ролики не смотришь? Там есть отрывок с процедурно генерируемым ландшафтом.

Отправлено Дядя Миша 28-01-2024 в 12:40:

Процедурно-генерируемый ландшафт это параметрическая поверхность, это ни о чём. Если бы речь шла о динамической генерации навмеша на произвольной геометрии, то да. Но смысла в этом нет - давно рулят предрассчёты.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-01-2024 в 12:50:

Цитата:

Дядя Миша писал:
Процедурно-генерируемый ландшафт это параметрическая поверхность, это ни о чём. Если бы речь шла о динамической генерации навмеша на произвольной геометрии, то да. Но смысла в этом нет - давно рулят предрассчёты.

Не очень тебя понял. Как предрасчёты помогут собрать навмеш на произвольной геометрии в реальном времени? Ну вот например ригидбоди ящик который можно двигать по уровню, как монстру его обходить?

Отправлено Дядя Миша 28-01-2024 в 13:13:

То что ящик движется - прекрасно делается на уже предрассчитанном навмеше. Находишь то место которое твой ящик перекрывает, и помечаешь ноды под ним как неактивные, всё. A* уже ищет другой путь.
Потом ящик передвинулся - старые ноды обратно включил, новые выключил.

Добавлено 28-01-2024 в 16:13:

Это с любыми обстаклями работает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-01-2024 в 13:48:

Дядя Миша
А как ты проверяешь бокскастом размером с монстра?

Отправлено Дядя Миша 28-01-2024 в 17:12:

Не понял вопроса

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 28-01-2024 в 20:52:

Дядя Миша
Как ты определяешь пересечение ноды с ящиком?

Отправлено FiEctro 29-01-2024 в 06:39:

И ещё вопрос в довесок, как быть с дверьми?

Отправлено Дядя Миша 29-01-2024 в 11:01:

Цитата:

FiEctro писал:
Как ты определяешь пересечение ноды с ящиком?

а шо тут определять? У ящика ббокс, у ноды ббокс. Определяем пересечение двух ббоксов. У двери тоже ббокс. Нам же не нужна там какая-то абсолютная точность, наоборот даже хорошо, если NPC не будет тереться возле закрытой двери или упавшего ящика, если у него совершенно иной маршрут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-01-2024 в 11:17:

Цитата:

Дядя Миша писал:
а шо тут определять? У ящика ббокс, у ноды ббокс. Определяем пересечение двух ббоксов.

И с какой частотой? Это сколько за кадр таких оверлапов на карте надо делать? К тому же коробки медленнее чем скажем теже сферы.

Отправлено Дядя Миша 29-01-2024 в 11:34:

Каждый дискретный кадр движения физического тела, которое потенциально может перекрывать навмеш. Ну разумеется при условии, что оно вообще куда-то двигалось или хотя бы крутилось.

Добавлено 29-01-2024 в 14:33:

Цитата:

FiEctro писал:
К тому же коробки медленнее чем скажем теже сферы.

А ты цикл разверни - будет не сильно медленее. К тому же корректный поиск по сфере включает в себя как минимум один dot или даже с корнем.
А те быстрые, что ты юзаешь - они не вполне верные.

Добавлено 29-01-2024 в 14:34:

Цитата:

FiEctro писал:
К тому же коробки медленнее

Когда я говорю коробки - я всегда веду речь про AABB. А ты видимо имел в виду OBB. Их я действительно юзать не советую.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-01-2024 в 11:44:

Что такое Иерархический поиск А* (на 38 секунде)? Чем он отличается от обычного A* и как работает?

Впрочем для Юнити он существует.
https://www.youtube.com/watch?v=1Q8zlnZXKec

Цитата:

Дядя Миша писал:
Каждый дискретный кадр движения физического тела, которое потенциально может перекрывать навмеш. Ну разумеется при условии, что оно вообще куда-то двигалось или хотя бы крутилось.

Так это всю карту перебрать надо? Это десятки, а то и сотни тысяч таких оверлапов, это же очень медленно. Как ты это оптимизируешь? Ну кроме проверки двигается ли ригидбоди или нет (хотя мне кажется эта оптимизация странной т.к. по карте постоянно что то да перемещается).

Отправлено Дядя Миша 29-01-2024 в 11:59:

Цитата:

FiEctro писал:
Что такое Иерархический поиск А* (на 38 секунде)?

Я ещё не впилился в эту тему - занимаюсь совершенно другими вещами.
Но беглый осмотр алгоритма A* как бы подсказывает, что он дико медленный. Кармак, к слову юзал portal flow для навигации. Изящно, элегантно, но к сожалению с полигональной геометрией не подружишь.
Да и оно точно так же требует замкнутого уровня для правильной работы.
Зато скоро нахождения пути чуть ли не нулевая.
Помнишь как быстро строился путь к дырке на карте?

Цитата:

FiEctro писал:
Так это всю карту перебрать надо?

Нет, зачем всю карту? Просто помечать только те ноды, которые перескаются.

Цитата:

FiEctro писал:
по карте постоянно что то да перемещается

Единственное что постоянно перемещается по карте - это игрок. Всё остальное по ситуации.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-01-2024 в 12:44:

Цитата:

Дядя Миша писал:
Да и оно точно так же требует замкнутого уровня для правильной работы.

Цитата:

Дядя Миша писал:
Помнишь как быстро строился путь к дырке на карте?

Сам себе противоречишь. Какой же уровень замкнутый если там дырка?

Цитата:

Дядя Миша писал:
Кармак, к слову юзал portal flow для навигации. Изящно, элегантно,

Тут конечно не поспоришь. Но навигация в кваке работает у монстров мягко говоря не очень. Они тупят порой когда у них игрок в прямой видимости. Например в этом месте:

И валве всеравно пришлось расставлять ноды вручную.

Цитата:

Дядя Миша писал:
Но беглый осмотр алгоритма A* как бы подсказывает, что он дико медленный.

Ну может для компов времен первой кваки да, медленный, НО сейчас я бы сказал что как минимум в моём случае перебор пересечений (как в твоём случае коробок) отжирает куда больше ресурсов. И я не очень понимаю как это правильно оптимизировать.

Ну тоесть у нас есть цикл который спавнит несколькр десятков тысяч нод, и каждый такт (или с таймером) проверяет пересекается какая то из нод или нет. Это уже жирно. Потом нам надо записать это в массив всё это для того чтобы скормить это A*.
Это тоже жирно. Если мы будем как ты пишешь перебирать заранее этот массив чтобы определить что перезаписалось а что нет, это ещё хуже.
Объясни мне пожалуйста как кухарке, пошагово, как правильно организовать этот момент?

Отправлено Дядя Миша 29-01-2024 в 14:08:

Цитата:

FiEctro писал:
Сам себе противоречишь. Какой же уровень замкнутый если там дырка?

Я про сам принцип поиска. Если бы в уровне была дырка, монстр бы искал кратчайший путь через внешний лиф и вываливался бы на ружу. Ну или просто долбился бы в эту щель.

Цитата:

FiEctro писал:
Но навигация в кваке работает у монстров мягко говоря не очень

Так это появилось только у ботов третьей кваки. Но ты прав, механизм существовал уже для ботов первой, написанный на QC.

Цитата:

FiEctro писал:
перебор пересечений (как в твоём случае коробок) отжирает куда больше ресурсов.

А зачем перебирать пересечения? В идеале тебе надо найти кластер и там проверить ну штук 10 нод. А ты штожы - все перебираешь?

Цитата:

FiEctro писал:
Ну тоесть у нас есть цикл который спавнит несколькр десятков тысяч нод

Нет, это предрассчитанные ноды, как лайтмапа. Геометрия-то не меняется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-01-2024 в 15:53:

Цитата:

Дядя Миша писал:
А зачем перебирать пересечения? В идеале тебе надо найти кластер и там проверить ну штук 10 нод. А ты штожы - все перебираешь?

Что то не сходится, у тебя в пределах видимости на скриншоте куда больше 10 нод. Помню была карта с амбаром, так там вообще их тысячи.

Отправлено Дядя Миша 29-01-2024 в 16:54:

Я и говорю - нод на карте миллионы могут быть. Ты что, собрался каждый кадр все ноды проверять на пересечение?

Добавлено 29-01-2024 в 19:54:

ЗЫ. А что за амбар-то?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-01-2024 в 17:54:

Цитата:

Дядя Миша писал:
ЗЫ. А что за амбар-то?

Ну у тебя скриншот был там дом похожий на амбар в середине поля стоял. Уже не помню где он был. Искать не стал.

Цитата:

Дядя Миша писал:
Я и говорю - нод на карте миллионы могут быть. Ты что, собрался каждый кадр все ноды проверять на пересечение?

Ну в пределах видимости хотя бы, но это тоже не мало. А какой путь искать в пределах 10 нод? Это несколько метров вокруг игрока.

Отправлено Дядя Миша 29-01-2024 в 18:55:

Цитата:

FiEctro писал:
дом похожий на амбар

Ну хорошо хоть не на туалет.

Цитата:

FiEctro писал:
Ну в пределах видимости хотя бы, но это тоже не мало. А какой путь искать в пределах 10 нод? Это несколько метров вокруг игрока.

Я ничего не говорил про пределы видимости вокруг игрока.
Я говорил что ноды должны быть помещены в какие-то кластеры для быстрого поиска текущей. Ну вот как к примеру узнать, на какой именно ноде стоит монстр? Для простоты предположим что ноды несолидные и используются только для построения пути.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-01-2024 в 19:13:

Цитата:

Дядя Миша писал:
Я говорил что ноды должны быть помещены в какие-то кластеры для быстрого поиска текущей. Ну вот как к примеру узнать, на какой именно ноде стоит монстр? Для простоты предположим что ноды несолидные и используются только для построения пути.

Ну опять же, игрок и монстр находятся в разных кластерах, как они увидят друг друга и построют путь?

Отправлено Дядя Миша 29-01-2024 в 19:47:

Ты неверно интерпретируешь слово кластеры. Это просто ускоряющая структура типа того же AABB-дерева для быстрого поиска конкретной ноды в трёхмерном пространстве. Только и всего.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 29-01-2024 в 20:16:

Дядя Миша
Не очень понимаю, покажи пример.

Отправлено Crystallize 30-01-2024 в 01:26:

Цитата:

FiEctro писал:
Ну у тебя скриншот был там дом похожий на амбар в середине поля стоял. Уже не помню где он был. Искать не стал.

grass demo наверное, где многослойный ландшафт и озеро.

Отправлено Дядя Миша 30-01-2024 в 05:21:

FiEctro когда займусь навигацией всё расскажу и покажу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 30-01-2024 в 05:52:

Цитата:

Дядя Миша писал:
FiEctro когда займусь навигацией всё расскажу и покажу.

Так ты же уже делал навигацию на картах сталкера или просто тогда не доделал?!

Отправлено Дядя Миша 30-01-2024 в 06:06:

Я рассчитал навигационную сетку. Теперь надо ей воспользоваться.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 30-01-2024 в 07:02:

Цитата:

Crystallize писал:
grass demo наверное, где многослойный ландшафт и озеро.

Да вроде там пол ровный был, ещё на крыше дома ноды были.

Цитата:

Дядя Миша писал:
FiEctro когда займусь навигацией всё расскажу и покажу.

К тому времени я сам уже разберусь.

Отправлено Дядя Миша 30-01-2024 в 10:04:

То была просто тестовая карта из PrimeXT, я проверял как модельки превращаются в браши. Ну вот на этом тестовом домике - отлично превращаются.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 03-02-2024 в 11:52:

Ну чтож, вот руки наконец-то дошли до поиска путей. Собственно сам поиск - это реализация алгоритма A*. Тут вроде как иных вариантов попросту нет, по крайней мере на первый взгляд. Однако, кроме непосредственно поиска пути, нас интерисует ещё несколько вещей:

1. рассчёт сетки на статичной геометрии. Это я успешно проделал весной прошлого года, где-то тут в теме есть скриншоты. Теперь у нас есть сетка доступности в рамках статичной геометрии. Хорошо, но это только половина дела.
2. блокировка сетки с учётом подвижной геометрии. К подвижной геометрии мы можем отнести все лифты, двери, вагончики, а так же других монстров и игрока.
И вот какие у нас тут есть варианты? Я к примеру не знаю как это устроено в Юнити\Унреале, но руководствуясь здравым смыслом и тем фактом, что ни в одной игре ни один монстр не добирается до конечной точки мгновенно (тогда бы его было проще туда телепортировать, а поиск пути был бы вообще не нужен), можно наметить два сценария:
1. Сперва делается поиск по статичной геометрии, а поправки на динамическую вносятся на каждом шагу, который сделал монстр.
2. Динамическая геометрия может вносить изменения в статичную сетку.

Я склоняюсь ко второму подходу, но с элементами первого. Если мы к примеру выбрали первый вариант, он нам рассчитал доступность пути, монстр по нему побежал и тут внезапно оказалось, что на пути есть закрытая дверь. И монстр будет в нее безнадёжно долбиться, прямо как в халфе. Кому такое интересно видеть? Во втором варианте идея в том, что ячейки навигационной сетки линкуются в тоже самое AABB-дерево, что и физические объекты. Поскольку это делается каждый кадр и обязательно для физики (чтобы искать объекты), нам даже не придётся перестраивать архитектуру всего этого дела. Только лишь определить какие именно объекты нам надо указать в качестве фундаментальных блокираторов пути. А дальше их линковка в сетку автоматически пометит те или иные ячейки как недоступные и A* будет это учитывать. Что немаловажно - мы например можем исключить из блокираторов двери, которые монстр в состоянии открыть самостоятельно - для него они будут прозрачными.
Единственный минус такого подхода - мы не сможем фильтровать объекты на уровне разных монстров. Ну типа один может открывать все двери, а другой - только определённые. Хотя и это можно решить, например заведя маску блокировки. Ну пока что не требуется. Обычно идёт разграничение на скриптовые двери и двери, которые могут открыть все.
А игроку построение пути не нужно.
Что же касается элементов второго подхода, то на мой взгляд блокировать сетку перемещением тех же NPC смысла не имеет. Пока наш монстр добежит, там уже 10 раз всё поменяется. Поэтому огибание локальных препятствий (в виде ббокса монстров) можно оставить классическим - т.е. так, как его реализовал Кармак - через рандом и сохранение общего направления пути. Потому что обогнуть таким образом ббокс получится, а вот найти более сложный путь - уже нет.
Собственно, именно поэтому монстры в кваке такие тупые.
Плюс в том, что проверка локальных перемещений больше не требует тяжёлой трассировки уровня, т.к. мы движемся по предрассчитаному пути, который гарантировано проходим.

Собственно пример того, как закрытие двери обновляет навигационную сетку:

Это всё делается на самом низком уровне, поэтому мы не зависим от логики самих дверей или лифтов. Дверь может остановиться в любом положении и в сетке будет доступен именно проход по ширине щели.

Ну и ещё об одном моменте хочу сказать. Если бы я смержил эти ноды в меш, то уже не смог бы проделать эту фишку. Так что пожалуй пока остановлюсь на дискретных нодах.

Добавлено 03-02-2024 в 14:52:

Поговорим об общей философии поиска пути. Учитывая что практически всегда используется A* либо его модификации, для увеличения скорости работы. Алгоритм находит кратчайший путь между двумя точками.
В переводе с человеческого на машинный это означает:
1. Найти все возможные пути из точки А в точку Б
2. Выбрать самый короткий из них
Оптимизация предполагает, что мы не будем трассировать все пути, а осуществлять непрерывную коррекцию дистанции прямо в процессе поиска, т.е. кол-во шагов сокращается. Всё это довольно долго.

Я смотрю на это дело следующим образом. Нахождение пути используется только и исключительно монстрами, которые в игре призваны имитировать живые существа, либо человекоподобных роботов. И те и другие могут ошибаться, как ошибается в реальной жизни и сам человек. Т.е. когда маршрут очевиден - человек разумеется выбирает кратчайший путь.
Если маршрут неочевиден, может быть выбран и не самый оптимальный путь.
Для игры это некритично. Ну сделает монстр десяток лишних шагов, так что же с того? Наоборот подобное поведение придаст ему больше человечности, он не будет ломиться каждый раз по одному и тому же пути.
Таким образом мы приходим к простой мысли: для большинства случаев нам вовсе необязательно искать все доступные пути и затем выбирать наилучший. Будет вполне достаточно найти из приемлимых. Это куда проще и быстрее. Мы можем использовать тот же самый алгоритм, который использует квейк для поиска пути - выбор одного из четырёх направлений + рандом. Вот только от квейка, который каждую ячейку долго и муторно тестирует на предмет заполненности геометрией, наличия обрывов, уступов, возможности сделать шаг вверх\вниз или скажем наличие водной преграды, в моём алгоритме ничего этого не понадобится - т.к. ячейки уже заранее предрассчитаны и если между ними есть связь, значит шаг возможен. Проложение пути осуществляется по кратчайшему расстоянию между точками. У каждой ноды - четыре соседа.
Значит аппроксимация для углов, отличных от 90 градусов - просто чередование смены направлений. Сперва влево, потом вправо.
Можно и локальный рандом подмешать, он погоды не сделает. Монстр не обязан бегать как по рельсам. Я помню как в P2 меня покоробило, что солдаты бегут по нодам именно как по рельсам, несмотря на все триангуляции. Но зато математически всё чётко - не придерёшься.
Опять же режим поиска может настраиваться при помощи флагов, например. Помоему такой фишки ещё нигде не было.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-02-2024 в 12:12:

Дядя Миша
У меня такой вопрос с которым я сам столкнулся. Вот если сам игрок и монстры будут являться преградой для А* то как поступать? Ну ладно упростим, игрока игнорируем его обходить не будем. Но что делать с монстрами? Они могут окружить игрока и тогда поиск пути к игроку будет невозможен. И тут я столкнулся с такой проблемой что вот именно в таком конкретном случае дерево начинает беспомощно разростаться в надежде найти нужный путь, и следовательно тормозить.

Цитата:

Дядя Миша писал:
Я склоняюсь ко второму подходу, но с элементами первого. Если мы к примеру выбрали первый вариант, он нам рассчитал доступность пути, монстр по нему побежал и тут внезапно оказалось, что на пути есть закрытая дверь.

Я тоже думал об этом, не придумал ничего более умного чем просто изредка например 1 раз в секунду прокидывать трассу между нодами. Наверное это не очень хорошая идея с т.з. производительности, но зато гарантировано определит всякие тонкие двери и мелкие препятствия лежащие за пределами точности сетки.

Цитата:

Дядя Миша писал:
Я помню как в P2 меня покоробило, что солдаты бегут по нодам именно как по рельсам, несмотря на все триангуляции. Но зато математически всё чётко - не придерёшься.

Мы боролись с этим так - по нодам как по рельсам двигается невидимый объект, а за ним просто как в точку бежит монстр на небольшом расстоянии. Это выглядит более естественно.

И ещё такой вопрос, что насчёт нодов для летающих и плавающих монстров (как глючный ихтиозавр из хл1 и верталёт)? Как они работают?

Отправлено Дядя Миша 03-02-2024 в 14:14:

Цитата:

FiEctro писал:
Вот если сам игрок и монстры будут являться преградой для А* то как поступать?

Да так же, как Кармак поступал. Очень тупой способ, но для локальных препятствий в виде коробки прекрасно работающий.
Допустим монстр идёт в заданном направлении. Упёрся в игрока. Выбрал путь влево или вправо. Сделал шаг. Затем попытался вернуться к заданному направлению - не прокатило. Сделал ещё шаг в обходном (выбранном изначально). Опять попытался вернуться - о, теперь путь свободен.
Плавно возвращаемся к заданному направлению под углом. Человек и в жизни бы сделал точно так же. Вот пояснительную картинку приложил.

Цитата:

FiEctro писал:
дерево начинает беспомощно разростаться в надежде найти нужный путь, и следовательно тормозить.

И это тоже проблема, совершенно верно.

Цитата:

FiEctro писал:
просто изредка например 1 раз в секунду прокидывать трассу между нодами

Не надо "Изредка". Надо всё чётко привязывать к событиям. Что за мода такая - изредка. Изредка можно запускать разве что сборщик мусора, да и то...

Добавлено 03-02-2024 в 17:14:

Цитата:

FiEctro писал:
мелкие препятствия лежащие за пределами точности сетки.

Не знаю что у тебя там за сетка такая, но в NT подобное невозможно просто по определению. Т.к. каждая нода имеет объем, равный размеру хулла монстра. И любое препятствие имеет объем. И ноды стоят вплотную друг к другу. Как там может что-то протиснуться?
На визуализацию не смотри, я их нарочно немного уменьшил, чёб в глазах не рябило. В реальности они впритык стоят.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-02-2024 в 15:15:

Цитата:

Дядя Миша писал:
Не надо "Изредка". Надо всё чётко привязывать к событиям. Что за мода такая - изредка. Изредка можно запускать разве что сборщик мусора, да и то...

Ну теперь то я всё понял как ты оптимизируешь. Я то всё в реальном времени обсчитываю и пути, и занятость нод и т.д. понятно почему у тебя оно не тормозит.

Цитата:

Дядя Миша писал:
И это тоже проблема, совершенно верно.

Но я даже пока не знаю как решать её. Пока что просто прерываю если циклов получается очень много. При обычных ситуациях такого практически никогда не бывает.

Отправлено Crystallize 03-02-2024 в 15:17:

Цитата:

Дядя Миша писал:
Что же касается элементов второго подхода, то на мой взгляд блокировать сетку перемещением тех же NPC смысла не имеет. Пока наш монстр добежит, там уже 10 раз всё поменяется.

Хороший монстр должен пытаться предсказать поведение других монстров как в непосредственной близости от себя так и чуть подальше по направлению своего движения. Как минимум через экстраполяцию их текущего движения на несколько сотен юнитов вперёд.

Цитата:

Дядя Миша писал:
Алгоритм находит кратчайший путь между двумя точками.

Сделай чтобы путь по возможности оставлял зазор в 1 ячейку от каждой стенки. И от других монстров и игрока. И чтобы монстров как бы немного заносило при обходе препятствий, ну типа скругленный путь. Потому что даже собака не будет идти и обтирать боком стену и никто не хочет на повороте внезапно столкнуться нос к носу с врагом или даже с коллегой идущим из-за угла. Тем более в ситуациях вроде каскадного резонанса.

Отправлено FiEctro 03-02-2024 в 15:29:

Цитата:

Дядя Миша писал:
Не знаю что у тебя там за сетка такая, но в NT подобное невозможно просто по определению. Т.к. каждая нода имеет объем, равный размеру хулла монстра. И любое препятствие имеет объем. И ноды стоят вплотную друг к другу. Как там может что-то протиснуться?

В целом тоже верно если оно всё содержимое коробки апроксимирует до её размера. Но коробки очень тормозные, у меня сферы, а сферы могут страдать фигнёй, хотя я этого не замечал, но боюсь что что то оно может пропускать.

Цитата:

Crystallize писал:
Сделай чтобы путь по возможности оставлял зазор в 1 ячейку от каждой стенки. И чтобы монстров как бы немного заносило при обходе препятствий, ну типа скругленный путь. Потому что даже собака не будет идти и обтирать боком стену и никто не хочет на повороте внезапно столкнуться нос к носу с врагом или даже с коллегой идущим из-за угла. Тем более в ситуациях вроде каскадного резонанса.

Ну да, в Юнити есть такая штука для навмеша типа отступы от стенок делать. А то любят они пушками сквозь двери светить.

Добавлено 03-02-2024 в 18:22:

Цитата:

Crystallize писал:
Хороший монстр должен пытаться предсказать поведение других монстров как в непосредственной близости от себя так и чуть подальше по направлению своего движения. Как минимум через экстраполяцию их текущего движения на несколько сотен юнитов вперёд.

Проблема этих предсказаний в их производительности. А* работает хорошо когда гарантировано у тебя есть свободный путь, но вот если его нет надо уже городить какие то костыли. Если каждый монстр будет чекать всех остальных это может привести ещё к большим затупам среди них.

Добавлено 03-02-2024 в 18:29:

Цитата:

Дядя Миша писал:
Да так же, как Кармак поступал. Очень тупой способ, но для локальных препятствий в виде коробки прекрасно работающий.
Допустим монстр идёт в заданном направлении. Упёрся в игрока. Выбрал путь влево или вправо. Сделал шаг. Затем попытался вернуться к заданному направлению - не прокатило. Сделал ещё шаг в обходном (выбранном изначально). Опять попытался вернуться - о, теперь путь свободен.
Плавно возвращаемся к заданному направлению под углом. Человек и в жизни бы сделал точно так же. Вот пояснительную картинку приложил.

Ты не понял. Вот игрок занимает 1 клетку. 8 клеток вокруг него это монстры его со всех сторон окружили. Монстр где то снаружи уже не сможет построить к игроку путь, т.к. монстры которые окружили игрока являются преградой. A* не имеет решения. Если таких монстров много, каждый начинает нищадно дудосить дерево приводя к тормозам.

MMM
MPM<-----------M(A*)
MMM

И везде где я встречал говорится именно о случаях где путь есть. Но вот случаи что делать если пути нет, они замалчивают. Я пытаюсь строить путь до первой преграды, что и приводит к вышеупомянутым проблемам.

Отправлено Crystallize 03-02-2024 в 15:33:

Цитата:

FiEctro писал:
Ну да, в Юнити есть такая штука для навмеша типа отступы от стенок делать. А то любят они пушками сквозь двери светить.

Для случая с пушками в Сорсе году в 2015 выпускали хак для рендера. Но вообще вплотную не прижиматься никуда всем телом это просто инстинкт живого существа.

Цитата:

FiEctro писал:
Проблема этих предсказаний в их производительности. А* работает хорошо когда гарантировано у тебя есть свободный путь, но вот если его нет надо уже городить какие то костыли. Если каждый монстр будет чекать всех остальных это может привести ещё к большим затупам среди них.

Когда у тебя 3000 энтитей и каждая чекает все остальные то да.

В остальных случаях не должно быть проблем.

Отправлено FiEctro 03-02-2024 в 15:36:

Цитата:

Crystallize писал:
Для случая с пушками в Сорсе году в 2015 выпускали хак для рендера. Но вообще вплотную не прижиматься никуда всем телом это просто инстинкт живого существа.

Я говорю про пушки у монстров в руках.

Цитата:

Crystallize писал:
Когда у тебя 3000 энтитей и каждая чекает все остальные то да.

3000 энтитей это крайне мало в современных движках. Но конкретно 3000 монстров с А* врядли кто то будет ставить в одном месте.

Отправлено Дядя Миша 03-02-2024 в 15:39:

Цитата:

Crystallize писал:
Хороший монстр должен пытаться предсказать поведение других монстров как в непосредственной близости от себя

Вообще-то когда толпа - все друг-другу мешают. Ничего предсказать невозможно.

Цитата:

FiEctro писал:
Но коробки очень тормозные, у меня сферы

Как у тебя коробки тормозные ума не приложу. Ты что каждый кадр проверяешь миллион коробок?

Цитата:

FiEctro писал:
Монстр где то снаружи уже не сможет построить к игроку путь, т.к. монстры которые окружили игрока являются преградой. A* не имеет решения.

Я же сказал, что монстров в качестве блокировщиков пути можно включать по желанию. Я это выключил. Т.е. построитель пути монстров не видит и не учитывает. Потому что пока тот для кого строился путь добежит - там уже 10 раз всё поменяется. К тому же если, это союзник и он увидит монстров - он переключится в режим боя. А там глядишь и путь освободится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 03-02-2024 в 15:49:

Цитата:

FiEctro писал:
3000 энтитей это крайне мало в современных движках.

В новых думах запрещают ставить на карту больше 12 кажется монстров в одном зале.

Цитата:

FiEctro писал:
Я говорю про пушки у монстров в руках.

Ну я понял.

Добавлено 03-02-2024 в 22:49:

Цитата:

Дядя Миша писал:
Вообще-то когда толпа - все друг-другу мешают. Ничего предсказать невозможно.

Толпа это крайний случай. Но когда два монстра сближаются под некоторым углом то они должны суметь разойтись ещё на некотором расстоянии, без необходимости одного уткнуться носом в бок другому. Один из них должен либо ускориться и пробежать наперерез, либо пройти за спиной.

Отправлено Дядя Миша 03-02-2024 в 18:37:

Цитата:

FiEctro писал:
3000 энтитей это крайне мало в современных движках

Всё зависит от того, какую роль выполняет каждый из объектов.
Если три тысячи монстров, то навряд ли Юнити это вытянет.

Цитата:

Crystallize писал:
Но когда два монстра сближаются под некоторым углом то они должны суметь разойтись ещё на некотором расстоянии

А зачем им сближаться? Если на локации толпа и все настроены враждебно, игрок в последнюю очередь будет рассматривать как они друг-друга обходят.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 03-02-2024 в 19:24:

Цитата:

Дядя Миша писал:
Я же сказал, что монстров в качестве блокировщиков пути можно включать по желанию. Я это выключил. Т.е. построитель пути монстров не видит и не учитывает. Потому что пока тот для кого строился путь добежит - там уже 10 раз всё поменяется. К тому же если, это союзник и он увидит монстров - он переключится в режим боя. А там глядишь и путь освободится.

Так, а если не выключать? Как это можно оптимизировать?

Отправлено Crystallize 03-02-2024 в 20:38:

Цитата:

Дядя Миша писал:
А зачем им сближаться? Если на локации толпа и все настроены враждебно, игрок в последнюю очередь будет рассматривать как они друг-друга обходят.

Это может влиять на геймплей. Пока монстр тупит он легкая мишень для игрока. В той же кудваке была фича когда энфорсер мог добежать до кнопки и включить сирену после чего взрывались ящики и прилетали враждебные дроны.
Но я имел в виду скорее кейс когда ученые ходят по скриптовым путям. Да и в хл2 людей бесило когда напарники блокировали собой проходы.

Отправлено FiEctro 03-02-2024 в 20:41:

Как правило при большом количестве мобов проблема в том что они сбиваются в длинную очередь и плетутся паровозиком за игроком.

Отправлено Дядя Миша 04-02-2024 в 13:57:

Цитата:

FiEctro писал:
Так, а если не выключать?

Тогда будет логическое противоречие.

У A* как я понял главная проблема в том, что он в принципе не допускает возможности фейла. Тогда как в играх это сплошь и рядом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено SNMetamorph 05-02-2024 в 00:36:

Так ты в итоге от навмешей отказался в пользу обычных нодов? Не особо понимаю какой концепт на текущий момент времени.

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord

Отправлено Дядя Миша 05-02-2024 в 05:38:

Навмешы я и не делал никогда. Я просто обратил внимание, что навмешы делаются из этих же самых нодов. Путём аналитической склейки нодов в примитивы. Вот этот шаг я просто не стал выполнять. Потому что ноды оказалось дико удобно выключать перекрывающими объемами, что с навмешем уже не проделаешь. Да я же серию картинок приводил.
У нодов единственный минус - то что их много, а так они даже удобнее в работе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-02-2024 в 06:06:

Цитата:

Дядя Миша писал:
У A* как я понял главная проблема в том, что он в принципе не допускает возможности фейла. Тогда как в играх это сплошь и рядом.

Да в этом и проблема. Его начинает раздувать на всё свободное пространство.
Кстати ты так и не рассказал что там за кластеры у тебя.

Кстати помимо A* можешь чекнуть ещё следующие методы:

Dijkstra's Algorithm (Алгоритм Дейкстры)
Breadth-First Search (Поиск в ширину)
Probabilistic Roadmaps (PRM)
Visibility Graphs (Граф видимости)
Cell Decomposition

Цитата:

SNMetamorph писал:
Так ты в итоге от навмешей отказался в пользу обычных нодов? Не особо понимаю какой концепт на текущий момент времени.

Работа нодов большой плотности ничем не отличается от навмешей. Единственный минус это как говорил ДМ что нпц ходят как по рельсам, но это можно сгладить.

Отправлено Дядя Миша 05-02-2024 в 06:26:

Цитата:

FiEctro писал:
Кстати ты так и не рассказал что там за кластеры у тебя.

Да это я так неудачно выразился штоле, а ты прям зацепился за это слово.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-02-2024 в 06:39:

Такую штуку ещё нашел, но пока не выкурил как это работает.

Отправлено Дядя Миша 05-02-2024 в 06:43:

Забавно. У меня изначально мысль работала как раз в направлении vector field pathfinding, я даже другие варианты и не рассматривал, мне этот казался самым очевидным. Собственно, именно его я сейчас и делаю.

Добавлено 05-02-2024 в 09:43:

Причём я вообще не штудировал никакой литературы на этот счёт, просто опирался на собственный опыт.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-02-2024 в 06:45:

Цитата:

Дядя Миша писал:
Забавно. У меня изначально мысль работала как раз в направлении vector field pathfinding, я даже другие варианты и не рассматривал, мне этот казался самым очевидным. Собственно, именно его я сейчас и делаю.

Расскажи хоть кратко как это устроено.

Отправлено Дядя Миша 05-02-2024 в 09:09:

Досмотрел видео. Ну как обычно, начали за здравие. Какая нахрен карта градиентов в рантайме? А если у меня четыре миллиона нодов?
Нет, у меня иной принцип.

Добавлено 05-02-2024 в 09:53:

Я не планирую строить никакие карты градиентов. Поиск пути должен закончится быстрее, чем будет построена эта карта.

Добавлено 05-02-2024 в 11:13:

Итак, первые опыты. Когда я говорю "первые опыты", это означает, что создан механизм линковки нодов в AABB-дерево, создана пользовательская команда для построения пути из глаз игрока до точки прицела, создан механизм визуализации, которые показывает построенный нами путь, раскрашивая его градиентом от красного (начало) до зелёного (конец),
и написан простейший эвристический анализатор, задающий вектор пути для поиска без перебора. Посмотрим как это выглядит:

На последней картинке путь упирается в препятствие, не в силах его обогнть - алгоритм пока что такое не умеет.

Добавлено 05-02-2024 в 11:19:

Теперь, собственно, как это работает. У каждой ноды есть четыре соседа.
Они идут в строгом порядке, сосед с индексом 0 - это левая нода, сосед с индексом 1 - передняя, итогдалие. Т.е. по часовой стрелке.
Зная эту особенность, мы всегда можем вычесть позицию конечной ноды из текущей, нормализовать получившийся вектор и при помощи нехитрой функции, превратить направление в индекс ноды, которую нам следует выбрать. Именно поэтому путь сперва прямой, а затем начинает заворачивать. Я не берусь утверждать, что найденный путь является кратчайшим, но это не имеет никакого значения. Потому что живые существа далеко не всегда выбирают самый кратчайший путь.
Достаточно чтобы он был приемлимым.

Добавлено 05-02-2024 в 12:07:

То что приведено на рисунках выше - это просто прямой путь.
Если он упрётся в препятствие, то всё закончится. Добавим к алгоритму так же поиск ближайшего пути с учётом проверки на наличие уже пройденных нод. Ну чтобы путь случайно не закольцевался. Пусть лучше сфейлит.

Как видите - это вполне неплохо работает. Препятствия огибаются. На третьем скриншоте изображён фейл - я хотел попасть в самую дальнуюю комнатку, алгоритм упёрся в угол и всё закончилось. Чтобы избежать такого поведения, нам надо сохранять лишь часть нашего пути и делать бэкапы в спорных местах. Спорное место - это когда мы упёрлись в блокирующую ноду, очевидно. Учитывая организацию нод в пространстве - у нас есть фактически бинарный выбор. Мы можем попробовать обойти препятствие либо слева, либо справа.

Добавлено 05-02-2024 в 12:09:

Прикол в том, что в поиске пути при подобной организации нод есть всего-навсего четыре варианта действий:

1. прямой и тупой поиск.
2. огибание препятствия по вектору
3. огибание препятствия по отрицательному вектору
4. настолько сложная конфигурация лабиринта, что надо вообще идти назад.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено (_-=ZhekA=-_) 05-02-2024 в 09:12:

Цитата:

FiEctro писал:
А то любят они пушками сквозь двери светить.

Можно научить его просто немного опускать оружие в руках, если подошел вплотную к стене, такое уже давно используется

Отправлено FiEctro 05-02-2024 в 10:58:

Дядя Миша
Я вот что подумал, а что если узкие проходы помечать как более приоритетные? Конечно в туннеле в 1 шаг делать это бессмысленно, но в твоём бы случае думаю это сильно помогло. Ведь даже человек бессознательно ищет как первую цель именно первый дверной проём. Что то в этом есть.

Ещё появилась такая мысля что для предрасчитаной статичной сетки можно и предрасчитать A*. Но это пока просто мысли, я ещё не обдумывал всё.

Дополню что можно сделать перебор по построению пути между комнатками, т.е. искать заранее не объект, а комнату относительно другой. А вот уже игрок будет искать ближайшее A* дерево т.к. ему ещё до начала поиска известно в какой комнате находится цель и в какой он сам.

Отправлено Дядя Миша 05-02-2024 в 12:15:

Цитата:

FiEctro писал:
Ещё появилась такая мысля что для предрасчитаной статичной сетки можно и предрасчитать A*

Градиенты можно посчитать. Чтобы алгоритм заведомо не лез в тупики.
Это неплохая оптимизация, но я пока что вожусь со своим велосипедом.

Цитата:

FiEctro писал:
Я вот что подумал, а что если узкие проходы помечать как более приоритетные?

От узкого прохода до нашей цели может быть ещё сколько угодно нод.
Само хождение по нодам весьма быстрое, поэтому на данный момент я пока не вижу смысла оптимизировать этот момент. Ну разве что столкнёмся с ситуацией, когда кишка на полкарты ведет в заведомый тупик, но опять же - это надо профилировать.

То что на картинке - это ты для себя переоткрыл portal flow, да. Хорошая штука, но ей нужны навмешы, вместо нодов. А я уже говорил, что пока принял решение остановиться на нодах.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 05-02-2024 в 16:32:

Ну, собственно. Впрочем, он частенько фейлит.
Буду думать.

Добавлено 05-02-2024 в 19:32:

Тест на реальных уровнях:

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-02-2024 в 19:54:

По скриншотам вроде всё ок?

Цитата:

FiEctro писал:
Конечно в туннеле в 1 шаг делать это бессмысленно

Кстати да, пришла такая мысля что в такой ситуации как опорные точки вместо проёмов можно использовать повороты туннеля (может даже выпуклые углы?). Попробуй лабиринт сделать классический. Интересно как у тебя будет работать.

Отправлено Дядя Миша 05-02-2024 в 19:57:

Цитата:

FiEctro писал:
По скриншотам вроде всё ок?

Эта штука очень сильно зависит от начального и конечного направления.
Впрочем, если не искать путь сквозь всю карту, то она нормально справляется. Но мне не нравится, что есть заведомо фейловые кейсы, их не должно быть.

Добавлено 05-02-2024 в 22:57:

Цитата:

FiEctro писал:
Попробуй лабиринт сделать классический.

Ну на скриншоте во вложении, что по твоему? Не классический лабиринт?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-02-2024 в 20:06:

Цитата:

Дядя Миша писал:
Ну на скриншоте во вложении, что по твоему? Не классический лабиринт?

Вот классический лабиринт:
https://cs12.pikabu.ru/post_img/201...38147937444.jpg

Цитата:

FiEctro писал:
(может даже выпуклые углы?)

Кстати да у нод на выпуклых углах интересная особенность что они всегда друг друга видят (за исключением карты коробки где все углы вогнутые), но там и препятствий нет). По ним реально пути можно строить. Странно что нигде об этом не упоминается, это в разы бы уменьшило количество необходимых нод если речь идёт именно о простом поиске пути.

Отправлено Дядя Миша 05-02-2024 в 20:26:

Цитата:

FiEctro писал:
Вот классический лабиринт:

Самое любопытное то, что AStar без проблем его пройдет, а мой алгоритм скорее всего нет. Но в реальных играх такие лабиринты и не встречаются.

Цитата:

FiEctro писал:
Кстати да у нод на выпуклых углах интересная особенность что они всегда друг друга видят (за исключением карты коробки где все углы вогнутые), но там и препятствий нет).

Картинку нарисуй штоле.

Добавлено 05-02-2024 в 23:26:

Я тут поизучал имплементации AStar и обратил внимание на примечательный факт. Запуск алгоритма начинается с перемещения всех узлов в локальный массив. И потом они из него перетекают в другой массив.
Вот сейчас у меня на баллотах 4.5 миллиона нод и я буду их в какой-то массив пихать. Делать мне нечего.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 05-02-2024 в 20:40:

Цитата:

Дядя Миша писал:
Картинку нарисуй штоле.

Вот. Имеются ввиду ноды на выпуклых углах геометрии. Остальные игнорируются.

Отправлено Дядя Миша 05-02-2024 в 21:14:

Ещё проще - ноды, где кол-во связей менее четырёх.
Да, ты прав, что-то в этом есть. Я подумаю над этим.

Можно замутить локальную трассировку между такими нодами.

Добавлено 06-02-2024 в 00:11:

A* почти во всех движках запускается в фоне, никто не может гарантировать что путь будет рассчитан за приемлимое время.
Мда.

Добавлено 06-02-2024 в 00:14:

А ведь действительно. Зачем мне бегать по этим нодам, я если я могу замутить в пространстве нод трассировку, как будто бы это не ноды, а реальная геометрия.
Скажем стрельнул по направлению к цели - ага, фейл, значит, стреляем между корнерами. Ну посмотрим. Идея интересная.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-02-2024 в 06:23:

Ещё такая мысля что монстр может искать только самую дальнюю ноду в прямой его видимости в 2д пространстве. Дабы не ходить и облизывать каждый угол на пути к очевидной цели.

Цитата:

Дядя Миша писал:
Ещё проще - ноды, где кол-во связей менее четырёх.

Так у стены тоже меньше 4 связей.

Добавлено 06-02-2024 в 08:56:

Цитата:

Дядя Миша писал:
Скажем стрельнул по направлению к цели - ага,

Ещё можно стрелять толщиной с бокс монстра. Ведь таракан например может пролезть там где не пролезет гаргантьюа. Промежуточные ноды могут хранить информацию о высоте потолка, и может даже проверять её, вдруг там сверху дверь опускается?

Добавлено 06-02-2024 в 09:23:

И ещё такой вопрос, как строятся ноды в таких случаях? Т.е. когда у нас есть место куда гарантировано попадает нода, но её позиция не совпадает с общей сеткой?

Отправлено Дядя Миша 06-02-2024 в 06:25:

Цитата:

FiEctro писал:
Так у стены тоже меньше 4 связей.

всё что меньше четырёх связей - это какие-то препятсвия\проёмы.
И оно требует проверки.

Цитата:

FiEctro писал:
Ещё можно стрелять толщиной с бокс монстра

Ты сейчас очень сильно удивишься, но нода и так уже толщиной с ббокс монстра.

Цитата:

FiEctro писал:
вдруг там сверху дверь опускается

Так эта нода будет заблокирована, как только ббокс ноды пересечётся с ббоксом двери.

Добавлено 06-02-2024 в 09:25:

Цитата:

FiEctro писал:
Т.е. когда у нас есть место куда гарантировано попадает нода, но её позиция не совпадает с общей сеткой?

Не делать таких узких коридоров, очевидно же.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-02-2024 в 06:25:

Цитата:

Дядя Миша писал:
Зачем мне бегать по этим нодам, я если я могу замутить в пространстве нод трассировку, как будто бы это не ноды, а реальная геометрия.

Дело не в трассировке, а в том что ноды на углах видят друг друга всегда, это довольно забавная особенность геометрии используются много где. Но вот в поиске пути не встречал, наверняка наверное уже кто то догадался, но найти похожую реализацию пока не удалось.

Цитата:

Дядя Миша писал:
Ты сейчас очень сильно удивишься, но нода и так уже толщиной с ббокс монстра.

Так это для каждого монстра тогда отдельную сетку строить. Жирно.

Цитата:

Дядя Миша писал:
Не делать таких узких коридоров, очевидно же.

Так такой же коридор удовлетворяет проходимости ббокса, но соосность нод всё ломает.

Отправлено Дядя Миша 06-02-2024 в 06:34:

Поизучал вчера навмешы в юнити и UE3. Ну что сказать. У меня сложилось впечатление, что навмешы начали использовать вот как раз в силу невозможности оптимизации AStar. При этом огребли проблем, например с расстановкой обстаклей, которые теперь в этих мешах должны выгрызать дыры (ну а как ещё?). Да и сам факт, что пространство больше не квантизировано, мешает сохранять какую-то дополнительную информацию. Ну скажем я бы мог в нодах на берегу водоёма установить подсказку - форсирование водной преграды. С навмешами, понятно, такое уже не прокатит.

Добавлено 06-02-2024 в 09:34:

Цитата:

FiEctro писал:
а в том что ноды на углах видят друг друга всегда, это довольно забавная особенность геометрии используются много где

Поздравляю, у тебя появилось базовое понимание конвексной геометрии.

Цитата:

FiEctro писал:
Так это для каждого монстра тогда отдельную сетку строить. Жирно.

Ну а что делать? Не для каждого конечно. Ну вот в халфе были клипхуллы - три штуки. Хватало.

Цитата:

FiEctro писал:
Так такой же коридор удовлетворяет проходимости ббокса, но соосность нод всё ломает.

Что ты сделаешь с регулярной сеткой?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-02-2024 в 06:36:

Цитата:

Дядя Миша писал:
Что ты сделаешь с регулярной сеткой?

Локальные сетки. Например если в геометрию влазит нода но она не соосна с регулярной сеткой, можно создать для неё отдельную группу с оффсетом.

Цитата:

Дядя Миша писал:
Поздравляю, у тебя появилось базовое понимание конвексной геометрии.

Да это понятно, я же сразу писал что углы конвексные. Просто я не знал что так пути искать можно.

Отправлено Crystallize 06-02-2024 в 07:06:

Цитата:

Дядя Миша писал:
Не делать таких узких коридоров, очевидно же.

Юзеры скосят калидор и когда монстр откажется идти, решат что это глюк движка.

Отправлено Дядя Миша 06-02-2024 в 08:45:

Цитата:

FiEctro писал:
Локальные сетки. Например если в геометрию влазит нода но она не соосна с регулярной сеткой, можно создать для неё отдельную группу с оффсетом.

Да, давай усложняй, чтобы каждый запрос на генерацию пути обрабатывался минимум 10 секунд.

Цитата:

Crystallize писал:
Юзеры скосят калидор и когда монстр откажется идти, решат что это глюк движка.

Вообще-то сетка визуализируется.

Добавлено 06-02-2024 в 11:45:

Можно попробовать ещё вот какую штуку. Сделать из карты нодов - двухмерное BSP-дерево и портализовать его. Тогда, соответственно поиск пути сведётся к Portal Flow. Правда репортализацию придётся выполнять каждый раз при обновлении обстаклей, что не слишком хорошо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-02-2024 в 09:23:

Цитата:

Дядя Миша писал:
Да, давай усложняй, чтобы каждый запрос на генерацию пути обрабатывался минимум 10 секунд.

Какая разница если сетки собираются в оффлайне? А в игре они уже единым массивом. Это только вопрос расстановки нод.

Пришла такая мысля что ноды например можно расставлять по нормали от стены. Тогда они будут учитывать повороты корридоров. Однако это уже конечно не регулярная сетка, и в местах стыков соседей надо определять несколько иначе.

Отправлено Дядя Миша 06-02-2024 в 12:33:

Потестировал свою конструкцию в сталкере. Ну в принципе норм.
Скорость рассчёта весьма быстрая, если речь только о поиске пути при наличии визуального контакта, то мой алгоритм почти всегда справляется.
Если же речь о том, чтобы монстр честно прорвался с одного края карты на другой, пока его никто не видит - то увы. Скорее всего сфейлит.

Но скажем поиск пути, когда враг забежал за угол или за два угла - вот это всегда работает чётко. А ведь именно это в играх и бесит больше всего.
Игрок за угол забежал - монстры его потеряли. Так быть точно не должно.

Добавлено 06-02-2024 в 14:09:

Постепенно приходит понимание, что алгоритм полного и честного поиска пути через перебор всех существующих ячеек на данный момент мне просто-напросто не нужен. В первой-второй кваке монстры вообще искали игрока тыкаясь в примерном направлении, куда он убежал и останавливаясь на каждом шагу. И ничего, игроки им эту тупость вполне прощали.
Моя реализация позволяет успешно огибать не слишком сложные препятствия, вплоть до поиска пути с одного этажа на другой.
Зато скорость поиска такого пути - мгновенная. Ну почти.
Так что я буду оттачивать и отлаживать свой алгоритм.

Добавлено 06-02-2024 в 15:33:

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 06-02-2024 в 12:41:

Дядя Миша
А как кстати боты в той же кваке третьей путь ищут? Там они довольно бодро бегают и не спотыкаются.

Отправлено Дядя Миша 06-02-2024 в 13:23:

Так я же объяснял - через портализацию. Это спайка технологий трёхмерного навмеша, фиксированных хуллов и portal flow. Впрочем с обстаклями там дело обстоит так же как грустно как и с классическими навмешами. Но для кваки некритично, там из обстаклей только двери, которые может открыть любой бот или игрок.

Добавлено 06-02-2024 в 16:23:

Я ведь поначалу и сам хотел сделать нечто подобное, но оно не подружится с полигональной геометрией. Хотя я честно три недели копал в этом направлении.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 07-02-2024 в 11:02:

https://webdocs.cs.ualberta.ca/~mmueller/ps/hpastar.pdf

Отправлено Дядя Миша 08-02-2024 в 08:59:

Итак товарищи, я финализировал свой авторский алгоритм поиска пути.
При его разработке я сделал целую кучу допущений и активно опирался на уже имеющееся у меня представление навигационной сетки.

Допущения были следующие:
1. В подавляющем большинстве случаев монстру не надо прокладывать кратчайший маршрут через полкарты. Обычно это или маршрут по прямой, или маршрут буквой Г, если враг успел укрыться за углом. Нахождение подобного маршрута может быть решено крайне быстро.
2. В некоторых случаях, например если мы хотим попасть в какую-то точку сквозь узкий проём, допустимо реверсивное построение маршрута, в случае если прямой путь зафейлился.
3. Лучше просто зафейлить построение маршрута, чем пытаться найти путь, который возможно вообще не существует. При этом мы не должны привязываться ни к каким магическим константам или радиусам, в которых этот путь ищется. Иными словами фейл проблемного пути должен завершиться так же быстро, как и поиск существующего.
4. Пусть маршрут будет не слишком коротким, главное чтобы он построился быстро.

Исходя из этого я разработал алгоритм, основанный на движении по заданному направлению, сходимости и отскоке от препятствий, с вариативностью. Суть алгоритма сводится к следующему:
Каждую итерацию мы выбираем ноду, согласно направлению между текущей и финальной. Из четырёх нод мы можем выбрать только три.
Первой будет выбрана самая предпочтительная, затем - менее предпочтительная, затем самая нежелательная. Таким образом на каждом шаге у нас может образоваться три ноды. Первая нода используется в поиске текущего пути, вторая и третья (если они выбраны) добавляются к уже пройденному пути (текущий путь + вторая нода) и (текущий путь + третья нода), которые помещаются в массив частичных путей. Изначально частичный путь состоит всего лишь из одной ноды - стартовой. Ну и в процессе построения первого пути достраиваются остальные частичные пути. Дальше начинается самое интересное:
Если самый первый путь успешно достроился, то функция завершает свою работу и возвращает этот самый первый путь. Если же нет, то функция в цикле пытается достроить остальные частичные пути (попутно порождая новые на каждой потенциальной развилке). Вы конечно можете задаться вопросом, что подобное порождение всё новых и новых частичных путей никогда не закончится и всё это зависнет в бесконечном цикле. Да, но нет. Ведь мы с момента построения самого первого частичного пути помечаем ноды, в которых мы уже побывали, как бы ограничивая пространство. Таким образом, путь ведущий в никуда уже заведомо отсечён чем-то вроде виртуальной секущей плоскости (в роли которой выступает сам наш путь, завершившийся фейлом). Из-за этой любопытной особенности у алгоритма есть сходимость - только один путь из всех закончится успехом, остальные упруться в препятствия. Зная эту особенность нам нет нужды проверять абсолютно все частичные пути - первый, достигший конечной точки и будет валидным маршрутом. Этот момент ценен в качестве оптимизации. т.к. потенциально алгоритм может наплодить до десятка тысяч незаконченных путей, но если уже самый первый путь достигнет финальной точки, то нам уже нет нужды их проверять - мы справились. Так же в коде присутствует специальный лукап, чтобы строящийся путь не упёрся в препятствие уже на следующем шаге, что потенциально может привести не то чтобы к быстрому фейлу, а к весьма замысловатой и нереалистичной траектории маршрута, которая будет похожа на слишком длинную змейку, которая огибает сама себя.
Эта же штука сглаживает обход препятствий и ускоряет поиск маршрута.
Однако для сложных маршрутов она наоборот сама по себе является проблемой. К примеру с этой включённой эвристикой невозможен проход сложного лабиринта, или поиск пути буквой U, когда финальная точка находится сзади начальной, а начальная - соответственно в нише, выход из которой противоположен направлению между стартовой и конечной точкой. Поэтому я сделал данную эвристику отключаемой со стороны пользователя. Таким образом есть флаг глубокого поиск пути, который используется для скриптовых сцен, например, если монстру надо прорваться сквозь всю карту. Если же он просто следует за врагом, то выставлять этот флаг не надо - время поиска значительно ускориться.

Теперь мне надо финализировать отладочный режим поиска пути, чтобы провести углублённое юнит-тестирование и по его окончании, я выложу разные интересные скриншоты и комментарии. Повторюсь, главное свойство моего алгоритма - это поиск, на который требуется не более 0.001 секунды (или меньше). Вне зависимости от кол-ва нод на карте.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 08-02-2024 в 09:14:

Всё же кажется что конвексный поиск который мы придумали был бы быстрее разрастающихся нод. Ну ладно, возможно такая реализация будет тоже хорошо работать, но конечно излишнее разрастание дерева это большой минус A* и причина тормозов. В конвексном поиске такого жесткого брутфорса уже не будет.

Надо будет уже у себя тогда поэкспериментировать.

Цитата:

Дядя Миша писал:
Вы конечно можете задаться вопросом, что подобное порождение всё новых и новых частичных путей никогда не закончится и всё это зависнет в бесконечном цикле. Да, но нет. Ведь мы с момента построения самого первого частичного пути помечаем ноды, в которых мы уже побывали, как бы ограничивая пространство. Таким образом, путь ведущий в никуда уже заведомо отсечён чем-то вроде виртуальной секущей плоскости (в роли которой выступает сам наш путь, завершившийся фейлом).

А если мы тут впервые?

Отправлено Дядя Миша 08-02-2024 в 11:54:

Цитата:

FiEctro писал:
А если мы тут впервые?

Цитата:

FiEctro писал:
Дата регистрации: Aug 2006

Добавлено 08-02-2024 в 13:53:

В режиме глубокого поиска мой алгоритм фейлит только в случае если пути действительно не существует. По крайней мере с обратной ситуацией я ещё не столкнулся. Но надо ещё на болотах рассчитать ноды для полноценного теста. Там их как раз 4.5 миллиона, вот и посмотрим.

Добавлено 08-02-2024 в 14:54:

Предварительные выводы:
1. Пока что подтверждается факт, что поиск со включённым режимом глубокого исследования никогда не фейлит.
2. В режиме глубокого исследования путь зачастую может выглядеть... странно. См аттач. В режиме быстрого поиска эвристика предотвращает появление подобных загогулин, но и вероятность фейла в случае сложного пути - кратно выше.
3. Производительность алгоритма прибита гвоздями к порядку следования нод и как следствие - к вектору направления поиска. Иными словами, поиск с севера на юг гораздо быстрее, чем поиск с востока на запад. Ну это к примеру, поскольку там целый ряд факторов. Заметным это становится тогда, когда мы выбираем сложный случай и сперва нацеливаем конечную точку в одну сторону (например на юго-запад), а потом на второй попытке целимся на северо-восток. Стартовая точка в обоих случаях остаётся идентичной.
И вот в одном случае у нас скорость работы может быть порядка 0.0005, а в другом - 0.27 секунды. Почему так происходит тоже понятно - алгоритм генерирует порядка десяти тысяч недостроенных путей и чем раньше он найдет правильный - тем быстрее завершится поиск. В первом случае валидный путь находится ближе к началу, во втором - ближе к концу, отсюда и такая чудовищная разница в скорости поиска. Однако всё вышесказанное относится только к предельным, максимально сложным случаям. Данные что я приводил выше не придуманы мной от балды, а получены на тестировании сталкеровской карты testers_mp_rostok.
Там, как вы знаете, по центру уровня стоит такой пятиэтажный недострой. Чем не лабиринт? И вот значит я тестировал выход с пятого этажа на один из краёв карты. И именно так и были получены эти значения. Впрочем подобный поиск пути в бою не нужен, только для скриптовых персонажей. Так что некритично. Важен сам факт, что по крайней мере пока доказать возможность фейла глубокого поиска мне не удалось, следовательно алгоритм работает правильно. В случае же типового поиска когда конечная и начальна точка лежат плюс-минус на одной плоскости (пусть даже и с препятствиями), поиск пути завершается примерно за 0.001 секунду, назависимо от направления поиска. Это глубокий. Обычный завершится ещё быстрее, хотя при таких значения это уже не имеет особого значения. Опять-таки сам факт, что поиск может сфейлить можно использовать для эмуляции умных и глупых монстров, например.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-02-2024 в 13:54:

Цитата:

Дядя Миша писал:
2. В режиме глубокого исследования путь зачастую может выглядеть... странно. См аттач. В режиме быстрого поиска эвристика предотвращает появление подобных загогулин, но и вероятность фейла в случае сложного пути - кратно выше.

где аттач

Цитата:

Дядя Миша писал:
Первой будет выбрана самая предпочтительная, затем - менее предпочтительная, затем самая нежелательная.

Надо найти ноды у стенок и запретить им быть предпочтительными.

Отправлено Дядя Миша 08-02-2024 в 14:25:

Пардон, забыл прикрепить

Цитата:

Crystallize писал:
Надо найти ноды у стенок и запретить им быть предпочтительными.

вот эвристика как раз этим и занимается. Но это же отсекает и потенциальные пути. Не всегда, но часто.

Добавлено 08-02-2024 в 17:25:

А вообще, я подумаю, может соображу такую табличку-матрицу 4х4 и там вручную пропишу приоритеты поиска. Глядишь станет веселее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 08-02-2024 в 14:43:

Цитата:

Дядя Миша писал:
Пардон, забыл прикрепить

О, круть.
Ну и на краях обрывов тоже неплохо бы им понизить приоритет.
Вообще задача борьбы с такими змейками перекликается с твоим советом мне про умную камеру от третьего лица. У тебя он строит буквы S а у меня игрок может пробежать кружком или ещё как и камера давай лети всё это за ним. Но у тебя это в сетку организовано. Получается лучше строить весь путь одним кадром и потом перебирать весь путь и смотреть какая самая дальняя нода доступна напрямую.

Отправлено FiEctro 08-02-2024 в 15:12:

Странно, похоже на баг, А* не должен так работать.

Отправлено Дядя Миша 08-02-2024 в 16:39:

Цитата:

FiEctro писал:
А* не должен так работать

Так это и не A*

Я ведь целую простыню накатал выше, что алгоритм мой собственный.
Да, он иногда выделывает затейливые вензеля, но в целом они предиктабельные.

Добавлено 08-02-2024 в 19:37:

Собственно, я что хотел сказать-то. Путь всё равно надо триангулировать, это касается результатов работы любого алгоритма.
Так вот срезать результаты этих вензелей - куда проще и практически ничего не стоит. Но это я как-нибудь потом, попозже сделаю.

Добавлено 08-02-2024 в 19:39:

Собственно результаты. Сложно сделать кадр так, чтобы в него одновременно попало и время работы графопостроителя и полный маршрут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено ZGreen 08-02-2024 в 16:46:

Подозрительно высокий фпс при таком количестве дипов, что это за компуктер?

Отправлено FiEctro 08-02-2024 в 16:52:

ZGreen
Так, а оригинальный сталкер разве меньше фпс даёт?

Отправлено ZGreen 08-02-2024 в 16:54:

Да какая разница что там кто дает, предыдущие билды с таким дип сотку показывали.

Отправлено FiEctro 08-02-2024 в 16:55:

Цитата:

Дядя Миша писал:
Так это и не A*
Я ведь целую простыню накатал выше, что алгоритм мой собственный.
Да, он иногда выделывает затейливые вензеля, но в целом они предиктабельные.

Хм, тогда хорошо. Интересно теперь проверить когда монстров будет ну хотя бы такое же количество как на картах в сталкере. Но в целом я согласен с тобой что строить пути прямо сквозь всю карту глупо с точки зрения гейм дизайна т.к. все монстры сразу сбегутся на игрока, а остальная карта будет пустой.

Отправлено Дядя Миша 08-02-2024 в 20:33:

Цитата:

ZGreen писал:
Подозрительно высокий фпс при таком количестве дипов, что это за компуктер?

Да всё тот же Corei3-3Ghz, GTX650.

Это как раз небольшое кол-во дипов. Проблемы начинаются от трёх тысяч.

Цитата:

ZGreen писал:
предыдущие билды с таким дип сотку показывали

Формат уровней поменялся, оптимизация поддержки детайлов. Может поэтому.

Цитата:

FiEctro писал:
Интересно теперь проверить когда монстров будет ну хотя бы такое же количество как на картах в сталкере.

Проверим, но монстры не перестраивают свои пути каждый кадр.

Мне сейчас самое главное набросать рабочий прототип. А потом что-то изменить или улучшить можно без нарушения совместимости.

Добавлено 08-02-2024 в 23:33:

По новостям: я сейчас портирую на Xash вот эту игру. Как управлюсь - будет масштабное обновление.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 22-02-2024 в 10:19:

https://twitter.com/turanszkij/stat...UiQDN4n_7A&s=19

Отправлено Дядя Миша 22-02-2024 в 12:18:

Сглаживание уже построенного пути - довольно простая и лёгкая задача на самом деле. Я планировал это потом тоже ввести, тем более что у меня путь потенциально может быть весьма затейливым.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 22-02-2024 в 12:32:

тут не только сглаживание, но и построение пути интересное, глянь видео по ссылке в свиттере

Отправлено Дядя Миша 22-02-2024 в 13:27:

Твиттор это экстермисткая организация, запрещённая на территории РФ.
Как я тебе гляну-то?
Но ты можешь рассказать своими словами.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 22-02-2024 в 13:51:

Дядя Миша
Это ты с метой перепутал. Посмотреть можешь в дискорде я тебе в личку переслал.

Отправлено Дядя Миша 22-02-2024 в 16:24:

Не пускает меня в Твиттор. Потом посмотрю.

Ну а тем временем я успешно заставил монстров следовать маршрутом.
Причём они не бегут по нему как по рельсам, а лишь придерживаются общего направления. В каком-то смысле получается халявное сглаживание пути. Ну я примерно на это и рассчитывал.
Если можете себе представить - это нечто вроде навигации в халфе, с тем лишь отличием что мы не ограничены теми info_node, которые расставил дизайнер, а наоборот - путь корректно построится из любой точки в любую.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 23-02-2024 в 10:18:

Дядя Миша
Ступеньки проверял? И как можно сделать навигацию в воде и воздухе (ихтиозавры и верталёты)? У них с навигацией в халфе было совсем всё плохо. Рандомно заполнять пространство нодами с большим шагом?

Отправлено Дядя Миша 23-02-2024 в 11:33:

Цитата:

FiEctro писал:
И как можно сделать навигацию в воде и воздухе

Никак не сделать. Тут только реалтайм проверка работает.
Предполагается что в воздухе нет препятствий, равно как и в воде.

Добавлено 23-02-2024 в 14:33:

Цитата:

FiEctro писал:
Ступеньки проверял?

Я же на скриншотах на канале показывал, что ступеньки обрабатываются наравне с остальной геометрией.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 23-02-2024 в 13:34:

Цитата:

Дядя Миша писал:
Никак не сделать.

Ну так я вон вверху предложил нодов понаставить рандомно, хотя бы вокруг конвексных поверхностей. Думаешь это жирно будет? И как вообще у тебя эта реалтайм проверка работает?

Отправлено Crystallize 23-02-2024 в 14:15:

Цитата:

FiEctro писал:
Дядя Миша
Это ты с метой перепутал. Посмотреть можешь в дискорде я тебе в личку переслал.

??? Твиттер в РФ давно забанен точно так же как и Мета.

Отправлено XaeroX 23-02-2024 в 14:25:

Цитата:

Crystallize писал:
Твиттер в РФ давно забанен точно так же как и Мета.

Лучше бы Дискорд забанили. Самый неудобный мессенджер на свете. Да ещё и десктопный клиент у меня как перестал коннектиться полтора года назад, так и всё. Никому до багфиксов дела нет.

__________________

Отправлено FiEctro 23-02-2024 в 15:25:

Цитата:

XaeroX писал:

Лучше бы Дискорд забанили.

Цитата:

XaeroX писал:
Да ещё и десктопный клиент у меня как перестал коннектиться полтора года назад, так и всё.

Мечты сбываются.

Отправлено XaeroX 23-02-2024 в 15:29:

FiEctro
Осталось понять, чьи.

__________________

Отправлено Дядя Миша 23-02-2024 в 16:42:

Цитата:

FiEctro писал:
Ну так я вон вверху предложил нодов понаставить рандомно, хотя бы вокруг конвексных поверхностей

Да смысл?

Монстр и так их обойдет безо всяких нодов.

Цитата:

FiEctro писал:
У них с навигацией в халфе было совсем всё плохо

Ну вот у тебя квадратный бассейн. О какой навигации речь?
Или русло реки. О какой навигации речь?
В воздухе ещё проще. Разве что исключая случаи с картой где подвешены сотни кубов против всякой логики. Но там вероятно и геймплей будет специфичным.

Цитата:

FiEctro писал:
И как вообще у тебя эта реалтайм проверка работает?

Ну а как в кваке монстр находит игрока?

Цитата:

XaeroX писал:
Самый неудобный мессенджер на свете

Вот плюсану. Более худшей мерзости я просто не видел.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 23-02-2024 в 16:48:

Цитата:

Дядя Миша писал:
Ну а как в кваке монстр находит игрока?

Рандомно как то. Яж говорю монстры в кваке максимально тупые, не могут добраться до игрока в прямой видимости.

Цитата:

Дядя Миша писал:
Ну вот у тебя квадратный бассейн. О какой навигации речь?
Или русло реки. О какой навигации речь?

Ты же знаешь что на практике это не так. Большинство областей имеет или П или Г или S образную форму.

Цитата:

Дядя Миша писал:
Вот плюсану. Более худшей мерзости я просто не видел.

Хоть объясните чего вы там не осилили?

Отправлено XaeroX 23-02-2024 в 17:05:

Цитата:

FiEctro писал:
Хоть объясните чего вы там не осилили?

Там в целом вообще всё неудобно. Это как вместо Хаммера открыть Радиант. Я осилил Радиант, рисовал в нём уровни для OI, даже выкладывал уроки по нему на форуме. Но он по-прежнему оставался неудобным, и при первой же возможности я перешёл на Джек.
Да, и ещё десктопный клиент не коннектится.

Добавлено 23-02-2024 в 12:05:

Цитата:

FiEctro писал:
Большинство областей имеет или П или Г или S образную форму.

Углы не всегда прямые, тогда уж надо говорить о Z или V-образной форме.

__________________

Отправлено Дядя Миша 23-02-2024 в 18:56:

Цитата:

FiEctro писал:
Рандомно как то.

Рандомно - это не в прямой видимости.

Цитата:

FiEctro писал:
монстры в кваке максимально тупые

Тем не менее ты же мне и сказал, что в римейке они стали вроде как поумнее, хотя я ничего с ними не делал. И потом сравнивал с оригиналом - особых отличий не заметил. Ну плюс-минус.

Цитата:

FiEctro писал:
Большинство областей имеет или П или Г или S образную форму.

Опять у тебя всё с ног на голову. Где ты такие бассейны видел со сложной формой, где ты видел гонки игрока с акулами под водой в сложных бассейнах?
С воздухом ещё проще - зачем там навигация вообще, если примерно любое направление достижимо по кратчайшей прямой?

Цитата:

FiEctro писал:
Хоть объясните чего вы там не осилили?

Если это надо объяснять, то не надо объяснять.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 23-02-2024 в 20:14:

Цитата:

Дядя Миша писал:
Тем не менее ты же мне и сказал, что в римейке они стали вроде как поумнее, хотя я ничего с ними не делал. И потом сравнивал с оригиналом - особых отличий не заметил. Ну плюс-минус.

Местами бодрее себя ведут, да.

Цитата:

Дядя Миша писал:
Опять у тебя всё с ног на голову. Где ты такие бассейны видел со сложной формой, где ты видел гонки игрока с акулами под водой в сложных бассейнах?
С воздухом ещё проще - зачем там навигация вообще, если примерно любое направление достижимо по кратчайшей прямой?

В халфе кишка с дамбой например, а так же карта после неё, а уж подводных помещений в халфе завались.

Цитата:

Дядя Миша писал:
Если это надо объяснять, то не надо объяснять.

Вы с Ксероксом как ходячий синдром утёнка прямо. Всего нового боитесь.

Отправлено XaeroX 24-02-2024 в 01:34:

Цитата:

FiEctro писал:
Вы с Ксероксом как ходячий синдром утёнка прямо. Всего нового боитесь.

Это ты сейчас на полном серьёзе про меня написал?

__________________

Отправлено Дядя Миша 24-02-2024 в 08:07:

Цитата:

FiEctro писал:
В халфе кишка с дамбой например

Через сливные отверстия, напомню, даже игроку было проблематично протиснуться.

Добавлено 24-02-2024 в 11:07:

Цитата:

FiEctro писал:
Вы с Ксероксом как ходячий синдром утёнка прямо. Всего нового боитесь.

Гениальный маркетинговый ход. Кормить людей дерьмом, а тем кто отказывается говорить - да вы просто боитесь всего нового.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 24-02-2024 в 09:33:

Цитата:

Дядя Миша писал:
Гениальный маркетинговый ход. Кормить людей дерьмом, а тем кто отказывается говорить - да вы просто боитесь всего нового.

Работает на ура.

Отправлено FiEctro 24-02-2024 в 11:18:

Цитата:

Дядя Миша писал:
Кормить людей дерьмом

Так не надо кушать дерьмо, надо пользоваться софтом

По мне дискорд куда удобнее той же телеги.

Цитата:

XaeroX писал:
Это ты сейчас на полном серьёзе про меня написал?

Ну так вы пишите что это плохой софт, но не можете вразумительно ответить почему. Это как называть?

Отправлено XaeroX 24-02-2024 в 14:04:

Цитата:

FiEctro писал:
Ну так вы пишите что это плохой софт, но не можете вразумительно ответить почему.

Вообще-то я исчерпывающе ответил на твой вопрос. Давай повторю:
1. Софт неудобный лично для меня.
2. В софте в течение продолжительного времени не фиксились критичные баги, например, неработающий десктопный клиент. Может, он уже и заработал, но увы, я забыл свой пароль.
При этом я нигде не написал, что софт плохой. Он хороший, просто если уж так необходимо банить какой-то мессенджер, то именно его.

Добавлено 24-02-2024 в 09:04:

Цитата:

FiEctro писал:
Это как называть?

А как назвать то, что ты агрессивно защищаешь неудобный софт?
Ну, видимо, у тебя не так уж много альтернативных способов приобщиться к чему-то новому, в отличие от нас с Дядей Мишей.

__________________

Отправлено Дядя Миша 24-02-2024 в 14:16:

Цитата:

FiEctro писал:
Ну так вы пишите плохой софт

Ещё лучше!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Cybermax 24-02-2024 в 15:20:

Цитата:

FiEctro писал:
Так не надо кушать дерьмо, надо пользоваться софтом

Самый неудобный мессенджер из всех известных, с контр-интуитивным интерфейсом, жрущий как не в себя ресурсы Дискорд удобнее Телеграм?

__________________
ㅤ

Отправлено Crystallize 24-02-2024 в 16:21:

Cybermax Если нужно одновременно стримить 2-3 потока плюс пара аудиоканалов и десяток чатов то нужен Дискорд.

Отправлено FiEctro 24-02-2024 в 16:36:

Цитата:

Cybermax писал:
Самый неудобный мессенджер из всех известных, с контр-интуитивным интерфейсом, жрущий как не в себя ресурсы Дискорд удобнее Телеграм?

Да. Функционал в телеге никакущий. Единственное приемущество телеги перед дискордом это больший размер файлов для загрузки.

Отправлено Cybermax 24-02-2024 в 19:03:

Цитата:

FiEctro писал:
Да. Функционал в телеге никакущий.

Для начала советую тебе узнать смысл слов которые используешь.
https://vc.ru/flood/283778-funkcion...nyaem-kak-pisat

Цитата:

Crystallize писал:
Cybermax Если нужно одновременно стримить 2-3 потока плюс пара аудиоканалов и десяток чатов то нужен Дискорд.

Будь так добор, переформулируй, что ты сказал, в каком контексте, чтобы понял я, да и все остальные. Пока что это звучит как Buzzword.

Добавлено 24-02-2024 в 22:03:

Цитата:

Что конкретно умеет Дискорд, но не умеет Гугл Митс, Зум?

__________________
ㅤ

Отправлено FiEctro 24-02-2024 в 19:59:

Цитата:

Cybermax писал:
Что конкретно умеет Дискорд, но не умеет Гугл Митс, Зум?

Там буквально можно поднять форум как здесь.

Цитата:

Cybermax писал:
Для начала советую тебе узнать смысл слов которые используешь.

Ну тоесть по делу тебе ответить нечего, и начинаешь цепляться к словам?

Отправлено Дядя Миша 24-02-2024 в 20:39:

Цитата:

FiEctro писал:
Там буквально можно поднять форум как здесь.

Это-то и плохо. Ни мессенджер, ни форум, а нечто среднее.
В результате нормально не работает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Crystallize 24-02-2024 в 22:01:

Цитата:

Cybermax писал:
Что конкретно умеет Дискорд, но не умеет Гугл Митс, Зум?

Типа я должен знать детальные возможности всего этого софта? Митс я вообще не в курсе, Зум это тупо скайп емнип. А Дискорд это несколько скайпов одновременно плюс мини форум.

Отправлено XaeroX 24-02-2024 в 23:28:

Цитата:

Crystallize писал:
Если нужно одновременно стримить 2-3 потока плюс пара аудиоканалов

Вот вроде все слова понятны, а смысл фразы ускользает.

Цитата:

Crystallize писал:
десяток чатов

А типа в телеге в десяток чатов нельзя писать?

__________________

Отправлено FiEctro 25-02-2024 в 09:41:

Цитата:

Дядя Миша писал:
В результате нормально не работает.

Если ты не пробовал, откуда знаешь как оно работает?

Цитата:

XaeroX писал:
2. В софте в течение продолжительного времени не фиксились критичные баги, например, неработающий десктопный клиент. Может, он уже и заработал, но увы, я забыл свой пароль.

У меня работает. Но винда иногда шалит из-за своей безопасности и может его блочить это да. Ну а то что ты забыл пароль и записал это в недостатки Дискорда это вообще финиш. Функция восстановления пароля для кого?

Цитата:

XaeroX писал:
1. Софт неудобный лично для меня.

В Дискорде всё каталогизировано в отдельные сущности, чаты, каналы, разделы и форумы. А Телега больше на Скайп похожа где всё вперемешку. Нормальных каналов нету, только в духе новостной ленты - аля жри что дают.

Отправлено Дядя Миша 25-02-2024 в 09:51:

Цитата:

FiEctro писал:
Если ты не пробовал, откуда знаешь как оно работает?

Я дискордом не пользовался? Мне в него заходить неприятно.

Цитата:

FiEctro писал:
В Дискорде всё каталогизировано в отдельные сущности, чаты, каналы, разделы и форумы

Ты потом поймешь что эти каталоги хороши для хранения архивов в которые ты лазаешь раз в 10 лет. А не для регулярного взаимодействия.

Так, всё свернули оффтоп про дискорд.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 10-03-2024 в 09:50:

Ну чтож, товарищи, по многочисленным просьбам трудящихся в Ксаш была добавлена полноценная поддержка PNG. Я взял реализацию от Шона Баррета, он там вроде что-то делал для ускорения распаковки сжатых частей изображения. Вообще удивительно конечно. В джипеге - точно такой же хаффман, но скорость загрузки отличается в десятки раз, например.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 11-03-2024 в 08:56:

Новый формат игровых архивов\ассетов .bundle успешно внедрён во все подсистемы движка и написан плагин для Total Commander для менеджмента таких паков. Это тоже временная мера, пока нет своего редактора.
Так же этот плагин позволяет заглядывать внутрь каждого уровня, модели, спрайта и даже игрового кода на шоте, поскольку все ресурсы в ксаше - это точно такие же архивы, но с некоторыми незначительными отличиями.
Другими словами любой игровой формат может хранить в себе не только чисто специфичные вещи, такие как внутренние структуры формата, но и абсолютно любые ресурсы - например текстуры, звуки. Отсюда же растёт и потенциально бесконечная расширяемость форматов - нет никаких ограничений на кол-во лумпов в них.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Ku2zoff 11-03-2024 в 12:38:

Цитата:

Дядя Миша писал:
написан плагин для Total Commander для менеджмента таких паков. Это тоже временная мера, пока нет своего редактора.

У нас на работе Total Commander используется в качестве временной меры для запуска батников VNC-подключений с админскими правами уже лет 10. Админы управляющей компании используют адресную книгу VNC, а мы - батники. А что, удобно. И файлики копировать и что-то редактировать, не вводя каждый раз данные админской учётки. И подключаться по VNC к удалённым машинам. И не надо запускать несколько приложений от имени админа. Хороший комбайн этот Total Commander. Вот бы для него сделать плагины для всех парсеров халфоресурсов. Было бы актуально 15 лет назад.

Отправлено Дядя Миша 11-03-2024 в 12:59:

Цитата:

Ku2zoff писал:
Вот бы для него сделать плагины для всех парсеров халфоресурсов. Было бы актуально 15 лет назад.

Поддержка паков есть с 2000-го года, к слову. Просто почему-то никогда не пользовалась популярностью у народа.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено FiEctro 11-03-2024 в 13:09:

Дядя Миша
Отличные новости, когда планируешь ближайшую обнову в бетатест ? И что там с .csm форматом? Ты вроде говорил что переделываешь его.

Цитата:

Дядя Миша писал:
была добавлена полноценная поддержка PNG.

Ты имеешь ввиду конвертер в ддс?

Отправлено Дядя Миша 11-03-2024 в 13:34:

Цитата:

FiEctro писал:
Ты имеешь ввиду конвертер в ддс?

Нет, я имею в виду всю экосистему.

Цитата:

FiEctro писал:
Отличные новости, когда планируешь ближайшую обнову в бетатест

Когда перенесу Камрадов с Quake II.

Цитата:

FiEctro писал:
И что там с .csm форматом? Ты вроде говорил что переделываешь его.

Нет, не трогал. А он нуждается в переделке?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 11-03-2024 в 14:07:

Цитата:

Дядя Миша писал:
А он нуждается в переделке?

Разве что нормаль от вершины отвязать, а так нет.

Отправлено FiEctro 11-03-2024 в 16:25:

Цитата:

Дядя Миша писал:
Нет, не трогал. А он нуждается в переделке?

Ну я говорил сохранять настройки для материалов из редактора моделей, дифуз, нормал, эмишен, роуднес, металик, альфа (как текстуру и как просто RGB или Gray цвет) и т.д. Чтобы уже на основе этих данных движок мог сам собрать необходимые уже ксашевские материалы автоматически. А не делать эту двойную работу в блокноте или другом кастомном редакторе.

Ты знаешь как в сорсе или ку3 бывает, качаешь карту, а материалы автор нужные забыл положить, всё розовое, а так вызвал rebuildallmaterials и всё пофиксилось, при условии что сами текстуры на месте. К тому же это поможет тебе в будущем редактировать систему материалов без потери совместимости.

Отправлено Дядя Миша 11-03-2024 в 17:40:

Материалы абстрактные, они не ограничены предлагаемым тобою набором параметров.

Добавлено 11-03-2024 в 20:38:

Цитата:

nemyax писал:
Разве что нормаль от вершины отвязать, а так нет.

Это ищо зачем?

Добавлено 11-03-2024 в 20:40:

Цитата:

FiEctro писал:
Чтобы уже на основе этих данных движок мог сам собрать необходимые уже ксашевские материалы автоматически

Не усложняй. Зачем писать какие-то там бинарные структуры, если плагин экспорта может автомагически сгенерить произвольные текстовые материалы с любым синтаксисом, который ты только захочешь видеть в своём материале. А ксаш просто к нему адаптируется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 11-03-2024 в 17:41:

Цитата:

Дядя Миша писал:
Это ищо зачем?

Чёб при обмене через .csm данными между программами (помечтаем-ка) не появлялись разрезы там, где их не предполагалось.

Отправлено Дядя Миша 11-03-2024 в 17:49:

Но ведь обмен и так уже есть - между блендором и джеком и компиляторами, например. Разве есть разрезы?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено nemyax 11-03-2024 в 17:52:

Конечно есть, куда они денутся. Под разрезами имеются в виду не щели, а дублированные вершины и рёбра на тех границах, где не коллинеарно.

Отправлено Дядя Миша 11-03-2024 в 18:00:

CSM не потдерживает рёбра. К тому же компилятор коллапсит вершины, их кол-во постоянно меняется. Этот механизм я трогать не намерен.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Временная зона GMT. Текущее время 19:39.

Страницы (2): [1] 2 »
Показать все 3608 сообщений этой темы на одной странице

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024