Hacker News new | comments | ask | show | jobs | submit login
ASCII Google Streetview (tllabs.io)
200 points by divy on July 30, 2012 | hide | past | web | favorite | 42 comments

What is your algorithm for shading here? It seems like brightness is partially provided by the density of the characters (eg, '8' vs '.', as in normal ascii art), but also partially by the color of the characters.

From reading the fragment shader code, it seems to

a) sample a 4x4 grid of 2x2 neighborhoods

b) quantize the color to 3 bits per channel (so 512 colors)

c) "hash" (not really hashing) the "key" computed from adding up all the pixel neighborhoods and index into a lookup table: http://tllabs.io/asciistreetview/fontHash.png

d) use the green channel from the hash table to index into the font: http://tllabs.io/asciistreetview/8x8.png

It could be a little smarter about using the shape of the neighborhood to figure out which character to use, but it seems the lookup table is solely based on brightness, or I'm missing some subtlety in the code. It seems overly complex for what it does, but not for what it could be doing.

This was just a quick shader port/hack from an openFrameworks library I was working on. You can see the LUT texture generation here (which is done on the fly in oF): https://github.com/TeehanLax/ofxAsciiArt/blob/master/src/ofx...

All of this is pulled from Sol's TextFX library. The character bitmap actually doesn't line up to Sol's table, so that's why you see weird characters popping up in places. The main goal was just to get image to text working on the GPU. I've typically done it on the CPU. Over time I hope the mess gets cleaned up.

Ah, I see what I was missing: there are four components in the key (r,g,b,a), and each one corresponds to how filled-in each quadrant of the character is. But since each component is 0..16, and the hash table lookup is 256x256, shouldn't packColor be defined as (color.r + 16.0 * color.g + 256.0 * color.b + 4096.0 * color.a)?

If you keep zooming in eventually the perspective flips. As you keep zooming in more the perspective gets warped and it creates a bizarre fish-eye effect. I had about as much fun playing around with perspective warping as I did the finding things to look at in ASCII.

It's a pretty cool toy!

It's interesting that to me, this looks more "3D" than normal street view. I would guess it's the thing about the human brain filling in the detail...

Actually, that's not because of the ASCII, but because of the GSVPano.js demo that it's based on: http://www.clicktorelease.com/code/street/

Pick a location and compare it to the standard street view on google maps, and you'll notice a similar "more 3D" appearance.

The reason is that it's using three.js to map the panorama onto a spherical geometry. This is actually quite an old trick used to give a more immersive feel to panorama viewers dating at least back to the days of QTVR.

What a nice way to find out that my rather old Thinkpad (on Debian testing) now has WebGL support - I only updated everything from time to time, and apparently stuff actually started working. Great!

Great hack, too. I really, really want that thing as a screensaver!

I Agree, this would be a most excellent screensaver. Very impressive stuff indeed. If it run in VT220 I'd be starting a new religion on your behalf.

Be aware that this eats CPU (and probably GPU) and thus battery like mad. I cannot imagine it being a good screensaver.

How is it that this and GSVPano does not violate Google's term of service, since they pull images from Google's undocumented street view API? I have a related project, but am not sure if I can make it public because of this issue. Does Google simply not care?

They seem inconsistent in enforcing it. One piece of software that accessed it got a complaint from Google: http://igargoyle.com/streetview/

I was working on a similar project a while back, to view Street View through various filters (B&W high-contrast, pseudo-cyanotype, etc.), but I did it by pulling a few hundred images and caching them, to avoid hitting it in real-time, which I thought might be a problem. Given that I see several of these not being taken down, though, maybe I was too cautious.

Fwiw, Cyano-View Copenhagen was my project (hit "[reload]" at the top/right for a new random view, or scroll down for concept blurb):


I would guess google doesn't care for five reasons:

1. There's a documented API to fetch these images, but it's less convenient.

2. These demos make Google look good.

3. There's no potential to squeeze money out of the creators of these demos, because they aren't monetized in any way.

4. Shutting down people who are playing (relatively) harmlessly with their technology would hurt Google's community image.

5. The demos are of no practical use, so if Google breaks compatibility, nobody will care.

So if you look at the costs and benefits, it would be unwise for Google to crack down on this sort of thing. But if you started selling an iOS app that used this, I'd be shocked if they didn't smack you down.

