Приглашаю помочь и заняться интересным 2d 3d web построение

[Xaositect]

Qx15(RUS) в сообщении #254248 писал(а):

А у меня вопрос, как разделить матрицу A на матрицу B?? Также как и умножать, только вместо умножения элементов делать деление?

Поскольку умножение матриц некоммутативно (например, $\left(\begin{matrix}1&0\\1&1\end{matrix}\right)\left(\begin{matrix}1&1\\0&1\end{matrix}\right)\neq \left(\begin{matrix}1&1\\0&1\end{matrix}\right)\left(\begin{matrix}1&0\\1&1\end{matrix}\right)$), то обратных операций будет две - левое деление и правое.
Если матрица квадратная и невырожденная, то для нее можно найти обратную матрицу $A^{-1}$, которая обладает свойством $AA^{-1} = A^{-1}A = I$. Тогда если $AB = C$, то $B = A^{-1}C$ и если $BA = C$, то $B = CA^{-1}$.

[Qx15(RUS)]

Правильно ли я сделал вывод?
Пусть $A = \left(\begin{matrix}a_{11}&a_{12}\\a_{21}&a_{22}\end{matrix}\right) $
$B = \left(\begin{matrix}b_{11}&b_{12}\\b_{21}&b_{22}\end{matrix}\right) $
Тогда:
$\dfrac{A}{B} = \left(\begin{matrix}\dfrac{a_{11}}{b_{11}}+\dfrac{a_{12}}{b_{12}}&\dfrac{a_{11}}{b_{21}}+\dfrac{a_{12}}{b_{22}}\\\dfrac{a_{21}}{b_{11}}+\dfrac{a_{22}}{b_{12}}&\dfrac{a_{21}}{b_{21}}+\dfrac{a_{22}}{b_{22}}\end{matrix}\right) $?

И еще я не до конца понял следующее:
Допустим, у мы повернули точку по оси X, значит применяем матрицу:
$\left(\begin{matrix}1&0&0\\0&cosp&sinp\\0&-sinp&cosp\end{matrix}\right) $
То, получиться уравнение, для вращения по оси X:
$X'=1\cdot X+0\cdot Y+0\cdot *Z$
$Y'=0\cdot X+cosp\cdot Y+sinp\cdot *Z$
$Z'=0\cdot X-sinp\cdot Y+cosp\cdot *Z$
Преобразуем:
$X'=X
$Y'=cosp\cdot Y+sinp\cdot *Z$
$Z'=-sinp\cdot Y+cosp\cdot *Z$
Это правильно?

[venco]

Qx15(RUS) в сообщении #254271 писал(а):

Правильно ли я сделал вывод?

Нет. Обратная матрица так просто не вычисляется.

[Qx15(RUS)]

Кстати, если надо функцию для вращения камеры мышкой, пожалуйста:
с мышки поступает следующее:
X - координата X мыши
Y - координата Y мыши
Button - переменная, равная номеру кнопки, состояние которой изменили (была нажата/отпущена)
Button = 1 (Левая)
Button = 2 (Правая)
Дополнительно создаем:
B(4) - массив с переменными, отвечающими за состояние кнопок (нажата/нет)
B(x) = 0 (Кнопка x отпущена)
B(x) = 1 (Кнопка x нажата)
Процедура, где обрабатывается событие, после нажатия любой кнопки мыши:

B(Button) = 1
If B(1) = 1 Then
    Mz = Rz + X
    My = Ry + Y
End If
If B(2) = 1 Then
    Mx = Rx + Y
End If

Процедура, где обрабатывается событие, если мышь перемещается:

If B(1) = 1 Then
    Rz = Mz - X
    Ry = My - Y
    If Abs(Rz) > 180 Then Mz = Mz - 360 * Sgn(Mz)
    If Abs(Ry) > 180 Then My = My - 360 * Sgn(My)
End If
If B(2) = 1 Then
    Rx = Mz - Y
    If Abs(Rx) > 180 Then Mx = Mx - 360 * Sgn(Mx)
