Найти поверхности

Добрый день

Есть полигонная 3D модель, так называемый "меш". Требуется найти поверхности и присвоить каждой свой цвет (аттач)

Спасибо

Миниатюры

 

0

Сообщение от leproza Самое смешное, что я именно этот чайник уже 100 раз видел. Это какой-то классический образчик, он даже в учебниках по OpenGL есть. Просто погугли Teapot.obj. Я, конечно, гарантию не дам, но по-моему это именно он.

Самое смешное то, что ты не читаешь мои комментарии. Я же выше писал:

Сообщение от Royal_X ТС привел "Чайник из Юты", который похож на тот, что используется в коммерческих продуктах от Autodesk

Всё это объясняет, почему ты видел этот чайник (или похожий чайник) 100 раз.

Вот только я сомневаюсь, что чайник из этой темы (имею в виду приведенный выше obj-файл) действительно взят, например, из 3ds Max. Чайник из этой темы с артефактами и вообще моделирован коряво. Не думаю, что разработчики топового софта будут такой мусор делать. На мой взгляд, кто-то просто решил создать похожий чайник и получилось у него не очень.

В 3ds Max этот чайник добавляется через Create → Geometry → Standard Primitives → Teapot. У меня нет данного редактора, чтобы точно ответить, он взят оттуда или нет? Или с какой версии 3ds Max он взят?

0

Сообщение от Royal_X я сомневаюсь, что чайник из этой темы (имею в виду приведенный выше obj-файл) действительно взят, например, из 3ds Max

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

0

Сообщение от alecss131 Ну разве что он не в obj.

Ну вот, видимо, тот артефакт у ручки, который виден на скриншоте в посте https://www.cyberforum.ru/cpp-... st17710308, это результат корявой конвертации в obj.

Я сейчас скачал другой obj, перейдя по ссылке https://www.cs.utah.edu/~natev... teaset.zip, которую нашел в статье Википедии Utah teapot в разделе OBJ conversion, и оказалось, что там этого артефакта нет. Эта ссылка университета Юты, т.е. родины чайника.

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

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

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

Сообщение от alecss131 У меня пока нету установленных 3д редакторов.

cофтули от Autodesk дорогие, по крайней мере, я как хоббист не стану их покупать. 3ds Max в год стоит более $2000 Столько же Maya.
у меня от Autodesk только бесплатный Fusion установлен

а вот Blender меня полностью устраивает и постепенно он становится все круче и круче. Сейчас вышла 5-версия, там процедурку еще улучшили, скоро порвет даже C4D, которая всегда считалась эталоном моушна из-за крутизны MoGraph.
Blender сейчас очень активно используется в гейдеве для UE и Unity. В нем можно сделать почти все, что нужно для разработки игр, кроме тех вещей, которые делает Substance Painter. Даже ZBrush не нужен, поскольку в Blender скульптинг круче, чем в C4D, 3ds Max, Maya, уступает, конечно, ZBrush, но обычно недостатки не чувствуются.
Так сказать это универсальная прога. Во многих туториалах по созданию игр используется Blender.

0

Сообщение от leproza Возьмите 2 куба у которых одно общее ребро. Это одна поверхность или две? Беда в том, что это самое общее ребро - это так называемый singular edge, т.е. ребро, через которое проходит более двух фейсов. И это беда, т.к. подобное нарушает однозначность топологического обхода. А например сингулярная вершина (2 куба с общей вершиной) нарушает полноту топологического обхода. За подробностями опять к Хоппу направлю.

Не стоит "витать в облаках", есть гораздо более прозаические вещи. Фейсы шарят один вертекс, ну тут все ясно - просто имеют общую точку/вертекс. А сколько таких "шарящих" обычно? Напр для треугольной модели? Далее. Два фейса шарят два вертекса - тоже ясно, нормальная поверхность. А если 2 фейса шарят 3 вертекса? А если 2 фейса шарят все вертексы? Это кстати достаточно популярный случай. Напр возможны фейсы
{0, 1, 2, 3}
{2, 1, 0, 3}
Это что? И будет ли Ваш алгоритм работать для такой модели? (нет). Далее. А если ребро (2 вертекса) шарится 3-мя или более фейсами? Это называется всяко-разно, напр "non-manifold mesh", но суть одна: однозначного решения нет, различные фичи могут работать, но могут и нет, как получится.

