GuriVR – Describe your VR experience and the editor will do the rest
gurivr.com
gurivr.com
I see a lot of potential to create and edit virtual worlds on the fly using things like NLP, big data, proc-gen, computer vision, etc. then expanding that into mixed reality.
In the other hand I'm playing with other kind of input, such as speech recognition, for in-vr authoring.
Source: I've done it both ways for several apps and people always complain, either way.
Having to click and drag in the opposite direction is pretty weird though. First person shooter style "move mouse left to look left / move environment right" is just mouse movements. You're not grabbing something to drag it, so there's no clicks.
Tough to translate that into a windowed thing where you can't do fullscreen mouse ownership like shooters do.
After all, when you press the button, the fingers close as if they are grabbing something in the scene. In real life, when you grab something and move it, it goes in the direction you move, not the opposite direction.
Someone correct me if I'm wrong, but I believe in large part it's gamers who tend to expect the reverse dragging. I think at this point far more people expect natural dragging as used in most online maps and street views, etc.
360cities used to have the reverse dragging, but I see they have changed it to natural dragging now. Try the panorama on their home page for example:
But the other thing I was told about gamers is that they don't expect to drag with the left button, but with the right button.
This suggests a possible solution: a left-button drag can use natural dragging, and a right-button drag can use reverse dragging.
The finishing touch would be to have the cursor change to something other than the closed hand when the right button is down. I'm not sure what a suitable cursor would be, but there must be something - anything other than the closed hand. Maybe a four-way arrow?
That said, I have no idea if JavaScript can capture the mouse like that.
https://developer.mozilla.org/en-US/docs/Web/API/Element/set...
Or for a capture that works even if the mouse button is not pressed, and remains until the Esc key is pressed:
https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Loc...
The first option would be the one to use for right button dragging.
Pointer lock should be done, but we count the desktop drag as a non-invasive preview mode, but experiences can implement pointer lock if they need.
What's right?
https://gurivr.com/stories/?token=PUraxsVQKdPcmD3wKd9uNC&uid...
They can both be made orders of magnitude faster simply by focusing on cache misses, branch predictions and data packing. But I don't see it happening without full rewrites in both cases.
We ended up writing a simple proprietary WebGL/WebVR renderer from the ground up - our scenes dropped from 18-20ms of CPU time to a very stable 0ms (and we made them much bigger as well.) Even the GPU time saw a big performance boost because we were using normalized integers instead of floats to reduce the vertex stream's bandwidth.
They're both good libraries to learn 3D and toy around with, but they're clearly aimed at beginner programmers with no or next to no experience in 3D graphics programming. Such a requirement goes directly against raw performance which requires loads of non-beginner friendly techniques.
Have you profiled any of them? They take at least an order of magnitude more CPU than required in the best of cases, not even counting wasted GPU bandwidth/cycles. Heck, babylon.js sets its active texture unit by string concatenation - I can't think of a less efficient way to do it.
Have you seen any other graphics engines to add weight to what you're saying? I spent a full week in both project's codebases to try and optimize them before giving up; like I said, both architectures cripple performance from the ground up. They're very naive implementations of very old ideas that haven't been used in game engines for at least a decade.
Don't be so quick to imply a lack of experience; it very well might just be the Dunning-Kruger effect at work.
Perhaps targeting mobile is a different story, mobile browsers are constrained. We built A-Frame on top of three.js, and we're able to build compelling 90 FPS room scale VR experiences running with the Vive in the browser. Perhaps it could be optimized, but it's worked wonderfully for our use cases. https://blog.mozvr.com/a-painter/
This is when we decided to write a custom engine tailored specifically for our needs based on my experience working with AAA game engines (I even shipped a title on the PSVita so had intimate knowledge of PowerVR and ARM architectures). And as I said in my original post, it is definitely not beginner friendly - while three and babylon both are.
It took about two weeks to write the core tech and it can only do what this specific project required. If not for performance issues on last-gen mobiles we'd never have rolled our own.
Desktop computers are incredibly fast - they can easily waste 90% of their CPU and still yield a lighting fast VR experience (for small scenes at least - less than a hundred draw calls). Mobile not so much.
I'm working in AR in a different space but as a longtime JS developer I would love to see this all come together.
[0]: https://www.youtube.com/watch?v=U6CpD4hVmqc&feature=youtu.be...
- CORS is a hard restriction for this tool. That's why I built the uploader into the editor. If you plan to do your own experience and can avoid it having your assets in the same domain on a CORS-enabled cdn please do
This being said, the A-frame community is the most welcoming I've ever seen