-
-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BlockifyVR (Virtual Reality) #1732
base: master
Are you sure you want to change the base?
Conversation
that looks cool |
sadly i dont think that's possible to stop this. |
Does this show the same scratch 3D perspective to both eyes? |
A-frame has stereoscopic rendering built in and I've enabled it in the rendering settings, so no. This fixes some issues with visualizing depth, so the eye offset allows your brain to process the image with more clarity. Even if the matrices aren't used in the renderer, it should properly use the correct eye offset. Why do you ask, just out of curiosity? If you'd like I could add a block that disables or enables this feature, in case the Scratcher wants to build that framework themselves, which I'd doubt. Keep in mind this is still a work in progress and most of the code is many months old so it's not the most efficient way to do VR. |
Yes. At one point I tried to extend my AR extension to support AR headsets and VR as well, but the multiple eye rendering has been the main thing holding me back. I was just curious to know how you solved it. |
I believe that there can be two XRViewerPose matrices for each eye if available, according to Mozilla Docs. You might want to look into that again. It'd be great if Augmented Reality could support AR headsets such as the Oculus Quest 3 in addition to just mobile touchscreen devices. There should be a views array that can do this. An example can be seen here. Just a suggestion though. I simply think having AR headsets would be a nice update. |
This comment was marked as resolved.
This comment was marked as resolved.
I'll take a look when I have time. Thought it will probably be hard because the only kind of VR I have access to is phone-based 3DOF no controller VR. Also, do you mind giving some links, so that I can faster figure out where to look? |
This comment was marked as resolved.
This comment was marked as resolved.
As for VR testing, you wouldn't really need a VR headset. I've used Meta Quest's Immersive Web Emulator extension for testing when I didn't care to load up the entire headset. |
ah yes, I remember seeing a trailer for this on scratch. I wanted to help, but now I can't |
nvm I think I can |
This comment was marked as resolved.
This comment was marked as resolved.
Hi siskka7 it's me Thebloxers998 |
Hi, nice extension |
I took a look and have no idea. It's all code specific to AFRAME. I don't know AFRAME. AFRAME is too big and complicated for me to try to debug, especially if the only tool in my disposal is WebXR API Emulator browser extension. |
This comment was marked as resolved.
This comment was marked as resolved.
Nic3 |
Not supported by A-frame (or WebXR as far as I'm aware of) probably nobody using the extension has a full-body tracking suit and Oculus standalone full-body tracking isn't consistent.
No idea what this is about. I haven't really tested on PC VR as my main focus is standalone. The blocks seem to work fine for me and I've never seen multiple menu options selected in a scratch block. Sometimes pressing menu inputs in the oculus browser with the oculus controllers is a little tricky |
i did not mean pc vr but when i was coding this bug showed up (i use github to share projects) |
This comment was marked as resolved.
This comment was marked as resolved.
I just published a new release version here which should fix the issue with the "when button" blocks. Note that I haven't yet tested this to confirm it's working but it was working last time before I changed the inputs to accept reporters. I've reverted this change. Note that this release also brings experimental WORK IN PROGRESS changes to the "get matrix" block which SHOULD NOT be used. For now, the best alternative is to just use the default perspective projection Simple3D offers and use the "camera FOV" block with it. This will only work if you confirm your headset rotation transformations are computed in the right order (ZXY, with headset Y rotation as X and headset X rotation as Y in Simple3D, varies between renderers) |
here is my test project that logs vr input https://github.com/siskka7/siskka7/blob/main/vr%20blockify%20input%20logger.sb3 |
|
|
Dang, but how did it end up bugging. Did you check the logic of the block |
Progress UpdateSo turns out looking at the same 1700 lines of code for a year messes with your brain and makes you have dumb oversights that waste your time. The "when button pressed" issue wasn't actually there at all (the extension code was fine), but rather it was a unique, project-specific backwards compatibility issue with scratchblocks that resulted in my demo project after changing the acceptReporters property of the input. All I had to do was delete the block and switch it out with the updated one. I also think I fixed the matrix processing issue. I was previously using a A-frame component to attempt to get the pose from each frame and the xrReferenceSpace, but A-frame doesn't have any way to return the referenceSpace it's using internally - all the matrices I needed were stored in the @Xeltalliv since you originally wrote the the image is from my computer but when you use VR mode it looks really weird
I should have a new commit soon. |
@siskka7 you'd be pleased to know I fixed this issue too.. turns out when updating Scratch.translate() all of the values of the device menu where I think I need more sleep. |
• Removed redundant pose-matrices component • Re-wrote all of get matrix block • Added new camera FOV block • fixed issues with some blocks & other minor block changes
Also probably a Sample Project soon v1.0-release-candidate-4 is available here (latest release & commit above) |
Everything in the entire extension is now working as expected except for combined matrices. Projection and view matrices work as expected. |
just confirmed it also works in packaged HTML files |
forgot to mention that sample project is now available for testing at https://brackets-coder.github.io/BlockifyVR/project.html |
Just fixed combined matrices. Turns out the matrix name was matrixWorldInverse instead of inverseViewMatrix... these little oversights are the ones that get me. Working on adding menu button support for oculus-touch-controls then it's basically done |
I guess this is ready for review now? |
Yayyyyyyyy!!!!!!! |
I Happy Now :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have done some nice progress!
I guess but there could be more it doesn't have controller vibrations and the menu button on Oculus touch controls isn't supported but other than that it's basically done I guess |
So.... A-frame doesn't support detecting the menu button/pause button or the Oculus/system button on the I'm leaving the "menu" and "system" buttons in the menus of the blocks because they should still work on vive and windows mixed reality Which speaking of I need people who can test non-Oculus platforms because I haven't really tested them at all. Other than that I think this extension should be ready for release. I know a lot of them are busy but it'd be great if we could get some reviewers/moderators over here... this extension is moderately large so I expect it to take longer than normal to review |
Ok |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You've done some nice changes 👍
I think I'm going to make a few changes to make the code more "professional" and less messy but I can't right now so I'll get around to it when I'm less busy with other things |
BlockifyVR
This is a Virtual Reality extension I've been working on since January 27th of 2023.
The end goal is to have:
Here are some things to note:
Upcoming release plan:
v1.0-pre-alpha: Earliest version. Minimal functionality, proof-of-concept version. Not available here. Not open source.v1.0-alpha: work-in-progress. Expect significant bugs and poor performance. Should not be used.v1.0-beta: Cross-platform compatibility, major bug fixes, and optimizations have been added.v1.0-release-candidate: Current version. Feature complete. Meets standards of full release with minimal issues. During this release period, preparations for full release include gallery thumbnail, sample project, documentation, etc.
v1.0: First release. Feature complete and meets all standards of great performance, very few issues, cross-platform compatibility, and intuitive design.
v1.5: Bugfixes and optimizations. Possibly a small feature or change, such as controller vibrations.
v2.0: Big update. Most likely something like hand tracking support for some platforms. Also will include some minor bugfixes and optimizations.
v2.2: Bugfixes and optimizations.
Active Development
v1.0-release-candidate