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

Пока не понятно как правильно взять индексы полиноды

зел - индексы вертексов
син - индексы полинод
* т.к. индексы полинод накладываются др на друга при отображении во вьюпорте (косяк ICE)
я ограничил их вывод Range'м с 4й по 9ю

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

Теперь по логике что бы получить вертекс в центре правого полигона (ну или хотябы на правой стороне нужно использовать такую строку

AddPointInteriorToPolygon "grid.polymsh.addedgeop", 1, 4, 5, 6, 0, 0, 0

то-есть использовать ноды 4,5,6
но результат точно такой же кривой как и в примере выше


Вот так выглядит реализация на C++
В ней докинут фильтр по интересующему нас полигону
Но в результате та же шляпа - вертекс уезжает в глубь геометрии.
(IMG:http://i.imgur.com/nPIx7VN.png)


Складывается ощущение что нужно указывать и не индексы полинод.

Слушай, ты так пишешь, что непонятно, это ты просто так, типа випа ведешь, или все таки совет какой нужен. Если совет, то давай вопрос, или сформулируй, что непонятно и чего хочется достичь.

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

Совет конечно же :)
Я уперся в команду AddPointInteriorToPolygon().
Я поспрашивал в гугл группе и частично ситуация прояснилась.
Стало понятно что в качестве аргументов эта команда хочет получить

Так вот проблема заключается в том что барицентрические веса для треугольников обычно в сумме не превышают единицу.
Но при использовании инструмента "Add Edge Tool" (который какраз и формирует значения для AddPointInteriorToPolygon()) мы видим что барицентрические веса выходят за пределы этого значения.

Вот тестовый Grid:

Попробуй используя "Add Edge Tool" добавить вертекс в эту точку:
http://i.imgur.com/PnjDmdX.png
и посмотри на барицентрические значения в логе. Там будет что то в духе:

Matt Lind, в группе так же заметил что барицентрические координаты превышают в сумме единицу только при использовании второго, третьего и т.д. треугольников полигона (то-есть номеров вертексов 023, 034 и т.д.).
Для первого треугольника барицентрические веса всегда указываются в пределах единицы.

Так вот задача состоит в том что бы понять почему барицентрические веса выходят за пределы единицы и как их правильно рассчитать в таком случае. Потому что все
методы которые есть в XSI для получения весов предназначены для треугольников и возвращают барицентрические веса правильно (то-есть в сумме они не превышают 1у).

У меня есть предположение что барицентрические веса в XSI для этой команды рассчитываются не для треугольника, а для всего полигона.
Хотя с другой стороны это никак не обьясняет того что они превышают в сумме единицу =\

Барицентрические координаты бывают только для треугольников. Для многоугольных полигонов такой объект не может быть корректно определен, поэтому и говорить о нем не стоит. Работа может идти только с треугольниками. Еще вот твой фрагмент лога.

Здесь сумма весов не превосходит 1-цы. Так что нормальные веса.

Ну и конечно дам неоригинальный совет: не надо использовать корявую, кое-как запрограммированную скорее всего для своих внутренних нужд, функцию AddPointInteriorToPolygon(). Используй стандартные методы для работы с топологией Get() и Set() и контролируй все индексы сам. Тогда и проблем с непониманием как что работает не будет.

действительно степень же отрицательная =_= Странно что Matt этого не заметил.
E-02
Спасибо.

Совет использовать Get Set совет неплохой. Но как писал ранее, я уже сталкивался с этим механизмом и он в произвольном порядке меняет индексы всех компонент в момент применения PolygonMesh.Set(). А мне нужно иметь возможность после изменения геометрии вернуть пользователю его селекты.
Поэтому я предпочитаю только двигать точки через GetPositionArray, PutPositionArray.

Хотя ты уже 3й человек который мне говорит использовать Get Set ... может я как-то неправильно добавлял компоненты.
У тебя часом нет примера в котором показана логика добавления новых вертексов и ейджей ?
Логика в том смысле что не просто на обум добавить полигону номер N вертекс
номер V. А допустим добавить вертекс так же как в этом примере (внутрь полигона, в эту область попутно создавая 2 ейджа).
http://imgur.com/PnjDmdX

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

От этого механизма я отказался месяца 4 назад поэтому сходу выдать конкретику не смогу. Но
насколько я помню не все индексы вертексов меняются. То-есть вполне возможно что 1й
вертекс останется там же но нет киках гарантий что не поменяется 2й или 10й и т.д.
Давай отложим до вторника конкретику относительно Get Set.

Частично вспомнил в чём проблема с гет сет была. Я добавлял на геометрию новые ейджи череез SplitEdge затем применял Get Set что бы их перемещать. Так вот в момент создания новых ейджей старые компоненты(те что не затронуты омандой SplitEdge) не меняют свои индексы. Но стоит применть PolygonMesh.Set() и все индексы перераспредиляются. Вот в чём была проблема этого метода. А при использовании GetPositionArray, PutPositionArray индексы не пересчитываются.

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

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

Всё зависит от того насколько это оправдано наверно. Например твоё предложение искать вертексы по координатам. Допустим у меня куб на 200 000 полигонов. Я выбираю ейджлуп складываю в массив и после Get Set мне нужно этот масив восстановить а это значит что для каждого элемента мне придётся прочёсывать длиннющий масив вертексов. Это будет затратно.

Идея использовать Сет единожды при изменении геометрии она правильная. Но требует пересчёта масивов по координатам. И всех связанных с этим масивом масивов.
Если есть команда которая позволит не прибегать к этим пересчётам я бы попробовал использовать её. Нада только понять как её использовать ... стабильно )))

В самом SDK кстати рекомендуют для работы с топологией использовать Обьектную Модель (питон vbs js другими словами) а не C++.
В большинстве примеров идущих вместе с XSI SDK используются вызовы имено команд из Обьектной Модели.

Единственное что действительно неприятно в таком подходе это то что в modelling history вместо одного оператора падает 2 : SpliEdge, AddEdge. То-есть Undo будет с гемороем.

Вобщем совместными усилиями мы команду победили.
Ещё одним важным моментом который не сильно освещён в SDK является то что
PolygonMesh инстанс мы должны использовать по состоянию на момент ДО применения AddEdge.
Веса именно от этих треугольников требуются в AddPointInteriorToPolygon().
Если мы возмём PolygonMesh инстанс после применения AddEdge() то будем иметь
дело с другими полигонами и как следствие другими весами.

(IMG:http://i.imgur.com/0NYwiBh.png)

Привет :)
Нужен небольшой сапорт по след вопросу:
https://groups.google.com/forum/#!topic...ist/_-zXdryNh2c

Суть проблемы в двух словах:
в случае если вы находитесь в компонентном режиме но не выбрали ни одной компоненты XSI возвращается пустой инстанс XSI::Selection.

Другими словами:
нужно получить список активных обьектов при условии что ни один из их компонент не выбран ещё.

По ссылке имеется вариант решения для python и js.
Я пытаюсь найти вариант решения для C+_+.

2016#08#05 11x32x49 SOLVED

Вопрос прикладного характера:
в майке можно протолкнуть кастомный курсор для своего инструмента =\
http://around-the-corner.typepad.com/adn/2...or-in-maya.html

В XSI к сожалению такого класса не предусмотренно.
Но мы всегда можем назначить для нашего инструмента курсор:
in_ctxt.SetCursor( siDotCursor);
И через OGL выводить небольшую текстурку с курсором рядом с положением мыши.
Или можем вывести небольшой текст там же рядом с координатой курсора:
n_ctxt.DrawTextString( l_Str );
Или небольшой OGL'ный примитив.

Проблема в том что для этого нам потребуется получать актуальные координаты мыши в колбкеках MouseMove инструмента.
Я не знаю деталей механизма отображения нативного курсора в XSI, но варианты описанные выше стабильно отстают от нее.

Другими словами частота обновления позиции нативного курсора выше чем частота
срабатывания колбека MouseMove поэтому кастомный курсор перемещается не так апперативно.

Отсюда вопрос: есть ли какие-то способы боле оперативной реализации или возможность протолкнуть кастомный курсор в XSI.

Давно не пользовался "коллективным сознанием" :)
Вот такая появилась ситуация:
C++
Я написал CustomOperator подоткнул в него вот таким образом геометрию кластер и UVхи:
http://take.ms/VZUAk
http://take.ms/bkaXi

Сам оператор процесит геометрию через PolygonMesh.Get() и PolygonMesh.Set()
и добавляет на геометрию в тестовом случае один дополнительный ейдж.
Таким образом в результате работы Оператора подразумевается что наш кластер
увеличится на 2 вертекса ( мы же 1н ейдж добавили ).
Но кластер не увеличивается не смотря на то что создавался он по пустому масиву
компонент (что гарантирует что данный кластер будет охватывать все компоненты геометрии и в случае увеличения компонент будет их подтягивать в себя).
http://take.ms/vEqpu

Но если мы зафризим моделинг стек то кластер получает все новые компоненты и увеличивается на 2 вертекса.
Это в случае с мои кастомным оператором.

В случае с нативными Операторами (в данном случае применятся SplitEdgeOp) после применения кластеры сразу получают новые компоненты.
http://take.ms/e6NNA

Вопрос что я делаю не так ?!
Проблема увеличения кластера напрямую связана с UVхами потому что простое
использование PolygonMesh.Get() PolygonMesh.Set() превращает их в труху )))

ты всё делаешь так. но... к сожалению эта хрень не работает в кастом операторе. Бился долго и плюнул на это дело. Решил проблему через ж-опу, тем, что присваивал текстурные координаты через АЙС. Почему то, когда ренеришь ЮВишки в айсе в аналогичных ситуациях, ЮВ-кластер обновляется норм.
У меня была целая схема, в которой я в кастом операторе делал все вычисления, но не удалял данные ,а сохранял всё в памяти. Потом адрес структуры (ссылку) я передавал в айс НОДУ. Ана считывала данные из памяти и присваивала объекту координаты. Метод работал вполне себе сносно.