Новое направление в развитии устаревающего рендера x-ray (добить окончательно).
Например, компиляция локации Болота занимала более 48 часов, то сейчас немного более часа ( у мощных компов и того меньше часа будет).
Кто то сочтёт этот рендер отстойным, но извините, есть любители статического рендера, я промолчу.

Что нового:
Что нам даёт такой метод? Экономию времени. Задел на большие локации. Оптимизацию.

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

Короче, я не Л.Н.Толстой, чтобы писать, сразу к делу:

Вот ресурсно-модернизированая база ЧН с форсированным движком SCS-3 и перекомпилироваными локациями ЧН (из под конвертера Бардака напрямую).
Компилятор геометрии внутри. Описание там же. Кто желает получить лучшее качество, то ищите оригиналы локаций, а не из под конвертера.
В компиляторе имеется HD компиляция геометрии (подробности позднее), это для продвинутых дизайнеров.

Постскриптум: для внедрения таких локаций в движок, требуется вырезать ассерты.
Идея компилятора принадлежит сообществу, а правки кода мне (Дизель).

Так как эта тема первая в новом направлении, первые локации несём сюда.
Задаём вопросы, если появятся непонятки. Ну, и так далее.

Переходник на локации без лайтмап:
https://yadi.sk/d/n9dTzGIRaAZPfA

Актуальный giper_fixx6 от macron для проекта SCS-3 https://yadi.sk/d/FFcA4UotMKRNrQ

Код компилятора геометрии xrLC SCS3 С++2008 на базе кода 1602. Первый вариант для гипер-звукового рендера https://yadi.sk/d/cZtdAXGE9parhA
Остальные компиляторы в проекте, не соответствуют компилятору геометрии, находятся в разработке.

Рекомендую вот эти эдиторы от Молнии в вакууме:
https://mega.nz/#!TS5VyYhQ!qG-lUxcg...NAuvz0ksPR08N14


Исходный код проекта SCS-5 : https://drive.google.com/file/d/1fo9EdfZ_kw...iew?usp=sharing

Проект закрыт!





Компилятор xrLC x64 SCS-6 (на движке от abramcumner).
https://disk.yandex.ru/d/3jXK9D2ANPZghg

xrLC.exe SCS-6 Super HD. Версия финальная. (на движке от abramcumner).
https://disk.yandex.ru/d/7Lu4EQ-otPybcg

компилятор SCS-7 POLYGON xrLCx64 (доп. AIx32) https://disk.yandex.ru/d/w2varuYHYMuh3g
Доп.компилятор для SCS-7 (без оптимизации) https://disk.yandex.ru/d/sJA08VgF_tY-wQ

SCS-8 xrLC P.O.L.Y.G.O.N.(искать в комментариях).
https://disk.yandex.ru/d/Zd8rOgBibXK5TA patch

SCS-9 P.O.L.Y.G.O.N. xrLC (0, sdk smooth only).
https://disk.yandex.ru/d/cjHBxgSglGVnzg

xrLCx64 SCS 10,11,12 P.O.L.Y.G.O.N.
https://disk.yandex.ru/d/54NZpbaKQh2m_A

Сообщение отредактировал Diesel - 27.01.2022, 21:51

Выстави hemi 0.

macron, 0. У меня один и тот же билд, уже давно на тесте.
Там на этапе объединения геометрии, косяк у меня нарисовался.

Я уже от безумия скрестил компилятор x64 от abramcumner c BearIvan

Бессмыленный конечно вопрос, но зачем???
Уже сто лет в каждом компиляторе есть опции, отключающие создание лайтмапов. Они собирают геометрию за те же час сорок(интересно почему так долго, там делов на пару минут). Может разобраться в настройках компиляторов.

abramcumner, я потом опишу проблему подробнее. Лог компилятора затёрся. Там кажись с CDB проблема нарисовалась, если нет то построрение билда не правильное, так как компилятор пытается создать файл который уже есть.

Не, пару минут там ни как. У меня самая быстрая скорость Затона - 40 минут.

Вот лог компилятора:

* New phase started: Building rcast-CFORM-mu model...
| Models...
| Building search tree...
| Saving...
stack trace:

0x000000003F98C63C xrLC.exe, CBuild::BuildRapid + 1660 byte(s), X:\xray15-VS2019\components\xray16-master\xray\utils\xrLC\xrBuildRapidModel.cpp, 139
0x000000003F97D148 xrLC.exe, CBuild::Run + 952 byte(s), X:\xray15-VS2019\components\xray16-master\xray\utils\xrLC\Build.cpp, 241
0x000000003F98DE64 xrLC.exe, Startup + 1300 byte(s), X:\xray15-VS2019\components\xray16-master\xray\utils\xrLC\xrLC.cpp, 138
0x000000003F98D928 xrLC.exe, WinMain + 120 byte(s), X:\xray15-VS2019\components\xray16-master\xray\utils\xrLC\xrLC.cpp, 176
0x000000003F973C42 xrLC.exe, __scrt_common_main_seh + 262 byte(s), D:\a01\_work\9\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl, 288 + 33 byte(s)
0x0000000076C855DD kernel32.dll, BaseThreadInitThunk + 13 byte(s)
0x0000000076EE2B1D ntdll.dll, RtlUserThreadStart + 29 byte(s)