End If

Процедура, где обрабатывается событие, если любую кнопку мыши отпустили:

B(Button) = 0

Это простенький код позволяет БЕЗ каких либо глюков вращать камеру, нажав левую кнопку и крутить, нажав правую. А можно вращать и крутить одновременно, нажав обе кнопки.
Я имею ввиду, что вращать - изменять Rz и Ry камеры, а крутить - изменять Rx.
Также здесь присутствуют функции коррекции угла, дабы не возникало ошибки переполнения чисел.
Rx, Ry, Rz - углы камеры
Mx, My, Mz - переменные, нужные для сохранения точки, откуда вращаемся, нигде больше их не нужно трогать.

А и еще: я использовал градусную меру, поэтому присутсвуют числа 180 и 360. Если используете радианную, то их надо заменить на Пи и 2Пи соответственно.

-- Пт окт 23, 2009 23:35:15 --

venco в сообщении #254274 писал(а):

Qx15(RUS) в сообщении #254271 писал(а):

Правильно ли я сделал вывод?

Нет. Обратная матрица так просто не вычисляется.

Тогда покажите готовую формулу, я просто этот момент видимо не понял

[Circiter]

2myconding

Цитата:

Нописал бы кно нормальные tutorial по 3d

Этакая мини-лекция по лин. алгебре.

Начнем издалека. Под матрицей поворота я подразумеваю любую квадратную матрицу с детерминантом $1$ (изометрически сохраняющую длины, углы, объемы), которая обращается простым транспонированием (ортогональность). Технически выражаясь, матрица поворота суть элемент группы $SO(3)$. Известно, что такие преобразования переводят прямые в прямые, поэтому (хоть я уже и упоминал это свойство в начале темы, но все равно повторюсь), чтобы вращать любой объект достаточно действовать матрицей поворота на его "контрольные" точки. Т.е. вопрос типа "как вращать линию" ничем не отличается от вопроса "как вращать радиус-вектор".

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

Что делает матрица поворота? Эта матрица описывает поворот системы координат (т.е. поворачивает координатные оси) вокруг её начала. Координаты любого вектора относительно старой системы координат остаются теми-же относительно новой координатной системы. Получается, что вектор в новой системе координат (после поворота) уже известен, так как покомпонентно равен вектору в старой системе координат; однако в практических ситуациях важно знать чему равны координаты вектора из новой системы координат, в старой системе координат. Для этого достаточно умножить вектор слева на матрицу поворота, это преобразование можно назвать поворотом вектора.

Для наглядности проиллюстрирую вышесказанное алгебраически. Пусть полем боя будет евклидово пространство $\mathbb{R}^3$. В нем выбирается стандартный ортонормированный базис (система линейно независимых векторов) $i,\ j,\ k\in\mathbb{R}^3$. Тогда любой другой вектор $v\in\mathbb{R}^3$ можно представить в виде линейной комбинации (разложения) $v=xi+yj+zk$, где $x,\ y,\ z\in\mathbb{R}$ -- просто числа, суть координаты (компоненты) вектора $v$.

Чем тогда будет поворот системы координат? Поворот будет просто сменой базиса $i,\ j,\ k$ на новый (тоже ортонормированный) базис $i',\ j',\ k'$. При этом под поворотом вектора следует понимать преобразование $v\to v'$, такое, что, как я писал чуть выше, вектор $v$ в старом базисе покомпонентно равен вектору $v'$ в новом базисе. То есть, $v$ раскладывается по базису $i,\ j,\ k$ как $v=xi+yj+zk$, и вектор $v'$ раскладывается по новому базису $i',\ j',\ k'$ как $v'=xi'+yj'+zk'$ (n.b., координаты те же, базис -- другой).

