skew через матрицы?

[nuran]

Кстати, я сейчас занимаюсь построением очень приличного для flash 3d движка. Занимаюсь этим уже примерно 6 месяцев, и думаю он будет самым навороченным из всех мной виденных (а видел я много, я вас уверяю).

Что там будет реализовано (примерно):
Камеры (Free & Target), движение камер по кривым, NURBS, системы частиц, различные примитивы (штук 30), несколько разных источников освещения, приличный класс для работы с цветом, возможность проецирования в несколько (на сколько хватит мощности PC) ViewPort'ов ... много всего, в том числе все возможные текстурирования, градиентные заливки, сортировки и пр., online интерфейс с возможностью сохранять свои сцены на сервере и потом загружать их, плагин для 3d max'a, собственный формат файлов.

Так что вам товарищи до меня, как до Африки пешком.

[nuran]

Многое, из того, что я перечислил - уже разработано ~ 40 классов.

[Dindin]

Так что вам товарищи до меня, как до Африки пешком.

Ещё бы, ведь ты там, судя по всему, велосипед изобредаешь =)

ЗЫ насчёт "изобредаешь" - я опечатался, но потом понял, что очень в тему

[Nox Noctis]

Оригинал написал(а) nuran
Так что вам товарищи до меня, как до Африки пешком.

малиновые штаны! четыре раза ку!

[DEAFFF]

Сижу тут читаю. Че то мы этошли от темы.
А нам всего лишь нужна была ваша помощь. Сделать skew более быстрее. Хочу сказать такую вещь. Сделать skew с помощью матрицы преобразований - реально. И это будет самый быстрый способ. Я во всем поддерживаю моего коллегу MihailV.
Простой вопрос - анимация skew почему то возможна спомощью простого инструмента во Flash (т.е. когда делаешь tween анимацию) , а программно как это делается, неужели там проходят все операции - _rotation+_xscale+_yscale?
Простой ответ - матрица преобразований. И не надо нам парить!!!!

По поводу nurana хочу сказать:
Ну зашел я на твои ссылочки - и неувидел ничего нового или навороченного. Это все очень просто делается. А вот натянуть растровую текстуру ты как то не подумал. А это и есть основа 3D во Flash т.к. без этого далеко не уедешь.

[Dindin]

Если вы хотели сделать Skew быстрее - вам указали ссылку на готовый класс. Но вы же, господа, начали низа что ни про что лажать совершенно незнакомых вам людей. Кроме того, лажать совершенно безосновательно. Меня лично больше всего задело именно это.

[D12]

может я несовсем вклинился в тему (
тут у меня есть несколько примерчиков глумления над фотками ну или текстурами как вам будет удобно )

[styx]

Sorry что не совсем в тему... Но мне тоже надо Есть много вставленных друг в друга клипов. У каждого свои __scale. Плеер ведь не обрабатывает их как цепочку растров - значит, он знает scale каждого относительно stage. И я хочу знать! Ещё раз сорри за вторжение - но, как мне кажется, это действительно ОДНА тема.

[Елё]

Вообще scale разный бываетю Бывает _xscale, а бывает и _yscale
Но что то средние можно получить при переводе
localToGlobal(p1) двух точек + отношение растояний между исходнями и результатом...

[styx]

Вообще scale разный бываетю Бывает _xscale, а бывает и _yscale

Угу. Это я имел в виду под вторым _. А с остальным проблемы.

Основная: localToGlobal не выдаёт ничего разумного (отличного от 0) до тех пор, пока не нарисует экран... увы. Я на неё, собственно, и рассчитывал.
Может быть, я зря воду мучу - информация по шестёрке; семёрку пока не пробовал. Но - в момент создания клипа localToGlobal не работает... О, мысль возникла - к тому моменту _parent ведь создан - так можно использовать его координаты... Надо подумать .

Вообще мне хотелось бы знать размер клипа - потому как идея в том, что строится фрактальная структура (в каждый ролик вложено несколько экземпляров его же со своими массштабами/поворотами) - чтобы не продолжать вложение до бесконечности. То есть - хочется знать - где я - что со мной (каков реальный размер каждого клипа на stage). При этом, разумеется, в каждом ролике минимум ДВА инстанса (о, ужас, что я делаю с русским языком!) - и в результате появляются ТЫСЯЧИ объектов - расчёт математики для которых... сами понимаете как сказывается на производительности.

Но это всё пол-беды.

Дальше это всё анимируется. Соответственно размер каждого клипа меняется за счёт изменения масштаба родительского клипа - и если размер его становится выше предела детализации, то приходится прорисовывать его дочерние элементы...И считать это для всех 2^15 объектов... Невозможно.

Глупый вопрос, наверно. Но, блин, сам-то флэш всю эту тучу объектов просчитывает без тормозов!!! А мне нужна 1 копейка из этих расчётов, чтобы убрать 95% своей математики.

Any ideas?

P.S.:
Прошу прощения за отсутствие исходников и прочих примеров. Очень не хочу их доработки . Хочу оригинальную идею. Благо время, данное на разработку проекта, позволяет.