Hi,
I think such behavior can't be described unambiguously. The camera has to choose an appropriate side to pass around the object and in most cases there will be other objects which are also undesirably to be crossed.

In this case I would go with several "Move Camera" nodes, or maybe with baked Camera animations.

Hi,

The most sensible introduction to b4w scripting is given in this tutorial.
It describes how to use Project Manager and how to modify js files to achieve simple interactivity. After reading it, I'm sure, you'll understand the above tutorial much easier.

Also is really programming knowledge needed?

As for now, a bit of programming is required to work with keyboard because logic nodes do not support it yet.

Currently, there is no such ability. We have plans on supporting Blender layers in some way, because yes - it will be a more convenient way to work with object groups.

At the moment the most suitable approach is to use object groups linked from another file (or scene) and to set the "do not export" flag on an empty-object which this group is attached to.

We decided that the behavior you have described is really more convenient.
We are going to implement it in the next few releases. Maybe, in the nearest one.

In such cases it is a good idea to just use the armature.get_bone_tsr method and block unwanted translations if bone position is close to some limit. This approach is much faster than physics one.

All manipulations with physics objects should be done with the help of physics module.

So in your case the set_transform method would be a good choice.

This can be done with the following method: animation.set_speed()

Even a negative value can be used for speed.

You can do the same of course. There are several ways to solve such task. For example, you can use objects.copy() and trasnform.set_translation methods to duplicate and place some predefined primitives to the required positions.

Hello,

It is better to wait for 16.04 in this case, because we are presenting exactly the described functionality in this version. You will be able to call specially predefined JS scripts from the node tree and vice versa.

Ответ на сообщение пользователя Кирилл
К моему предыдущему посту:

Посмотрел, в блендере во вьюпорте нормали правильно отображаются. Со стороны синего источника синяя сторона, стороны жёлтого, жёлтая. А после экспорта наоборот…

Файл проекта car2d.blend

В вашем примере, действительно отличаются результаты в Blender и B4W, и это связано с тем, что в Blender выход Normal на текстурной ноде приводится в тангентном пространстве (что не интуитивно), а в b4w в мировом. Это можно отнести к недоработке самого Blender и мы уже предложили несколько патчей, чтобы устранить эту проблему. Если вы посмотрите на освещение на кадрах 1-90 оно тоже будет неверным (в Blender).
На данный момент решением является использование ноды:Replace, которая в Blender выдает верхний выход, а в b4w нижний. В верхний вход обычно подается нода Material, в которой лежит материал с уже измененными нормалями.
Я прикрепил ваш измененный пример. Здесь Blender и Blend4Web дают одинаковый результат. Хоть он тоже визуально некорректный, но его уже можно настроить в Blender.