Вообщем товарищи, имею сказать следующее. Нормалям, полученным из текстовой модельки доверять вообще нельзя. Там полное дерьмо порой бывает, а кто-то вообще не заморачивается и пишет туда мусор.
Дядя Миша текстовость не при чем. В 3дмаксе всратая система нормалей - есть группы сглаживания, а есть явные нормали. Сложно понять, какие из них используются в данный момент, и какие будут экспортированы. В одном из плагинов экспорта в smd можно выбрать экспорт явных нормалей, но тогда нужно перед экспортом кидать на меш модификатор Edit Normals, чтобы эти явные нормали у модели были и соответствовали тому, что видно во вьюпорте. В любом случае, всегда надо проверять, что вышло.
А плагин экспорта в obj в 3дмаксе сломан, начиная с 2017 версии, - вершины экспортируются в мировом пространстве, а нормали в локальном.
Текстовость как раз даже очень причём. Бинарные форматы как правило записываются пограммистами, которые хоть что-то там проверяют. А текстовые парсят все кому не лень. Даже если накосячат - пофиг, парсер проглотит.
Добавлено 22-11-2020 в 18:24:
Короче нафиг эти нормали из исходников. Лучше я их сам посчитаю.
Дядя Миша писал: Короче нафиг эти нормали из исходников. Лучше я их сам посчитаю.
Ты же в курсе, что при использовании нормалмап нормали должны быть те же самые, что были при запекании с хайполи? Или, может быть, в курсе того, что нормали не завязаны на геометрию и могут быть произвольно отредактированы? Например, для волос или веток деревьев нормали часто проецируют со сферы.
Дядя Миша писал: Нормалям, полученным из текстовой модельки доверять вообще нельзя.
Ну вот как раз нормали в моем рендере smd всегда получались валидными, даже в анимации, после умножения на матрицу преобразования. В отличие от костей, которые до сих пор плющит и я фиг знает, что с этим делать, уже нервы извёл все
ncuxonaT писал: Почему ты думаешь, что виноват формат
Виноват не формат, а то, как с ним обращаются.
Добавлено 23-11-2020 в 09:39:
Да, насчёт деревьев. Я листве просто использовал half-lambert. И получал примерно тоже самое.
Добавлено 23-11-2020 в 09:41:
Надо традиционно сделать два переключателя: глобальный запрет на входящие нормали и локальный запрет по материалам, или персональный запрет для конкретной энтити. Что-то такое.
Вот товарищи, какая мерзкая штука получается.
Если сгруппировать сурфейсы по блокам, по которым на каждый блок приходится один ректангл лайтмапы, то этих блоков получается адское кол-во. Значит каждый блок - это один сурфейс. На маленьких всяких картах, типа кутришных еще трепимо. Но если взять к примеру сталкеровскую, там ужос-ужос. Под 200000 сурфейсов. Рендерить 20000 тысяч сурфейсов очень тяжко, даже если ничего не рисовать - всё время уйдет просто на их группировку и отправку на рендеринг. Оптимальное кол-во блоков - 3-4 тысячи на всю карту, в каждом блоке, от 100 до 6000 полигонов.
Ну примерно. В самом сталкере сделано как. Там сперва рассчитывается атлас для лайтмапы и занимаются места в этом атласе. Полученный атлас, очевидно назначается целому ряду сурфейсов. Потом эти сурфейсы мержатся обратно, поскольку больше нет причин держать их разделёнными.
Но есть проблема. При таком подходе плотность люкселей должна быть заранее посчитана на этапе компиляции BSP. То есть чтобы изменить разрешение лайтмапы придётся заново пересчитывать всю карту. Одним только светом не отделаешься.
В сталкере там еще хлеще, там свет всегда считается вместе с остальным, как я понял, свет можно пересчитать потом, но для первой компиляции он считается всегда.
Добавлено 23-11-2020 в 18:27:
Впрочем, я тут погуглил, всё еще интереснее. Компилер света считает освещение для детайлов. Для всякой там травы и мелких кустиков.
А основное освещение отключить вообще не вариант.
Т.е. каждая компиляция принудительно считает освещение.
| IP: 
22-11-2020 11:55