Задача заключается в отыскании разложения вектора $v'$ в старом базисе, т.е. нужно найти числа $x',\ y',\ z'$ в разложении $v'=x'i+y'j+z'k$. Как это сделать? Для этого можно воспользоваться таким приемом. Разложим новый базис по элементам старого, т.е. $i'=r_{11}i+r_{21}j+r_{31}k$, $j'=r_{12}i+r_{22}j+r_{32}k$ и $k'=r_{13}i+r_{23}j+r_{33}k$. В этих разложениях девять чисел $r_{11},\ r_{12},\ \ldots$ как раз таки и составляют матрицу поворота $R$.

Как использовать эти числа? Просто подставим только что полученные разложения для $i',\ j',\ k'$ в разложение $v'=xi'+yj'+zk'$, что немедленно даст искомое разложение для $v'$ в старом базисе, которое хоть и громоздко, но эквивалентно краткому матрично-векторному выражению $v'=Rv$, переводящему тройку $x,\ y,\ z$ в тройку $x',\ y',\ z'$. Именно так можно объяснить связь поворотов с умножениями на матрицы.

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

Когда мы вращаем систему координат, вращение происходит вокруг какой-то оси (не обязательно совпадающей с одной из координатных осей). Эта ось является неподвижной точкой преобразования $R$ (или элементом ядра преобразования $R-I$, где $I$ -- единичная матрица). Поворот вокруг такой оси будет соответствовать двумерному повороту в плоскости, ортогональной оси вращения, а такой 2D-поворот можно описать, как известно, углом.

Любой поворот, таким образом, можно задать осью вращения и углом, что достаточно удобно (это, наверное, самый экономичный по памяти способ описания вращения; нужно хранить лишь три числа, вместо девяти, т.е. направление оси задается вектором, а угол его длиной). Однако, мне лень выписывать формулы для компонентов соответствующей матрицы (к тому же, само понятие произвольной оси вращения почти не имеет никакого смысла в пространствах других размерностей), поэтому далее элементарные повороты будут задаваться лишь относительно (вокруг) координатных осей (формулы я уже приводил), а произвольные повороты будут получаться в виде композиции элементарных (под композицией понимается последовательное применение или перемножение соответствующих матриц). Ранее я вводил следующие обозначения для элементарных поворотов, $R_x(\alpha)$, $R_y(\beta)$, $R_z(\gamma)$, где углы $\alpha,\ \beta$ и $\gamma$ обычно кличут эйлеровыми углами (хотя названия могут быть разными). На самом деле, достаточно использовать не все три, а лишь два элементарных поворота (например можно описать произвольный поворот как композицию $R_z(\alpha)R_x(\beta)R_z(\gamma)$).

Мы здесь немного поспорили с ИСН по поводу коммутативности поворотов. Возможно, мы просто говорили о разных вещах, но на всякий случай попробую прояснить ситуацию. Итак, повороты на плоскости коммутируют, это известно. В трехмерном же случае повороты уже не перестановочны, и я с этим полностью согласен. Но когда я говорил о накоплении углов, я имел ввиду именно накопление поворотов относительно разных координатных осей. Каждый такой элементарный поворот, как я уже писал, суть поворот в плоскости, перепендикулярной оси вращения, именно в плоскости, поэтому такие элементарные повороты "двумерны" и допускают скалярное накопление соответствующих углов. Другими словами, эйлеровы углы независимы (друг от друга), а так называемые эйлеровы повороты, представляющие собой изменения одного из эйлеровых углов при фиксированных двух других углах, коммутируют. Готов отдельно подискутировать на эту тему (возможно я в чем-то и заблуждаюсь, это не исключено).

Несмотря на очевидные достоинства эйлеровых углов и естественность их применения, скажем, в авиасимуляторах, задание положения (поворота) тремя углами влечет за собой некоторые проблемы. Здесь и неоднозначности в интерпретации, и возможная потеря одной из степеней свободы (cf. gimbal lock, i.e. опаньки карданову подвесу). Поэтому в реальных приложениях зачастую используют другие интересные, хотя, возможно, и несколько менее "интуитивные" объекты вроде кватернионов, билинейных форм, тензоров, и пр.

