We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.

Ok, I Agree

Thomas Fabini

Forum Replies Created

Viewing 15 posts - 31 through 45 (of 65 total)
1 2 3 4 5
  • Author
    Posts
  • 2024-03-01 at 12:53 pm in reply to: VR Controller Navigation (Quest 2) #71265
    Thomas Fabini
    Customer
    kdv wrote:

    Actually, it’s not a bug.

    …and that is the comment i was rather afraid of. ;)
    That’s why i wondered if it is to be considered a bug.

    It’s hard to wrap my head around the relationship between the headset and the camera control object: It is like a child relation when walking physically but a parent relation when pushing the camera control object around with the stick.

    Does the headset offset the camera inside the camera control object when walking physically?

    2024-03-01 at 12:07 pm in reply to: VR Controller Navigation (Quest 2) #71263
    Thomas Fabini
    Customer
    Yuri Kovelenov wrote:

    we’ll look into this!

    Thank you very much Yuri! – no need for a bug report, then?

    2024-03-01 at 9:04 am in reply to: VR Controller Navigation (Quest 2) #71254
    Thomas Fabini
    Customer

    That’s the comment i was hoping for… :D
    So in your opinion it’s rather a bug, then?
    Dunno if it can be fixed, but i’ll kindly ask Alex and Yuri if they can take a look at this.
    Thanks for your feedback kdv!

    2024-03-01 at 8:05 am in reply to: VR Controller Navigation (Quest 2) #71246
    Thomas Fabini
    Customer

    No not before. After entering VR, but physically making a few steps with the headset on, or in the browser dragging the headset in the webxr plugin interface a few meters away.
    In the example above it is (desktop) chrome with the webxr plugin for the controls.

    1. Enter VR
    2. Move (either physically with the headset on, or move (drag) the headset in the webxr plugin interface so it’s offset)
    3. Rotate with the right stick (either physically on the controller with headset on, or in the webxr plugin interface)

    2024-03-01 at 7:51 am in reply to: VR Controller Navigation (Quest 2) #71241
    Thomas Fabini
    Customer

    Start in https://v3d.net/qef VR mode with the headset offset 3m to the right (virtual_reality_1_VR_offset_3m_right.jpg).
    Rotate the view 90 degrees to the right (virtual_reality_2_VR_rotation_90deg_right.jpg).
    Rotate the view 180 degrees to the right (virtual_reality_3_VR_rotation_180deg_right.jpg).

    In https://v3d.net/ec5 it seems to be just the same. Offset the headset by 3m left on the green, rotate 180, you’ll end up on the right side of the pathway on the green.

    It happens only if you physically move the headset away from the point it was initialized when entering VR. Movements with the stick, where the camera control object coordinates get updated, are not affected.

    In my setup it is even more obvious since I am using continuous rotation. The farther you walk away from the starting point, the worse it gets. You start rotating in larger and larger circles.

    I assume, when walking in VR, without using the stick, the camera control object position doesn’t get updated. So it’s last (known) position in 3D space is used for the rotation.

    Ok, it’s arguably why you would need rotation when you are walking and not just sitting in VR (and for that, can turn physically 360deg)… but in my experience, anything that can go wrong possibly will, where clients or users are concerned. Its usually just a matter of time ;)

    Attachments:
    You must be logged in to view attached files.
    2024-02-29 at 12:05 pm in reply to: VR Controller Navigation (Quest 2) #71220
    Thomas Fabini
    Customer
    kdv wrote:

    Reworked VR controls. Can walk on inclined surfaces and stairs. Added rotation like in the home room.

    Hi kdv,

    cool setup btw. :)

    I’ve recently hit a problem with the rotation in my controller setup:
    It seems that the rotation center for the camera control object is local as long as the user stays in on place.
    When walking (physically) with the headset on, the rotation center gets offset to the point of initialization. Although your approach is a bit different and you are using change local rotation, it seems to occur in your app as well…
    In a browser with a webxr plugin enabled it seems the rotation gets offset after moving the camera (instead of moving with the controllers axes).

    Is this the expected behavior? A technical limitation? Or rather a bug?

    Anyways, always happy for some feedback that could shed some light on this.

    • This reply was modified 8 months, 3 weeks ago by Thomas Fabini.
    2023-12-12 at 8:29 am in reply to: VR Reticle Ray can’t be turned of when restarting XR Session #69108
    Thomas Fabini
    Customer

    Hi kdv, a late but very welcome reply ;-)
    I always used the hide puzzle with the reticles, completely unaware they could actually be removed. I’ll try that with the current VR project on 4.5.1.
    Thank you very much for pointing that out…

    2023-11-09 at 7:46 am in reply to: VR Controller Navigation (Quest 2) #68311
    Thomas Fabini
    Customer
    bigcatrik wrote:

    I couldn’t figure out how to address the Quest’s left and right analog sticks separately. This seems to address both controllers at the same time

    Hi bigcatrik,

    you should be able to address the thumb sticks’ axes separately by checking the controllers handedness (left, right) first. Numbers for the axes seem to be the same, while the handedness is not. I’ve attached an example from my project (right stick is used for walking and moving sideways while the left stick rotates the view).

    Attachments:
    You must be logged in to view attached files.
    2023-07-27 at 8:28 am in reply to: VR Reticle Ray can’t be turned of when restarting XR Session #65629
    Thomas Fabini
    Customer

    I did further testing, comparing the behavior under pre3, pre4 and the final 4.4.0 release.
    Basically the reticles won’t be turned off when returning from standby. Sometimes they stay turned off if you return shortly, e.g. less than 5 seconds, but they still are shown if you go into standby for more than 10 seconds.

    I assumed they were fixed in pre4 since they didn’t show, but that was probably just because testing with short standby periods. I really tried to pinpoint the exact circumstances, but I really can’t, it always is slightly different. The behavior described above is all I could somewhat safely reproduce.

    With the first tests I also had the impression that pre4 rendered an average of 2-5 fps faster than the final release, but after today’s tests I’m not really sure. Were there any significant changes between pre4 and final release which could affect performance?

    Btw., after installing 4.4.0 I had the problem ending up with a 0 byte v3d.js library when updating apps. Might be related to the license, while it still showed as valid (green), the problem went away only after re-entering the key. Just wanted to point this one out.

    Thanks,
    Thomas

    2023-07-25 at 1:17 pm in reply to: VR Reticle Ray can’t be turned of when restarting XR Session #65510
    Thomas Fabini
    Customer

    Hi Alexander,

    I’ve tested 4.4.0 pre3 and pre4 – which left me with the impression that you fixed some more glitches under the hood:
    in pre3 I had some occasional returning of the reticles (not when leaving VR, just when taking off the headset, which sent it to standby, and then putting it back on).
    In pre4 I tested recently and wasn’t able to find any situation where the reticles would return, once turned off with puzzles.

    I will get back with more info as soon as I’m able to test the 4.4.0 release.
    Anyways – thank you very much for the fixes!

    2023-07-21 at 8:49 am in reply to: Verge3D 4.4 pre4 available! #65367
    Thomas Fabini
    Customer
    Yuri Kovelenov wrote:

    We supported the margin parameter in the physics puzzles per request on the forums. As such you can now retrieve and assign margins in runtime–a feature that can greatly improve the stability and performance of physical simulations, especially involving mesh bodies.

    Hi Yuri, thank you soo much for adding physics collision margin getter and setter to the new release!

    I was able to upgrade our recent VR app with all its complex physics and everything worked right out of the box. I only had to update the parameter name in the puzzles which I had called ‘collision margin’ then instead of ‘margin’.
    (Thanks go out to kdv too for his suggestions and solutions which made this request even possible).

    2023-06-26 at 9:35 am in reply to: Verge3D 4.4 pre3 available! #64837
    Thomas Fabini
    Customer
    Ivan Lyubovnikov wrote:

    This is a bug that only happens in Puzzles’ performance mode. We’ll fix it in the next update, but for now as a workaround you can just disable the performance mode in App Manager’s settings.

    Hi Ivan, thank you very much for your fast reply – I switched performance mode off and everything’s fine now. I’m working with larger puzzles but using mostly Firefox might reduce any performance gain anyhow. ;-)

    2023-06-26 at 6:46 am in reply to: Verge3D 4.4 pre3 available! #64834
    Thomas Fabini
    Customer
    Yuri Kovelenov wrote:

    We fixed another issue with malfunctioning VR reticles occurred after the VR headset returns from the standby mode. Thanks for bringing this up on the forums.

    Thank you very much for fixing the reticles! I was able to test them with pre3 and they work like a charm. Hiding works when entering and exiting VR, as well as getting into and leaving standby on the Quest2.

    With pre3 I noticed that the blockly styles are using white backgrounds with a bright font color for the searchable dropdown lists on the dark theme, which are now hard to read. Is this possibly a bug which recently crept in?

    Attachments:
    You must be logged in to view attached files.
    2023-06-15 at 10:57 am in reply to: Verge3D 4.4 pre2 available! #64639
    Thomas Fabini
    Customer
    Yuri Kovelenov wrote:

    We fixed the bug with VR reticle which could not be turned off after re-entering the WebXR session. Thank you for reporting this on the forums.

    Hi Yuri – thank you so much for fixing this, wasn’t able to test the second pre-release sooner. Currently I’m using 4.4 pre 2 and it works like a charm.

    Regarding the reticles I have a question, though: when putting the Quest2 in standby and then back on (while in the VR scene) the standard reticles go back on and won’t turn off anymore, even if hide / get controller ray / reticle is called again .

    I assume this is an issue beyond the reach of Verge3D, more tied to the firmware of the Quest2 or the Oculus browser?

    2023-05-22 at 5:20 pm in reply to: Zero Physics Collision Margin for Meshes #63952
    Thomas Fabini
    Customer

    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.

  • Author
    Posts
Viewing 15 posts - 31 through 45 (of 65 total)
1 2 3 4 5