More and more I'm noticing "blogs" and "articles" that feel like repackaged content from other sites. This article seems like a regurgitation of information from learnopengl.com, and as such it doesn't feel noteworthy or even interesting.
Unless you've already internalized how this stuff works, ShaderToy code is pretty incomprehensible. Some of it is commented, most of it isn't, and even then, GLSL is not a great literate coding language.
Here's an example of a blog post I wrote "repackaging" a technique:
<< 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.
A lot of the shadertoy stuff is iteratively built making it even harder to tease apart. A sophisticated demo may contain a 3d noise function, a ray marcher, a signed distance field approximator etc... and there's nothing like library separations.
Well...sure, that's fair, but I'll bet these are mostly people who are interested in the subject and trying to learn more about it. They probably used a smattering of those resources to pull their examples together, and plan on using it as a foundation for more exciting things.
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.
I found this to be a very well-written piece with a nice live demo. That's valuable. Having a few explanations of the same thing is good for learning, especially when they are at varying levels of detail.
Wow! Parallax occlusion mapping looks almost exactly like extra 3D detail on the model. Though I guess it wouldn't work if the details were sticking out of the face, or otherwise changing the silhouette? Is that why the demo uses a cube with concave faces?
This kind of mapping hit mainstream a few years ago. Look at the ground in most games, it's not actually 3D but does a damn good appoximation.
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.
Too lazy to check my games right now but the Unigen Heaven benchmark was the first time I saw "tesselation", which used to be known as displacement mapping in software rendering days. Crank that thing to max and wander around a bit.
> it's not actually 3D but does a damn good appoximation
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.
That is not the same thing. Polygons exist in 3D space, this is a technique using a shader to fake render a surface within the bounds of the polygon that is actually being rendered.
Yes, you're entirely correct - that is precisely why it's concave - as Parallax mapping is purely the illusion of depth, instead of adding any actual depth or height, this means that the perceived depth effect is constrained to the surface of the object.
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.
15 comments
[ 508 ms ] story [ 581 ms ] threadI'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.
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.
For stuff that's novel, you could always browse through this year's SIGGRAPH papers. http://kesen.realtimerendering.com/sig2017.html
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.
Cool! What games are using subds? I thought they were mostly relegated to offline use due to evaluation cost.
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.
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.
http://i.imgur.com/iC7czF5.png