nobbis

The "native WebGL bindings" still call into JS.

Desktop GL emulation is just a layer on top OpenGL ES if, for example, you're still using OpenGL's fixed function pipeline (deprecated 13 years ago.)

You're correct. WebGL does require extra validation compared to native GL, but it's effectively the same API as OpenGL ES 2.0/3.0 and Emscripten handles the translation from C/C++ for you.

There's some overhead but it's negligible (assuming you're not making overly redundant API calls.)

Is this AR/VR? It looks like 2D circuit schematics.

As a counterpoint, I've enjoyed building VR on the web using C++ (with WebAssembly/WebGL/WebXR) and not having to touch the DOM or JS, see: https://twitter.com/nobbis/status/1425266634982248451

Benefits include complete control at frame and pixel level, being cross-platform (same code runs on web, iOS, macOS, Linux), and having access to third-party C/C++ libraries for 3D graphics.

Yes, different failure cases (purely vision can't tell the depth of a plain white wall) but there are orders of magnitude more pixels in regular cameras. Apple's LiDAR produces a 256x192 depth map, but its RGB cameras run at 1920x1440. You get much more detail, but passive stereo is orders of magnitude slower (ToF sensors are 60 Hz, photogrammetry takes minutes.)

They complement each other well, which is the basis of our approach at Abound: combine the detail of multi-view stereo for short-range with the robustness of ToF out to 5m.

Cubify was a rebranded Structure Sensor, which was a Primesense camera, which was the original Kinect (that Apple bought in 2013.)

It used structured light: project a static pattern of infrared dots and then measure parallax using an infrared camera a couple inches from the projector to calculate depth. It worked well, but can't be miniaturized as it relies on a large offset between projector and camera. Orbbec make similar cameras today, e.g. https://orbbec3d.com/product-astra-pro

Modern depth cameras, like the LiDAR Scanner in iPhones and iPads, use a different technique: time-of-flight (ToF), which shoots laser pulses and measures the time taken to reflect back to infer depth. Apple leads the field here, because they're the first to integrate a "direct" ToF sensor into mobile devices, which has a number of advantages over the "continuous wave" ToF found in Android phones.

FYI, NZ is multiple islands the size of the UK with a population 15x that of Iceland.

How does the accuracy of your system compare to ARKit’s people/skeleton tracking with the LiDAR Scanner in the new iPad Pro?

For comparison, here's the PR1 from 12 years ago:

https://www.youtube.com/watch?v=oyHWkQcin7I

His personal blog post has eight obtrusive ads plus a Donate button (to an engineer in finance in London.)

I get the sense the author's deliberately stirring controversy.

NZ was a few days after Germany, yes, but it's a very isolated country.

Germany locked down after almost 100 deaths (and 20,000 cases.)

NZ locked down as soon as community transmission was detected (2 cases out of 50 total were untraceable.) No deaths yet.

As a Kiwi living in NYC, I'm impressed by the "go hard, go early" approach the NZ government has taken, compared with the delayed response here.

NZ also has easily enforceable border control (surrounded by the Pacific ocean) which is already strict (their economy is so reliant on agriculture exports.)

They should come out of this better than most.

It was the first self-driving car project to cause established companies to take notice and start investing heavily, kickstarting the industry, which was my point.

Other co-founders, yes, but Anthony was overall product lead. The article goes into detail.

Google's SDC efforts are rooted in Anthony's work: he helped kickstart the entire industry. Mark Harris broke the story here: https://spectrum.ieee.org/robotics/artificial-intelligence/t...

I don't know what IP is in question, but it seems to me that he had been working in AVs longer than almost anyone in the industry, so it's believable that Uber was valuing the Otto team's accumulated experience, rather than any stolen ideas.

Got it. If you’re just listing open source photogrammetry software, there are many more you can add, e.g. Regard3D, OpenMVG.

I find COLMAP has better dense depth maps, a more configurable pipeline, is cross-platform, the code is solid, and the accompanying research is principled (it takes a Bayesian approach to stereo matching.)

What aspects of these make them great alternatives in your opinion?

Range is too limited, it's front-facing (can't see what you're scanning), and the OS-provided SLAM system isn't available (so tracking error accumulates.) Issues that will disappear in the long-run, of course.

One startup taking that approach is https://standardcyborg.com. Apologies if linking to a business is unseemly - they are YC-backed at least.

Yes, we support Laplacian filtering of the level set prior to meshing in the SDK (plus other mesh smoothing techniques.) There are trade-offs involved.

Another great free alternative is COLMAP (https://demuc.de/colmap).

And for those interested in doing this on mobile in real-time, we've just released a beta SDK (https://abound.dev) that lets you add real-time photogrammetry to any iOS app.

VIX is a variance swap, so a "CryptoVIX" would move in line with the expected short-term realized volatility of a basket of cryptocurrencies, not their price.

It'd certainly be possible to price such an index (replicating strategy of portfolio of strips of calls/puts of various cryptocurrencies) but it'd be impossible to hedge because transactions costs are too high. You could hedge with crypto-options, but AFAIK they don't exist yet.

Photorealism (or "better rendering") doesn't mean perfect imaging. You can model the radial distortion, rolling shutter, Bayer filtering of cheap webcams in 5 lines of code.

A better simulation is closer to reality, not closer to an ideal.

It's the opposite. Simple rendering makes pose estimation harder, not easier - texture and shadows resolve depth ambiguity. So it's easier to show you've "closed the simulation-to-reality gap."

Trust Google to look at their c. 1993 gouraud shaded, untextured renderings without shadows and conclude "let's use deep learning to make it look realistic!"

I commented here on Tango 3.5 yrs ago: "remains to be seen if Google can persuade cellphone manufacturers to include 2 special cameras + 2 extra processors in their future devices." Looks like that was the case.

It appears the ARCore API is well designed and 1-1 feature equivalent to ARKit, i.e. VIO + plane estimation + ambient light estimation. The API's even share a lot of names, e.g. Anchor, HitTest, PointCloud, LightEstimate.

Now that stable positional tracking is an OS-level feature on mobile, whole sets of AR techniques are unlocked. At Abound Labs (http://aboundlabs.com), we've been solving dense 3D reconstruction. Other open problems that can be tackled now include: large-scale SLAM, collaborative mapping, semantic scene understanding, dynamic reconstruction.

With Qualcomm's new active depth sensing module, and Apple's PrimeSense waiting in the wings (7 yrs old, and still the best depth camera), the mobile AR field should become very exciting, very fast.

We're planning to bring occlusion to ARKit with Forge. The accuracy can't match a depth camera, but still plenty of use cases. Here's an example on a Pixel:

https://www.youtube.com/watch?v=K9CpT-sy7HE

450 lbs, not 480 kgs. The main power draw comes from the 2 desktop computers sitting in its base. Runs for ~4 hrs if you turn one off.

Economists were modeling the economy using circuits in 1949 (see MONIAC), before the Integrated Circuit was even invented.

Magic Leap got $50M first round funding to do just that:

http://www.nytimes.com/2014/07/15/science/taking-real-life-s...

Project Tango has a 320x180 depth sensor running at 5 fps, i.e. 290k depth measurements per second. Compare this with off-the-shelf depth cameras (e.g. DS325) that generate 320x240 at 60 fps, i.e. 4.6m measurements per second.

The reason for this is that mobile processors aren't fast enough to process more information. So the Tango prototype has to have, in addition to its depth camera, a special motion tracking camera with a fish-eye lens and 2 dedicated processors in order to robustly track.

Even then, with less depth information, the quality of any Tango reconstruction will be far inferior. Maybe in 5-10 years, mobile processors can approach what desktop GPU's are capable of today.

In any case, it remains to be seen if Google can persuade cellphone manufacturers to include 2 special cameras + 2 extra processors in their future devices.

My understanding is the Leap Motion is a wide-angle stereo IR camera. It's built to detect fingers/hands/pointers, and doesn't produce a depth map so can't do 3D scanning.

A sensor with a similar form factor is the CamBoard pico, which does produce depth maps. I don't think it's shipping yet.

http://www.pmdtec.com/products_services/reference_design_pic...