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.

Thomas Fabini

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 52 total)
  • Author
    Posts
  • in reply to: VR Controller Navigation (Quest 2) #71283
    Thomas Fabini
    Customer

    The trick is to perform rotation at the camera’s position point.

    I almost expected some matrix math voodoo for offsetting the transformation center… glad you didn’t :)
    Thank you very much for sharing this solution, i really haven’t thought about parenting the camera control object to an offset empty for the offset rotation…

    In my setup with the continuous rotation this could be harder to achieve since it would mean parenting and unparenting each frame / each simulation tick or maybe at least at each rotation start and end.

    But i still wonder if it’s not possible to change the coding for the camera control object so that it keeps always sync with the headset position in space when walking. I mean, wouldn’t that be the expected logic?

    in reply to: VR Controller Navigation (Quest 2) #71268
    Thomas Fabini
    Customer

    But it’s quite possible to make it work as needed.
    https://v3d.net/qef

    If i understand the problem correctly it’s basically a cyclic dependency in their relationship.
    I admire the problem, the answer still eludes me.

    Ah nice one! That really seems to work…
    Do you mind helping me out on this one?

    in reply to: VR Controller Navigation (Quest 2) #71265
    Thomas Fabini
    Customer

    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?

    in reply to: VR Controller Navigation (Quest 2) #71263
    Thomas Fabini
    Customer

    we’ll look into this!

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

    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!

    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)

    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.
    in reply to: VR Controller Navigation (Quest 2) #71220
    Thomas Fabini
    Customer

    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.

    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…

    in reply to: VR Controller Navigation (Quest 2) #68311
    Thomas Fabini
    Customer

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

    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!

    in reply to: Verge3D 4.4 pre4 available! #65367
    Thomas Fabini
    Customer

    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).

    in reply to: Verge3D 4.4 pre3 available! #64837
    Thomas Fabini
    Customer

    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. ;-)

    in reply to: Verge3D 4.4 pre3 available! #64834
    Thomas Fabini
    Customer

    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.
Viewing 15 posts - 16 through 30 (of 52 total)