Здравствуйте, в документации баг - поправим, но сами методы должны быть рабочие. Может дело в переменной "m_cam"? По ошибке похоже, что это не тот модуль. Он должен был подключаться так:



Вообще метод верный, но fov можно и прямо в блендере настроить, в движке поведение камеры должно быть такое же.

Test video loader

Ответ на сообщение пользователя Ryan Uttech
I think the camera is confused when set to its max and min vertical limit. The values trace out correctly, but the view is clearly wrong.

Yes, it was a bug related to the camera's upside down position.
It would be fixed in the upcoming release in the next few days. So, there would be no need to set vertical limits.

Also, I was wrong about the "set_trans_pivot" method. It doesn't keep the correct view (correct vertical aligning). "set_look_at" is more appropriate. Sorry for the confusion.

Ответ на сообщение пользователя Ryan Uttech
I applied some vertical limits, instead of being -90, 90, are now -60,60. Setting these values fixed the issue.

OK, if this solution fits for you. Thank you for feedback. We will investigate this issue.

set_trans_pivot

Also, it is used in the "Camera Animation" code example. You can reach it from the Code Snippets App in our SDK.

Hi!

I suppose that you have the "TARGET" camera. Try to use set_trans_pivot method. It is more suitable if you want to change camera position and pivot at the same time.

Currently the documentation about this method is incorrect. You should call it as follows:
set_trans_pivot(camera_object, camera_eye, camera_pivot).

Hi

Where is the part of tutorial telling about NLA editing gone?

The "Interactive Web Application" tutorial you talk about has been changed a bit since release date. But it never has a part about NLA. Perhaps you are referring to the one of this NLA tutorials.

Am i not supposed to use the old version tutorials while using 15.03 sdk?

You can use any tutorial with the latest sdk (although code examples may be outdated and produce errors but this is what we are working on) - they weren't change very much. Every article has the list of changes that we made (in the end of the article). Basically they are cosmetic changes.

Функция m_scs.remove_object() удаляет не тот объект и портит физику соседнего копированного объекта.

Привет, к сожалению это баг. Будет исправлен в ближайшем релизе. Спасибо за обратную связь.

Ага, ясно, спасибо. Я думаю, что матрица - штука удобная очень, особенно когда надо сразу сделать несколько трансформаций. И смысла прятать её куда-то далеко не вижу.

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

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

Также проще будет в перспективе передавать на шейдер комбинацию из перемещения поворота и масштабирования (всего 8 значений) вместо матрицы 4x4.

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

Вряд ли, вращение в мировом пространстве относительно Y не будет зависеть от ориентации камеры. Тут надо менять сам поворот, он, кстати, реализован в функции rotate_pivot(). Но я бы посоветовал не вращать саму сцену. Можно ведь просто изменить представление, не трогая логику.

Еще такой вопрос есть: для работы непосредственно с вертексами и фэйсами объекта есть модуль geometry и функции extract_index_array и extract_vertex_array. А что за третий параметр у extract_vertex_array?

Указывает какой именно буфер данных возвращать: координаты вершин, нормали, тангенты, текстурные координаты и т.д.

А тут нет системы ЛС?

Сейчас - нет, может быть, в будущем сделаем.

Это-то понятно, это все я уже нашел в документации. Но меня интересует где сама матрица-то?

Для dev-версии библиотеки мировая матрица на каждом объекте будет здесь: obj._render.world_matrix, но в скомпилированной версии многое подвергается обфускации, поэтому может быть что-то вроде: obj.D.K. Матрицы недоступны через API, т.к. всегда хватало кватернионов. Да и в будущем мы планируем полностью избавиться от необходимости держать матрицы на js.

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

Всё, я, наконец-то, понял. Шарнирный замок тут не причем - это специфика режима TARGET, а именно: вращение слева направо - это вокруг мировой оси Y. В вашем случае - нужно вращать локально. Действительно, такого режима у нас нет. И вообще, все текущие режимы построены с выравниванием относительно вертикали, т.е. со слежением за up-вектором камеры, иначе её ориентация быстро нарушится, ну т.е. будет как в космосе.

Единственное исключение, которое вам может подойти - STATIC камера. Она с точки зрения внутренней логики движка неподвижна, поэтому её можно как угодно двигать и вращать с помощью API - тут движок препятствовать не будет.

Ну, получается, да - нужно реализовывать самому, используя STATIC-камеру.