Great write up, that was a fun read.

In understanding how the rotation was implemented, it took me longer than it probably should have to realize that the normal map (which I think of in terms of lighting) is actually a radial position on the sphere.

I had to go back and forth with the final and original code a few times, and finally noted that "n" gets renamed to "point" when it becomes an argument to colorLookup.

This dual usage of the normal for lighting brightness calculation and as a radial position on the sphere surface for looking up the color makes sense in retrospect but is also a somewhat subtle aspect that you might want to address more explicitly in your text instead of just silently renaming the variable in the code.

In the final video, there are still some texture artifacts whenever the number is on the edge (e.g. the ball 4 at 5 seconds). Maybe because of mipmaps? I can't really think of a reason why it happens. It even happens at the bottom of the 4, even though that part is white in the texture.

Nice work! My only recommendation is to add a pow(color, 1.0/2.2) or similar at the end, and then turn down your light brightness. Your light falloff has the distinctive look of gamma-space lighting makes it look dated and less realistic. Doing your lighting in linear space should help.

It might also be simpler to do your rotations without a matrix, for the learners ( just expand out the functions, e.g. https://github.com/magcius/sw3dv/blob/gh-pages/b_vert.glsl#L... )

Great article! I would be interested in more info about the physics and ball path mapping that you mentioned in the beginning.

Over the last few months, I’ve started competing in billiards, and the roll vs slide, english, tangent lines, and even forced follow to be incredibly interesting.

Is any of that involved in the physics simulations that you’ve worked out? If it is, I would really like to know more.

Cool, I recently started with GLSL, and it’s interesting there are many roads that lead to a similar solution (how I draw circles or make a center is tad different)

Where or how did you learn GLSL?

With a good phong it's all about the dot products and specular highlight (if you using highlights). Make sure you clamp the dot products and give yourself a minimum ambient light value of around 0.15 to 0.2.

The thing that got me, in a classic Phong, you have to test whether dot > 0.0, it really won't work outside of the front hemiphere. The clamp isn't enough.

> Came for the title

Well played

Edit: I’ll take the downvotes, the author edited the thing for silly innuendo, it’s silly, I’ll have fun too and take my lashes.

That's very interesting. Thank you for the link. From what I read and see in the images, I gather he's done the same thing I have, as you guessed as well. Obviously he's going much further. The author is using a subtle bump map (simulating balls scratches and imperfections), a reflection map with a gradient and indecent angle, what looks to be a faux sub surface scattering effect.

Also he is placing his balls in a 3D environment with nice shadows that really help to sell the illusion.

That's a good find and an interesting read. Thank you.

I'm also new to shaders, so I might be wrong: Camera distortion (/perspective) is done in the vertex shader, this post here presents a fragment shader. So if you take a quad, in the vertex shader then rotate it so it'll face the camera (i.e. all vertices have same z/depth value in clip space), you can then probably use this fragment shader to render the ball.

You have to rotate the quad to face the camera, since it has to cover the area where the ball may render (imagine the extreme case: if the quad is perpendicular to the camera, it looks like a line to the camera, you could only render the ball within that line, it wouldn't protrude to the left or right).

It can be incorporated into a 3D scene as long as you can make a square billboard . You may have problems with clipping that' you need to address manually, but it might be worth it as you can get better visuals, assuming you are trying to render spheres.

As far as I know there shouldn't be any distortion issues. A sphere will always look like a circle from any perspective. Well that is unless it's really really big or your are really really tiny and you give the size difference you are relatively close to its surface. At that perspective it just look like a flat plane.

Think of it similar to an impostor: in world space, a sphere is always a sphere, and you should do all your lighting in world-space, so you don't need to account for the distortion. You do need to project into the camera's viewing, typically typically the projection matrix. But since a sphere under rotation has the same silhouette, you can also rotate the quad to view different parts of the sphere, and use a circle inside, though the rotation math would have to view a different part of the sphere. To integrate with other objects, you likely would turn on depth writing, and use gl_FragDepth to write the front depth to the buffer, and discard when outside of the silhouette.

It could be used as a sprite that looks like real geometry with some tweaking.

Well first of you get infinite smoothness and better lighting (and reflections if you add them) because there is no underlying geometry. It's just math. It's also much faster, as you're only giving the GPU four vertices defining the square. This can even be sped up further by using point sprites which consume only one vertex.

It is faster for the case of a "top-down" 2D game. You render this and just draw a single quad per ball. You do not really have any vert shader.

Because graphics is fun. It's a good way to engage with students. Beside, what's important is not the outcome but the journey. You learn to read documentation, to design, to debug and more importantly you learn to learn. Which is what higher education is about.

Education is about exercising the mind. I don't think many play with inflated balls in their adulthood, yet it's very important to teach children hand-eye coordination, team play, and other concepts so that they become better functioning humans.

There are problems with the curriculum though, one of them that it plays catch-up with the state of the world. IT in particular moves very fast. Graphics programming is not one of these things however. For example, if you've done the courses, and experiences just how hard it is to crate anything in 3d, you can better appreciate the work that goes into modern 3d engines. Look at this beautiful breakdown of the inner workings of the GTA V engine:

http://www.adriancourreges.com/blog/2015/11/02/gta-v-graphic...

inb4 you get 10 replies along the lines of "wow I wish my professors let me do something cool like ray-tracing. I spent 4 years implementing cache-inefficient data structures that nobody uses in an ancient version of some programming language that nobody uses in a crappy env doesn't even have a real debugger"

Not that I can relate. I dropped out of uni well before I encountered anything that would discourage me from going into software :)

In theory if Free Pascal had a SPIR-V backend, it could be used as well.

That’s a little bit more accuracy than what is needed for this post, but good catch :-) https://www.jpl.nasa.gov/edu/news/2016/3/16/how-many-decimal...

Lol, wow what a find. You notice the details. I corrected it. Thank you.

Interesting point if it had been apparent it would have been an issue, at what point does a poor Pi become an issue?

What would a Pi of 3.0 do?

I'm surprised you'd have to define pi in a fragment shader at all. Surely such a commonly used constant would be defined in the language/headers already?

Fixed.

Well that backfired on you.

boo !

I fixed it. Thanks.

I believe they titled it that way on purpose.

(Testes btw)