Thomas Fabini

A short addition to my previous post:

I did actually encounter a situation where I needed non-zero collision margins lately:
Trying to stabilize a physics simulation with small objects (around 10cm / 0.1 BU) gaining some speed by falling, I had to modify (raise) the value for the margins. With a zero margin the mesh collision objects where passing right through the floor.

Considering this, it might be actually beneficial being able to set specific collision margins for physics objects (mesh and primitives).

The only thing that actually helped, was setting the collision margin in combination with applying high angular and linear damping to reduce the speed.

I do not know if this is a proven way of stabilizing physics collisions with ammo.js, but up to this point I haven’t found another solution – open to any suggestions, as usual.

Hi Alexander,

Thanks a lot for looking into this.

Thank you very much for posting your setup…

nice setting the rotation only after the normals change, and setting the additional rotation after setting the direction to the pointer… Is it neccesary converting prevNormal to string before checking it against the current normal? Would checking array against array go wrong?

The setup I use was less slick and efficient, but from the basics pretty similar.
Today I took that into a separate testing scene it actually worked, but it really helped checking the setup against your approach and understanding it further.
The Raycaster seems rock solid, as far as I can tell, it returns definitely face normals unless “point” is checked. https://v3d.net/j2d

Hi kdv,

with your recent post I realized some serious errors in my setup – first one that I was feeding the raycaster the right object for the origin of the raycast, but a direction vector in world coordinates [0,1,0] which does cast, but always in y+ without rotating with the object…
So there’s that. Your info regarding the default raycast direction proved useful because that’s what it did when i fed the object’s direction, casting in y-.
About the point option, I’ve had it off (expecting face normals, instead a single point in space) an on, too – but with the current setup it’s really hard to tell the difference.

I will need to do some isolated testing next, take the raycaster features out of the current vr setup and check the basics in a simple test scene.

Thanks again for your hints!

Hi Alexander,

thank you very much for your reply.
I think it’d be awesome if Verge3D could handle this kind of collisions in the near or further future…

I have tested the room positioning mode, only to learn that the Quest 2 ignores completely which mode I choose. As far as I get it, it knows only two modes: “Roomscale boundary” and “Stationary boundary” of which the user has to choose one when using the headset. I assume these correspond with “room” and “sitting or standing”. The Quest 2 seems to ignore these settings in the WebXR app and goes with the internal setting.

Anyway, I couldn’t match probably the VR and real world space unless we rent a stadium or a larger hall :) . That’s why I added the controls for moving and rotation, while having the possibility to still walk physically within the defined boundaries.

For now I’m going down the road where I let the physics engine do the heavy lifting and push the entire scene farther when the user hits the walls. In a test setup, against my initial expectations the frame rate didn’t change at all when these collision occurred. But it is still unclear if it’s a real solution to the problem.

Anyways, I’d love to hear if you are implementing anything pointed in this direction or have any other suggestions.
Thanks,
Thomas