Также не вижу Ваших предложений: какие еще есть способы выделения/нахождения поверхностей? Сейчас у простого куба найдется 6 поверхностей, он ведь имеет свои вертексы (и значит свои ребра) для каждой грани (всего 24 вертекса). Это может показаться странным, но выгоды весомее, напр у цилиндра с крышками находятся 3 поверхности (верхняя крышка, нижняя и середка), что обычно и нужно. Но в любом случае: как еще можно выделять поверхности? А если мыслей нет, то давайте честно признаем: проблемы "что считать поверхностью" не существует

Сообщение от leproza Меня удручает, что, похоже, никто внимательно мой код не смотрел - реализация обхода не совсем волновая.

Да, и что? Кому это мешает? По поводу кода. Понимаю что Вы хотели показать что "работает", спасибо, но тратить время на загрузку и отрисовку не стоит. Для этого каждый использует свои наработки/системы, это неизбежно. А вот "как получить соседей фейса(ов)" нужно бы почетче. Вот исходные данные
Соседи могут быть представлены напр так
Нужно написать ф-цию

0

Как обычно, вопрос - подскажите, как сделать то, не знаю что.

Сообщение от Igor3D Наверно потому что это интуитивно, очевидно что чайник имеет "части", как минимум крышку, а обычно ручка и носик тоже отдельно

У редакторов, а тем более у C++, нет интуиции. Любую модель кто-то когда-то создавал, и ПРИ СОЗДАНИИ, неявным образом создал эти части. Например, автор создал сферу (корпус чайника), потом вырезал дыру под крышку и создал саму крышку. Крышка, так получилось, стала отдельной частью. С носиком и ручкой аналогично, интереснее с дном - автор мог сплющить низ сферы - вот и вышло дно, но оно не является отдельной частью, а мог вырезать фрагмент и "заклеить" куском плоскости - а так дно вышло, как отдельная часть, хотя внешне результат не различается.
Аналогично с ручкой на крышке - на картинке она закрашена одним цветом с крышкой, но с чего автор взял, что это интуитивно? По мне, так эта ручка - отдельная запчасть.
То есть на первый вопрос ответ: эти отдельные части явно или неявно создаются при создании моделей.

Сообщение от Igor3D Ну а как это "формализовать" - в задачу входит, разжевывать все детали ТС не обязан

ТС, конечно, никому ничего не обязан. Может, он неспособен сам формализовать и просит именно в этом помощи. Но тогда он должен описать, при решении какой задачи он столкнулся с этой проблемой.
Вот это:

Есть полигонная 3D модель, так называемый "меш". Требуется найти поверхности и присвоить каждой свой цвет (аттач)

Могло бы считаться формальным описанием задачи, но только ТС сам себе противоречит:

Сообщение от Igor3D Надеюсь будете писать код для любой модели, не только для данного чайника

То есть написанное в п.1 не является полным описанием задачи. Принципы разделения у "любой модели" могут быть не такими, как у чайника из п.1
Получается, что на этот вопрос нет ответа потому, что нет явного вопроса.

Можно попробовать включить воображение: "По каким признакам я, глядя на модель, делю её на части?" Но ответ на этот вопрос не уложится в несколько десятков строк на C++, это достойно ИИ, который просто "научится" на миллионах моделей, и при этом всё равно будет иногда ошибаться.

0

Сообщение от Igor3D И будет ли Ваш алгоритм работать для такой модели? (нет)

Это, позвольте поинтересоваться, с чего бы? Вот, задаем faceList
запускаем processModel() и получаем ответ - оба фейса принадлежат одной поверхности. А если вы считаете, что это неправильно - пожалуйста, укажите, почему, т.к. это означает, что вы не критерий наличия соседий используете в своем рассуждении, а какой-то другой.

Сообщение от Igor3D тратить время на загрузку и отрисовку не стоит

Сообщение от Igor3D Вот исходные данные

Нет, исходными данными был obj файл и картинка. Может быть, в следующий раз, когда вас будет интересовать какой-нибудь конкретный алгоритм, вы подготовите условия задачи так, чтобы никому и не пришлось тратить время на какие-то дополнительные действия?

0

Сообщение от Mikle Quits То есть написанное в п.1 не является полным описанием задачи. Принципы разделения у "любой модели" могут быть не такими, как у чайника из п.1 Получается, что на этот вопрос нет ответа потому, что нет явного вопроса.

