Flat Surface Shader
wagerfield.github.io
wagerfield.github.io
> HTML/CSS nonsense
Structured and well declared markup is no joke. If you actually refer to the common "hacks" to get demos and eye-candy stuff working, then I do agree. On the contrary, if you refer to ditching all HTML and CSS in favor of WebGL, then we're fucked.It's just one of the many examples of how broken HTML and CSS are. I dare say that anyone who claims that HTML and CSS aren't completely broken simply has absolutely no imagination and should consider accountancy.
On WebGL, we can reinvent presentation and styling entirely without sacrificing performance. Maybe keep parts of HTML, and ditch CSS entirely in favour of something better, and use a JS lib to render it all on GLES hardware, the same in every browser. Designers can think about different devices and screen sizes, and not about ways of telling a browser that a div is secretly a table cell so that it can be centered. We now have many competing programming languages, competing frameworks, and so on, with a few mainstream ones and improvements/replacements all the time. Rendering entire websites in WebGL enables having the same world-wide innovation in presenting web sites and web apps to users.
But even if you don't think going all-in on WebGL is a good idea, you have to agree that HTML/CSS is a gigantic 馃挬[2].
[1] https://news.ycombinator.com/item?id=6191350 [2] http://www.fileformat.info/info/unicode/char/1f4a9/browserte...
While HTML/CSS has serious compatibility and expressive issues, it's moving in the right direction very quickly. WebGL will be fantastic for gaming and visualizations, I think it is very much inferior for web pages & applications.
I'm not sure I follow you when you say "keep parts of HTML". Are you suggesting that we should have a canvas element that spans the entire region of the page, store the actual markup of the page hidden somewhere on the page, and then parse and render that markup to the canvas element using JS+WebGl+<some CSS alternative>? Or are you saying that the browser should simply give up on rendering HTML markup, and give it over to your JS App which will render it itself using WebGL?
> We now have many competing programming languages, competing frameworks, and so on, with a few mainstream ones and improvements/replacements all the time. Rendering entire websites in WebGL enables having the same world-wide innovation in presenting web sites and web apps to users.
If the rendering is done in user/app space, I find it hard to believe there would be any uniformity at all. Everyone would end up having their own unique dialect of HTML that behaved and displayed differently in their own customized WebGL based rendering engine.
EDIT: Disregard that last bit, I misread what you were saying to imply that it would be more uniform than what we have now.
Because of this, it really makes no sense, in the context of an HTML document, to center something vertically--it'd just end up at some arbitrary position on top of some paragraph in the middle of the page's content, found after N/2 screens of scrolling. This is what separates an HTML document from, say, a PDF: PDF pages don't reflow, each one has a fixed height, so there is such thing as the "center" of a page on a PDF.
If the web were like PDFs, sure, it'd be easy to render it all using WebGL. But try imagining, now, writing an interactive text-layout-and-reflow engine in Javascript, to render web documents onto a WebGL canvas. How would you specify the constraints for that engine to follow? Some sort of declarative markup language based on a box model with paddings, borders, and margins, perhaps?
---
Now, on the other hand, web applications tend not to care so much about the shape of any "document"--what they're interested in is the shape of the viewport. That has completely different semantics, and can be done easily in WebGL ("viewport" being a jargon term in GL.)
But... web applications tend to embed, and rely upon, the reflow semantics of web documents surprisingly often. As soon as you want to include any controls with user-contributed content, you need that rich-text layout engine, and you can't just pre-render it all to a canvas to bring it in, since users will want to copy and paste text from it...
You don't have to throw out the whole shebang to fix that class of issues :)
Doing layout and capturing input events on elements in Javascript instead of native code, without performance loss? Nah. Maybe you can do it in shaders, but that still sounds like the bad old days of flash, of binary blob websites without accessibility. I'd be glad to be proved wrong, but it just sounds horrible.
Oh, but WebGL games need good UI toolkits either way, so at worst, any such stuff would still be useful for that, even if not for general websites.
I would personally like to get rid of the presentation layer, not because I hate art(I do lots of web design and development) but because it's an enormous waste of time for the users, creators, and traffickers of those data.
I would prefer to read all blogs the same way I read IRC, email, XMPP, source code, logs... And I mostly achieve this, but addiction to the presentation layer on the web prevents me from having this typographic and stylistic consistency for blogs, news articles, and the whole shebang.
Before trying to convert the concept of modal dialogues and print ads to the web, ask yourself if this is what you really wanted.
Webapp developers can just ship the browser (or, well, the renderer) with the application.
All it's doing is lighting each tile individually. It's a throwback to the per-tile lighting of ascii roguelikes (http://osx.iusethis.com/screenshot/osx/brogue.png). So each square chunk on the wall gets a single amount of light and color evenly distributed on it. That's it. Also, there are shadows on top of them.
The props (torch and statue) have a banded light shader on them. It's just standard diffuse lighting but clamped to a certain set of values.
I loved Dustforce too. Keep up the good work.
http://blogs.msdn.com/b/sean_mcdirmid/archive/2009/07/27/a-w...
I'm not sure if it was useful though.
What is meant by that? WebGL does seem to work here as in the appearance and frame rate are the same compared to SVG but with less CPU usage on my machine/browser (Chrome).
I think WebGL has a lot of potential, feel free to check out my hackish background bump mapping @