PalSan

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

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

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

либо как вариант возможность ставить несколько галочек в чекбоксах активировав режим выбора всех элементов (чекбоксы вместо точек).возможно это будет оптимальный вариант.

и так и не так . кисть может вертексы двигать. а так любой элемент - фэйс-ребро или вертекс тот же без предварительного выделения.подсвечивается активный элемент. смотри пример. это с геометрией ,но суть та же. http://screencast.com/t/uIW76xhdop9G

+5

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

3.1.07 XP 32 DX симметрия неправильно работает. пробовал на creature из стандартного набора примеров.

и еще несколько штук) 1) чтобы сшить указываем ребро одного куска. подсвечивается цветом. одновременно подсвечивается цветом также кусок для которого это ребро является общим. выбираем кусок который надо переместить ближе для сшивания(или нажимаем команду находясь мышью просто над ним,без предварительного выделения), кликаем на команду(или хоткей)кусок перемещается ребро к ребру с родительскому.кликаем "сшить"- куски сшиваются. 2)Shift+A центрировать кусок по окну юви. 3)A - все куси в пределах окна. 4) Хайд анселекшен,хайд селекшен,анхайд все. вот ну вроде все)

и еще забыл сказать. внутренний радиус/спад чтобы видно было наглядно зону воздействия кисти.

Vista 32 DX and XP 32 DX ок! Andrew, please, read here the list of specifications and additions. Very important!

Андрей,несколько пожеланий по улучшению юви инструментария. сначала хочу сказать,что ты сделал ОГРомный шаг в создании проф.инструментов для юви.СПАСИБО! уточнения,изменения,совершенствование инстументария и рабочего процесса с юви в коате): 1)интерактивное выделение нескольких вершин,ребер,полигонов удерживая мыш зажатой и просто закрашивая нужные элементы. ускоряет рабочий процесс. 2) окно юви. возможность пропорционально масштабировать окно, сохраняя пропорции окна. 3) возможность масштабировать юви в этом окне. когда работаешь с небольшими частями очень сложно разглядеть маленькие элементы. 4) автоматическая подгонка масштаба развертки. проще говоря, чтобы чекер везде был одинакового размера. сейчас при масштабировании одного куска видно влияние на другие части, значит это также можно реализовать. пак сейчас распределяет куски по юви. но масштаб чекера разный. 5) возможность разрезать и сшивать куски на части. часто сложные куски проще разрезать пополам развернуть и потом сшить. работаешь с меньшим кол-вом элементов.это очень удобно. 6) возможность указывать ребро жесткости относительно которого можно производить разворот. например на голове это будет середина. таким образом,центральное ребро будет прямым и относительно него сетка будет строится. 7 ) возможность по двойному клику выделять лупы и по двойному средней ринги. скорость даст, что всегда хорошо! 8 ) возможность закреплять отдельные вертексы. чтобы также при разворачивании кусок выравнивался относительно них. по аналогии с ребром жесткости. 9 ) возможность интерактивно скейлить луп ребер. сейчас они какбы начинают двигаться в одну координату по оси и потом в разные разъезжаются. опять же скорость +удобство. 10) кисть. великолепная штука.добавить к тому ,что есть также возможность раздвигать полигоны и сжимать. это будет одной из самых сильных фич!!! сейчас не понял пока, кисть как бы перераспределяет полигоны.т.е.сглаживает.( с шифтом иммею ввиду, а так просто можно двигать области) 11) хоткеи на режимы переключения ребер,вертексов,полигонов и островков. 12) закреплять выделенные полигоны(аналогично вертексам.см.выше) чтобы при развороте они оставались неподвижными. 13) куски развертки сделать ,чтобы не вылезали за пределы окна юви. сейчас они вылезают,возможно сделано,чтобы компенсировать некоторый недостаток места. но уже сейчас по программе UVLayout нанесен серьезный апперкот) чуть чуть работы еще и будет нокаут)))) Андрей,респект! Коат вперед! п.с. развернул голову,опробовал весь инструментарий.пока полет нормальный)

http://screencast.com/t/ycCl3NBg http://screencast.com/t/21wxDf219 пара багов. при применении пака в юви модуле. и при переключении во вкладку рендер, часто панель свойств пустая. можно восстановить лайаут, но потом все-равно периодически так случается. п.с. возможно юви будет уже неактуально)

I would like to express my opinion concerning developing and program testing. I agree with Andrey, that the beta testing command cannot see, pick up and find all bugs. As regarding open testing it works much more effectively. However I agree and with Taros that many bugs are casually. As repeat in other versions. Meanwhile I would like to offer you such a concept of development of a package. For the certain period of time, the prior direction is chosen. For example, UV Tool is developed thoroughly. The developer's toolkit is improved. The work process is grinded. All bugs are caught as far as it is possible. There is a real "brain storm" of some active users of the program. Now there is a ready module. Now we can move to the next direction. For example to the module rendering, etc. Thus, we receive a stable, strong and functional toolkit with the minimum quantity of bugs after each completed period. How to choose a prior direction? whether it is a public opinion poll or point professional users' point of view, it is the other subject. And I think, evrything can be solved easily. There is a situation now, that there are a lot of utilities and powerful tools in the program, there are a lot of changes in all modules, which occur permanently and a lot of raw and insufficiently functional tools and a lot of bugs. Andrew, quickly corrects them it is necessary to note, but I think that also it would facilitate process and to it. thank you for attention) Я хотел бы высказаться по теме разработки и тестирования программы. Согласен с Андреем, что команда бета тестеров не может увидеть,выловить,найти все баги. и открытое тестирование в этом смысле работает гораздо эффективнее. Однако,согласен и с Taros, что многие баги нахожятся случайно.и повторяются в следующих версиях. Между тем хотел бы предложить вот такую концепцию развития пакета. На определенный временной период выбирается приоритетное направление. Допустим UV Tool ,разрабатывается,разбирается "по косточкам". вылавливаются все баги, насколько это возможно. совершенствуется инструментарий. шлифуется рабочий процесс. устраивается настоящий "мозговой штурм" активными пользователями программы. Все есть готовый модуль. После этого переход к следующему направлению. Например Render модулю и т.п. Таким образом, после каждого завершеного периода, мы получаем стабильный,сильный, функциональный инструментарий c минимальным кол-вом багов. Как выбирать приоритетное направление, опрос ли это, точка зрения профессиональных пользователей,это уже другой вопрос и тут ,я думаю, все можно решить достаточно просто. На текущий момент же складывается ситуация ,что в программе огромное кол-во полезностей и мощных инстументов,изменения во всех модулях постоянно происходят и много сыроватых и недостаточно функциональных инструментов.и много багов. Андрей, быстро правит их надо отметить,но думаю, что также это бы облегчило процесс и ему. спасибо за внимание)

имен вебмастера и Андрея вообще не видно. белое на светло-голубом)

+1. I like a dark palette of colors

Thank you for link

кхе-кхе))))хотел помочь)

fantazer в русской части форума есть мануал на великом и могучем. даст ответы на многие вопросы. или последней редакции мануал идущий с программой на английском языке.

I look forward

''Started coding ABF++. I am not sure that it will be done at once, but need to spend some time for this at least to touch this topic.'' отличная новость! очень давно этого ждал и вот вроде двинулось дело)

-Shadow- красавчик

пасиб