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

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

Прости, не совсем понятно - чего ты хочешь таким образом добиться?

Пытаюсь совместно с Deaf'ом (он свои 3D исходники кидал, наверное видели) сделать быстрый и шустрый 3D движок с "динамическим" текстурированием (когда положение текстуры можно задать с помошью координат для каждой вершины полигона). Так вот все наши исходники достаточно громоздки (хотя добились уже хороших результатов), а вся проблема связано в том, что приходится делать кучу трансформаций. К примеру чтобы реализовать программно Skew приходиться делать _rotation + _xscale + _yscale и кучу всего... Хотя движок флэш плеера все равно все преобразования над клипом делает с помощью всего лишь одной матрицы трансформаций (как в программном градиенте...). Как бы изменить p-код SWFа, чтобы нужные параметры передавать непосредственно в матрицу для трансформации клипа??? Может это все таки реально??? Это сократит кучу вычислений и кучу отдельных трансформаций!!! Пожалуйста подскажите!!!

http://www.andre-michelle.com/

DistortImage class

можно поподробнее : откуда информация

Ну иначе было бы странно... Врядли можно себе представить плэйер который каждую точку отдельно сначала поворачивает, потом "скюит", а потом смещает

Наверняка они внутрях матрицами пользуются
И жаль что ничего о внешнем интерфейсе к этим матрицам не известно

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

в любом случае интересно чем вызвано такое категорическое высказывание

Господа, а Вы в курсе, что плеер просто демонстрирует последовательность имэджей, а трансформирует в эту последовательность компилятор?

Посмотрел ссылку http://www.andre-michelle.com/
(которую дали выше), посмотрел внутренности - почти один в один как ув наших исходниках, тока через классы.... И тока не так шустро как у нас! :) :) :)
В общем этот Андре ниче нового и не придумал, и матрицы он не юзает :( А я надеялся что он сделал реальный прорыв во флэш :)
Для Dindin'a по поводу фразы "Господа, а Вы в курсе, что плеер просто демонстрирует последовательность имэджей, а трансформирует в эту последовательность компилятор?" - ага, особенно если этой последовательности вообще нет при использовании читого экшена!!! (и даже если у тебя обычная анимация, не через экшн, то нифига это не последовательность имэджей, а просто компилятор всю анимацию (все твины и т.п.) разбивает на фрэймы, и для каждого клипа в каждом фрейме запоминаются его трансформации (scale, rotation и т.п.)!

У нас - это у кого? И что Вы понимаете под словом "шустро", глубокоуважаемый изобретатель велосипеда?
Чувствуется, что для человека прорыв в любой области навсегда связан с матрицами. А может Вы просто поклонник Нео? Или напротив Агента Смита?
Польщён, что мне оказывается подобное внимание, и могу только порекомендовать сцылочку. Итак, спецификация формата swf от Macromedia, PDF

ЗЫ И не морочьте нам голову.

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

1) по теме посоветовали. Просто ты этого не понял.
2) какими критериями меряется загрузка системы? (с учётом того, что грузит систему не скрипт, а виртуальная машина). Кроме того, хотелось бы посмотреть на Ваш расчудесный код :)
3)Что именно вызывает у Вас добрую улыбку? С чем именно Вы не согласны? С тем, что при компиляции мувиклипа все графические изображения (в том числе и анимация) преобразовываются в последовательность кадров? В таком случае - перечитайте спецификацию еще раз.

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

вот исходник MixailV. Мне, кстати, дружбан скнул этот линк, как качественной тридешки во флеше... и я с ним согласен.

наш ответ Чемберлену ;)

:D:D За что так животинку-то?

Дело в том, г-н MixailV не осознаёт, как мне кажется, чёткой разницы между объектно-ориентированным и процедурным программированием - это раз. И не понимает,разницы между конечным продуктом и кодом вообще :)

to Dindin: не навижу спорить, но так же немогу равнодушно все это читать - "как мне кажется, чёткой разницы между объектно-ориентированным и процедурным программированием" - может быть, но исходник, который вы видели (уже давно не похож на то, что есть счас..., хотя о чем речь, я же просто попонтиться решил, может у меня за душой и нет ничего ;) )
"И не понимает,разницы между конечным продуктом и кодом вообще" - может я и не прав, но конечный продукт, в особенности его качество, ОЧЕНЬ сильно зависит от его изначальных составляющих (частности даже простой 3D движок сильно зависит от реализации текстурированного полигона)

to Silin: ответ хорош конечно, но когда уже есть образец, в котором представлена реально работающая идея - http://flasher.ru/src/getfile_3226/ (от моего коллего DEAF'а) - то почему бы её не попользовать, не правдали принцип (см. исходники) ну очень похож :) , хотя бывает так, что одинаковые задачи приводят к похожим решениям...

Всем спасибо за здоровую критику, очень ценю, это всегда полезно! Будем с DEAF'ом как говориться "вариться в собственном соку" :) :)

Исходник - в студию...
Кто бы спорил, но покажите нам, пожалуйста, КОНЕЧНЫЙ ПРОДУКТ, а не его составляющие.
И, собственно говоря, принципиально нового я в вашем исходнике не увидел ничего:
1) матричная трансформация объекта - стандарт
2) алгоритм определения видимости граней не реализован - всё вручную
3) новых решений в текстурировании здесь тоже нет.
Если уж есть такое настойчивое желание "повариться в собственном соку" зачем же было постить на форум?