Например, кватернионы (aka кватернионы поворота aka единичные кватернионы aka версоры) имеют огромные преимущества перед другими, до этого рассмотренными методами поворотов. Кватернионы позволяют избежать gimbal lock'а, избежать лишних артефактов трансформаций (композиция матриц поворота замкнута, т.е. вновь является матрицей поворота, но это выполняется лишь в теории, de-facto же из-за глюков машинной арифметики в матрицу "подмешиваются" и другие преобразования, масштабирование, скос; кватернионы конечно тоже портятся из-за ошибок округления, но восстановить кватернион гораздо проще чем матрицу), "жрут" меньше памяти (четыре числа vs. девять), а также имеют ряд других практически важных плюсов, в частности позволяют качественно интерполировать повороты.

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

Забудьте на некоторое время про матрицы, кватернионы и прочую конкретику. Мыслите о трансформациях как об абстрактных предписаниях типа "повернуть на прямой угол", "вперед на два шага", "увеличить в три раза" и т.д. Если вам нужно "повернуть", а потом "переместить", то соответствующие предписания необходимо "склеить", получив в результате список-композицию вроде "повернуть на прямой угол -> вперед на два шага".

Усложним задачу. Представьте, что у вас есть несколько объектов и вы хотите манипулировать не только всей сценой (работая в мировых координатах), но и отдельными объектами (работая в их локальных координатах). Т.е. например вы хотите повернуть некоторый объект вокруг его геометрического центра, но объект находится вдалеке от точки-начала координат, а вы умеется вращать объекты только вокруг этой точки.

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

Такой подход легко обобщается на любую глубину иерархической трансформации. Для этого заводится стек списков. Изначально в нем находится пустой список. когда нужно поработать с локальными координатами, в стек преобразований добавляется (push) новый список (копия уже лежащего на вершине стека). Команды добавляются к этому новому списку, находящемуся на вершине стека, после их выполнения текущий список удаляется со стека (pop). Таким образом операция push сохраняет имеющуюся координатную систему, а pop -- восстанавливает её.

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

Что вам нужно сделать, чтобы добавить поддержку матричных трансформаций? Сначала подумайте, как будете хранить матрицы. Если работать с однородными координатами (для кодирования матрицами любых аффинных трансформаций, а не только линейных), то матрицы можно хранить в виде двумерных массивов $4\times 4$. В "левой верхней" части будут храниться матрицы линейных преобразований ($3\times 3$), при этом в "нижнем правом" элементе будет единица, а остальные элементы можно забить нулями (для начала).

Затем реализуйте алгоритмы умножения матрицы на вектор (вектора в однородных координатах тоже придется расширить лишней единицей) и матрицы на матрицу.

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

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

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

2Qx15(RUS)

Цитата:

А у меня вопрос, как разделить матрицу A на матрицу B?

Как такового, матричного деления нет, есть только обращение матрицы. Иногда обратную матрицу можно посчитать сравнительно легко (как, например, в случае с обсуждаемыми здесь матрицами поворота), но в общем случае это не так. Пусть есть квадратная обратимая (имеющая ненулевой определитель) матрица $A$. Обратная матрица $A^{-1}$ может быть найдена как $A^{-1}=\widetilde A/\det A$, где $\widetilde A$ -- присоединенная матрица, составленная из алгебраических дополнений матрицы $A^T$, траспонированной по отношению к $A$: $\forall\ i,j\in[1;n]\ \exists\ \widetilde{a}_{ij}=(-1)^{i+j}\triangle_{ji}$, где $\triangle_{ji}$ -- минор элемента $a_{ji}$, являющийся детерминантом матрицы, составленной из элементов исходной матрицы, за исключением элементов строки и столбца, на "пересечении" которых находится элемент, минор которого отыскивается.

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

[mycoding]

С матрицами не разобрался, но дело движется
http://my2d3d.narod.ru/
Огромнейшее спасибо Circiter, за формулы без матриц.....
Что-то мне кажется и не нужны эти матрицы....

[Circiter]

Пипец...

[Yuri Gendelman]

Circiter в сообщении #254790 писал(а):

Пипец...

