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.
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.
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.
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!
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)
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.
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.
New York (Times Sq)
San Francisco (Union Sq)
Corsica
Prague
Tokyo (Shinjuku)
Tokyo (Shintomicho)
Nevada desert (I-80 east of Reno)
Washington (White House)
London (Waterloo Bridge)
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.
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.
