Существует ли такой фреймворк где можно кодом генерировать геометрию на высоком уровне?
То есть оперировать вершинами, ребрами, гранями, треугольниками, мешами и группами геометрии. Выполнять операции над этой геометрией, трансформацию, генерацию, анализ, модификацию.
Что-то вроде подобного.
Vertex v1 = Vertex(0, 0, 0) Vertex v2 = Vertex( 0, 1, 0) Edge e1 = Edge( v1, v2) Geometry g1 = e.extrude( Vector( 0, 0, 1))
slepov ну это прям совсем что-то старенькое. С точки зрения дизайна.
Хотелось бы видеть внятный API и биндинги для разных (современных) языков.
houdini, quixel, substance designer, blender и любой другой графический 3д редактор.
А выше стоят уже игровые движки, но надо больше знать чтобы оперировать данными на уровне произвольных структур. Но если прям не с нуля и не в вакууме (с абстракциями). А на каком то конкретном примере, типо там Домик с разной расстановкой окон или карнизов, то для начала подойдут даже игровые движок (не возникнет особых сложностей).
Salamandr ставить проприетарный софт такая себе затея.
Хорошо бы если было бы вот такое только чтобы оно развивалось.
Это пару строк кода, понимаешь? Тем кто понимает, он не нужен. А чтобы понять нужны годы опыта.
это BSP в чистом виде (тот самый из Quake).
houdini отлично с этим справляется, есть бесплатная версия
blender имеет собственные структуры - отлично с этим справляется
UE, Unity или любой другой движок - отлично с этим справляется.
Не справляешься только ты, потому что не знаком ни с BSP, ни с моделированием, ни со структурами.
Чувак, пользуйся готовыми вещами. Если даже их ты осилить не можешь. Сделать что то своё будет ещё сложнее, просто в 10ки раз.
Начинать надо всегда с малого, с того что уже за тебя сделали во всех удобствах. А вот когда поймешь как они это делают, тогда можно размышлять на эту тему.
windel
windel
Все новое хорошо забытое старое ;)
Salamandr
> Чувак, пользуйся готовыми вещами. Если даже их ты осилить не можешь.
Вот я и ищу эти готовые вещи - библиотеку для высокоуровневой генерации процедурной геометрии.
Edge e1 = Edge(v1, v2)
Geometry g1 = e.extrude(Vector(0, 0, 1))
давай порассуждаем
struct Vector3 { float x,y,z } std::vector<Vector3> vertex; struct Edge { unsigned index1, index2 } struct Face { Edge e1,e2 //или там unsigned v1, v2, v3, v4 }
то есть
vertex[edge.index1] и vertex[edge.index2]
ок. Теперь extrude
func void extrude(e1, axis = Vector3(0,0,1)) { Vector3 v1(vertex[e1.index1]); Vector3 v2(vertex[e1.index2]); Edge nEdge(vertex.count+1, vertex.count+2); //при добавлении надо проверить что такой вершины ещё не было //но мы это опустим vertex.push(new Vector3(v1 + axis) ); vertex.push(new Vector3(v2 + axis) ); //ну и в этот момент у нас образуется полигон Face face(e1,nEdge); faces.push(face); }
всё, баста. Что тут сложного?
Ну и рисуем это всё
https://github.com/rbfx/rbfx/blob/aaba15c6dcb9f04b6fcae3352f5f1d0… etry.cpp#L109
Только вот эта хрень обманчива, нужен учесть много всяких подводных камней и прочего.
Правило буравчика)))
Наверное оно как то по другому называется.
Проблема №1
у тебя есть вершины, ты должен по ним собрать полигон в правильном направлении. Даже если у тебя есть normal полигона, ты должен указать порядок точек так, чтобы если нормаль смотрит на смотрящего, то полигон видно. Такие полигоны строят по часовой стрелке. Как ты по нормали определишь какая из точек у тебя первая, какая вторая, какая третья и четвёртая (ну можно и треугольниками, тогда только 3 вершины).
Проблема №2
Как только тебе надо разделить полую фигуру, разрезать по полам или там вдоль какой то прямой или плоскости. Начинается вторая проблема.
Проблема №3
булевые операции (boolean) над мешами. Когда мы один меш вырезаем из другого и нам надо получить или остаток от первой фигуры или остаток от второй фигуры или как раз разницу вырезания.
Проблема №4
Она не совсем проблема, но тоже имеет место быть. При всех операциях ты должен учесть UV развёртку на моделях, учесть второй материал с которым она будет пересекаться или накладываться.
Всё это решается через BSP-дерево, но оно же и усложняет этот процесс. Ты не можешь нарушить его правила если будешь использовать его алгоритм.
Однако, все эти проблемы решает houdini и blender сам, тебе лишь надо сказать что делать, даже не кодом, а просто перетягиванием нод. Мне кажется выбор просто очевиден. Можно и кодом, если удобнее через него.
Salamandr
> Можно и кодом, если удобнее через него.
есть пример?
https://blender.stackexchange.com/questions/115397/extrude-in-python
примеров масса, главное версия blender, например до существования нод всё приходилось делать через Python. Blender 2.82 (справа внизу версия) в видео
В общем спрашивай если что не понятно, в какой то степени я в этом разбираюсь.
Всё что ты делаешь отображается слева внизу (в видео)
и если ты напишешь в коде любую из тех строчек из этого лога, будет тот же эффект.
например это строка в скрипте добавит Plane в 0,0,0
bpy.ops.mesh.primitive_plane_add(size=2, enter_editmode=False, location=(0,0,0))
размером в 2 (2x2 юнита = метра), в режим объектов (их там несколько: режим работы с объектами, режим править сетку edit_mode, режим скульптить, рисовать веса, режим поз - для анимаций костей и ещё какой то был).
То есть тебе не обязательно помнить все команды, тебе лишь надо повторить команду которая есть в логе.
Для всего остального, существуют структуры Blender через которые можно получить доступ к другим вещам.
Все аддоны, импортёры и экспортёры моделей какого то специфичного формата имеют открытый исходный код (его лишь надо понять, по началу довольно сложно).
Поэтому не стесняйся спрашивай.
Но думаю большинство ответов сейчас на ютубе и куда подробнее будут
houdini я не знаю, но возможно когда нить изучу и его. Он мне нужен для VFX, хотя может и в blender напишу свои скрипты (ведь знаю о нём куда больше).
windel
> ну это прям совсем что-то старенькое. С точки зрения дизайна.
Opencascad - тоже не айс
CGAL - убер сложно, не френдли
Как то давно, впечатленный openscad, я подумал - нафига делать еще и язык, редактор к нему + двигло, есть же ламповый c# поверх которого можно зафигачить internal DSL с вызовами в какой нить cad engine. На тот момент уже был опыт в Solidworks. И сделал даже чтото, работало.
Минусы:
- декларативно описывать геометрии все равно не выйдет, т.к. построения - это императив, невозможно предсказать даже структуру результата не выполнив метод построения
- зависимости от движка (хотя для внутреннего использования пофиг, мне помогло).
Плюсы:
- то ради чего сыр бор - генерить сложные геометрии скриптами удобно. IDE языка, которая вроде бы для кода, а на самом деле помогает разбираться со структурой геометрии прямо в IDE.
Наверно главная трудность - удобный DOM + API, если он будет такой же уродский как в CAD-ах то смысла нет
Salamandr
а геометрические ноды можно заставить работать через скрипты?
Вот еще что нашел.
https://github.com/pmp-library/pmp-library
windel
> а геометрические ноды можно заставить работать через скрипты?
судя по всему можно, но я не представляю зачем https://blender.stackexchange.com/questions/259867/geometry-nodes… ration-script создавать ноды через скрипт или как ты будешь ими управлять, каждый раз удалять чтобы создать новую во время разработки - ну это так себе. С точки зрения сохранения и загрузки - наверное удобно, но не более.
Они из разных вселенных и никак с друг другом не пересекаются. Один работает на основе связей, другой работает на основе вершин и полигонов.
Это как в UE бегать между блупринтом и c++ туда обратно передавая данные или даже хуже.
Тема в архиве.