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

Скомпилил Болота на максималках от saas- 10 часов на x64. Ранее Болота x32 - 1ч 40 минут.

Если экспериментируешь со старым x32 безлайтмапным вариантом, попробуй ставить hemi 0, чтобы не было пересветов. Остальное можно подстроить через r2_sun_lumscale_hemi и т.п.

macron, билд получился косячный.



Пока удалил ссылку на x64

Перекомпилил на полном Hi (c качеством hemi 3). Заняло 11,5 часов. Подстроил в игре r2_sun_lumscale_amb/hemi. Выглядит уже неплохо. Можно сделать две версии компилятора (или две опции в одном): быстрый с оптимизацией для hemi 0 (как в раннем x32), и вариант для обычного hemi 3.

macron, я что то притупил с самого начала. У Абрама есть 64 ЗП компиляторы, и у меня есть гипер компиляторы ЗП. А на ЗП в гиперкомпиляторах, был самый нормальный рендер.
Что ж, теперь скоро ЧН версию доделаю, возможно будет в порядке всё.

Вообще, я сейчас уже их тестирую на Прохоровке.

Что то косячно выходит. Есть фейсы без освещения хеми.

Пойду ЗП вариант смотреть.

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

Компиляторы геометрии точно не соответствуют, по своим функциям, оригинальным. Но всё равно, работа проделана abramcumner полезная - самое главное - есть база для x64.

че там кстати с гиперзвуком

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

Сутки тарахтит компилятор на Прохоровке - уже по-любому это не укладывается в норматив гиперзвука.

Выстави 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] : Невозможно создать файл, так как он уже существует.

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

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, я понял в чем дело. Это у тебя в ЗП недоделано, в ЧН посмотрел - там нормально _Work*

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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



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

А нормали нормальные? Если в АЕ освещение включить, ничего подозрительного не видно?


thm по идее нужны, а сами текстуры - только с прозрачностью. Обычно компилятор ругается, если чего-то нужного не хватает. Ругается ли, который выкладывали, не знаю.
Слева на скринах есть прямоугольные клумбы, в них не та же текстура использутся?

Это побочка от хеми или теней в 0. Тоже самое можно видеть на драфт-компиляции.
В ЗП это решили увеличив скейл в настройках левел-эдитора до 4, а saas вообще до 5 зафигачил. Что именно, тени или хеми - не знаю, но что то из этих.

Видно, что косяк на уровне фейсов , а не мешей.

Там всё нормально.

Другая.

Вот еще пример, когда углубленные части геометрии дома не освещаются (тоже все шейдеры def_shaders/def_vertex).


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

Компилятор SCS5 x32 на VS2012 перевел. Запустилось, а не хотело с начало. Потом ядро у абрамкумнера вытащил и завелось. Если нормальный билд пройдёт, то есть смысл этот проект на 64 перевести. Самое главное, чтобы об CDB ни где не торкнуло.

xr_LC x 32 SCS-5 VS2012 (ядро от abramcumner), безлайтмапная версия - гипер. Ничего не надо писать в батник лишнего ( просто там все как в оригинале), как обычно.
https://disk.yandex.ru/d/LX0AvjhIjc39Mw



Косяков нет. Буду пытаться на x64 перевести - сомневаюсь что то в себе.

Похоже, что на 2019й 32 xrLC SCS-5 собрал. Компиль запустился.

А вот x64 - это пока в планах, так и останется однако.

ЗЫ: x64 докомпилился, клумба лучше не стала.

macron, это болезнь стандартного копилятора ЧН.
Я почему и свалил в ЗП версию.

x32 xrLC vs2019
https://disk.yandex.ru/d/2LgCV2v3HVgbXQ



Косячных фейсов так же не наблюдается.

И всё же...


МГ под зп (20мин компила на высоких настройках):
рендер 2.5

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

Возможно. Действительно, код на 90% ЧН. Тогда нужно стартовать с SCS-3 на базе кода 1602. Там чистоган ЗП версия.

Yara, вот SCS-3 екзеху ЗП версию адаптировал - потестируй.
https://disk.yandex.ru/d/qtqNE5ICjdPwuw
Добавить в проект SCS-5 vs2019 с заменой.

Я уже начал компиль.

Пересобрал, местами чернуха (5-й скрин с r2_sun_lumscale_hemi 3)

Yara, я удивлён. У меня на R3, вообще нет, ни одного бага на Прохоровке. Хотя там точно не идеальная геометрия. Скорее всего дело в шейдерах.
-nosmg затестируй, может что справит.

Я только понять не могу, зачем настраивать то, чего там нет в природе.
Возможно чернуха прёт от статического запечённого света? В ЧН это дело выпилено. build.lights не читается на R3.

Компилятор xrLC x64 SCS-6 (на движке от abramcumner).


https://disk.yandex.ru/d/3jXK9D2ANPZghg


В игре картинка примерно такая на R3:

Ура, на этот раз без косяков теней! 11 минут с hemi 0.

Это успех...


Геймдата с уровнем, если кто захочет затестить гипер компиль:
https://drive.google.com/file/d/1oOeCtT8pYA...iew?usp=sharing

Я встречал и ранее этот баг - А на R3 у меня движок как раз и работает.
THM ТЧ несовместимы с уровнем. Ниже в ссылках описано решение.

https://www.amk-team.ru/forum/topic/12733-i...comment=1314994

https://modfaq.ru/ResourceManager_Resources.cpp

Yara, компилятор xrLC SCS-6 работает по коду SDK06-07.

macron, теперь можно локацию из ГТА-4 собирать.

ЧН - Болота SCS-6 компиль. R3.


А у меня есть где то ЧАЭС 5 в 1, которая вылетала в памяти 32.