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 - 1 through 15 (of 29 total)
  • Author
    Posts
  • 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.
    in reply to: Verge3D 4.4 pre2 available! #64639
    Thomas Fabini
    Customer

    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?

    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.

    Thomas Fabini
    Customer

    Hi Alexander,

    thank you very much – I am really glad it is fixable, because I wasn’t able to find any reasonable workaround for this.

    in reply to: Zero Physics Collision Margin for Meshes #63531
    Thomas Fabini
    Customer

    Hi Alexander,

    Thanks a lot for looking into this.

    in reply to: Align Euler Rotation to (Raycast) Vector #63511
    Thomas Fabini
    Customer

    That’s one of workarounds in JS to compare two lists (arrays) .

    That’s something I wasn’t currently aware of – thanks for the explanation.

    Today I got the whole raycaster setup finally working. At the end things got funny when the raycaster hits rotated objects, specifically dynamically rotated ones, or child objects of rotated parents.
    What worked was adding the rotation of the raycast target object to the normal direction while setting and getting all rotations in world space. What helped, too was setting child objects to the -y (as the default raycast) world orientation before parenting.

    There is still an issue which might relate to Euler rotations and gimble lock, in my setup I can work around it. When it gets to math and vector math my brain goes like “just keep looking for a solution – I’m taking a break “.

    in reply to: Align Euler Rotation to (Raycast) Vector #63365
    Thomas Fabini
    Customer

    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

    Attachments:
    You must be logged in to view attached files.
    in reply to: Align Euler Rotation to (Raycast) Vector #63346
    Thomas Fabini
    Customer

    I realized that right after sending the post, obviously… duh.
    It works flawlessly and beautiful, definitely face normals – your solution is based on puzzles I assume?

    I’m trying to achieve similar features, only not raycasting from camera / mouse but cast from an object and based on it’s direction in 3D space, and besides maybe some modifications to the cursor based on the uv coordinates returned by the raycaster.

    Anyways – your suggestions and findings lead to the conclusion it’s possible, even with puzzles.

    in reply to: Align Euler Rotation to (Raycast) Vector #63330
    Thomas Fabini
    Customer

    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!

Viewing 15 posts - 1 through 15 (of 29 total)