Через компилятор собрал ДаркЛаб (Максимальное качество)
Результатом остался доволен, всё работает как надо!


Сегодня буду Кордон на средних собирать, посмотрю, что выйдет

В общем, кордон он мне так и не захотел компилить

Упал на стадии
[10.08.20 21:43:43.362] | | ::compact:: 227 verts removed
[10.08.20 21:43:43.362] | | * ERROR: Internal precision error in CDeflector::OA_Export

Заметил то, что кордон он выше драфта компилить попросту не может
Инвалиды все срыл
Память: 16 гигов
Фулл лог: https://drive.google.com/file/d/1q3fEr8-KJB...iew?usp=sharing

Никсон, ты какие компиляторы используешь?

Asterix, последний от hi_flyer

Никсон, у меня кордон и медприбор собрал на максах с 20 п/метр. Этот Х64 компиль

RSFSR, везёт!

Попробую собирать по немногу (террейн и деревья, террейн и объекты, объекты и тд)
будут результаты - отпишу

Тут, кстати, не в компиляторе дело. Данную проблему я поймал на вообще, блин, всех компилях

еще заметил, что в конце сборки проекта в сдк он мне выдаёт сообщение о том, что детейлы не были экспортированы. сообщение в духе "cant find texture esc_dez_det". Вдобавок и не оповещает, что билд успешно собрался

прикол, без террейна компилит
--------------------------------------------------
0_0

Никсон, не. У тебя прикол какой то с развёрткой.

У меня бывает и без дефолтного сектора компилит, что там террайн.

Кстати, террайн не обязательно создавать на уровне.

Diesel, с чем может быть связано? сектора и порталы перепиливал в тот момент
инвалиды все убрал

Никсон, а на что влияют инвалиды?

Я не знаю, таких подробностей, что тебя интересуют.

Без контекста пост выглядит как-то так.
)

Лохотрон, ахах, точно! =)

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

Никсон, чтож нас всех тянет кордон и агропром?
Хоть бы кто билдовский бар или чаэс сделал

Предположу из-за того, что маленькие треугольники сложнее рисовать. Все ваши "инвалиды" ни что иное как слишком маленькие треугольники (т.е. треугольники с почти нулевой площадью).

Возможно для современных видюшек это уже не является проблемой и/или скорее всего современные движки, подготавливая геометрию, просто "убивают" такие треугольники и смерживают геометрию вокруг, но тут я не специалист =)

atanda, нет. Это уже не треугольники в обычном виде. Это бывший треугольник с вершиной в основании. Читать такие инвалиды движки умеют. Возможно в ститическом свете были фантомные тени от этих инвалидов. На динамике таких косяков, а точно в R3 нет.

Сейчас забилдил 1510 двиган, чуть не умер я от оптимизации и рендера - эта такая шняга девственный ЧН, по сравнению с ЗП рендером и DX 2010.
Разрабы пытались найти причину плохой оптимизации, потому грешили на всякую фигню.

Еще было бы странно, что родной компилятор сам создаёт инвалиды, а движок родной их бы не читал.
Хотя там ПЫСы в компилятор, ассерт заделали на всякий случай.
Зачем там ассерт - от инвалидов привнесённых из 3d редактора, а компилятор которые создаёт, ассерт уже не поможет.
100% новых инвалидов - это дело рук xrLC на стадии оптимизации, при усечении геометрии.

RSFSR, билдовский бар у меня давно на харде есть

А вот для ЧАЭС пока время не пришло...

Что просто за херню ты тут написал? Это треугольники, но с близкой к нулю площадью. Инвалидными или, если угодно, degenerated они считаются в большинстве случаев если их площадь меньше определённой компилятором погрешности. Конечно, есть случаи когда у полигона потянута текстура, т.е. фактически тоже площадь, но уже развёртки этого треугольника -> 0;


Вполне возможна такая ситуация на стадии подразделения геометрии.

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

atanda, треугольник с вершиной в основании = 0 площадь.

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

Мля, я в 2010 году Макс освоил, и нихрена не шарю. Чистил код компилятора для безлайтмапной компиляции, собирал и правил куеву тучу x-ray движков, 10 лет ежедневно по 10 раз запускаю Сталкеров и нифига не шарю. Собрал и скомпилировал шук пять уровней из Сталкера - и не фига не шарю.

Опять таки же, это частный случай.


Да уже все убедились насколько суров твой "опытный путь".


именно

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

Какие еще инвалиды вы видели в Эдиторе? Ни один инвалид с битой развёрткой в ассерт компилятора не попадает (по крайне мере я таких не встречал).

Понаслушались Д.Сташа и А.Непряхина, и несёте. Хотя я уважаю этих товарищей.

Никаких, перечитай - про редактор речи ни шло.


Приветики. Я тут ему два поста разъясняю, что эти самые инвалиды могут создаться на этапе подразделения геометрии, а он мне снова. Крч, всё с стобой понятно.


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

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

Да хрен сними. Пусть будет три вертекса - убедил.

Такое еще и в Максе можно словить, когда открываешь модели деревьев из СпидТри формата.
там листья вертесками (точнее инвалидными фейсами) отображаются.

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

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

https://yadi.sk/d/gEAhJyNrd4KW7Q

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

Если на листьях uv-развёртка имеет нулевую площадь или её вовсе нет, то это логично

Для ЗП нового ничего нет?
Пользуюсь компиляторами K.D., иногда возникают артефакты (темнота там где ее быть не должно), ну и хотелось бы более быстрой компиляции.