Согласен, и я об этом тоже говорил. Конкретно чайник из данной темы, хоть и состоит из одного меша, но его крышка, ручка и носик были смоделированы отдельно и эти части не связаны друг с другом. Именно поэтому разделять их на части не составляет труда даже в 3d редакторах. Выше я уже говорил, что, например, в Blender можно нажать любую вершину на этих частях и нажать Ctrl+L, как редактор выделит всю часть. Соответственно, написать код конкретно для этого чайника, который найдет эти отдельные части, вообще не сложно.
Но вот, допустим, что чайник cмоделирован таким образом, что все части соединены друг с другом. Кстати, нормальные люди именно так и моделируют. Даже если они создают части из новых примитивов, то все равно в конце они соединяют все части.
Ну и как в таком случае алгоритм может понять, как правильно разделить меш на части? Никак. Ну разве что нужно написать приложение, использующее ИИ, которое анализирует меш в целом и потом как-то пытается отделить на части.
Именно поэтому, я писал, что нельзя написать код, который будут работать для всех случаев. alecss131 тоже правильно сказал, что это задача для 3d редактора, а не С++. Т.е. даже если части модельки будут связаны друг с другом, в 3d редакторах есть много продвинутых функций для удобного выделения частей. Некоторые даже определяют части автоматически, но все же человек должен проконтролировать процесс, поскольку очень часто эти инструменты могут выделить не полностью или наоборот охватить что-то лишнее.

Сообщение от leproza ТС вроде и не требовал универсально ответа, требовал "как на картинке" =)

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

0

Сообщение от Royal_X Даже если они создают части из новых примитивов, то все равно в конце они соединяют все части.

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

0

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

нет, ты не понял меня

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



Вот тут, в отличие от чайника из этой темы, где отдельные части не соединяются друг с другом, если попробуешь выделить в Blender посредством Ctrl+L (Select Linked), то выделится всё, а не одна сфера, поскольку алгоритм уже не может понять, как нужно отделить. Конечно, в Blender есть и другие методы для быстрого выделения только одной сферы (например, в виде сбоку можно просто выделить прямоугольником), но все же, код из этой темы, который ищет "Sharp edges - эйджи, через который проходит только 1 фейс" работать не будет.

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

0

Сообщение от Royal_X я имел в виду, что меш может быть создан, например, из двух отдельных примитивов (две сферы), но потом они были соединены. Т.е. у сфер теперь есть 8 общих вершин.

Всё я понял, на месте стыковки нормали меняют направление (это видно на первом рисунке по освещённости), там на самом деле не 8, а 16 вершин на совпадающих координатах. Программно это несложно отследить.

0

Сообщение от Mikle Quits Всё я понял, на месте стыковки нормали меняют направление

нормали там не меняют направление

Сообщение от Mikle Quits там на самом деле не 8, а 16 вершин на совпадающих координатах

нет, там именно 8, а не 16, поскольку я как раз использовал функцию Merge, которая из двух совпадающих оставляет только одну. В Blender есть даже функция Auto Merge, которая объединяет совпадающие вершины, либо вершины, которые находятся очень близко (там можно настроить Threshold).

Сообщение от Mikle Quits Программно это несложно отследить

неа, ты никак не отследишь. Для программы этот меш это просто цельная деформированная сфера. Это как если взять один шарик и сжать в центре, то по бокам повылазят две сферы.
Конечно, конкретно для этого меша ты можешь написать лисапедный код, заранее зная для какого меша ты пишешь и какие части именно нужно отделить, но универсальный код ты не напишешь. Получится так, что для 1000 разных мешей тебе придется написать 1000 кодов)))

0

Royal_X, да, я присмотрелся - сфера не сглаженная, тут каждый 4-угольный фейс имеет свою нормаль, по моему методу тут будет разделение на сотни частей (как куб на шесть).

Сообщение от Royal_X там именно 8, а не 16

Возможно, редактор в своём формате так может хранить, но, если это экспортнуть в любой, подходящий для видеокарты, вид, то будет 16 вершин, даже больше - там ведь сходится по три фейса от каждой сферы.

0

Сообщение от Mikle Quits Возможно, редактор в своём формате так может хранить, но, если это экспортнуть в любой, подходящий для видеокарты, вид, то будет 16 вершин, даже больше - там ведь сходится по три фейса от каждой сферы.

Не совсем понял, что ты хочешь сказать. Там у каждой сферы были удалены 4 фейса, далее сферы были соединены. Теперь у них 8 общих вершин и 8 общих ребр. Там нет совпадающих, а именно они стали общими.
Даже если при экспорте произойдет триангуляция, каждый прямоугольник поделится на два треугольника, то на количество вершин и на то, что они уже соединены, это никак не повлияет.
Части соединены навсегда, и сейчас это как цельный меш.

