Вот есть у меня коробушка:

Рифлёным стенкам назначил материал с флажком двусторонности.
А как это отразится на производительности? Будет быстрее или медленнее рендерить?

И вообще - как реализована двусторонность полигонов в хрее? Чисто на шейдерах или что-то в движке закомпостировали? Есть ли такая техника в других движках?

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

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

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

Берём полигон - просто треугольник, три вершины. Если я хочу придать ему объём в майе по-тупому, то выполняю операцию выдавливания, и у меня получается 1 треугольник спереди + 1 треугольник сзади + между ними 3 стенки по 2 треугольничка в каждом.
А что делает СДК? У него получается 1 треугольник + 1 треугольник, разнесённые на какое-то микрорасстояние, чтобы полигоны не просвечивали сквозь друг друга?

Нет, они находятся точно в одном месте, просто направленны в разные стороны, а т.к. в игре у нас всегда включен backface culling увидеть всегда можно только один треугольник.

Для того чтобы сделать в майе то что делает СДК галочкой 2-sided нужно все полигоны скопировать и применить к ним Normals -> Reverse. Если бэкфейс куллинг включен ничего рябить не должно.

CULL_NONE спасет.

Не советую вообще связываться с этим 2-sided, реально оно вчетверо увеличивает кол-во полигонов и индексов (хотя СДК говорит, что вдвое).

А если объект - nosun под террейном?
Ты же не про траву говоришь?

Покажите простой пример, как будет выглядеть эта модель в игре без флага DoubleSide и она же с ним

Про траву. Намедни нужно было ее модели в .ogf заготовить, так при экспорте из СДК вместо 10 получается 40 поликов. Я сначала не обратил внимание, да и в игре визуально ничего не изменилось. Обнаружил косяк позже по кол-ву отправляемых на отрисовку индексов: 120 вместо 30. И затем уже просек причину. А с другими моделями не проверял, не было нужды. Думается мне, там так же.


Ну и что. С CULL_NONE он в любом случае будет с обоих сторон обрабатываться. Причем если полигоны обращены в другую сторону, то их обработки пиксельным шейдером не будет, т.к. z-тест не пройдут. Наверняка в современных движках так и делается, что Modera выше говорил. Т.е. ставится в материале флаг, а движок уже выставляет нужный режим отсечения - для двухсторонних CULL_NONE + инверсия нормали по SV_IsFrontFace, и всех делов. Быстро и просто.

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


А зачем nosun двусторонность? Должно хватать одностороннего с фейсами наружу.

Визуально ничего разбито не было, как было, так и осталось. Уж не знаю, чего он там разбивал. Добавилась 1 вершина и 4х полигонов с индексами. Кроме того, если 2-sided в СДК отключить, на выходе получаются честные 10 поликов и 30 индексов.

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

2-sided on


2-sided off (в стате poly на 992 меньше)

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

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

Yara, фпс одинаковый, значит, смысла действительно нет.

Травы у Yara маловато и она от камеры далека. Лучше сделать травы побольше и близко к камере. Чтоб площадь экрана больше занимала. Что-то вроде такого:



А еще лучше проверять каким-нибудь Render Doc, сколько полигонов на отрисовку отправляется. Встроенный в двиг статистик может для травы неверную инфу отображать. Он полигонаж каким-то своим способом высчитывает, из кол-ва кустов или вроде того. Я не вдавался. Так что есть опасения, что он может врать.

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


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

Никто не в курсе, что за модели травы лежат в SDK (ЧН-ЗП) в папке detail\standart, для чего они? На локах в игре, судя по level editor используются меши травы из папки detail. Мне кажется, эти из папки standart какие-то глюкавые, напутано с индексами-вершинами. Или они все же где-то используются?

Похоже в папке standart - это меши травы из ТЧ.