Эту тему обязательно читать тем, кто считает, что программисту не нужна математика.

mycoding в сообщении #254785 писал(а):

Что-то мне кажется и не нужны эти матрицы....

Кстати, в современной литературе по 3D часто вместо матриц вращения и трансляций используют кватернионы...

[Qx15(RUS)]

Mycoding, делаете успехи! Вот по поводу 2D хочется высказаться:
Лучше было бы пользователю предоставить открывающийся список, где он выберет нужный элемент например:
...
y=m*Sin(ax+b)+y0
y=m*Cos(ax+b)+y0
...
И после выбора функции, он сможет самостоятельно ввести m, a, b, y0...
И посмотреть результат. А то самому вводить функцию нерационально, все равно у вас ограниченное кол-во функций. Вот поэтому и много ошибок. Вообще я советовал бы исправить следующее:
tg(x) и ctg(x) вообще не работают.
pow(x,n) при n>4,6 не работает
В функции e(x) нельзя умножать, а только делить, в отличии от sin(x) например.
Го поводу граффика:
При произвольном масштабе, значение по оси х и у округлено до 0,001 поэтому цифры заползают на граффик, это некрасиво. Здесь я бы посоветовал несколько вариантов решения:
- Округлить до 0,1
- сместить влево на 3 цифры
- написать функцию определения длины переменной и смещать влево в соответствии с этой длинной
- Не париться и написать цифры оси Y справа.
По поводу мышки: я бы назвал это не перетаскиванием, а установлением нуля, т.к. мышка действительно устанавливает начало координат. Я написал решение этой проблемы выше. А лучше запостите все участки кода, где делаются операции с мышкой и я показу, что и где надо дописать.
По поводу 3D. Circiter, вы дали Mycoding'у формулы 3D? Вот часть кода, которую вы запостили:

Circiter в сообщении #250468 писал(а):

Цитата:

...
// Final step.
    Vertex->u = Canvas->Width/2+xz*Scale;
    Vertex->v = Canvas->Height/2+yz*Scale;
...

Примерно так.

Фактически это отображение X и Y точки на экране, относительно центра, т.е 2D граффика Вместо этого участка, пожалуйста напишите нормальную формулу для преобразования X,Y,Z в V и U, буду сам благодарен, если она окажется лучше, чем моя. Пока ее нет, задумываться в вращении мышкой бессмысленно, хотя это также просто как перемещение.

[arseniiv]

Кстати, почему бы не использовать для функций стд JS-функцию eval?

var str; // в str должно загружаться то "строительное" выражение перед построением графика
// ...
var f = new Function("x", "with (Math) { return eval(str); }"); // перед построением
// ...
y = f(x); // при построении

И выписать список функций и констант из Math, чтобы пользователи знали. Также можно сделать будет поле для самостоятельного определения функций.

Кстати, mycoding, вы так и не исправили в 2d-графике скакание при перетаскивании. Запоминайте, с какой точки началось движение! (Вам ровно это уже и советовали.)

Qx15(RUS) в сообщении #254836 писал(а):

граффик

график

Criticer давал формулы работы с матрицами.

[Qx15(RUS)]

arseniiv в сообщении #254842 писал(а):

...график....

У меня по русскому не 5, но точно одна "ф" запомню.

[mycoding]

Qx15(RUS) в сообщении #254836 писал(а):

Вообще я советовал бы исправить следующее:
tg(x) и ctg(x) вообще не работают.
pow(x,n) при n>4,6 не работает
В функции e(x) нельзя умножать, а только делить, в отличии от sin(x) например.

Не знаю, как у вас у меня всё работает, и работате отлично, в инет эксплауре могут быть глюки , я там больно не тестил. Главное в мозиле пашет

-- Вс окт 25, 2009 21:13:57 --

Qx15(RUS) в сообщении #254836 писал(а):

Фактически это отображение X и Y точки на экране, относительно центра, т.е 2D граффика Вместо этого участка, пожалуйста напишите нормальную формулу для преобразования X,Y,Z в V и U, буду сам благодарен, если она окажется лучше, чем моя. Пока ее нет, задумываться в вращении мышкой бессмысленно, хотя это также просто как перемещение.

