John Carmack, a brilliant, gifted developer, recently said this about V/AR, and it continues to bother me:

I remain unconvinced that mixed reality applications are any kind of an engine for increasing headset sales. High quality pass through is great, but I just don’t see applications built around integrating rendering with your real world environment as any kind of a killer app. I consider it interesting and challenging technology looking for a justification.

But we already have mixed reality applications. AirPods in transparency mode are one, but even transitor radios at baseball games in the late 50s. Telephones? They don't render sight, but they do render augmented soundscapes. Ask the blind if a sightless world counts as a reality.

And what are our phones? They aren't VR. They do interact. Take the blue dot on a map -- or the location-based notifications we get walking into an Apple store.

Do I just not understand what Mixed Reality is? Tom's hardware tries to explain:

Virtual reality (VR) is a fully immersive world that is created by hardware that does not bring in elements of the real world.

...

Augmented reality, meanwhile, is the other end of the spectrum — which Microsoft refers to as the mixed reality spectrum. Augmented reality (AR) basically adds digital overlays to the existing real world.

...

Mixed reality (MR) lies somewhere in between the two. It adds overlays and real-world objects into a virtually rendered world. Intel actually describes it really well. “You can play a virtual video game, grab your real-world water bottle, and smack an imaginary character from the game with the bottle.” In proper mixed reality, the lines completely blur.

If you say so. I mean, our location is already "mixed" into the virtual world of Pokemon Go. And as much as you try, if the imaginary character tries to let you drink out of their imaginary water bottle, you'll stay thirsty, my friends.

MR seems to be another way of saying "AR, but, like, really augmented".

So I'm back to wondering what Carmack is talking about.

Maybe it's the immersion. There, I'd tell him to lower his bar. You don't have to have Apple Vision to have mixed reality. Again, any interface that puts the digital into the "real" works. The McDonald's app that lets you order food. Your EZ Pass transponder.

Does Mixed Reality require glassses? Then why doesn't it require earphones? How about gloves and sleeves and suits that remediate touch? Is his argument that AR glasses aren't MR enough and are, therefore, doomed to fail?

If so, the critique reduces to the absurd: "There is no MR killer app until the digital IS REAL!!1!"

I think his metric for MR success is literally what he says -- "headset sales". He'd say, sure, MR sells phones, radios, EZ Pass accounts, but not glasses. It'll never sell glasses.

I'm wearing glasses typing on a laptop right now. If I could get my phone and computer into that same shape without a concern for weight or power (or eyesight), I would. The potential isn't just there, it's at least as big as the market for glasses.

I don't know about Carmack, but I'm glad Apple has started looking for a way to make those glasses happen.

Labels: apple, apple vision, AR, business, johnc, VR

On Windows, I have two tools that get a lot of work when I'm ready to check in files:

1. Merge tool: KDiff3 -- since 2012, it appears.
   
2. Diff tool: WinMerge -- more recently; used to use KDiff3 for both
   

The WinMerge usage is recent-ish. When you want to compare two files and two files only, its simplistic UI is refreshing compared to the busyness of KDiff3.

One problem: KDiff3 uses KDE and is available pretty much everywhere. WinMerge is, um, Windows specific.

When I'm on macOS, I've been using BBEdit (nee TextWrangler) in place of WinMerge more recently and, I've found, you can use BBEdit as your official diff tool in SourceTree now too with a dedicated dropdown option.

One problem: SourceTree puts the more recent file on the left in BBEdit for some reason. That's not how SourceTree does it with WinMerge.

How do I swap that? Funny you should ask... Just ran into this SourceTree help request today that happens to show exactly how...

I spoke to BBEdit about this and they reminded me of the solution I had (with their help) implemented previously, before SourceTree added BBEdit to the official part of the external diff menu. I pass it along here, in case it is helpful:

in the "Diff Command" field, it needs the full path to bbdiff, e.g.

/usr/local/bin/bbdiff

I had been just putting "bbdiff" and that may have been the full problem I was having. In the "Arguments" field I put "--ignore-spaces --wait $REMOTE $LOCAL" and that seems to work well.

That still puts the newer edit on the left, but that's easy to fix. Swap $REMOTE and $LOCAL and...

Success. That's a nice, usable working environment I've almost got on macOS. 😉

Labels: BBEdit, git, macOS