Ok, so I got BabylonNative to run on my iPhone (looks good) and on a VR headset (Samsung Odyssey using Windows Mixed Reality), so now that I know that it works, and has decent performance, I’m going to try and get Cryptovoxels running on BabylonNative (initially so I can put it in the WindowsMR store).
This is going to be my dev blog for that.
Day 1:
Missing APIs that I’ve come across so far that will take some work to fix:
The webworkers I can just move all the code to the main thread, and probably reimplement the voxel meshing (most expensive function we have) in threaded c++.
The canvas is a bit more problematic, I guess I can write some c++ code with SDL2 to generate the DynamicTextures we need.
No setInterval no problems!
btw if you want to contribute the support canvas we would love it 
Tried to fetch some urls and got libc++abi.dylib: terminating with uncaught exception of type std::runtime_error: unsupported URL. Added logging to xmlhttprequest to catch the offending URLs.
Woohoo! Loading up all the Cryptovoxels javascript and we’re rendering a skybox!
I was thinking of just implementing helpers to render the dynamic textures in pure c++ - but if I end up reimplementing the canvas API I’ll for sure contribute it. 
Ok, using the whatwg-fetch polyfill for the fetch api and it’s not firing off any XMLHTTPRequests.
Hi bnolan,
This is awesome! Just as a quick note in case you weren’t aware, Babylon Native intentionally avoids bringing in implementations of DOM elements as much as possible — hence the absence of Canvas and XMLHttpRequest. That’s just the core repo, though; plugins and polyfills are specifically intended to make it easy to bring in anything you want.
If you do end up wanting to make extension components, we have a relatively new quick-start guide in our docs for a pretty easy way to develop them. This also touches on a conversation about Babylon Native extension conventions that we haven’t explored yet. We want to make it as easy as possible for people to develop, use, and share extensions, but we don’t have any established conventions or known preferences for how people might want to go about that. Thus, if you do end up going down that road, we’d love to get your input on what the best approach might be!