Я тут ещё пришёл к выводу на днях, что мне стандарт который разработан для 3d по поводу вращения мышкой не нравится, хочется взять просто и передвинуть обьект, а не прващять его мышой, так что в этом плане меня устраивает.

-- Вс окт 25, 2009 21:23:28 --

arseniiv в сообщении #254842 писал(а):

Кстати, почему бы не использовать для функций стд JS-функцию eval?
[code]var str; // в str должно загружаться то "строительное" выражение перед построением графика

Кстати, mycoding, вы так и не исправили в 2d-графике скакание при перетаскивании. Запоминайте, с какой точки началось движение! (Вам ровно это уже и советовали.)

По поводу eval я его использую, но немного для другого, он каждый раз вычисляет значение y , т.е. я просто кидаю формулу и он её вычисляет.
По поводу мыши , если есть необходимость сдвинуть график, можно воспользоваться клавой , она сдвигает дальше, так же есть зумм для слишком не терпеливых, а еще мне нравится что можно быстро вернуться в центр, без перетаскиваний назад.
Так, что в принципе реализовано именно как я хотел, но конечно надо еще некоторые вещи добавить )))
Я пришёл к выводу, что изобретение велосипеда очень хорошее дело, не надо делать как все , делай так как тебе надо... оно зачастую лучше

[Circiter]

2Qx15(RUS)

Цитата:

Вот часть кода, которую вы запостили

Вот это да. Процитировать две строчки и утверждать, что они не работают. Ну вы даете.

Цитата:

пожалуйста напишите нормальную формулу для преобразования X,Y,Z в V и U, буду сам благодарен, если она окажется лучше, чем моя.

Весь тот псевдокод и есть формула. К тому же я оговаривал, что это ad hoc решение (да, в нем действительно, для простоты, применяется параллельная проекция, вместо центральной, т.е. перспективной).

Лучше этой "формулы" (алгоритма) только матрицы.

P.S.: Прочитайте тему всю, внимательно.

2Yuri Gendelman

Цитата:

Кстати, в современной литературе по 3D часто вместо матриц вращения и трансляций используют кватернионы...

Да, здесь о них уже упоминалось, но вот ждем когда mycoding разберется с матрицами...

Где вы слышали, чтобы кватернионы использовались для трансляций? Это чисто вращательная примочка.

2mycoding

Цитата:

Я тут ещё пришёл к выводу на днях, что мне стандарт который разработан для 3d по поводу вращения мышкой не нравится

Нет такого стандарта.

[arseniiv]

mycoding, по вашему последнему сообщению кажется, что вы страницу для себя пишете, а не для всех. Учитывать чужие интересы ведь тоже надо.
Выход, кстати, очень прост - флажок "Пускай будет по-вашему"

[Qx15(RUS)]

mycoding в сообщении #254875 писал(а):

...Не знаю, как у вас у меня всё работает, и работате отлично, в инет эксплауре могут быть глюки , я там больно не тестил. Главное в мозиле пашет...

У меня последняя версия GoogleCrome. Должно работать вообще все-все-все. Но нет у меня FireFox3 или хотя бы 2, что-бы сказать точно. Ладно я вам поверю наслово.

Circiter в сообщении #254910 писал(а):

2Qx15(RUS)...Вот это да. Процитировать две строчки и утверждать, что они не работают. Ну вы даете...
...Нет такого стандарта.

Я НЕ горовил, что они не работают Не придумывайте!!! Я проверил эти две строчки: Они дают параллельную проекцию. Ошибся только в том, что назвал это 2D, а не 3D.
Не знаю насчет стандарта, однако все геймеры, которых я знаю, пользуются мышкой. НИКОГО не встречал, кто-бы в 3D вращался стрелочками....И во большинстве 3D приложениях, особенно сложных играх тоже пользуются мышкой. Это не стандарт, а общепринятая часть программ...