picture home | art | events | music | rack extensions | downloads | pixel blog

omino pixel blog

pixels, motion, and scripting
entries for category "webgl"
david van brink // Mon 2013.10.21 21:22 // {webgl}

webgl 5 — cubies!

I finished this almost two weeks ago, fifth day of coding. Was so satisified, forgot to post!

For your amusement. Generates a “maze” with no dead ends, and lets the cubies loose on it, with collision avoidance. Implements a very, very simple parallel ray shadow map, too. The shadow map is pretty glitchy, but still adds some character to the scene.

oh, i dont know. what do you think?


david van brink // Fri 2013.10.11 15:04 // {webgl}

webgl 4 — sprites

WebGL.

It appears that gl.drawArray() is expensive! Didn’t gather numbers, but could see that more than a few started racking up the CPU load. Adopted a “sprite” approach, that lets the same geometry values get reused, and a texture is submitted to the vertex shader to offset them. Handy!

A bit of the vertex shader goes like so.

    attribute float sprite; // each vertex is anchored to an offset, represented by a pixel in the Sprite Control texture
    uniform sampler2D sprites; // 
    ...
        vec4 spritePos = texture2D(sprites, vec2(sprite, 0.5)); // texture is 512 by 1
	pos4.xyz += spritePos.xyz;
        // (and use spritePos.w for a yaw rotation.)

Here we see 511 sprites, all rendered with a single gl.drawArray() call.

The motion comes by moving each sprite along a different 3d Lissajous path.

oh, i dont know. what do you think?


david van brink // Sun 2013.10.6 01:08 // {webgl}

webgl day 3

Built machinery around textures and frame buffers. In the olden days we called this an Offscreen G World. Added some basic surface normals. For rendering, randomizing them a bit adds some cheap interestingness.

Also: filters. Ported omino_glass chromatic aberration filter to run here, realtime.

Next: multiple camera angles, alternating.

oh, i dont know. what do you think?


david van brink // Thu 2013.10.3 19:46 // {webgl}

webgl matrix interlude

This just in: The entire world of WebGL matrixes is backwards.

Instead of saying

translatedPoint = [x y z 1] [1 0 0 Tx
                             0 1 0 Ty
                             0 0 1 Tz
                             0 0 0 1]

or

var translateM = [1,0,0,tx,
                  0,1,0,ty,
                  0,0,1,tz,
                  0,0,0,1];

or

vec4 p2 = pos * rotateFirstM4 * translateM4;
// alternatively
vec4 p2 = pos;
p2 *= rotateFirstM4;  // first transformation
p2 *= translateM4;    // second transformation

they want everything backwards, like

mat4 translateM4 = mat4(vec4(1,0,0,0),
                        vec4(0,1,0,0),
                        vec4(0,0,1,0),
                        vec4(tx,ty,tz,0));
vec4 p2 = translateM * rotateFirstM4 * pos;

It does have one small advantege. It takes a little less paper-space to write out.

translatedPoint = [1  0  0  0  *  [x
                   0  1  0  0      y
                   0  0  1  0      z
                   Tx Ty Tz 1]     1]

And you could just do it all the other way, transposed, and left to right. Except… I’ve chosen to use a matrix library glMatrix.js. It’s handy, it’s good, it has all the basics like mat4.rotate() and everything. But it enforces the OpenGL backwards-ness.

I grump.


People blame this on the fact that OpenGL lays out its matrixes in-memory in “Column Major Order”, meaning the first column takes the first four memory locations. Whereas we read them and code them in “Row Major”-ey style, left to right and top to bottom.

But that’s no excuse… by putting your horizontal vector on the left of the matrix, instead of vertical on the right, you can get pretty code.

On my backlog is “translate glMatrix.js to Row Major stylings”, so my code can look more like textbook math.

oh, i dont know. what do you think?


/\/\/\/\/\/\/\

0.0227s
(c) 2003-2023 omino.com / contact poly@omino.com