WebGL Water
madebyevan.com
madebyevan.com
But it is. This post by Nathan de Vries [0] shows how you can hack the UIWebView to enable WebGL contexts in your iOS apps. You have to get a little more creative these days (the compiler has gotten stricter about private types and functions), but all it takes is something like this:
-(void)setWebGLEnabled:(BOOL)enableWebGL forWebView:(UIWebView *)uiWebView
{
id webDocumentView = [uiWebView performSelector:@selector(_browserView)];
id backingWebView = [webDocumentView performSelector:@selector(webView)];
[backingWebView performSelector:@selector(_setWebGLEnabled:)
withObject:[NSNumber numberWithBool:enableWebGL]];
}
[0] http://atnan.com/blog/2011/11/03/enabling-and-using-webgl-on...
Of course, it would be better if Apple just tested the damn WebGL vulnerabilities. Not like they have to worry about many graphics cards.
1. so they could be prepared to rapidly enable it if market exigencies required them to (say, if webGL experiences for whatever reason started blowing up on competitor platforms).
2. they have some other, grander plan behind webGL that we don't know about yet. Maybe someday they want Xcode to be the premier web app dev tool
Remember this is from the company that developed Mac OS X in parallel for PowerPC and x86 "just in case"...clearly they plan for the future
[1] Insider cuts into Apple, peels off Intel Mac OS X port secrets - http://www.theregister.co.uk/2012/06/11/apple_project_markla...
Officially only available through iAd on iOS 4.2 and higher, for all devices
except for 2nd Gen iPod Touch or iPhone 3G and earlier. However, there is a tweak
for jailbroken devices to enable functionality for Mobile Safari and all other
WebKit browsers.
Today, even Microsoft supports WebGL with IE 11, so hopefully Apple activates it with iOS8...
One gets the impression that Apple feels WebGL is perhaps too much power in a cross-platform package. If you need to do 3D-accelerated GUIs or games on iOS today, you build an Objective-C app for the App Store because there's no other way to access those APIs. Is Apple protecting their lock-in?
EDIT: Added last sentence.
The App Store also provides marketing, which is huge. Where is the public listing of WebGL games that you can quickly browse and start playing?
I'm not convinced the App Store is a meaningful marketing channel anyway, except for the 0.001% of game developers that can afford to buy downloads and then happen to get lucky in the App Store curation roulette.
Considering that Mobile Safari has access to lots of confidential data (eg. iCloud keychain), and runs in a less restricted sandbox (can make data pages executable), that's probably the last place where Apple wants to try out some new technology.
EDIT: It's weird how iOS is now arguably the most secure mobile platform, after all the shit they got from Blackberry in the beginning :)
Security problems were pointed out to the WebGL guys a very long time ago and continue to be pointed out - they have not all been addressed (for whatever reasons - i don't want to imply that any of them are impossible to resolve) although extensions exist or have been proposed to resolve the more serious concerns.
This is quite well documented: http://www.khronos.org/webgl/security/
I'd be more inclined to think that Apple don't want to include WebGL for other reasons though. Their track record with technology is much less than encouraging...
There's not a tweak currently in Cydia for WebGL, because the last guy to do that was naughty [2] and nobody's published a replacement.
Both rpetrich and I have open-source WebGL enabler tweaks if anyone's interested: [3] and [4]
(I'm not sure if his works on iOS7, as the last commit was three years ago.)
[1] https://developer.apple.com/library/ios/documentation/Device...
[2] http://ryanhileman.info/posts/webgl
I don't like a lot of what Apple does, but I'm glad somebody isn't thrilled with the idea of "the browser" becoming the world's most Lovecraftian cross-platform runtime, even if it's only out of self-interest.
Writing a native application requires you to port that application to every conceivable app-store and platform in order to get it to run most places, this includes, but is not limited to: Writing it once in C++, once in ObjectiveC, once In java, package it for x86-64 windows classic, package it for x86-64 windows metro, once for x86 windows classic, x86 windows metro, Wart, Android, iOS, RPM, DEB, etc.
A native app also requires you to come up with a solution to windowing (on windowing platforms, such as WGL, GLX etc.), sound (alsa, openal, directsound etc.), input (xinput (X), xinput or directinput (windows), cocoa (osx) etc.), etc. etc.
It also requires you to come up with a solution on how to build guis, which a lot of games do these days by simply embedding webkit...
It also requires you to come up with a solution to scripting, which is already built into browsers, but nevertheless, many embedd anglescript, lua, etc.
Etc. etc. etc.
Why do WebGL? Maybe think about that again, really carefully.
How can you tell a tech company is dead and done for? It's when they stop pushing the boundaries, when they stop serving their users, when they stop inventing, when they stop competing. Because, they think they can afford it, famous last words of countless once mighty giants.
Jailbreakers have exploited vulnerabilities in FreeType of all things, but who cares, let's just give them more ammunition! I'm sure it will work out fine.
Apple: Dead and done for because they made a sane decision. You heard it here first, folks.
There are holes in every graphics driver and OpenGL implementation out there (it's practically unavoidable, as it's a fairly low-level API). To expose that layer of an operating system to any random webpage a user clicks on is utter lunacy.
"So don't visit those sites." That's like saying your operating system's security policy is "just don't go to bad sites and you won't get viruses!"
@pavlov I'm not happy about CSS3 animations or the abundance of Javascript you see today either, but that doesn't excuse people to pile even more ridiculous and insecure crap onto "the browser."
I was adding it to my original comment when the driveby downvoters arrived.
>Complaining about your phone's battery life when you can just as easily not visit the site has a lot less weight to it.
Do you really think that advertisers won't latch on to WebGL if it becomes widely adopted? I'm not "complaining" about the possibility of seeing some WebGL on $game_site, I'm worried about the inevitability of the banner ads that I already can't block on my phone suddenly becoming filled with eyecatching, battery-wasting 3D graphics, just as banner ads these days already use CSS3 animations to the same effect. I don't see why that isn't a valid concern.
Also, it's a matter of principle for me that apparently web developers don't agree with. I like the web as hypertext + the dumb terminal of our time. I don't see how things like WebGL benefit anybody but game developers and advertisers. Sometimes I feel like I'm the only one that sees the value in keeping the dumb terminal and the cross platform application API separate. We need both. There should be a simple way to run a game on all platforms (err, ignore for the moment that it already exists and is called SDL), and there should be some kind of easy-to-use "dumb" interface to society, but we're doing the world a disservice to combine the two.
Maybe I'm crazy, but I think certain vested interests are determined to turn the former into the latter, because they want to have their advertising pie and eat Apple's/Microsoft's/etc's app store pies as well. Maybe they were from the beginning, what with the talk of Netscape being at war with Microsoft.
The web is practically necessary to lead a normal life at this point. That people would focus not on taking the core of what makes the web actually matter for communication and as interfaces for the important services in our lives, making it simpler and more secure and more portable and easier to develop for, but instead on making it harder and harder to get down to that core, seems almost as wrong to me as banks in South Korea that require IE6.
That's the kind of principle I'm talking about. I understand if you don't agree with me; a lot of people have a lot invested in the web these days. However, I also don't see why I should have to bite my tongue about it.
@pyalot2 it's not FUD, because more code always means a larger attack surface, and OpenGL implementations happen to be a particularly large and historically poorly tested source of code. Bounds checking buffer accesses is an improvement but it doesn't magically make the implementations free of bugs. Check out this article from a while back on the state of OpenGL implementations for common chipsets used in Android devices, and tell me with a straight face you trust random webpages to talk to them:
The answer is the same one that would have been given to people in 1991 who were asking why Gopher wasn't good enough.
I think a better comparison is to the Java applets of the late 90s and early 2000s: Cool demos, cool games, totally pointless and enormous security vulnerability. But hey, the Runescape devs made a lot of money off of their Java-applet MMO back in the day, and someone will probably do the same soon with WebGL, and that's what the web's all about.
Not having WebGL is not a feature.
Fast forward a few years... any kind of AR or VR type content...
Edit: You might want to add some more visual feedback (e.g., blanking the email input field or hiding it) when you enter your email successfully on the front page of figma.com. I had to launch Firebug to make sure it accepted my email with a 200 OK because that check mark icon appearing briefly while the email field's contents stayed the same seemed suspiciously like a silent request failure.
* I know that shaders aren't guaranteed to execute on the GPU, depending on the OpenGL implementation. But for simplicity let's just assume they do.
The more general answer to your question is that in fragment shaders, you can get "non-locality" via texture lookups inside the shader code.
So you define a way to encode arbitrary non-local data as texture data, correct? That is, you're hacking textures as a store for arbitrary data instead of the image data that textures were originally designed to store?
I could see canvas extended to have 3D operations. Like say draw point takes 3 coordinates now. I can see a third party library that does 3D but projects it down to 2D and uses regular 2D commands on the canvas, or I see supporting WebGL interface and writing OpenGL style code.
I think that's the role WebGL essentially fulfills. It was just done in a way that uses OpenGL instead of reinventing the wheel, since a 3D rendering engine is a non-trivial thing to build. In other words, you can do either:
var ctx = myCanvas.getContext('2d');
// ctx has the 2d api
var ctx = myCanvas.getContext('webgl');
// ctx has the webgl 3d api
I think it would be a lot slower. Either way there's a 3D rendering engine. Embedding the engine natively and having GPU speedups is a dominating factor.
> or I see supporting WebGL interface and writing OpenGL style code.
See first point above.
*I'm a co-founder
[...] API that conforms closely to the OpenGL ES 3.0 API.If it was based on canvas and using that directly I would expect it to be an add-on library that takes a 3D scene for example and translates it to a 2D canvas commands.
It seems it is doing more than that though...
Back in the day computers didn't have 3D accelerated cards, it was all done on the CPU and there were enough 3D games that ran on them.
I can also see canvas API extended to have 3D operations on it.
It just seems WebGL is (was?) popular, lots of demos, but I still haven't seen too many industry uses of it and I have heard people at work claim "it is dead". So I was just wondering, ok, if it is dead is there any hope of having 3D accelerated graphics in the browser or is there something else replacing it.
* It seems a sibling comment answered my question:
IE5point5 50 minutes ago | link [dead]
> and I have heard people at work claim "it is dead".
Then people at your work are clueless I'm afraid
-----
My own startup's products use WebGL for simple GPU-accelerated 2D image operations (Bayer demosaicing). It even works on my Android phone.
So there are definitely companies making serious use of it.
We are in the BIM space and have one of the few web based viewers for such models. Some other products require a plugin to render 3D, but we really wanted to reduce friction to use our product, so we decided to go with WebGL. It's now supported in all 3 major browsers too.
One way you could hedge the WebGL vs. Canvas bet is to use something like THREE.js, where you use THREE's cameras, lighting, etc and then specify whether it should use WebGL or Canvas for rendering. But then again, you'd be betting on THREE.js :)
http://projects.propublica.org/nyc-flood/
If your data is inherently 3 dimensional I'd say it is worth the effort to dive in, but the majority of visualizations that we do are charts and plots which don't really need to be 3D.
The caustics are also pretty simple. Basically you take your heightfield mesh that represents the water surface and project each vertex independently along the ray refracted from the light through that vertex (using the vertex normal) and onto the pool floor. So you now have a mesh that is completely on the pool floor and contains lots of tiny triangles. To render caustics, just make triangles that got smaller brighter and ones that got bigger dimmer. I think I used the ratio of the projected area to the original resting area.
The reflection and refraction raytracing is all hard-coded for the geometry in the scene, which makes it really easy. It's just a simple sphere and box intersection test. The "ambient occlusion" is done by making parts of the objects darker when they get near each other.
State of the art for real-time water uses a full 3D volumetric representation for the water like in this paper: http://www.matthiasmueller.info/publications/tallcells.pdf. This lets you get waves that can fold over themselves like real waves. I haven't seen any other realtime methods that have caustics as good as the ones in my demo though.
If you look at the equations that govern the liquid surface, the assumptions that this model is based on are not that bad. Reality is a bit more complex, but the average-of-neighbors seems like a good start. Pretty simple too, which is always good computationally.
> The reflection and refraction raytracing is all hard-coded for the geometry in the scene, which makes it really easy.
Which reminds me...
Back in the days of 386 CPUs, I did a real-time 3D ray-tracer that drew a few spheres rotating around each other, with a fixed light source, and correct illumination depending on incidence angle at any point on the spheres. All on a 30 MHz 386 CPU, nothing pre-rendered, no assembly code, no GPU, running at high frame rate. Bricks where shat when people saw it.
The reality was that the math was highly optimized for that specific scene. I massaged the equations until I worked out of them all the expensive functions. No sin() or cos(). I think the worst thing I had was a sqrt(), and even that was used sparingly.
> The "ambient occlusion" is done by making parts of the objects darker when they get near each other.
You're basically modelling Le Sage's theory of gravitation, with surface illumination representing "pressure" from the "corpuscles".
http://en.wikipedia.org/wiki/Le_Sage%27s_theory_of_gravitati...
http://www.techspot.com/news/52326-watch-this-mind-blowing-w...
But besides that it is very nice.
[1] http://www.zdnet.com/windows-phone-8-1-the-latest-on-whats-o...
That being said it is easy to OOM mobile browsers with textures.
I wish Apple would activate WebGL on iOS...
Let's all bully Apple into supporting something over OpenGL 4.1.
the simulation using renderbuffers and float textures is cool - although the method used is ancient unexciting technology (see the water effect in winamp avs which uses the same trick in software 15 years ago) it makes sense from the webdev perspective of 'javascript is damned slow' - infact probably far too slow to do even attempt to do this CPU side.
the caustics are much more interesting though - firstly because i didn't know the trick already or re-invent it during my career or even know about the OpenGL ES extension that makes it practical (which is very very old on Desktop and very generally useful).
its always cool to see some raytracing logic applied with some cleverness applied to get some more mileage out of it at real time...
Edit: Tips below on enabling WebGL fixed it.
Should start working after a refresh.
Is there a better place to store GLSL shaders than in string literals?