Камон, ребята, создайте уже специальную тему для обсуждения LGBTQ+ и перемещайтесь туда, а то всплываете где придётся, то в коронавирусной теме, то в сталкеро-пбр'ной.

Pavel_Blend, едва ли я что-то понял. Когда речь заходит об индексах, мне нужно рисовать, без картинок я не понимаю.

А от чего зависит выбор типа данных компилятором? Для статических объектов автоматически выбирается progressive? А ещё беспокоит вопрос всё таки как выбираются вершины для уровней детализации.

Что-то типа такого алгоритма используется.
https://dev.gameres.com/program/visual/3d/P...onReduction.pdf

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


индексы - это просто номера. Один треугольник опирается на три вершины. Треугольник не хранит координат вершин, он хранит номер вершины. Номера этих вершин хранятся в индексном буфере. Координаты вершин хранятся в вертексном буфере.


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

Павел Бленд, я ж спросил из интереса, на какой видяхе тестишь?

Да, вот в дискорде OpenXRay мне дали такой ответ:


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

Никакой автоматики. Если в АЕ в свойствах объекта стоит галка "Make progressive", создается progressive.
В АЕ же можно посмотреть на эти лоды.
Но в оригинале пользы от нее немного, алгоритм слишком мягкий, убирает буквально единицы треугольников.

Локация вот с такими данными:

на р1 выдаёт стабильные 60фпс, а на р3 всего 15фпс (из-за 13 миллионов треугольников деревьев). Причём фпс не сильно-то меняется от перемещения из заспамленного деревьями угла в незаспамленный. Вывод - оптимизировать надо не р1

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

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

Хм. Слушай, я планировал провести разные эксперименты по выводу локаций на X-Ray на актуальный уровень детализации: круглые трубы, фаски на углах по возможности везде, где их нельзя сделать трим шитами. Я помню из опыта, есть ограничение на импорт в SDK моделей, ограничение на минимальное расстояние между вершинами, меньше 5мм - вертексы слипаются. А ещё я знаю, что есть рецепты его обходить.

Может с настолько детализированной геометрией эффект от Progressive LOD будет заметнее? А ещё может нужно уметь готовить геометрию под алгоритм?

За работу! (Полковник со слоника)

Так уже полечили антифризом.

Pavel_Blend, а другие движки пробовал?
X-Ray Oxygen, OGSR Engine возможно какие-то фиксы для x-ray


В теории локации большого обьема нужно делать на докрученном x-ray
gsc постепенно увеличивали размер локаций сначала болота ЧН, потом локации ЗП


Не знаю поможет эта инфа как либо
В build 2571 в бункере под антенной наблюдался положительный эффект на FPS от тумана
возможно как способ оптимизации следует использовать параметры погоды настраивая туман для тяжелой локации, сочетая с дальностью прорисовки(в опциях)




Любимый приём у 4a games прослеживающийся и в билдах сталкера и играх метро

Ну я бы не использовал фпс в качестве метрики

Сами хомы довольно быстро софтварно растерайзятся и тестятся (на моей конфигурации было что-то около 1 мс). В принципе можно попробовать заоптимизировать растеризацию и тестирование bbox'ов с помощью SSE и параллельности, но мне не кажется, что это даст какой-то СУЩЕСТВЕННЫЙ выхлоп.


ну нет, имхо, это какой-то бред

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

Спроси у моделлеров про твой 3д-пакет. Сейчас должно быть возможно настроить тулчейн, чтобы в игре получать ровно те же самые треугольники, что делаешь в 3д-редакторе.


В АЕ можно просматривать progressive-лоды. Поэкспериментируй.

Интегрированная графика AMD A8 5600k APU with Radeon HD 7560D

внешней карты нет.

Спасибо Павел. Я понял. Радеон короче.

Туман должен быть равен дальности видемости в погоде. Ни больше, ни меньше. У пыс достаточно странный ползунок в опциях. Там максималньый множитель дальности видемести 1.5, когда на туман оно не распросроняется. Рекомендую опускать его до еденицы через консоль. Параметр чето там vis_distance кажется, по подсказке найдете. Ну а от дальности прорисовки зависит и качество.Я тестил это на шарах. Простых относительно низкополигональных шарах. Алгоритм прогрессивных мешей не идеален у пыс. Сферы обрабатываются странно. Суть в чем. Детализация падает не ровномерно. Сфера не превращается в шестигранник, а превращается в пирамиду + полусфера. Ну это от модели зависит. Вот например на тестовой сцене у меня что происходит.

речь об экономии fps для слабого железа
с нормальным железом и x-ray модификацией движка проблем возникать не должно

такие алгоритмы из серии для arbitrary geometry, может просто клампать коэффициент лоддирования? ) например, не меньше, 0.3 или задавать минимальный порог для клампа коэффициента в User Data объекта


всё равно у тебя компилятор перед запеканием света разобьёт геометрию на мелкие куски по типу материала и тд

Пытался понять что делают параметры в графе Material в настройке текстуры в SDK. Провёл такие тесты:

OpenXray, шейдеры ЗП 1.6.0.2, R2 (конфиг: улучшенное полное динамическое освещение), r2_loss_factor = 8.0

Base: OrenNayar <-> Blinn
Weight: 1 - 0.1

Base: Blinn <-> Phong
Weight: 1 - 0.1

Base: Phong <-> Metal
Weight: 0.01 - 1

Base: Metal<-> OrenNayar
Weight: 0.01 - 1


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

Объекты я делал по технологии Face Weighted Vertex Normals, а по сути это тест работает ли переброс кастом нормалек из майки в X-Ray. Не работает

Теперь нужно выяснить на какие вертекс номралки больше похожи эти: на Maya нормалки, или на 3DsMAX нормалки.

А ещё оказалось, что параметр Weight означает выбор между двумя моделями создания спекулярных отражений: тем, что слева (0) в пункте Base, и тем, что справа (1). Эффект выбора gloss (шершавости поверхности) это почти что не даёт.


Любопытно, что как-то раз давно я тоже пробовал засунуть текстуры из Substance Painter с кастомной моделькой в X-Ray, тогда это был пропатченный ТЧ:


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

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

Для этого нужно изменения в плагин внести + сдк, по-другому никак.

https://github.com/StalkMen/xray_re-tools вот тут вроде бы плагин под майку с экспортом нормалек уже есть, осталось только правки в сдк сделать

Ыгы, ну я так понимаю, правки в СДК нужно делать в области компиляторов, исходники которых существуют?

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


Что в целом ты для себя ты под этим понимаешь? Эта штука позволяет лишь более качественно рассчитать нормали у вершин используя площади граней в качестве весов ибо потом всё равно нормализуется, не более.

