Edge Slide, алгоритм ?

Возникла проблема с алгоритмом сортировки:

(IMG:http://i.imgur.com/QbZLoy3.png)

ИМЕЕМ:
sorted_edge_list [ 89, 93 ] - список правильно отсортированных ейджей
additional_sorted_edge_list [ 321, 4, 123 ] - дополнительный список правильно отсортированных ейджей.

Так вот задача по возможности используя только порядок следования ейджей из списка
sorted_edge_list получить список вертексов упорядоченных от начального вертекса первого
ейджа из списка до конечного вертекса последнего ейджа из списка sorted_edge_list.

Если это в принципе не возможно для такой ситуации (а это вполне может быть невозможно)
то попробовать решить туже задачу используя дополнительный список additional_sorted_edge_list
который так же упорядочен в правильной последовательности. Но задача та же упорядочить
правильно вертексы принадлежащие ейджам из списка sorted_edge_list.

То-есть в конечно вариант мы должны получить вот такой список вертексов [ 233, 23, 4, 122].

Тут важно помнить что в XSI да и в ряде др ПО ейдж может вернуть вертексы как в порядке [233, 23] так и в порядке [23, 233].

Обычно такие алгоритмы построены на связи правильного следования ейджей и наличии общих вертексов между ейджами.
В данном примере общие вертексы отсутствуют и незачто зацепиться.


2016#01#08 14x02x16
Так вариант отсортировать используя additional_sorted_edge_list я уже вижу.
Так что остаётся только первая часть вопроса можно ли посортировать используя только один список sorted_edge_list.

Ты так вопросы задаешь, что ничего не понятно, чего хочешь-то. Но кажется, что ответ на вопрос - нет, нельзя. Ведь сам посуди, как вершин 4 относится к вершине 23. Они вообще в разных частях меша находятся. Конечно, можно рассуждать, дескать, она ближе, чем вершина 122. Но это только на этой картинке. А ведь хочется, наверное, когда набор ребер вообще произвольный и они по всякому разбросаны по мешу.

Сегодня обнаружил что PolygonMesh.Set() перестраивает все индексы компонент обьекта.
То-есть кластеры наполненные до применения этого оператора становятся не актуальными.
Как-то можно кластеры актуализировать ?!
Или единственный вариант сохранить все индексы и кластеры это вместо PolygonMesh.Set() использовать Point.PutPosition().

Метод Point.PutPosition() как выяснилось не работает. Но работает GetPositionArray, PutPositionArray :

Таким образом геометрия не перестраивает индексы всех компонент и
можно продолжить использовать кластеры и посчитанные масcивы.
Др словами вы не теряете "селекты" начальные или финальные как вариант.

Но вроде как у такого механизма есть какие-то проблемы с непофриженой геометрией. Какие пока не понял.

:umnik2:
Получается OGL отрисовка НОВЫХ компонент это здорово и быстро
но как только возникает необходимость рисовать OGL для subdivide lvl > 0
- FAIL.
Геометрии то новой ещё нет. Есть только предположительные OGL координаты.
Crease лвл не возмёшь, Соседей так просто не возмёшь, Бордер статус не возмёшь.

Вот сижу на распутье или попытаться подкорректировать subdivide модуль что бы он
отталкивался только от координат а не от геометрии (но опять же как брать соседей
и статусы) или перелопачивать всё и всётаки добавлять геометрию и давать
пользователю её таскать а не OGL.

Или !!!
Попробовать 3й вриант.
Рассчитывать не напрямую Catmul координаты новых компонент которые пока
представленны в виде OGL а рассчитывать координаты компонент "на которые" будут
строится OGL компоненты и вносить корректировку в расчётные формулы координат новых OGL компонент.
Но опять же как получить центральную Catmul координату нового OGL ейджа которого ещё не существует на геометрии.
Двух соседних фейсов то нет пока ещё. Значит Face-Point построить так просто не получится.
Но у нас есть start\end Catmull координаты ейджа а значит если взять
противолжащие координаты вертов у нас фактически есть 4 верта составляющие
полигон (квад в данном случае).
А если это n-gon.

А нет такой вариант тоже не приемлем т.к. пока геометрия не будет добавлена
остальная геометрия не будет пересчитана в Catmul. То-есть даже если мы будем
правильно отрисовывать OGL координаты при добавлении геометрии они всёравно
пересчитаются и не будут соответствовать тому что видел пользователь.

Тогда вариант один. Добавлять геометрию =\

:read:
ну вобщем получается или через OGL быстро рисовать новые компоненты даже на тяжолой геометри
НО не отрисовывать правильно при subdivide.lvl > 0

или

добавлять сразу на геометрию компоненты, отрисовывать всё правильно при subdivide.lvl > 0
НО на тяжолой геометрии ооооочень медленно

https://vimeo.com/groups/1792/videos/50290984
Если у кого-то есть пример из этого видео по Fabric Engine или кто-то знает как
можно использовать фабрик из C++ плагинов ксюхи поделитесь плз информацией.
Любой. Все старые линки убили.

Если вдруг кто-нибудь это видит )))
Люди ))) Как удалять элементы из списка CValueArray ?
Удалят так что бы не оставалось пустышек в маcсиве (как в случае с .Clear()).
И ещё в догонку вопрос.

