Open andreasplesch opened 7 years ago
I see, the canvas size is correctly set to the HMD display:
https://github.com/Sgeo/cobweb/blob/master/cobweb.js/cobweb/Browser/X3DBrowser.js#L136
The webvr emulator emulates a Vive which has that high resolution.
This is not VR related since a maximized cobweb in a large browser window has the same performance issues on my midrange system. Let me try a higher end system.
I'm not sure what you mean by the camera being close dependent on canvas size. I am traversing for each eye separately, including a full camera/collision/depth/draw pass. Possibly with more effort this could be cleaned up, maybe skipping some event processing? The background gets drawn in the camera pass, and I'm not sure where lights get calculated exactly. The mouse interaction bug was fixed in a commit later than the build I released (although I'm not sure if mouse clicks are actually going to the correct destination), maybe I should just leave the build artifact in the repository.
Sorry, I am not sure either. It is probably just a side effect of the resizing. Here is what I see in the emulator:
https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Browser/Rendering/X3DRenderingContext.js#L111 should ensure that the viewport is resized also: https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Browser/Rendering/X3DRenderingContext.js#L248 but it looks like it is not.
Perhaps skip the .addBrowserEvent() here https://github.com/Sgeo/cobweb/blob/master/cobweb.js/cobweb/Browser/X3DBrowser.js#L138 as it might interfere with detecting a change in reshape() ? And is done then in reshape() ? The canvas = canvas[0] is mysterious, ah it is a jquery thing. It is the dom element directly.
The minor advantage of having github release files is that it is not necessary to use rawgit since github serves those with the correct mime types. But having the just latest build in the repo would make it easy to try it out.
After some experimentation, it looks like the expected way to resize the canvas is to modify the style of the X3DCanvas element.
So in https://github.com/Sgeo/cobweb/blob/master/cobweb.js/cobweb/Browser/X3DBrowser.js#L136 changing from
that .getCanvas () .width/height
to
that .getElement () .style .width/height
and skipping the .addBrowserEvent() may work better.
I used a higher end system, and it could handle the larger canvas well.
I'm reenabling .min.js and .uncompressed.js. More recent commits than the build should fix some of the resizing stuff (I was failing to restore the original size at one point). I might experiment with the .getElement() approach. That .addBrowserEvent() was added so that there's at least one redraw, but maybe the resize makes that obsolete, I'll need to try it.
Unrelatedly, any thoughts on the center point for collision and gravitation? Currently it seems to effectively be at the center of the room, meaning if I walk with my HMD off a cliff, I don't fall. Should I consider trying to fix that?
Not sure how gravity and colliding are best handled in VR, in a room experience. A-frame probably has recommendations on colliding. As a starting point, it may be best to emulate walk mode and check what it does. Probably it is necessary to update the current viewpoint's position and orientation (in addition to the matrixes) but I did not look into anything.
I updated the tests to use the current cobweb.uncompressed.js :
https://rawgit.com/andreasplesch/cobweb/30f0502b067b991dccef4b995e5295b354d69114/cobweb.js/tests/VR/Basic_Inline.xhtml https://rawgit.com/andreasplesch/cobweb/30f0502b067b991dccef4b995e5295b354d69114/cobweb.js/tests/VR/world.html https://rawgit.com/andreasplesch/cobweb/30f0502b067b991dccef4b995e5295b354d69114/cobweb.js/tests/VR/Basic.html https://rawgit.com/andreasplesch/cobweb/30f0502b067b991dccef4b995e5295b354d69114/cobweb.js/tests/VR/PosInterp.html
Mouse type error is gone.
uses .style to resize the canvas to VR. This works a bit better for me.
The exact invocation became:
that .getElement () [0] .style .width = Math .max(leftEye .renderWidth, rightEye .renderWidth) * 2 + "px";
that .getElement () [0] .style .height = Math .max(leftEye .renderHeight, rightEye .renderHeight) + "px";
//that .addBrowserEvent ();
...
that .getElement () [0] .style .width = that .oldCanvasWH .width + "px";
that .getElement () [0] .style .height = that .oldCanvasWH .height + "px";
Slightly concerned about omitting the addBrowserEvent, in case by chance the render target is the same (mobile devices?) and thus no redraw in the world.
I noticed in your Basic_Inline, when I look at the floor, the color shifts. I don't think that should be happening, and I thought I resolved that issue.
Yes, ok. An explicit redraw is probably needed in that case.
has the explicit redraw.
The color shifting happens without the VR additions as well. It is the top of a floor box with default material. Let me add a material to the box or/and a light.
has a component of emissive (glow) color.
I updated tests to use v0.0.2 release:
https://rawgit.com/andreasplesch/cobweb/cc30beaeb64fae1fb88df65ddc33eb5b338d3d95/cobweb.js/tests/VR/Basic_Inline.xhtml https://rawgit.com/andreasplesch/cobweb/783c67d2ca2a16302d926d7931469d16ed898feb/cobweb.js/tests/VR/world.html https://rawgit.com/andreasplesch/cobweb/783c67d2ca2a16302d926d7931469d16ed898feb/cobweb.js/tests/VR/Basic.html https://rawgit.com/andreasplesch/cobweb/783c67d2ca2a16302d926d7931469d16ed898feb/cobweb.js/tests/VR/PosInterp.html
As you have observed, the camera seems very close and performance is degraded. Are you traversing for each eye separately now ? Only using the webvr emulator, I see that the canvas is now taking up the whole screen:
which would tend to slow down things. Manually, in the developer tools, resetting the canvas size to the original:
actually gets the frame rate back up, so I guess the large canvas is a factor. Also, the distance looks better.
While HMD pose changes are ok and lead to continuous updates, mouse interactions now provoke a type error:
c08d02e4-2ddc-11e7-83ac-e7fe94008dad.js?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAISTNZ…:53 Uncaught TypeError: Cannot read property '0' of undefined(…) assign @ …:67 traverse @ …:76 traverse @ …:67 onmotion @ …:67 dispatch @ …:50