Thomas Fabini

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

Hi kdv,
when I tested your second variant, setting the zero margin for both, meshes and primitives seemed to affect collisions primitives in a negative way – meaning that physics objects with those collision primitives would sometimes fall through the floor while collision meshes where ok. Did you encounter this behavior, too?

It’s why I went with your first variant, the patched zero margin setting for mesh collision bodies before they are generated.

Nice find, thanks for having a look at this.
Hope the devs might take a closer look, too.

I’ve ran into these issues mainly with detecting collisions (“detect collision of”) to trigger further actions. They where triggering before the collision bodies where touching. So it was less about the visible margin around physics bodies which I observed only after.

I’ll run some tests, I strongly assume the detection in between mesh collision objects will be more precise which the modified margin.