DEV Community: Jesse Solomon

Creating an Impossible Box with GLSL & THREE.js

Jesse Solomon — Tue, 02 Mar 2021 18:56:21 +0000

One of my favorite types of visualizations are the physically impossible ones. And of those, one of the most fun is a bigger-on-the-inside box!

The Final Product

If you want to play around with it yourself, you can view it on my website.

And you can check out the fully commented GitGub repository for more insight.

Let's Build It!

If you're not familiar with the basics of how shaders and WebGL works, I highly recommend you check out this MDN article on the topic.

Now let's dive into how I went about building this!

To begin, let's talk about the feature that made this whole thing work discard.

The fragment shader has a special keyword that works similarly to return in a common programming language. discard instructs the GPU to not render the current fragment, allowing whatever is behind it to show through. You can read more about it here.

Using this feature we can turn a boring regular cube, into a super cool transparent cube!

Source: outer_fragment.glsl

// Check if the fragment is far enough along any axis
bool x_edge = abs(worldPosition.x) > 0.4;
bool y_edge = abs(worldPosition.y) > 0.64;
bool z_edge = abs(worldPosition.z) > 0.4;

// Check that the fragment is at the edge of at least two axis'
if (!y_edge && !z_edge) {
    discard;
}

if (!y_edge && !x_edge) {
    discard;
}

Now we just need to find a way to tell which face we're seeing though. This was by far the most difficult part, not because the solution was terribly hard, mostly because I'm not very good at math.

So let's go over how I went about implementing this.

1st, since there's a top and bottom to our box, we don't really need to work in 3D for this. So let's think of our 3D box, as a 2D box:

Now, we can take the 3D geometry (red) that's inside of the box, and flatten it to 2D:

Next, let's add a camera (blue) and some example fragments we want to render (green):

With this setup, we can make a line between our fragments and the camera, and check which face they go through:

If we apply this method to our box, and give a color to each face we get this fun effect!

Source: inner_fragment.glsl

// Define all the corners of our box
const vec2 corners[4] = vec2[](vec2(0.5, 0.5), vec2(-0.5, 0.5), vec2(-0.5, -0.5), vec2(0.5, -0.5));

// Define a line from the fragment's position (A) to the camera (B)
vec2 a = worldPosition.xz;
vec2 b = cameraPosition.xz;

int intersectedFace = -1;

// Iterate over each face
for (int i = 0; i < 4; i++) {
    // Get the second point for our face
    int next = int(mod(float(i + 1), 4.0));

    // Create a line from 2 corners based on the face
    vec2 c = corners[i];
    vec2 d = corners[next];

    // Does line 1 and 2 intersect? If so, assign the intersected face
    if (intersect(a, b, c, d)) {
        intersectedFace = i;
        break;
    }
}

// Color the fragment based on the face
switch (intersectedFace) {
    case -1:
        gl_FragColor = vec4(1, 0, 1, 1);
        break;
    case 0:
        gl_FragColor = vec4(1, 0, 0, 1);
        break;
    case 1:
        gl_FragColor = vec4(0, 1, 0, 1);
        break;
    case 2:
        gl_FragColor = vec4(0, 0, 1, 1);
        break;
    case 3:
        gl_FragColor = vec4(0, 1, 1, 1);
        break;
}

From here, we can just assign a face to each object we want inside, and discard any fragments that don't pass through the given face.

Source: inner_fragment.glsl

// Define a line from the fragment's position (A) to the camera (B)
vec2 a = worldPosition.xz;
vec2 b = cameraPosition.xz;

// Get the second point to define the face
int next = int(mod(float(face + 1), 4.0));

// Define a line at the given face
vec2 c = corners[face];
vec2 d = corners[next];

// If the defined lines do NOT intersect, then discard the fragment
if (!intersect(a, b, c, d)) {
    discard;
}

Then we'll just add some interesting animated objects, a little directional lighting for depth, and we're done!

Thanks for reading! I hope you enjoyed it as much as I had making it!

Recreating a classic starfield in GLSL & three.js

Jesse Solomon — Sun, 21 Feb 2021 19:37:38 +0000

A starfield was one of the first things I built when learning to program. It's been quite some time now, and I've started learning shader programming with GLSL and three.js, so I decided why not go back to where it all started!

The Final Product

If you're in a hurry and just want to see what I've put together, you can look at the final product here, and view the GitHub repository here!

(I'd drop a gif, but you couldn't really make out what's happening 🤷‍♂️)

Let's Build It!

If you're not familiar with shader programming, don't worry! I'll be sure to keep it informative, but accessible.

Also, there's a lot of boring padding code to get everything running, so all the GLSL here is paraphrased for your enjoyment (and my own sanity). Take a look at the repository for the real code.

Part 1 - The classical approach

let's start with the most straight forward way to do this, a rough GLSL port of what you might write in JavaScript:

// Loop through all the stars we want
for (int i = 0; i < STAR_COUNT; i++) {
    // Give the star a random position
    vec2 star = vec2((random(i) - 0.5) * 2.0, (random(i) - 0.5) * 2.0);

    // Get the direction from the center to the star, and scale it by time and a random offset
    star = normalize(star) * mod(time + random(float(i) * 16.0), 1.414214);

    // If the star is within 0.1% if the viewport size then draw it as white
    if (distance(screenPosition, star) < 0.001) {
        color = vec3(1, 1, 1);
        break;
    }
}

So what's wrong with this method? Mostly, that it just doesn't scale. GLSL runs your shader for every pixel, you can think about it like this:

for (let pixel of screen) {
    for (let star of stars) {
        ...code
    }
}

This is horribly inefficient!

So how can we make this more performant, and maybe make it even better?

Part 2 - Let's make it better!

In order to make this thing awesome, we're going to need to fix the biggest issue. Iterating over hundreds of stars.

My favorite thing to do in a situation like this is to try a totally new perspective. Like, what if instead of each star being a point emitted from the center, it was a point along a column that went from the center to the edge?

Imagine a pie that covered the entire screen, each slice would represent one star traveling from the center to the edge.

Since the "slices" wouldn't move, we could map screenPosition to a slice, and figure out what star to process:

vec2 direction = normalize(floor(normalize(screenPosition) * STAR_DENSITY) / STAR_DENSITY)

We can define STAR_DENSITY for the number of slices we want.

Now, instead of using i to figure out the stars offset, we can convert direction from a point, to a float and use that instead:

// I'm using `scale` because `distance` is a built-in method
float scale = mod(time + random(direction.x + direction.y * 10.0), 1.414214);

With a direction and a scale we've now defined our star using polar coordinates, using just the screenPosition!

We can now do our distance check like this:

if (abs(scale - distance(screenPosition, vec3(0, 0, 0)) < 0.001) {
    ...
}

🎉 Tada, mission accomplished! We've now not only improved performance, but created a super dense starfield visualization that you couldn't do in JavaScript!

Thanks for reading, I hope you enjoyed the article, I aim to make more of these (hopefully better) so if you have any feedback please let me know!