Camera in Eye mode for FPS gaming

Hello,

The Eye mode is very nice and convenient (side stepping is already implemented). However, there are several parameters set by default that I would like to change to have a real classic FPS feel.

1) Currently the camera moves only when you click. How to make the camera always responding ?
2) Is it possible to change the default ASDW keys, here in France we have AZERTY keyboards for instance. BTW, would it be possible to read key number instead of actual symbol ?

Thx.

BTW, I notice that when in Eye mode the camera is bound automatically to the character, which seems fine to me. However the character doesn't respond to gravity anymore and therefore can elevate in the air like a ghost which is highly unexpected.

Hi,

1) Currently the camera moves only when you click. How to make the camera always responding ?

It happens because your document element doesn't have a focus on it. If your app is inside the i-frame you can try adding the next line to the load callback: If you have a full-screen application there is nothing can be done here. When a document element doesn't have a focus it won't process any user events.

Is it possible to change the default ASDW keys, here in France we have AZERTY keyboards for instance

Yes. app.js addon is responsible for camera controls. Feel free to change enable_camera_controls function. Lines like in particular.

BTW, would it be possible to read key number instead of actual symbol ?

No. Browsers doesn't have such a low-level API as far as I know.

BTW, I notice that when in Eye mode the camera is bound automatically to the character, which seems fine to me. However the character doesn't respond to gravity anymore and therefore can elevate in the air like a ghost which is highly unexpected.

This is what app.js controls really do . Enable flying mode. And when there is a character you can fly around the scene and collide with objects that have physics.
If you want real FPS controls you need to rewrite app.js a bit. Take a look at Game example tutorials

OK, thank for the answer.

After some testing, I solved most of my problems. Instead of modifying app.js (although this works well too), I wrote my own controls not using the Eye Mode, camera in Static move style. This had a few consequences. First, there isn't anymore the "click to change the view" problem. It reacts as I wanted but I did nothing for that (well, cool). Then I discovered that I have to bound the camera location to the character but the parent feature of blender prevented the use of a function like "set_rotation_euler" that I wanted to use on the camera for the "mouselook" free view capability. So I used a constraint "append_copy_trans" and with some more code it worked as expected.

However another problem has emerged since then. If I set "Special: Collision" on an object material of the scene, I cannot move my character anymore, pretty strange.

However another problem has emerged since then. If I set "Special: Collision" on an object material of the scene, I cannot move my character anymore, pretty strange.

Is there some output in console? What you have described should work properly.
You can send an example to evgeny-ar@blend4web.com and I'll tell what is the root of the problem.

I appreciate the help ! Thank you. Unfortunately no special warning in the javascript console of Firefox.

I just sent you a zip file to your mailbox and some instructions.

I appreciate the help ! Thank you. Unfortunately no special warning in the javascript console of Firefox.

I just sent you a zip file to your mailbox and some instructions.

The problem is that your character capsule is inside the collision mesh. You need to raise it above the ground and everything will work fine.
Why this issue is being reproduced only when special-collision is on? I think it's because physics fps dropped a bit and the character moved underground a bit more so that he became totally stucked in collision mesh.

Btw. I wouldn't recommend using such a high polygon density models for collisions because of performance issues. In our demos we often have nice models for rendering and low-polys for static physics.

It is true that before sending the zip I reorganized the scene a little and put in my hurry the character capsule inside the ground. But before that the object was way above the ground and the problem was already present. For a new test I just put the character again well above the ground and still got the problem. I am sending you another zip file with everything set up. Just open the html file, and of course you can control the height of the character in the blendfile. You will see that there is no contact with the collision mesh and yet the bug happens.

Moreover If you hit O you will trigger a camera animation and see that the character is standing still in the air and is not stuck in the ground. Yet it can not move.

I totally agree with you with the mesh density of the rocky cube. This model is not mine, as I am into a collaboration work with someone else. In fact I think that the problem may well reside in the mesh of this big cube. As a matter of fact, in another test I applied a Remesh modifier on it and everything went back to normal. So I don't know yet the true reason, it is not strictly the mesh density since I was able to subdivide it after that quite a lot without having the problem back. However you may have some more clues about the whole subject. It may be worthy to find the true reason, if it is a bug it can bite again.

I have investigated your project. You are right - there is a problem with such a setup. In the "Collision" object there is a Special Collision flag (which is for mesh collisions) selected in it's material. At the same time we are enabling Detect Collisions in Objects physics (which is for a box collision in our case). We need to choose only one of them. This is described in our physics documentation.

And when we turn on both there is bug appeared to be here. Your setup should work properly anyway (box collision should overwrite mesh collision). We'll fix this in the next release.

And now for fixing this issue you can left only one flag selected.

Thanks for report!

Glad you have found the root of the problem. May be a warning could be helpful too during export. I want to stress on the fact that the documentation you refer to doesn't say explicitly that you have the choice between the 2 options. On the contrary it presents the two ways sequentially and each time says that the given option has to be enabled. The result is that someone inexperienced may think that both options need to be enabled. It is, at least, what probably happened to me.

But, now, it does make sense, I was in fact a little puzzled why there were two fields for the ID collision in different panels.

A little question, BTW, when you go for a material with "Special :collision", does this bypass the "Collisions bounds" setting like capsule, box or cone ? Does it force physics calculation to be mesh accurate like Triangle Mesh in the BGE ?