WebGL PBR Implementation

Just want to see the demo? Click the link below. Warning: it loads quite a few images, some of which are ~10MB, so may take some time to load (it does report loading progress though):

http://demofox.org/WebGLPBR/

More Info

There is a great PBR (Physically Based Rendering) tutorial at: https://learnopengl.com/#!PBR/Theory

I followed that tutorial, making a WebGL PBR implementation as I went, but also making some C++ for pre-integrating diffuse and specular IBL (Image Based Lighting) and making the splitsum texture.

Pre-integrating the diffuse and specular (and using the splitsum texture) allows you to use an object’s surroundings as light sources, which is more in line with how real life works; we don’t just have point lights and directional lights in the real world, we have objects that glow because they are illuminated by light sources, and we have light sources which are in odd shapes.

It’s possible that there are one or more math errors or bugs in the C++ as well as my WebGL PBR implementation. At some point in the future I’ll dig deeper into the math of PBR and try and write up some simple blog posts about it, at which point I’ll be more confident about correctness other than “well, it looks right…”.

The source code for the C++ pre-integrations are on github:
IBL Diffuse Cube Map Integration
IBL Specular Cube Map Integration + Split Sum Texture

The WebGL PBR implementation is also on github:
WebGLPBR

Here are some screenshots:





Links

Learn WebGL2:

https://webgl2fundamentals.org/

Free PBR Materials:

http://freepbr.com/materials/rusted-iron-pbr-metal-material-alt/

PBR Links:

http://blog.selfshadow.com/publications/s2014-shading-course/frostbite/s2014_pbs_frostbite_slides.pdf

https://learnopengl.com/#!PBR/Theory

http://renderwonk.com/publications/s2010-shading-course/hoffman/s2010_physically_based_shading_hoffman_b_notes.pdf

https://disney-animation.s3.amazonaws.com/library/s2012_pbs_disney_brdf_notes_v2.pdf

http://blog.selfshadow.com/publications/s2013-shading-course/karis/s2013_pbs_epic_slides.pdf

A Tool To Debug Teams (Knoster)

In the professional world, programmers work in teams as a rule, with very few exceptions.

For the programmers aiming to remain programmers, and not going into management, we are often focused on our specific trade or area of expertise though, and so we spend less time learning about or thinking about what makes a team successful.

We learn some from personal experience – realizing that certain things are bad for a team many times by seeing the failures manifest in front of us – but we are definitely more likely to pick up a book on algorithms than we are a book on team management.

My mother in law is the opposite however, as part of what she does is mentor people to being leaders of teams and large organizations, and also consults to organizations in the field of education to fix budgetary and organizational problems they may be having.

She showed me an interesting chart the other day that is really eye opening. It’s a formalized look at how to identify some things that may be going wrong with a team.

The chart itself is from the educational sector (Tim Knoster in ~1990), and is meant to be used to “Manage Complex Change”, but looking at it, and having been a professional programmer for 16 years, it is definitely applicable to any team.

The chart is valuable whether you are leading a team, part of a team, or observing a team you are not a part of.

How you use this chart is you look on the right side to see what sort of problems your team may be having: confusion, anxiety, resistance, frustration, or false starts.

From there you scan left until you find the black box. That box is the element missing which is causing the problem for the team.

That’s all there is to it, it’s pretty simple. It actually seems like pretty obvious stuff too in hindsight, but I wouldn’t have been able to formalize something like that.

Obviously not every situation can be boiled down into a simple chart like this, and there are variations of this chart including more or different rows and columns, but this is a good start at trying to “debug a team” to figure out the source of an issue.

Want more details? Here are some links:

http://www.belb.org.uk/downloads/rc_knoster_managing_complex_change.pdf

http://www.d11.org/LRS/PersonalizedLearning/Documents/KnosterMANAGINGCOMPLEXCHANGE.pdf

http://nebula.wsimg.com/90f9e490329402583fea599cad009bb0?AccessKeyId=8AAC8D005153628DDDFA&disposition=0&alloworigin=1

Why Are Some Shadows Soft And Other Shadows Hard?

This is a quick post on why some shadows have soft edges, and other shadows have hard edges.

The picture below looks pretty normal right?

Let’s zoom into the shadows on the ground:

The shadows of the circular platforms on the right are sharp, but get softer as they go to left.

Here you can see a similar effect with a light post, where the shadow is sharp on the left and soft on the right (click these images to zoom in if you want to):

And lastly you can see that the plants in this picture have a sharp shadow (and so does the curb), while the trees above it (out of the picture) cast a soft shadow:

Why are some shadows soft and some shadows hard?

The crux of what is going on here is that shadows that are nearer to the objects casting the shadow are sharper. Shadows that are farther from the objects casting the shadow are softer.

More plainly: Things closer to the ground have sharper edged shadows.

Go have another look at the pictures if you want (click them to see them full sized) and see how distance from the ground affects the sharpness of the shadow’s edge.

Why Does This Happen?

The reason this happens is actually pretty simple. Let’s look at the problem in 2d where we have a light source (the sun), the ground to cast a shadow on, and an object casting a shadow:

Now let’s think about where the ground would be completely in shadow. We can draw a line where all the ground to the left is completely in shadow. This is the point where all the ground to the right can “see” the sun, but all the ground to the left cannot see it. This area is called the “umbra” which is latin for shadow.

Now let’s think about where the ground would be completely lit up. We can draw a line where all the ground to the right is completely lit up by the sun. This is the point where all the right to the right can “see” the sun completely, but all the ground to the left has some amount of the sun obscured, so can only see some of the sun if any of it.

This leaves us with the area in the middle of the two where the ground can see some of the sun, but not the whole sun. This area is called the “penumbra”, which in latin literally means “almost shadow”. (You may remember the “pen” prefix from peninsula which is also latin, meaning “almost an island”)

So the penumbra is where the soft edge of a shadow is, but how is this related to distance?

Here is the situation when the shadow casting (brown) object gets closer to the ground. Note how the penumbra is a lot smaller.

Here it is when the shadow casting (brown) object gets farther away from the ground. Note how the penumbra gets larger!

Distance isn’t the only thing that can affect penumbra size though. Here you can see that a larger light makes a larger penumbra.

Here you can see how a smaller light makes a smaller penumbra.

If a light was infinitely small (a point light), it would not make a soft shadow edge, no matter how far or close the shadow was to the thing casting the shadow. While point lights do exist in computer graphics, you likely would still want to make a soft shadow for them if you are able to, as point lights can’t exist in real life.

If you’ve never noticed this property of shadows before, you will probably never be able to un-see this.

This is what it’s like being a graphics programmer (or an artist, photographer, etc, I’m sure!) – looking at and understanding how things like this work completely changes how you see the world. Lately, everywhere I look, I’m checking out the reflections and thinking about SSR (screen space reflections). Just check out the cool reflections below, that you probably didn’t even think anything of when you first saw the picture!