Very cool! I wrote some quick and dirty code that adds some functionality to the page: http://pastebin.com/FZGwjJvv . It should work if you have a javascript console or greasemonkey or something like that.

h - Toggle visibility of the HUD (minimap and information)

space - Toggle the rotation on/off

- (numpad) - Slow down the rotation (slowing below 0 reverses rotation)

+ (numpad) - Speed up the rotation

- (main keyboard) - Lower the delta by which the rotation speed is increased/decreased (default delta is 0.005, lowers by 0.0001)

= (main keyboard) - Raise the delta by which the rotation speed is increased/decreased (default delta is 0.005, raises by 0.0001)

Might I suggest warp speed? ;)

I'm on macbook with nvidia 9400m, only works on Firefox. On Chrome (latest) and Safari, it doesn't show anything. I wonder why WebGL isn't working on these browsers.

These MacBooks have dual graphics chipsets don't they? So does the HP Envy I'm using now. Chrome has a built-in list of chipsets on which it disables WebGL. It detects the onboard Intel chipset as on that list and disables WebGL even though the ATI Radeon chipset I'm actually using at the moment would handle the site easily. I'm guessing it's the same situation on your MacBook.

You can probably manually flip a setting in about:flags to turn WebGL back on. I just switch to Firefox to check out the demos.

> These MacBooks have dual graphics chipsets don't they?

My 13" does not: 9400m is the sole GPU. I get the same blackness on Safari 6 despite WebGL being enabled. WebGL works otherwise [0], albeit it seems much slower than before.

[0] http://madebyevan.com/webgl-water/

You might have to enable WebGL in Chrome and Safari. They usually default WebGL to off for me when they update for me.

From my boy Hakim in May, 2011 - http://hakim.se/experiments/textify Not sure how the approach differs technically, but obviously a different stylistic feel per the translations.

And I'm glad I read the comments and played with the zoom. Drastically changes the effect ... very much like a video-game world with incredible detail.

Looked pretty cool but it slowed down my work computer so bad that it practically crashed it.

And this box is an i7 with 10GB of memory...

But do you have a GPU on it, and if so how powerful is it?

My Macbook Pro handled it with no noticeable slowdown.

It is WebGL so it would require a video card.

This look pretty good, but is there any way to turn of the default scrolling behaviour? Kind of makes me nauseous.

Are the start locations completely random?

I ask because the 3-4 times I opened it, the start location looked absolutely stunning

Also: My laptop usually have issues with WebGL sites, they crash or run really slow. This is smooth as can be!.. Great work

edit: people are talking about zooming.. How do you zoom?

Upon startup it picks one of the following locations at random:

  lat: 40.759011, lng: -73.98447220000003
  lat: 37.785747104443196, lng: -122.40620172951662
  lat: 39.36382677360614, lng: 8.431220278759724
  lat: 50.09072314148827, lng: 14.393133454556278
  lat: 35.69143938066447, lng: 139.695139627539
  lat: 35.67120372775569, lng: 139.77167914398797
  lat: 39.907974000227846, lng: -118.82814144140627
  lat: 38.897556289243894, lng: -77.0365502699753
  lat: 51.509651382445206, lng: -0.1184348782348934


  New York (Times Sq)
  San Francisco (Union Sq)
  Tokyo (Shinjuku)
  Tokyo (Shintomicho)
  Nevada desert (I-80 east of Reno)
  Washington (White House)
  London (Waterloo Bridge)

>people are talking about zooming.. How do you zoom?

The scroll wheel.

EDIT: If you keep zooming you can fisheye everything inside out.

This is the dopest WebGL application, IMO.

Totally loving this, including the green mode.

Totally agree.

This has the potential to be the first real-life gta-ish matrix racing game.

If you're lucky, your personal skin is already available as driver model.

If you zoom out, it gets quake-ish.

Looks like effects from Matrix in green

I see nothing.

If you are using a supported browser and WebGL is enabled, make sure to also enable javascript if it's disabled, then reload and wait a minute, took a little while to load up.

Do you have WebGL enabled?

The site is incredibly unfriendly to mobile. You can't use it from an iPhone.

I'm not sure why I'm being down-voted, is it frowned upon to complain about that? I'm simply stating that the site is unusable from a popular mobile device. Sometimes the site maintainer reads the thread and he might not be aware.

WebGL isn't really supported by any mobile device.

Great work!




it hurts my eye.

Is that you, Cyclops?

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact