Messages posted by: Golem

по моему все отклонились от темы.
насколько я понял, savva пытается во AS3-проекте использовать библиотеки flex-а.
потому что не знает как по другому сделать кнопку.
у него естественно это не получается.
а вручную он кнопку сделать не может (читай "не умеет и не хочет потратить время на научиться").
я сам еще не пробовал, но вроде как в AS3 mx-библиотеки использовать не получится. слишком много надо тянуть за собой.
хотя кажется где-то встречал статью на эту тему.

так вот, к сути темы:
поиском находится много готовых хмл-ориентированных менюх, достаточно выбрать на вкус и цвет.

PS. savva, будьте добры, растолкуйте связь поста с альтернативой? может мы упускаем какой-то важный момент, который кардинально изменит стиль и содержание ответов?

я всё-таки так и не понял, имеется связь у темы поста с альтернативой?...

гугляндекс плюс "AS3 создание собственной кнопки"... как-то так.. времени посмотреть пару уроков займет немного..
или синхронно использовать гугляндекс во взаимодействии с "as3 исходники меню xml"..
а если уж совсем уж никак - зайти например на allday . ru, и там в разделе веб-дизайн найти много разных готовых меню на флэше с XML.

в чем проблема использовать кнопку из той же minimalcomps, если не нравится стандартная?
и какая связь поста с веткой A3D8 ?

тут кстати не всё так просто, как мне кажется.. мяч состоит не из одной вершины, а значит при расчете того, насколько вершина А переместится, если перемещать вершину Б, нужно учитывать влияние на А еще и перемещение вершины Ц.

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

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

добавил:
а, заглянул, нет такого свойства....

makc wrote:Вот тут сделано аккуратнее и длины сохраняются лучше: http://wonderfl.net/c/oHaY

у меня открылась физика с определением коллизий... пока не улавливаю прямой связи...

Aks wrote:А как в меше с множеством вершин выбрать для любой вершины окружающие ее вершины?

по фэйсам, в которые входит эта вершина, не?

ага, значит все таки есть некий "коэфф. сглаживания"?! может этот же коэффициент будет определять изменение расстояний между вершинами?

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

PS.
добавлю еще один момент - что там все-таки с ребрами и расстояниями между соседними вершинами? мы тянем вверх паука или паутину?

При этом координаты остальных вершин не изменяются, но меняются длины ребер. Как сохранить длины ребер и пропорционально изменять координаты соседних вершин?

вопрос 1) у вас эти 6 вершин соединены только с центральной или между собой тоже?
вопрос 2) если соединены между собой - длины этих ребер тоже не должны меняться?
если не должны - то ничего толкового не выйдет. представьте себе пирамиду, которую вы тянете за вершину. если длины ребер не будут меняться - вся пирамида как есть пойдет за вершиной.
что-то мне подсказывает, что вам на самом деле не нужно сохранение длин ребер, а нужно просто смещение соседних вершин на расстояние, обратно пропорциональное удалению от вытягиваемой вершины.

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

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

Я примерно так и делал, правда еще на пятой версии.
тут кстати есть два варианта:
1) запечь текстуры.
2) рисовать контуры шэйпами.

в 7-ой версии мувики уже вроде как нельзя использвоать напрямую. только через отрисовку в текстуру.
или я что-то пропустил?

вопрос такой:
есть ли смысл (в плане поддержания производительности на приемлемом уровне) делать динамическое освещение на сцене с большим количеством объектов (10 тыс полигонов, объекты простой формы) или лучше продолжать юзать запеченные текстуры?
понятно что с текстурами будет бегать быстрее, но приходится много колдовать с их подготовкой.
может есть вариант построения динамического освещения с минимальным падением ФПС ?

вот уже и о 7.7 информация проскальзывает (:
а когда оно выйдет? сколько это немного?