chriotmao, гипер-звуковой компилятор, безлайтмапная версия.
Это не шутка, хотя многие будут меня материть за такой совет.
Шуршее компилятора нет на свете. Ну, и конечно он 32 бита (не всегда гуд).

Мне нужно для True Stalker, мы практически на релизе, так что времени внедрять правки в рендер нет..
Я заметил что стадия LIGHT: Waiting for MU-thread идет очень долго, в этот момент проц используется на 5-40%

chriotmao, есть лишь фикс на лайтмапы (правда он на ЧН, но он подойтёт наверное)

http://files.xray-engine.org/raytwitty/sdk.../xrLC_fixes.rar

кстати, думаю можно попробовать компиляторы отсюда - https://github.com/TheBearProject/XRayEngine/releases

Скомпилил через x64 компиль с ключом -att... Охх.

Почему может вылетать на стадии build uv mapping? Лока - Агропром из исходников 1935, Склады оттуда же. Компиль - x64

Сделайте запечённый рей трейсинг

Ну по факту он и так есть. Технически именно он и используется для расчета карт освещения. Просто расчет этих самых карт освещения достаточно медленный.

Билдоман,
Диалог с самим собой. Правка сжатия лайтмапов, возможно, порождает вылет, но не на Build UV mapping, а на стадии Subdividing geometry, ибо он выпал у меня в другом компиляторе, без сжатия лайтмапов (или в том же, но на меньшем качестве, при том же PPM=30) Для гарантии попробую затестить старые x64 компили от K.D.

Правка сжатия лайтмапов не может порождать вылет на Build UV mapping и Subdividing geometry. Эта правка просто сохраняет лайтмапы в формате без сжатия. Если какой-то вылет она и может породить, то только при сохранении лайтмапов.


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

abramcumner,

Но любопытно, что компилятор с билда 2365 локу проглатывает)

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

Компилятор x64 от Hi-flyer'a молча вылетел на стадии Build UV mapping. Толкового объяснения, как и почему в инете не нашел. Локация - кордон из фриплейных исходников, из изменений только добавленный nosun. В чём может быть проблема?

Отбой, проблема решена. Оказалось у nosun'а был неправильный шейдер.

Лог вылета где?
Мы что на кофейной гуще должны гадать?

Ошибки не было в логе, если ты не понял. Да и вообще проблема уже решена.

Супер-пупер Универсальные компиляторы уровней х64 (2022) от тов. SkyLoader.

Оригинальные компиляторы разработаны: GSC Game world
Правки компиляторов и сборка: SkyLoader
Благодарности: Abramcumner, K.D.

Состав компиляторов:
Компилятор геометрии [ТЧ, ЧН, ЗП]
Компилятор травы [ТЧ, ЧН, ЗП]
Компилятор АИ-сетки [ТЧ, ЧН, ЗП]
Сборщик спавна [ЗП]

https://ap-pro.ru/forums/topic/3341-univers...ry-urovney-h64/

macron, затестировал?
Сколько LA компилится без лайтмап?

Да, вылетает на стадии "Converting to OGFs". Пойду жалобу писать.

macron, пусть вот это отключит в void OGF::Stripify ().
{
// alternative stripification - faces
{
DWORD* remap = xr_alloc<DWORD> (fast_path_data.faces.size());
HRESULT rhr = D3DXOptimizeFaces (&fast_path_data.faces.front(),fast_path_data.faces.size(),fast_path_data.vert
ices.size(),FALSE,remap);
R_CHK (rhr);
vecOGF_F _source = fast_path_data.faces;
for (u32 it=0; it<_source.size(); it++) fast_path_data.faces[it] = _source[remap[it]];
xr_free (remap);
}

// alternative stripification - vertices
{
DWORD* remap = xr_alloc<DWORD> (fast_path_data.vertices.size());
HRESULT rhr = D3DXOptimizeVertices (&fast_path_data.faces.front(),fast_path_data.faces.size(),fast_path_data.vert
ices.size(),FALSE,remap);
R_CHK (rhr);
vec_XV _source = fast_path_data.vertices;
for(u32 it=0; it<_source.size(); it++) fast_path_data.vertices[remap[it]] = _source[it];
for(u32 it=0; it<fast_path_data.faces.size(); it++) for (u32 j=0; j<3; j++) fast_path_data.faces[it].v[j]= (u16)remap[fast_path_data.faces[it].v[j]];
xr_free (remap);
}
}

ЗЫ: дописал еще кучу опций, скомпилилось успешно за 00:16:35.

xrCompiler.exe -geometry -nohemi -removeinvalid -noise -f liberty_city -nosmg -notess -noweld -nomerge -nostrip -dx_opt

macron, -nostrip они уже внесли правку.

Классный инструмент получился. Интересно посмотреть на результаты производительности в сравнении с имеющимися компиляторами.
Заметил только что опцию отключения компиляции лайтмапа террейна не завезли. Да и в целом интересно, завезут ли просчёт лайтмапов на ГПУ.

На самом высоком качестве и hemi 4 около 3 часов. Глюки с вылетами и выбитыми треугольниками победил. Но остались местами глюки с освещением, и в целом, в сравнении с твоим компилем, картинка понравилась меньше. У тебя hemi как бы совсем нет, всё немного светится само по себе, а здесь затеняется, но по очень "грубым" стандартам из нулевых годов, даже при минимальном hemi=1, что больше вводит в диссонанс. Еще проверю новый компиль с -nohemi.