ncuxonaT писал: Smd объединяет вершины с одинаковыми координатами в одну вершину, это не круто.
Это кто тебя так обманул?
studiomdl этим действительно занимается, но это его дело. В хл2, к примеру ничего подобного не происходит, хотя модель создается из точно таких же smd-шек.
Накидал тут примерные структуры будущего формата BSP. Основной упор сделан на максимальную прозрачность. Т.е. не хранить ничего такого, что в дальнейшем устареет и не будет востребовано.
Добавлено 25-02-2020 в 14:54:
Цитата:
nemyax писал: Хочешь раздельные вершины — записывай туда раздельные индексы.
smd вообще не поддерживает индексы и слава богу. В текстовом формате они только место зря занимают.
Добавлено 25-02-2020 в 15:11:
Вообще, что для текстового формата в приоритете должно быть?
1. неизменность формата. Для текстового подобное правило соблюсти невероятно тяжело, потому что некоторым товарищам очень хочется предусмотреть вообще всё на какие-то мифические будущие случаи. Для smd это правило слава богу соблюдается, за 23 года единственное расширение формата - это развесовка.
2. упор на максимально быстрый парсинг. Аналогично, здесь smd вне конкуренции, поскольку он парсится не словами, а строками. А строка читается при помощи sscanf, который на порядок быстрее чем COM_ParseFile. Я знаю о чём говорю, когда-то давно, году в 2007-м я переделывал .smd парсер вот как раз на COM_ParseFile и на гигантских моделях получил чудовищное падение скорости чтения, раз в 8 примерно.
3. не пытаться сохранить в модель избыточную информацию, типа тех же индексов или цветов вертекса либо еще какой-то чертовщины. Всё это как правило уникально по месту вставки статичной модели, например для освещения или смешивания слоёв ландшафта. Т.е. в исходник эту информацию запекать всё равно бессмысленно, а индексация подобных моделей лишь увеличивает время парсинга, потом их придётся всё равно разиндексировать и построить нормальные стрипы, потому что никто не будет проверять как построены индексы в исходнике, это бессмысленная операция. Да как угодно! К тому же, когда модель вставляется в карту - вертекс тяжелеет, начинает содержать какую-то дополнительную информацию, из-за чего старая индексация моментально теряет свою актуальность.
4. возможность ручного редактирования. И здесь smd без равных, потому что данные идут предсказуемыми блоками безо всякой индексации. Я помню, как в том же .ase пытался заменить материал, а он не менялся и в итоге выяснилось, что там записано несколько одинаковых материалов - формат-то позволяет. В .smd просто включаешь автозамену и никаких сюрпризов. Ну и тот факт, что любой меш всегда привязан к кости в данном случае благо - мы всегда можем его быстренько покрутить или подвинуть целиком на какое-то расстояние. А вы попробуйте этот же фокус проделать в .ase или .obj. Obj кстати имеет милую привычку ссылаться на внешний материал описания файлов (тоже разумеется текстовый), но цымес в том, что имена ссылок вполне могут совпадать с реальными текстурами, поэтому одни парсеры считают эти ссылки путями к текстурам, а другие падают с ошибкой о том, что mtllib.c не найден.
Я с этими текстовыми форматами уже второй месяц вожусь плотно, я ведь сперва тоже думал, что они все примерно одинаковые и удобные. Хрен-то там. Дичь лютая творится. Я уже в .ase парсере сделал кучу магических условий, чтобы он мог адекватно парсить разные выхлопы экспортёров.
То что было закомпилено при помощи q3map2 надо свапать вертексами и потом еще дополнительно вращать на 90 градусов, то чтобы сделано при помощи самописного экспортёра от авторов X-Real, надо свапать индексами, при том, что сбор имён текстур материалов - само по себе увлекательнейший квест, оно может быть прописано как в MAP_NAME так и в BUTMAP так и в MATERIAL_NAME, либо в сабсекции DIFFUSE_NAME, где есть очередные BITMAP и MAP_NAME. И каждый экспортёр это оформляет как ему больше нравится.
Вложение: bspfile_new.zip (1.4 кб)
Этот файл был скачан 84 раз.
studiomdl этим действительно занимается, но это его дело. В хл2, к примеру ничего подобного не происходит, хотя модель создается из точно таких же smd-шек.
Как оно определяет, это одна вершина или несколько разных?
Дядя Миша писал: 3. не пытаться сохранить в модель избыточную информацию,
Хранить на каждый треугольник полностью 3 вершины - это и есть избыточная информация. 99% вершин принадлежат больше, чем одному треугольнику, поэтому отделение одного от другого с индексированием уменьшит объем занимаемой памяти в несколько раз.
ncuxonaT писал: Как оно определяет, это одна вершина или несколько разных?
то, чем занимается studiomdl вообще делалось для immediate отрисовки.
Цитата:
thambs писал: VertexBlend же для ландшавтных-моделей очень удобен безо всяких хейтмэп, или ты не об этом?
Да, но цвета задаст компилятор, в .smd им просто нечего делать.
Цитата:
ncuxonaT писал: Хранить на каждый треугольник полностью 3 вершины - это и есть избыточная информация
под избыточной я имел виду всякие дополнительные атрибуты.
А то, что текстовый формат неиндексирован - так это очень большой прирост в скорости парсинга, я выше объяснял почему.
Добавлено 25-02-2020 в 18:58:
Приступил к разработке виза. Поскольку лайтмапы отменяются, набор для компиляции будет состоять из двух утилит, ну понятно.
Думаю за пару дней справлюсь.
Добавлено 25-02-2020 в 19:00:
Вообще говоря, я потом этот виз протестирую на работу с двойной точностью и если это не скажется на скорости и не внесёт негативного эффекта, то можно будет объеденить их с makebsp, как фкутри.
Там просто жы эти пассажы, они память жрут.
Дядя Миша информация об индивидуальных вершинах теряется при записи в smd. Бывает такое, что вершин одинаковые координаты, но они при этом принадлежат разным треугольникам. После экспорта в smd этого уже не восстановить, вершины сольются в одну, у треугольников появится общее ребро. TBN будет строиться криво, привет швы из дума 3.
Добавлено 25-02-2020 в 19:53:
nemyax из того, что развесовка совпадает, не следует, что это вершина одна. На неё можно смотреть, если типа целый объект предполагается разделять, и фрагменты привязаны к разным костям. Но в случае моделей с симметричной разверткой типа дум3 это не сработает.
ncuxonaT писал:
у треугольников появится общее ребро
Значения нормалей по углам от этого не изменятся.
Добавлено 25-02-2020 в 19:59:
В конечном итоге ты всё равно не знаешь, какие вершины в какой момент на видимокарте окажутся склеены и какая там будет индексация. Дядя Миша пострипает, как ему нравится, или уложит всё под вызов какого-нибудь glDrawElements на своё усмотрение.
nemyax писал: Значения нормалей по углам от этого не изменятся.
Зато изменится тангент вектор, который станет нулевым.
Цитата:
nemyax писал: В конечном итоге ты всё равно не знаешь, какие вершины в какой момент на видимокарте окажутся склеены и какая там будет индексация. Дядя Миша пострипает, как ему нравится, или уложит всё под вызов какого-нибудь glDrawElements на своё усмотрение.
От стрипов и индексации ничего не случится. А вот переклеивать вершины не надо.
25-02-2020 11:25
Вложение: 
