Exploring bump mapping with WebGL
apoorvaj.io
apoorvaj.io
If the pyramid shape were to extend past the surface of the texture, it would look fantastic up until the point that the viewing angle of the surface would cause the pyramid to visibly protrude past the edge, at which point anything extending beyond those boundaries would be lost.
Here's a terrible mspaint example, please ignore my awful consistency, it's early and I've not had any caffeine yet.
In some games you'll see real subdivision surfaces which are even more awesome but somewhat expensive.
I remember being super excited when these features were making their way from software rendering to GPU years back. I would guesstimate a very large fraction of the perceived increase in game graphics have come from these techniques in recent years.
That is the driving force behind almost all real time graphics! Everything from rasterization to texture sampling to transparency, to this occluding parallax example - it's not exactly correct, but close enough that when used appropriately it is convincingly real and fast.
Cool! What games are using subds? I thought they were mostly relegated to offline use due to evaluation cost.
I'm all for cool OpenGL stuff, but there are much better examples of novel graphics stuff on places like shadertoy.com or https://experiments.withgoogle.com/chrome?tag=WebGL.
Here's an example of a blog post I wrote "repackaging" a technique:
http://roy.red/droste-.html#droste
Compare to the code I'd found on ShaderToy:
https://www.shadertoy.com/view/4tlGRn
Is it interesting if you've already spent time on this particular thing? Probably not. But it's meant to be a useful introduction, not a novel work.
Yes, except it's really a copy/paste job from learnopengl.com and other sources. It's actually not a useful introduction since it just parrots stuff that is already available on other sites.
For stuff that's novel, you could always browse through this year's SIGGRAPH papers. http://kesen.realtimerendering.com/sig2017.html
But they also probably weren't entirely satisfied with the documentation they found, ran into some stumbling points that took them too long to resolve, and feel like maybe people could learn from their experiences and avoid those pitfalls.
That's usually my motivation for writing a technical blog post. Sure, you might not be able to phrase it in a more succinct or comprehensible way than the tutorials that you used, but you can at least collate them in one place for others. And if nothing else, the process of putting together a detailed set of instructions to reproduce your efforts definitely helps reinforce your own understanding of the subject matter.
You put "blogs" in quotation marks, but then it kind of sounds like you describe a blog.