Sgeo / cobweb

Cobweb WebGL X3D Browser
Other
0 stars 0 forks source link

v0.0.2 tests #5

Open andreasplesch opened 7 years ago

andreasplesch commented 7 years ago

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:

<canvas width="3024" height="1680" tabindex="0" style="display: block; width: 3024px; height: 1680px;"></canvas>

which would tend to slow down things. Manually, in the developer tools, resetting the canvas size to the original:

<canvas width="768" height="432" tabindex="0" style="display: block; width: 768px; height: 432px;"></canvas>

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

andreasplesch commented 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.

Sgeo commented 7 years ago

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.

andreasplesch commented 7 years ago

Sorry, I am not sure either. It is probably just a side effect of the resizing. Here is what I see in the emulator:

image

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.

andreasplesch commented 7 years ago

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.

andreasplesch commented 7 years ago

I used a higher end system, and it could handle the larger canvas well.

Sgeo commented 7 years ago

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?

andreasplesch commented 7 years ago

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.

andreasplesch commented 7 years ago

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.

andreasplesch commented 7 years ago

https://rawgit.com/andreasplesch/cobweb/7ca2575e7c40a67ca34aab0fcad3706b84127c70/cobweb.js/tests/VR/Basic_Inline.xhtml

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";
Sgeo commented 7 years ago

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.

andreasplesch commented 7 years ago

Yes, ok. An explicit redraw is probably needed in that case.

https://rawgit.com/andreasplesch/cobweb/f877a6840c94a9576af866c88a2fe11ad3d68cc8/cobweb.js/tests/VR/Basic_Inline.xhtml

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.

https://rawgit.com/andreasplesch/cobweb/d2f2c6272983b71db8ea4e887ff4c2344ebf96cc/cobweb.js/tests/VR/Basic_Inline.xhtml

has a component of emissive (glow) color.