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

Это не ошибка. NLA всегда запускается при старте сцены, поэтому и частицы у вас сразу срабатывают. Это просто такая логика NLA-сценариев: достаточно настроить в блендере NLA-треки, и в приложении потом все сразу будет играть автоматом, даже управлять им не нужно. Т.е. заранее подготовленная последовательность анимаций на шкале времени.

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

Тем не менее для запуска в произвольный момент больше подойдет обычная анимация, а не NLA. С частиц нужно снять Allow NLA, а запускать через ноду Play Animation / методы apply, play из API, смотря, чем пользуетесь. Тут смысл в том, что не нужно привязываться к NLA-таймлайну, раз мы хотим сами вызывать анимацию в произвольный момент времени.

Которая хочу заметить не описана в документации.

Спасибо, что обнаружили, опишем.

Коллеги, обнаружил удивительное поведение функции b4w.camera_anim.track_to_target(s_movs.camobj, m_scs.get_object_by_name('Camera_char') , 0.2, 5, 5, 3). Я точно абсолютно знаю, где находится Camera_char, но зум исполняется вдоль -Z вместо -X.

Мы эту функцию забыли поправить, когда переходили на блендеровскую систему координат, поэтому сейчас пока её лучше не использовать. К этому релизу пофиксим.

В смысле не париться то 30 fps?

К 30 кадрам, скорее всего, vsync приводит. На самом деле их могло быть, допустим, по 45, но синхронизация может урезать до стандартного значения.
Такое наблюдается всегда или только для больших сцен? А если vivaldi заменить 2-м окном хрома такое будет воспроизводиться или нет? Или наоборот для 2 окон vivaldi?

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

Тут дело не в сенсорах и типах, а в специфике перемещения персонажа. Если ему движение задавать через set_character_move_dir, то он так и будет двигаться, пока его тем же методом не обнулить. Поэтому здесь и триггер сработает.

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

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

Уточните, а в чем принципиальная разница между CT_TRIGGER и CT_CONTINUOUS?

В том, сколько раз будет вызываться колбек пользователя. Если ещё не видели, то вот здесь в API документации про эти типы написано подробнее: ссылка.

Если просто объяснять, то допустим мы отслеживаем сенсором движение/остановку камеры. Так вот CT_TRIGGER вызовет колбек один раз, когда камера начала движение (с праметром pulse = 1) и один раз когда она остановилась (pulse = -1), поэтому и называется trigger, т.е. как бы одиночный импульс, когда состояние изменилось. A CT_CONTINUOUS отличается тем, что будет вызывать колбек постоянно каждый кадр во время движения (pulse = 1) и один раз при остановке (pulse = -1) - т.е. это тип продолжительного действия.

А мы до 75% ограничиваем

а можно ещё запрещать таким людям в конкурсах участвовать
как в казино: что-то вы подозрительно часто выигрываете

ну там, скорее всего, приходит событие мыши "mouseup"

if (e.button != 0)
return;

Буквально будет: если была отжата не левая кнопка мыши, а какая-то другая, то ничего не делать
в поле button хранится индекс кнопки: MouseEvent - вообще документация у MDN хорошо написана, можно там искать.

if (e.preventDefault)
e.preventDefault();

Ну, исходя из названия, он предотвращает дефолтное поведение браузера, например, если обычно мышью можно выделить текст, то таким образом можно это запретить. Можно использовать, чтобы исключить нежелательные эффекты по действию пользователя.
Если интересно, то по поводу preventDefault() можно в спецификации почитать: Default actions and cancelable events

Браузеры все доступные. FX-8300 и GTX-760
Да, так сильно.

Проц и видеокарта хорошие, поэтому такое падение фпс неадекватное. По сути на сцене с кубиком падения не должно было быть вообще. Протестил даже на стареньком mac mini 2011 года - аналогичная сцена падает с 60 до 40 фпс. Проблема может быть в том, что, как я писал выше, операция чтения из текстуры отрендеренных анкоров "не очень хорошая" - если не вдаваться в подробности, то считывание данных обратно из GPU может приводить к тормозам - в течение этого времени все подвиснет. В большинстве это не должно так сильно сказываться и мощности современного железа вполне должно хватать. Тут могут повлиять какие-нибудь заморочки железа, особенности драйвера и т.д. - в общем сложный момент, можно сказать, что вам не повезло.
Есть возможность оптимизировать этот процесс и сделать, чтобы все это по сложности не зависело от количества анкоров, т.е. как будто он один в сцене. Этим мы, наверное, займемся.
Также есть ещё возможности неплохой оптимизации в WebGL2, но до этого ещё надо подождать.

Еще замечание по производительности.
У меня на сцене всего 2 селектабл(или пикабл) объекта. Когда я вращаю таргет камеру вокруг объекта (ЛМБ+драг) не то чтобы фпс падает, сложно сказать, но микрофризы каеие-то происходят. Отключил функцию выделения объектов (при mousemove)- фризы ушли.
Видимо вот этот блок вызывает напряг.

Там то же самое зло, что и для анкоров.

Нужна какая-то более конкретная тулза для профилирования. Если знаете - порекомендуйте.

Можно использовать встроенный профайлер в Chrome или FF. Я привык к хромовскому - он довольно удобен.

Еще я заметил, что при билд проекта почему-то не подхватываются все js файлы в app_dev, и не компилируются, соответственно. Это надо вручную делать? Если вручную, то как потом нормально сделать деплой, если фактически загружается архив с проектом, но без дополнительно разработанных js?

все должно быть нормально - все скрипты, которые подключены в html, компилируются в один min.js файл

Уточните, а почему bin стал почти в два раза меньше - это за счет выключения tangent shading или сам движок был оптимизирован?

Да, из-за tangent shading - у вас в сцене его неприлично много. Из-за этого и зависания - очень много материалов c таким шейдингом + вся сцена довольно полигональная - из-за этого расчет тангент происходит очень долго, поэтому и кажется, что все зависает. Тангентый шейдинг на таком кол-ве материалов очень избыточен, тем более у вас там везде ещё и shadeless проставлен . А раньше мы эту опцию не поддерживали, поэтому экспорт был быстрым. Мы этот момент конечно попробуем оптимизировать, но так сильно злоупотреблять им не надо, тем более вам он в сцене вроде и не нужен.

Скажите, как можно отключить привязку камеры к персонажу, чтобы она могла двигаться сама? Имеется ввиду возможность и привязать, и временно отвязать. А то m_cons.append_stiff_trans там есть, а disappend нет.

Есть метод m_cons.remove - в качестве параметра в него нужно передать камеру.