What happened here is that we did in fact render a cube, but the back part of the cube was drawn last and thus over the front side.

One of the hardest things about using WebGL and many other graphics APIs is that you will often get an unexpected result but it's really hard to debug especially if you don't know what you're doing yet. It's actually important you define the triangles in counter-clock-wise order. I start in the bottom left corner for each face and vertices are order counter-clock-wise. You probably want to draw the cube on paper and manually check all the vertices. While you don't have to specifically lay out everything in terms of individual triangles I find it's at least easier to reason about. The problem with even something simple like a cube is the vertices rapidly become hard to deal with. Perhaps the most natural thing to expand into 3 dimensions is a cube. If you've seen my other posts on gradients this type of effect is something we still can't quite do yet.įull screen rectangles are getting a little old. Again we're taking our 3d color and augmenting it to be 4 valued because that's typical. Finally we assign to that varying value we defined. 0.0 corresponds to Z, and 1.0 corresponds to W which is kinda like the alpha of positions. We'll come back to this but right now we're taking our 2d values and simply augmenting them with 0.0 and 1.0 as we need vec4s. It's passing position information to the hardware so it renders in the correct spot in screen space. gl_Position is another return-value like thing. And it's probably obvious but we're passing a vec4 worth of data. You can use highp for everything until it's a problem, just note you might not see a difference over mediump and lowp. To be honest you don't need to worry about this now as it's all about fine-tuned optimization. The underlying hardware can pick something higher but not lower. This specifies the minimum precision of the values we pass. There's a second keyword mediump or 'medium precision'. The 3rd line is almost like a return value, it's additional data we're passing to the vertex shader and it defined by varying. Line 1 we've seen, it's the position input. And we'll make some tiny edits to the vertex shader code. Being amateur myself I don't know if there are merits to doing that but I've found having separate buffers seems to work well especially if you want to turn features off.Īnyway, we need to call this.createColors() to setup our new color buffer and in our shader we now have access to aVertexColor. That's what the offset and stride parameters to vertexAttribPointer do. So in order to do this in one step we'd need to interleave the data. The maximum size of a vertex vector is 4, and we need 5. You may wonder if buffer data is configurable could we just do all of this in one step with 5-value vertices. Each vertex here corresponds to a vertex in the position buffer so they should be the same order. They are float representations of Red, Green, and Blue in RGB float format. The values should be understandable if you've worked with color before. Besides the naming changes, we're taking 3 elements at a time instead of 2. This buffer of data has color information for the vertices. Enter fullscreen mode Exit fullscreen mode

Code for polygon generator in scratch