Добавлено через 28 минут
Mikle Quits, для лучшего понимания, почему задача ТС бесполезна для общего случая, могу привести такой пример:

Допустим некто говорит - отделить "56, 72" на два числа. Конечно, ты без проблем это сделаешь. Ты это сделаешь и когда будет "56 72". Одним словом, запятая или пробел, или другой разделитель помогают разделить на два числа.
Но если я тебе дам "5672", то ты сможешь разделить только в случае, если я тебе дам подсказку, что числа двузначные.
Однако, если я тебе буду давать "4596", "2198" и пр. без всяких подсказок, то ты никак не разделишь на два числа, поскольку 4596 можно разделить на два числа неоднозначно.

То же самое с мешами. Если части отделены физически, то ты без проблем напишешь код. Но когда там цельный меш, то ничем программа не поможет в общем случае.
Для конкретного случая, конечно, можно написать велосипед. Но вот написать универсальный код, который будет что-то отделять у цельных мешей (когда мы не знаем, как они вообще выглядят), невозможно.

0

Сообщение от leproza Нет, исходными данными был obj файл и картинка.

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

Сообщение от leproza Может быть, в следующий раз, когда вас будет интересовать какой-нибудь конкретный алгоритм, вы подготовите условия задачи так, чтобы никому и не пришлось тратить время на какие-то дополнительные действия?

Боюсь что в этом случае получим обвинения в "xy" (которые даже могут быть справедливы), вопросы типа "да ты скажи что надо-то?" (хотя они всегда есть если нет ответов) и.т.п. Поэтому я считаю что лучше всегда начинать с "хотелки юзера", т.е. что есть желаемый/финальный рез-т

В данном случае "содержательная часть" формулируется просто

каждый фейс должен знать всех своих соседей

Все остальное (волновой алгоритм и др) всем известно и никому не интересно. Вы привели нормальный код, тем более "сходу". Но все-таки хотелось бы пошлифовать, сделать менее "жирным". Хорошая, интересная задачка на плюсах

Сообщение от Mikle Quits Ну, этот случай как раз не сложно отследить - даже после объединения у двух мешей не будет ни одной общей вершины, будут продублированные на одних и тех же координатах разные вершины потому, что нормаль в любом случае не сойдётся. Это не сложно отследить. Но этот метод имеет свой недостаток - он будет считать разными все части модели, в которых нет общих вершин, например, куб, если с нормалями, будет всегда шестью частями, и меньше 24 вершин в нём быть не может, хотя, казалось бы, их восемь.

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

Нет в жизни счастья

0

Сообщение от Royal_X Теперь у них 8 общих вершин и 8 общих ребр. Там нет совпадающих, а именно они стали общими.

Я же написал:

Сообщение от Mikle Quits если это экспортнуть в любой, подходящий для видеокарты, вид

На первой картинке на месте стыка фейсы одной сферы освещены, а второй - затемнены, очевидно, что это влияние Diffuse освещения. А видеокарта берёт нормали для света в вертексах, если бы вертексы были общими - свет бы плавно менялся.
Простой пример - если в D3DX сгенерировать куб (командой D3DX->CreateBox()), то в нём будет не 8, а 24 вертекса. Это потому, что нормали сторон на месте стыка разные. А вот у чайника фейсы стыкуются плавно, без видимого перехода, там соседние фейсы используют один и тот же вертекс.

0

Сообщение от Mikle Quits На первой картинке на месте стыка фейсы одной сферы освещены, а второй - затемнены, очевидно, что это влияние Diffuse освещения. А видеокарта берёт нормали для света в вертексах, если бы вертексы были общими - свет бы плавно менялся.

Ложный вывод, поскольку скриншот сделан во вьюпорте в режиме Viewport Shading, который я сам кастомно настраиваю как хочу. Там нет ни реалистичного затенения, ни реалистичного освещения. Там даже нет источника света. Так что, делать такие выводы не нужно.
Я же всё прекрасно вижу в редакторе, и сколько у меня вершин (в редакторе показывается статистика) и в какую сторону нормали. Зачем мне эти сомнительные методы Ванги.
У нетронутой сферы у меня 482 вертекса / 512 фейсов / 992 ребр. А у этого меша (созданного из двух приклеенных сфер) 954 вертекса / 1968 ребр / 1016 фейсов.
У сферы без четырех фейсов 481 вертекс, 988 ребр, 508 фейсов.
Не нужно быть математиком, чтобы понять, что вертексы общие (481 * 2 = 962 ≠ 954)
Так что, я еще раз повторяю, что вертексы общие. И нормали тоже не отличаются. Стык ничем не отличается от остальных ребр, так что ни одна программа не сможет определить такой стык.