[error][ 183] : Невозможно создать файл, так как он уже существует.

Сообщение отредактировал Diesel - 07.03.2021, 21:18

А какие фазы сколько занимают по времени?

abramcumner,
* New phase started: Adaptive HT...
* New phase started: Converting to OGFs...
* New phase started: LIGHT: Waiting for MU-thread...
* New phase started: Converting MU-models to OGFs...

Честно я даже не помню, еще какие долго.

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

Да, что-то наворотил с xrCDB. Его так просто нельзя в x64 затаскивать. А может дело и не в х64, а еще в чем-то. Надо запускать под отладчиком и смотреть.


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

Сообщение отредактировал abramcumner - 07.03.2021, 21:36

abramcumner, я понял в чем дело. Это у тебя в ЗП недоделано, в ЧН посмотрел - там нормально _Work*

Да уж. А как люди ЗП компилируют x64?

И там и там доделано, просто по-разному. В оригинале в CDB у треугольника было объединение указателя и четырехбайтового числа. И в разных местах кода использовался то указатель, то число, в движке, еще было два двухбайтных числа. Все это можно обработать не меняя.
В ЧН я решил сделать отдельные типы: Work* вроде когда нужен указатель, Game - когда нужно число.

Все хорошо, но под х64 указатель неожиданно стал размером 8 байт.
Может помнишь было такое, что build.cform, полученный из 64-битного хрлц, могли загрузить только 64-битные храи. Это как раз из-за этого.
Но никто не мешает перед сохранением build.cform уменьшить до 4 байт для совместимости с 32-битным храи.


Все должно быть нормально и там и там. Но скрестить будет затруднительно

abramcumner, буду выпиливать это. Это нужно только для тесселяции и совместимости с другими компиляторами. И более ни о чём.

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

Сообщение отредактировал Diesel - 07.03.2021, 23:17

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

Короче, нужно оставить террайн, остальное на tree перевести.
Всю дефолтную статику на мультиплей юседж в сдк - реально - да и лод текстур всего 240 с чем то кажись?
По идее и время компиля вырастит в просчете MU.

Зато какая оптимизация будет. Бред полный однако.

А может просто включить текстурам лайт имплисит и создать недостающие шейдеры?

Сообщение отредактировал Diesel - 08.03.2021, 02:58

Будет лучше, если компиль сам всё переведет куда ему надо (например, любую статику воспринимать как multiple usage). Или на крайняк в level-декомпиляторе заменить в готовом level-файле. SDKшные объекты/параметры лучше не портить.

Сообщение отредактировал macron - 08.03.2021, 11:21

Можно поподробнее? Хотелось бы добавить поддержку компиляторов х32 xrAI в х64 xrLC.

Надо конкретно смотреть, что объявлено в xrCDB.h, и на код в xrBuildRapidModel.cpp.

abramcumner, в твоей ЧН версии, у меня без стандартного DXSDK2010, xrLC не желает дружить с твоими инклудами DX9.
Весь блок Status ("Processing textures..."); - в печале.
Может я что то не до понял? Вроде с 2010 сдк всё нормально - на 32 бита, по крайней мере.

Сообщение отредактировал Diesel - 10.03.2021, 04:16

Как избавиться от тёмных, без хеми которых, фейсов?



Вот такой ерунды на ЗП - гипер компиляторе, не наблюдается.

Сообщение отредактировал Diesel - 10.03.2021, 04:56

Инклуды в папке SDK/include/d3dx, но можно и 2010сдк добавить.

Ну это не фейсы, это целые меши. Проверял у них в АЕ материал/энжин/компайл-шейдеры? Нормали в правильную сторону смотрят?

На последнем скрине, например, троссы. Длинные нормально освещены, корткие - нет. Нет у них отличий в АЕ?

Сообщение отредактировал abramcumner - 10.03.2021, 13:04

Кстати да, на x64, что здесь выкладывался, местами глюки. В sdk и на старом безлайтмапном x32 клумба нормальная, на x64 (High settings) темнеет. Везде def_shaders/def_vertex.



Там используется текстура gta3\gta3_dirt64b. В Image Editorе ее нет, может есть смысл импортировать заново и перекомпилить... Может с этим связано, может нет.

Сообщение отредактировал macron - 10.03.2021, 14:14