trouble getting controller type FPS to work

[julescone]

I am playing with using GLAM to build a prototype of a virtual showroom in which I want to place some objects (models, images, videos) that the user can explore in FPS mode, initially just in the browser but eventually using an Oculus Rift as well.

Following the examples I have got my head around the basics but for some reason I can’t get controller type FPS to work. It appears to just be defaulting back to type=”model”, just allowing me to rotate and zoom around the model, rather than move around the space like I am expecting.

For example if I modify https://github.com/tparisi/glam/blob/master/examples/basic/glamcube.html to include a controller tag inside the <scene> tag then it renders fine if I set it to type="model", but when I change it to type="fps" the cube doesn't render, but it also doesn't seem to generate any errors in the console.

example code that doesn't work: <scene> <controller type="fps"></controller> <box id="photocube"></box> </scene>

Any help would be much appreciated, and a demo of the FPS controller mode in action would be a great addition to the documentation.

[tparisi]

Hey Jules - I verified that this is a bug. I found an issue with fixing it, namely that in order to have a good FPS you will need keyboard input. We need a way to make the GLAM canvas take the keyboard input. Internally there is a way to do that via JavaScript by setting it as a "tabstop" but I need to think about how to surface this to the tag set. Maybe just a "tabstop" attribute on the root <glam> tag?

Any thoughts?

[julescone]

Hi Tony, thanks for getting onto this. So as I understand it the tabstop setting is essentially targeting the canvas inside the glam tag to expect/accept the keyboard input.

I haven't tested whether I can have multiple glam tags (and scenes) in one page, but assuming you can it might make more sense to call the attribute something like keyTarget or inputTarget or something similar rather than expose the tabstop concept at the tag level.

I presume it makes more sense to have that attribute set on the glam tag rather than the scene but that is obviously your call.

Thanks again for looking at this, once we get the fps setting working I would be happy to contribute an example to the GLAM repo for others to refer to.

[tparisi]

Good points...

I don't have multiple GLAM canvases working on a single page yet. That's something I need to work on - later.

Would tabstop/keyTarget/whatever automatically give the set focus to the canvas, or would it just make it so that clicking gives it focus?

Do you think this is an appropriate thing to put in the declaration syntax, or would it be better to just provide an API method e.g. glam.focus()?

Tony

[julescone]

No problem on the multiple canvas scenario, I hadn't actually thought of using that in any case. :)

I guess you could add it as an attribute on the GLAM canvas so that if the attribute is present then it would automatically set the focus to that canvas, and then add an API method as well that could be used to programatically switch on and off the focus.

A default behaviour of setting the focus by clicking in the canvas would probably make sense too, then it would still work even if you didn't set the attribute or make the API call.

Is that useful?

[tparisi]

Yes very useful. r/e the default behavior of clicking: that makes sense but I would also want to provide a "notabstop" attribute to override that. Thanks for the input; let me meditate a little and I'll keep in you in the loop as I make the changes.!