Как можно расширить функционал исходного CValueArray не внося изменения в
header файл отвечающих за этот класс в XSI ?
Friend классы и friend функции требуют обьявления их френдами внутри исх класса (то-есть в исходном хедере).
Наследующий класс от CValueArray потребуют во всем плагине исправление типа массивов на этот класс, что тоже не удобно.

А оставлять просто функцию и для каждого инстанса её дёргать не красиво как-то.

Вот, сошлась у меня вроде картина в голове. Я разбираюсь с проекцией векторов.
Задача была такая: есть вертексы ейджа лежащего между двух соседних ейджей. Нужно определенить направления смещения вертексов в соответствии с вектором смещения мыши.
(IMG:http://i.imgur.com/y90Cg8k.png)
Проеция векторов через dot_product напрямую задействована в такой задачке. Если коротко то мы строим по screen координатам drug_vector ( (cur_x, cur-y) - (start_x, start_y) )
Далее строим вектора src_ops1 (сосед слева ), src_ops2 (сосед справа). Данные вектора построены по world координатам. Теперь уплощаем эти вектора ( приводим к screen координатам) с помошью проекции на view плейн (или через проекционную матрицу). Далее через dot_prod проецируем на плоские вектора src_ops1 и src_ops2 наш drag_vector и берём то направление вектор проекции которого больше по длинне. При этом если посмотреть на ксюшино SDK то методы WorldToView есть только у ToolContext'a. У OperatorContext'a их нет. Я так понимаю что это обьясняется логической связью drag_vector'a и проекционной матрицы, которые напрямую зависят от текущего расположения камеры через которую пользователь смотрит на обьект. Поэтому если мы хотим аперировать таким механизмом проецирования векторов В ОПЕРАТОРЕ то нам нужно брать и drag_vector и проекционную матрицу ещё в ToolContext'e и передавать и в оператор в качестве "констант". В противном случае (еслии руками написать механизм получения проекции и конвертирования координт вертексов WorldToView в теле оператора) у нас при любом изменении параметров оператора будет подбираться текущее расположение камеры вьюпорта и результат будет неадекватный.
В ту сторону мысль идёт или нет ?

Кто-нибудь знает как назначить кастомный функционал на Mouse Wheel (на вращение скрола) ?

Я как то спрашивал, стандартными функциями нельзя

:) покажи как

я не знаю :)
Ребята говорили что через программу которая перехватывает клавиши это можно сделать, но я не стал заморачеватся

не очень хорошее решение.
можно тогда и через WIN API попытаться дотянутся до колеса.

2016#06#22 05x55x43
вопрос снят. Нужны индексы полинод а не вертушек.

Сегодня вопрос по построению геометрии.

#VBScript

Данный код даёт вот такой результат:
(IMG:http://i.imgur.com/wZr0oGg.png)

Предполагалось что новый вертекс (7й) встанет в центр правого полигона
но вместо этого он упорно встаёт в центр левого полигона.

Я с 2х ночи сижу не могу понять ПОЧЕМУ ?
И как нужно задать AddPointInteriorToPolygon что бы он встал в центр правого полигона.