nemyax тангент-вектор (красный на иллюстрации) должен лежать в касательной плоскости, то есть быть перпендикулярным нормали. Векторов в плоскости много, поэтому для стандартизации люди договорились считать тангент-вектор направленным в одну сторону с осью U на развертке. По одной вершине непонятно, куда направлена U, нужны соседние, поэтому тангент-вектора сначала считаются для треугольников, а потом уже для вершин берётся среднее значение от соприкасающихся треугольников.
Представь, что на третьей картинке используется развертка из двух зеркальных частей. То есть на левой половине вместо D7 D8 D1 будут отзеркаленные D4 D3 D2. Для правой половины тангент-вектор будет направлен вправо, для левой - влево. А в сумме выйдет ноль.
Дядя Миша а можно не расшарить. В SMD нет информации, какие вершины нужно шарить, а какие нет.
ncuxonaT
Ну так данные нормалей предоставляют тебе всю потребную информацию, чтобы находить общие рёбра и чтобы векторы не гасились. А ты как будто топишь за то, чтобы их наоборот можно было гасить в произвольных местах.
ncuxonaT писал: Представь, что на третьей картинке используется развертка из двух зеркальных частей
ну так это проблема моделлёра, а не касательного пространства. Впрочем, можно сначала построить тангенты, а потом уже расшарить вертексы.
Проблема надуманная абсолютно.
Доделал виз, работает. Я почти всё взял от оригинала, там особо нечего модифицировать. Впервые за всё время существования квейков появилась возможность оценить вклад CSG в работу виза. Так вот вклад есть и он существенный. На q3dm1 без виза получается в среднем 42 портала на лиф, а с CSG - всего 30 порталов. Отдельно скажу за механизм портально-пассажного виза. Ничего особенного он не делает, обычный баланс междуь памятью и процессорным временем. Классический портальный виз вычисляет сепараторы по ходу работы, портально-пассажный строит их до начала вычислений, сепараторы конечно требуют какой-то объем памяти.
Есть еще интересная штука - мержилка лифов и фейсов. По дефолту она выключена. Может помочь сократить кол-во порталов и лифов, которые по смыслу можно объеденить, главное что бы у них плоскости совпадали.
Впрочем на размер виздаты это никак не влияет. Наверное было бы логичнее эту мержилку перенести в BSP.
Так же хочу отметить, что итоговый фпс с визом нельзя назвать прямо сильно отличным от старых халфовских карт, для которых я построил оптимальное визтри на лету. Ну я рассказывал об этом.
На сипульчере в оригинале 290 фпс, на кутришной карте 350 фпс. На гренделе оригинальная карта показывает даже более высокие значения.
Добавлено 26-02-2020 в 10:45:
И чтобы окончательно закрыть эту тему с касательным - абсолютно все лоадеры, которые я видел избавляются от индексов на этапе загрузки, строят уникальные вертексы, т.е. эта информация теряется в любом случае.
nemyax я не понимаю, что ты говоришь. Нормали кроме касательной плоскости ничего не дают.
Цитата:
Дядя Миша писал: ну так это проблема моделлёра, а не касательного пространства.
Так же думали погромисты дум3. А моделлеры дум3 думали, что это проблема погромистов, ведь в 3дмаксе у них всё нормально было, вертексы разделены. Если сначала строить тангенты, то это нужно делать еще до экспорта из 3д редактора.
Цитата:
Дядя Миша писал: они в любом случае пошарятся, для стрипификации.
Моделлер решает, где вертексы шаренные, а где нет. И в нормальном формате это записывается. Только что проверил, FBX, DAE, неоптимизированный OBJ из 3дмакса и просто OBJ из блендера сохраняют всё нормально.
К слову, в SMD не добавишь ни второго канала развертки, ни vertex color.
Добавлено 26-02-2020 в 17:27:
Цитата:
Дядя Миша писал: абсолютно все лоадеры, которые я видел избавляются от индексов на этапе загрузки, строят уникальные вертексы,
зачем это делать, если индексы уже подразумевают под собой уникальные вертексы
ncuxonaT писал: Так же думали погромисты дум3. А моделлеры дум3 думали, что это проблема погромистов, ведь в 3дмаксе у них всё нормально было, вертексы разделены.
Тогда объясни как это в хл2 нету проблем с бампом, они-то модельки тоже из smd компилят.
Цитата:
ncuxonaT писал: К слову, в SMD не добавишь ни второго канала развертки, ни vertex color.
А зачем добавлять то, что игнорируется в любом случае?
Цитата:
ncuxonaT писал: зачем это делать, если индексы уже подразумевают под собой уникальные вертексы
Индексы не подразумевают ничего. Я в любом случае это по своему индексирую.
Добавлено 26-02-2020 в 19:50:
У smd на самом деле есть одно важное преимущество - он по дефолту уже ориентирован "По Кармаку", значит его не надо никуда лишний раз поворачивать при импорте-экспорте. По крайней мере в рамках рабочей среды, если это экспортёр из блендера, то там наверное надо.
И вообще мне честно говоря это уже вкрай надоело. Чтобы я ни сделал - начинает спорить, что-то доказывать. Да нахер мне это надо? Иди свой движок пиши и там делай как тебе нравится.
Добавлено 26-02-2020 в 19:52:
Главное столько лет этот бамп в параное делали - ни слова от тебя не было на тему того, что он из-за smd кривой. А тут вдруг выяснилось. Тебе просто скучно и надо поспорить.
Дядя Миша писал: Тогда объясни как это в хл2 нету проблем с бампом, они-то модельки тоже из smd компилят.
В хл2 нет моделей с симметричной разверткой как в дум3
Цитата:
Дядя Миша писал: Главное столько лет этот бамп в параное делали - ни слова от тебя не было на тему того, что он из-за smd кривой. А тут вдруг выяснилось. Тебе просто скучно и надо поспорить.
Было. Я еще на ксме говорил, что на модели толстяка из дума шов на нормали
Цитата:
Дядя Миша писал: А зачем добавлять то, что игнорируется в любом случае?
Сейчас игнорируется, а потом понадобится. А уже не добавить.
Цитата:
Дядя Миша писал: Чтобы я ни сделал - начинает спорить, что-то доказывать.
Когда я не спорил и не доказывал, у вас нормали были в разные стороны, а на моделях со скелеткой вообще черти чего. Ты этого хочешь?
ncuxonaT писал: В хл2 нет моделей с симметричной разверткой как в дум3
ну вот видишь как просто это решить
Цитата:
ncuxonaT писал: модели толстяка из дума шов на нормали
да это Элбер его криво экспортнул. Мы же понятия не имеем чем он пользовался.
Цитата:
ncuxonaT писал: Сейчас игнорируется, а потом понадобится
не понадобится.
Цитата:
ncuxonaT писал: не доказывал, у вас нормали были в разные стороны
А как же они по твоему должны быть в одну сторону штоле?
Добавлено 26-02-2020 в 21:12:
В любом случае тангента строится на основе нормали и текстурных координат для дублирующихся вертексов. Если она будет отличаться, вертекс шареным и не станет, очевидно же. Т.е. это элементарно восстанавливается.
Дядя Миша писал: В любом случае тангента строится на основе нормали и текстурных координат для дублирующихся вертексов. Если она будет отличаться, вертекс шареным и не станет, очевидно же.
Вероятно, это сработает. Конечно, если на развертке не будет диких искажений. И нужно будет поставить какой-то значительный порог сравнения тангентов. Ну чтобы не получилось, что никакие вертексы не шарятся.
ncuxonaT я вот еще думаю, если получившийся TBN прогнать через BFN-карту и сохранить их как char[3]. И по хорошему, когда снимаешь нормали с меша, их тоже перед записью в tga надо прогонять через BFN.
Добавлено 27-02-2020 в 10:46:
Цитата:
ncuxonaT писал: И нужно будет поставить какой-то значительный порог сравнения тангентов.
Гм. Векторы сравнивают через дот, а в качестве порога берут угол в радианах. Я обычно использую шаг в 2 градуса. Впрочем в оригинальных студиомоделях нормали индексируются с точно таким же шагом. Это нам даёт 32400 уникальных нормали по идее. Но конечно в BFN разрешение даже выше получается.
Дядя Миша писал: А Крайтек по этому поводу ничего не писал?
Неа. Они делали свой энкодер для ATI2N, который считал ошибку не по отдельным каналам, а по восстанавливаемой нормали. Но он одну текстуру сжимал 3 часа, поэтому использовался только в крайних случаях.
| IP: 
25-02-2020 22:47