Ха Ха

ХиХиХи, бедный вася :D

Мой ответ :D
http://nuran.org/lab/flash/0010.htm
http://nuran.org/lab/flash/0011.htm
http://nuran.org/lab/flash/0012.htm
http://nuran.org/lab/flash/0013.htm
http://nuran.org/lab/flash/0020.htm
http://nuran.org/lab/flash/0031.htm
http://nuran.org/lab/flash/0032.htm

http://nuran.org/lab/flash/0007.htm

далекоооо не полный список ...

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

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

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

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

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

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

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

Вот и я
 

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

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

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

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

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

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

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

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

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

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

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

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

Any ideas?

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

Я конечно вообще не в тему, но хочу спросить nuran'а, как ты реализовал определение видимости граней? В смысле видимости юзером? Просто пытаюсь сделать простенький движок...

to Dindin: лана, пободаемся еще раз :) В ссылке на готовый класс (image distortion) у чела все сделано вот так (основа, нет смысла весь код приводить):
v2.update = function () {
var v5 = Math.atan2;
var v7 = Math.sqrt;
var v12;
var v11;
var v9;
var v3;
var v6;
var v2;
var v4;
var v10;
var v13;
var v8;
this._x = this.p0.sx;
v11 = this._x;
v3 = this.p1.sx - v11;
this._y = this.p0.sy;
v9 = this._y;
v6 = this.p1.sy - v9;
v10 = v5(v6, v3);
v2 = this.p2.sx - v11;
v4 = this.p2.sy - v9;
v13 = v5(v4, v2);
v8 = (v10 - v13) / 2;
this._rotation = 57.29577951308232 * (-v8 + v10);
this._yscale = 100 * Math.tan(v8);
v12 = 70.71067811865474 / Math.cos(v8);
this.innerClip._xscale = (v7(v2 * v2 + v4 * v4) / v12) * this.t_width;
this.innerClip._yscale = (v7(v3 * v3 + v6 * v6) / v12) * this.t_height;
};

А теперь найди десять отличий (старый исходник DEAF'а):
x01 = x0-x1;
y01 = y0-y1;
x21 = x2-x1;
y21 = y2-y1;
alfa = Math.atan2(y01, x01)*180/Math.PI;
beta = Math.atan2(y21, x21)*180/Math.PI;
gama2 = (alfa-beta)/2;
delta = 45-gama2;
cosdelta = Math.cos(Math.PI/180*delta);
sindelta = Math.sin(Math.PI/180*delta);
this._rotation = alfa-90-gama2;
this._x = x1;
this._y = y1;
this._xscale = (cosdelta-sindelta)*100;
this._yscale = (sindelta+cosdelta)*100;
this.v._rotation = 45;
this.v._xscale = Math.SQRT(x21*x21+y21*y21);
this.v._yscale = Math.SQRT(x01*x01+y01*y01);
(здесь ниче не оптимизировано специально для наглядности..., если чуток подогнать, то будет фактически одно и тоже, что в верхнем исходнике)

Так вот с какого фига модный класс, на который ты указал, будет работать быстрее, и лучше?????? Нифига подобного!!!!


tpNucer: видимость полигона
vid = (x2-x0)*(y1-y0)-(y2-y0)*(x1-x0);
if (vid>0) {полигон видно} else {невидно}

Да и вообще мне не интересно кто что сделал и как сделал, меня интересовал только конкретный ответ на мой вопрос (см. название топика), на который так никто и не ответил.......

К твоему сведению, это совсем не skew класс, а planar distortion. Если не знаешь о чём здесь люди толкуют - лучше помолчи.

Бред? Ну ну. Кто бы говорил.

Вы вообще тут кто собрались? Кто-нибудь что-нибудь понимает? Я про 3d и про всё остальное - геометрическое?

Да не слушай ты людей, которые в этом ничего не понимают.

Они ведь только и могут - ссылаться на других. Это там про dindin, iLoveYou etc...

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

Видимость в два проходя делается.
Первым проходом ты убираешь все грани, вершины которых расположены не по часовой стрелке, вторым проходом ты сортируешь все оставшиеся по z глубине.
Если используешь камеру, то z вычисляешь по направляющему вектору камеры.
У меня здесь, на flasher.ru лежит движёк, который реализует убирание граней и сортировку их, но без камеры.

Смотри здесь:

http://flasher.ru/src/getswf_2731_1/

Или качай его прямо отсюда:

http://flasher.ru/src/getfile_2731/

Про часовую стрелку есть тоже тут, на flasher.ru в моём уроке:

http://www.flasher.ru/tutorial/viewtut.php?id=156

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

Для MixailV.

У меня ещё круче код. Там не нужно вкладывать картинку в несколько MovieClip'ов, не нужно её размещать как то определённо (ну там повернуть на 45 градусов, или отцетрировать или ещё как нибедь над ней извращаться).

У меня лежит один MovieClip в библиотеке.
Далее, где нужно воспользоваться этой текстурой мы пишем:

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

Вот он есть здесь, но исходник я пока что не выкладываю, но можете взломать декомпилерром и посмотреть.

http://nuran.org/lab/flash/0007.htm

Если интересно конечно ...