Ага. Для Maya использовал скрипты ADN Modeler Tools, там есть скрипт Vertex Normal, который лочит верекс нормаль прям как нужно. Эта техника требует поддержку Custom Normals, да. Применяется она для создания фасок на объектах с тайловыми текстурами, чтобы не запекать фаски в нормал мапы. Я как раз хотел применить технику для стен зданий. Как видно, просто взять и применить технику нельзя. Нужно либо компиляторы учить кастом нормалям, либо просто фаски делать не 1-м полигоном, а 3-мя (вокруг фаски по двум бокам ещё два саппорт эджа.

Я закинул свой металлический шарик в ТЧ на mp_atp_test. Рендер R2.
Первый скрин показывает красивый френель на модели отражения blinn (правый шарик) и отсутствие френеля на модели отражения phong (левый шарик).
На втором шарике видно, что отражения неба не видно - sky occlusion работает как надо.
На третьем скрине видно белый блик от жёлтого источника света - отсутствие цветных бликов.

Если сравнить с предыдущим постом, можно сделать вывод, что в ТЧ смоллскаи отражаются хоть как-то, а в ЗП вообще нет. Этим R2 ТЧ изначально ближе к IBL как минимум, чем ЗП, если не к PBR.

мои поздравления

Хых, не знал что в сталкире есть френель.

если сохранять в object, то не работает, так как object не поддерживает сохранение нормалей. Но ogf поддерживает. В блендере при экспорте в ogf нормали сохранятся. Но есть минус: нет сохранения swi в аддоне блендера. Это не критично для hud-моделей оружия, так как им не нужны swi данные, модели всегда перед лицом.

Тут писали, что дело не в экспорте object из DCC, а в компиляторе геометрии, который vertex normal делает сам. Поэтому ogf и динамика работает, потому что берёт что дают. А на статике компилятор всё портит.

А какова цель добавления пользовательских нормалей из 3д редактора? Если только ради face-weighted vertex normals, то может проще добавить эту технологию в компилятор чтобы он автоматически рассчитывал как надо?

Вообще смысл есть. То надо править плагин+компилятор, а то только плагин.

Modera, потому что группы сглаживания поддерживает далеко не весь софт + это довольно старая бесполезная хрень, тем более 3д редакторы всё равно работают именно с нормалями. Тем более увы 3д редактор не умеет сам раскидывать группы на основе уже существующего сглаживания при помощи нормалей. Я много у кого спрашивал, можно ли такое сделать, автодески даж обещали в макс добавить но воз и ныне там.

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

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

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

Учите компилятор понимать, то что вы туда пихаете.

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

mortan, я не пользуюсь максом и всякими левыми скриптами, а в майе с официальными плагинами у меня всё работает.

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

Custom normals нужны вообще в принципе. В кадлрм DCC вертекс нормали считаются по-разному, поэтому результат запечки нормал мап разный. Поэтому если ты переделываешь вертекс нормали сам, у тебя должен быть редактор, который делает такие же нормали при запечке, а то у тебя объект пойдёт шейдить, особенно если у тебя на нормалмапе компенсации.

Работал в одном проекте на CryEngine, у нас был перепиленный CE, и перепиленный экспортёр, стандартный не подходил. И у нас сломали custom normals, CE умеет считать vertex normals сам, алгоритм у него как у 3DsMAX. А я майщик. Моделил в майке, потом обязательно переэкспорчивал в 3DsMAX, а потом уже экспортил объекты на запечку, чтобы вертекс нормальки в SP и Marmoset совпадали. И скажу я, это геморрой. Мы очень радовались, когда custom normals наконец починили :-)


Вот ещё человек считает, что компилятор нужно научить работать с custom normals :-) И не заставлять его считать vertex normals на основе smooth groups самому.

Я же правильно понимаю, исходники компилятора есть и есть люди, которые умеют его править?

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

Я это дело выпилил. Оставил эдиторское автосглаживание. А в место групп остваил 0 - мне это зашибись в P.O.L.Y.G.O.N. помогает.

Вру, наоброт: вместо групп - автосглаживание, а вместо автослаживания - 0.

А это то есть если использовать Vertex Normal Edit tool для редактирования нормалей вместо простых Soften Edge/Harden Edge/Set Normal Angle. Да, так не работает. Правда не знаю зачем та штука нужна, ни разу не пользовался.

soft/hard edges - это способ установить Split Normals. Сами направления нормалей автоматически расчитываются. А при сохранении нормалей во время экспорта в object и компиляции xrlc даст возможность в 3д редакторе произвольно указать направления нормалей. Сейчас xrlc автоматически их вычисляет. Вот пример:



Слева - автоматически расчитано, справа - split-нормали совпадают с нормалями полигонов сторон куба. В итоге плавный переход от затенения есть только на фасках:

Diesel, прошу тебя, не позорься. Уже просто невыносимо читать.

Отвернись от монитора, зажмурся, очки розовые применяй. Много способов снять стресс от чтения.

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

Результат со стандартным алгоритмом -
Результат с зависимостью от площади -

Это и называется Weighted Vertex Normals.

atanda, так а в чём прикол тогда, почему для реализации этой фичи необходимо выбирать какой-то там плоский полигон?

Modera, можно чуточку конкретней? О каком плоском полигоне идёт речь?