Конкретно для данного случая, конечно, можно написать код, которые сможет определить стык, например, сравнивая угол между фейсами. Однако, приведенный объект только для примера, который показывает, что можно соединить два примитива или куска в один меш таким образом, что подход с "Sharp Edges", упомянутый в данной теме, работать не будет. То есть, достаточно, как я поменяю меш, как код снова не будет работать. К тому же, написание кодов для каждого конкретного случай (меша) это идиотизм. Вот, и говорю, что такими темпами для 1000 мешей нужно написать 1000 кодов)))

0

Сообщение от Royal_X всё прекрасно вижу в редакторе

Я же писал:

Сообщение от Mikle Quits подходящий для видеокарты, вид

Для видеокарты!!!

Сообщение от Royal_X нормали тоже не отличаются

Вид в разрезе, добавлены нормали. Грани A и B стыкуются в чёрном вертексе. Какая должна быть нормаль у этого вертекса?

Миниатюры

 

0

Сообщение от Mikle Quits Грани A и B стыкуются в чёрном вертексе. Какая должна быть нормаль у этого вертекса?

у этого вертекса такая же нормаль, как у любого из этой картинки.

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

Сообщение от Mikle Quits добавлены нормали

ну это твоя фантазия. Ты для одного вертекса на месте стыка нарисовал сразу две нормали, тогда как в реальности там только одна нормаль у каждого вертекса. Я же тут уже несколько раз написал, что нет никаких двух совпадающих вертексов, а есть только один общий. И нормаль одна. Не может быть у одного вертекса сразу несколько нормалей. Один вертекс, одна нормаль. Нормаль общего вертекса (таких общих вертексов 8 штук) на месте стыка смотрит наружу (а не внутрь), как и все остальные нормали других вертексов.

0

Royal_X, при таком расположении нормалей на границе сфер при освещении будет градиент вместо резкого перехода.
Можно мне эту модель? Я её отрендерю видеокартой и пришлю результат.

Сообщение от Royal_X Не может быть у одного вертекса сразу несколько нормалей. Один вертекс, одна нормаль.

Естественно. Именно поэтому я и утверждаю, что вертекса должно быть два. Если он только один - то это ВНУТРЕННЕЕ ПРЕДСТАВЛЕНИЕ В РЕДАКТОРЕ, а я неоднократно подчёркивал, что речь о видеокарте, о том формате, который может быть загружен в вертексный буфер.
Можно даже проще - не эту модель, а сгенерировать в редакторе куб с нормалями, обычный, без фасок и т. п. Потом посчитать вертексы. Редактор может и напишет, что их 8, но я 100% уверен, что в вертексном буфере в файле модели их будет уже 24, либо на кубе не будет работать освещение.

0

Сообщение от Mikle Quits Если он только один - то это ВНУТРЕННЕЕ ПРЕДСТАВЛЕНИЕ В РЕДАКТОРЕ

Если это было бы внутренним представлением в редакторе, то работало бы оно так только в этом редакторе.

Это не представление в редакторе, а это общепринятое представление, которое существует для полигональных сеток (мешей). Это представление никак не привязано к моему редактору. Я вот могу сохранить файл в obj или в любом другом формате и кто-нибудь другой его может открыть в другом 3d редакторе, или использовать меш в редакторе игрового движка и т.д. Но от этого ничего не поменяется. Количество вертексов и их нормали не поменяются.
Именно это представление используется повсюду в 3d при работе с мешами. А вот то, как оно представлено на уровне видеокарты - это уже не волнует людей, которые работают с мешами (3d моделлеры, геймдевы, аниматоры).

Сообщение от Mikle Quits неоднократно подчёркивал, что речь о видеокарте, о том формате, который может быть загружен в вертексный буфер

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

Я все прекрасно понимаю, что на уровне видеокарты будут всякие вершинные, индексные буферы, мешлеты и прочее. Конечно, понятия вершины, нормали используются и в контексте представления на уровне видеокарты. Это все прекрасно, но какое оно вообще имеет отношение к теме?
Я тебе говорю, что там у моего меша общие вертексы, а ты мне говоришь, что на уровне видеокарты там иначе. Ну и что с того? А на еще более низком уровне там нули и единицы. Представляешь, там на месте стыка не вертексы, а нули и единицы

0