Graphics Size Coding

Qoob added to GeeXLab

2010-10-30T21:11:00.002+02:00

JeGX has added Qoob 1.0.2 support to his graphics quick prototyping tool GeeXLab.There is already a demo out. More about Qoob in GeeXLab and how to download.

Qoob added to ZGE

2010-10-25T23:34:00.001+02:00

Vill Krumlinde has added Qoob 1.0.2 support to the ZGameEditor (ZGE). See the full details at the news section at the Qoob website as well as a link to the first ZGE demo containing qoob...

http://qoob.weebly.com/news.html

Qoob libs Released and Modeller Upgraded

2010-10-24T00:31:00.001+02:00

Qoob libraries are out! You can now include qoob models in intros or anything really. To go with the libs, the modeller has been upgraded and many bugs removed. It should be 99% stable now. There are a few new features such as moving the model using the mouse (much requested). Oh and Undo now works ... ahem...better.

Check it out at http://qoob.weebly.com

Benoit Mandelbrot Dead

2010-10-16T11:18:00.002+02:00

Rest in peace, sir.

Simple Code to Calculate normals for a Quad Mesh

2010-10-15T09:01:00.008+02:00

I'm ripping iq here. However, I've fiound a lot of people haven't read his brilliant normals idea buried deep in one of his presentations, plus I add face normals and a subtle way to rewrite crossproduct that shortens code again.

Here is some tiny pseudo-code to calculate both the vertex and face normals of a mesh made of quads. It is pseudo-code because your mesh structure will not be the same as mine. The idea is based on iqs idea in his Breakpoint presentation.

for ( i=0; i<numberofquads; i++) {
for (uint k=0; k<4; k++) cross ( &quad[i].v[k], &quad[i].v[(k+1)&3], &facenormals[i] );
for (uint k=0; k<4; k++) add ( &facenormals[i], &vertexnormals[&quad[i].v[k]]);
}

Now this neat and easy to read and incredibly small for such power. Essentially it is:

for each quad
    for each edge in quad
         accumulate crossproduct of edge vertices into face normal
   for each vertex in quad
         add face normal

One subtle trick here in the code is that cross product is redefined thus:
cross(v1,v2,v3) :: v3 = v3 + crossproduct (v1,v2)
Add is as you expect::
add(v1,v2):: v2=v2+v1;

During qoob modeller writing I found redefining cross product in this way was fine, after all it can be called with a zeroed vector in last place if a true cross product is required rather than accumulating. If you don't understand how accumulating cross products of each edge of the polygon equates to calculating a normal, see iqs presentation. That is the really smart thing here.

N.B.: Assumes facenormals and vertexnormals contain zero values before calling this function.
The normals are not normalised (leave that to shaders or GL_NORMALIZE).

Qoob moved to its own website

2010-10-15T08:29:00.001+02:00

So that this blog can get back to non-qoob stuff, qoob has been moved to http://qoob.weebly.com
The whole package including .h and .o to link against will be out (this weekend) ermm not quite.. real soon now.

Qoob (OpenGL version) final results

2010-10-03T16:18:00.001+02:00

Qoob library for 3d modelling and uncompression of 3d models is compiled in two ways. One includes all the loading and saving etc used for modelling. The other mode is an intro mode. After making a basic test intro with qoob, I discovered speed was a factor and had to rewrite a few routines. This forced me to add a few bytes but not too many. Now finding normals and smoothing are much much faster and models typically load in sub-second time.This is important if we are using 50+ models in an intro - compo rules usually enforce a total run time that includes loading/unpacking.

The final size using crinkler 1.1 with settings :
/CRINKLER /COMPMODE:SLOW /ORDERTRIES:3000 /UNSAFEIMPORT /REPORT:report.html /TRANSFORM:CALLS
is 2165 bytes.

This includes, selection handling and recording specific polygons used in modelling, 3d maths lib, catmull clarke smoothing with holes, subdivision, insertion and deletion, unpack routine, extrusion, tapering, bulging, rotations, translations and scaling on polygons and model level, making a cage and making rounded holes, basic cube geometry, vertex and face normals.

Models vary in size. The largest I've done so far is around 350 bytes which was a unicorn head. The compression of models is better than I predicted as picking polygons early in modelling is inexpensive as polygon ids fit within one byte and crinkler does a good job with them. Most abstract models come in around 30-70 bytes and most real world ones 100-200. Better than expected.

If you want to play with the qoob modeller (opengl), send me an email on my gmail account chris thornborrow and I'll release it to you. Especially if you are a 3d modeller used to wings3d - I'd like feedback.

3d Modelling : the challenges for Compression

2010-08-11T00:29:00.001+02:00

Quick reminder, qoob is a modeller and library that stores 3d models by a series of modelling commands, not by storing the mesh. The hope is to get smaller models for intros. As I write qoob, three fundamental challenges are emerging:

The size of the qoob library with the modelling commands code
Storing modelling commands in a compact way
Picking and selection compression

The Size of the Library
The Qoob library is around 2k after compression. It must be included in intros to decode cube models. As such the existing library simply wont work at 4k. Its fine for 64k and for 8k/16k. However I'm also hopeful a much smaller one could be produced. There would be three keys:

use DX maths and subdivision
reduce the modelling options and target abstract objects ONLY
use default values for all functions so storing a model means storing only a series of commands - no parameters.

That may seem crazy but there are a huge range of abstract objects that can be done this way. From plants to cubes to geometric abstracts. Even basic human figures.The first characters I showed on this blog were done this way!

Storing Modelling Commands

I made the mistake of targetting a low number of entry points in qoob lib. This kept the library small and tight but meant even a simple extrude needed 9 bytes to store!! However after considerable redesign, I've managed to reduce the average byte count per modelling command to less than 2. The result is less compressible but not by much and a factor of 5x on average is a very good saving. 50 modelling commands is a enough for many models. Thats 100 bytes BEFORE compression.

The first trick was to increase the number of possible commands (eg translate became translate, translateX, translateY, translateZ). Translate in X requires only one float whereas translate requires 3. Often the modeller does not need the full expressive power. In most cases the reduced bytes needed to store the new commands parameters far outweigh the extra code, which is highly compressible.

The second trick comes from accepting that we dont need the full range and accuracy of floats. A single byte is enough for most functions and should greater range be required, the modeller can always concatenate. For example, a translate in X can be expressed as a single byte. If further translation is required, the modeller simply translates again, however usually this is not the case.

Selection Compression

A talk with iq depressed me. Essentially selections needs 5 bytes (command and quad id) to store. In addition polygon ids are random (over many picks) and so do not compress. Iq guessed that 50 picks would render qoob models less effective than mesh based compression.
Well this is a fundamental mathematical barrier. The trick is to avoid it. Procedural selection comes to the rescue. Commands like "select similar" from wings3d mean that the modeller picks a single seed polygon then expands the selection using a command or two.
I'm still exploring the solution here so more when I'm sure what is a good thing but Im pleased with what I have so far.

So qoob lib got bigger but that could be fixed by porting to dx and reducing flexibility. Models got much smaller and picking is nearly solved but again costs bytes in the library.

Simple Algebraic Surfaces Reference

2010-08-09T12:17:00.000+02:00

Serious size coding involves trawling forums and the net for ideas and resources. Here is a little link that came over twitter this morning with a bunch of tiny algebraic surfaces that may, or may not, be useful:

http://www.freigeist.cc/gallery.html

Qoob Matures

2010-07-19T23:49:00.007+02:00

Qoob now has about 80% of the functionality I want in a basic modeller, at least for now. For personal reasons I will take a break from coding for a few weeks and leave you with a few more sample images. The next step will be to make an actual intro using the tool.

Click on the images for larger versions. I've managed to get some organic, some holes and some asymmetry into the modeller. Undo is implemented (well,ok, one level). The next major step is to put the geometry lib into a 64k framework.

But a burning question is - how big is the Qoob library? Whats the overhead?
Here is a test I performed.
Using crinkler 1.0 ( I cant get 1.1 to work for me) I constructed a minimal OGL program : 600 bytes after compression. I then added Qoob library and called each function once to force inclusion. The program size was 2.4k with crinkler settings of /CRINKLER /COMPMODE:SLOW /ORDERTRIES:3000 /UNSAFEIMPORT. No smarts here to help crinkler and probably not the right settings. Likely, the library can shrink a bit but also could grow a little with the few functions I have left to put in. Its safe to assume therefore that <2k is the Qoob overhead.

2k - thats good, better than I expected. Very useful for 64k. The models range from 3 bytes (a chamfered cube) to 200 for the characters.

Maybe its worth rewriting this using DirectX and getting it into 4ks after all? The 4k might be non-demoscene standard - a sort of model show in 4k...but thats an achievement by itself in some ways.

Shorter code for Point in Interval

2010-07-19T14:54:00.005+02:00

Nice little coding trick for checking if a value lies within two other values. The result is faster and (slightly) smaller than checking both values. The trick could be extended to do bounding box intersections for collision detection for example.

Neat trick

It resolves down to this macro:

#define InRange(ch, a, b) (unsigned((ch) - (a)) <= (b) - (a))

.cool

Qoob Character modelling

2010-07-18T14:34:00.004+02:00

So, Qoob, the tiny modeller, finally is competent enough to model simple characters. Its all a bit pikachu for now - but that may be more my inner pokemon than the tool, not sure yet. The qoob library grew hardly at all to support this, only the modeller.

Characters are about 200 bytes. Thats ok but not great. The culprit is picking. You do quite a lot of polygon picking to model the limbs, eyes, nose etc. Click on the images to see larger versions.

Picking consists of a command (1 byte) and a polygon (3 bytes). Thats 4 bytes before compression. Assuming the command compresses well, the specific polygon id is the problem. A lot of the time the first byte will be zero which will help. Still, we can assume a total of 3 bytes on average per pick after compression. These models take about 50 picks. Hence 150 bytes as a base. Ideas:
1. Store the command pick n times, (meaning select the next polygon n away in the array). This means great compression but even so, thats a lot of data to compress and there may be problems.
2. Duplicate what the modeller does, by storing the 2d pick co-ordinates and have qoob lib project that into polygon space. Well its 2-3 bytes anyway and then the projection code. So no.
3. Delta encode the polygon id. In my modelling at least this would help often. Polygons being picked often come from the same base polygon in the model before subdivision and therefore their ids are similar.
4. Exploit hierarchy of subdivision more ... have to think here. In theory a polygon might be identified by 3 bits for original face of cube (the base input)2 bits x n where n is the subdivision level.
5. Restrict picking to be pick + grow pick. This would help with large groups of polys but the modeller would go nuts.

... hmm need to think more, none of the above convince me.

3d Modelling thoughts.

2010-07-10T09:51:00.007+02:00

The objective of Qoob is to be a demoscene modeller that targets 64k intros. It should allow hundreds of models in a 64k. That means man made and organic. Organic seems to require arbitrary extrusion (think pipe or ribbon). It allows for models like loonies use in their 4ks eg benetoite and, more impressively, 64ks such as Flight666. The maths for modelling with arbitrary extrusions is quite large (>500 bytes) and adds a lot of bytes to Qoob which is already growing in size.

In addition, Qoob must support selecting individual polygons for arbitrary complex shapes. That will be the key to true modelling. But selecting, say 50 polygons currently requires:
select p1
select p2
select p3
... 50 selections
to be stored and compressed. Compressing the command is obvious and cool. I'll just store the command queue and the data queue seperately. The data for each entry is four bytes and may not compress well. I could try sorting and delta encoding - the usual tricks - of course. This worries me.

Size wise then, I'm struggling now: selections and extrusions add lots of bytes. ONe to the lib and one to the models. Suggestions are welcome.

However, on the bright side, Qoob could support displacements on large and small scale, like sculpting. I might therefore be able to create highly detailed geometry with bumps and ridges, for very little cost.

In the mean time, some screenies of what can be done without such functions:

p.s. Hope people like the new design for the pages here. Also check out the demotivation demoscene picture to the right (with apologies to iq/mentor) as elevated races toward 500 thumbs on Pouet.

Catmull Clark Subdivision Musings

2010-07-06T11:32:00.008+02:00

Before you read on. Blogger is simply crap for posting code. I've done my best for formatting but if you see dodgy symbols or things that make no sense - blame blogger as this code is right out of the compiler.

Modellers seems to like quads. Catmull Clark subdivision smooths and maintains a quads only model. Doo-sabin introduces triangles. Loop works on triangles. So I decided to use Catmull clark in qoob. I got it working last night after spending a whole weekend when I should have been in the sun. The model above, I estimate, would be around 22 bytes to store compressed. Its approaching organic but is still embarressingly geometrical. Thats has to be the next goal, to produce some organic stuff.

Most code on the net works using winged edge data structures. Classes abound. The examples are no use for size coders. Fortunately iq tackled CCSD in his 2007 presentation for breakpoint, Tricks and techniques for RGBAs Past and Future Intros.

(By the way his normal a mesh trick in that presentation is without doubt the best piece of size coding I've seen.)

Firstly wikipedia has a description of the algorithm. Unfortunately, its not totally clear what an edge point is -the midpoint of an edge or the new displaced midpoint of the edge (its the first). But there are other references to clear this up. IQ proved its possible to do Catmull clark without winged edges but still he uses edge ids. I wanted to avoid this and did so but in doing so, each time I add a vertex I loop through all vertices to see if an identical one already exists. I think its a case of what I gain on the flat I lose on the hill. Here is the final code in old style C (ie no C++ operators for maths) which makes it look horrendous - thats why operators were introduced :-).

addVert is key. It checks all existing vertices for an exact duplicate (exact is fine in this case) and returns either the index to the existing one or adds the new vertex and returns its index. addquad adds a quad to the model. The last line deletes old quadsr. The routine supports subdivision without displacement and CCSD, hence the if(smooth) in places.


Vert disp[MAXSIZE]; // displacements
uint val[MAXSIZE];  // valences

void subdObj (Object *ob, uint smooth) {
Vert tmp,ep,fp;
uint eid[4],cni; //indices for new vertices, edges and centre
uint onq = ob->nq;
uint onv = ob->nv;

ZeroMemory(disp,MAXSIZE*sizeof(Vert));
ZeroMemory(val,MAXSIZE*sizeof(uint));
for (uint iq=0; iq < onq; iq++  ) {
          centroid (ob, iq, &fp);                        
          cni=addVert(ob,&fp);                       
          for (uint v=0; v<4; v++  ) { // for each vertex in each quad quad
              lerp(&(QV(ob,iq,v)), &(QV(ob,iq,(v 1)&3)), 0.5f, &ep);                                 
              copy(&ep,&tmp);                                  
              if (smooth) smul(&tmp,0.5f);                                 
              eid[v]=addVert(ob,&tmp);   // orignal vertices of edge/4.0                                 
              // add contrib of face points to displacement for new edge points                                 
              smadd (&fp,0.25f, &(disp[eid[v]]), &(disp[eid[v]]) ); // add fp/4 to edge vector                                 
              // add face points to displacement for original point
             add (&fp, &(disp[ob->q[iq][v]]),&(disp[ob->q[iq][v]]) );
             // add 2x edge points to disp for original points
             smadd (&ep, 2.0f, &(disp[ob->q[iq][v]]),&(disp[ob->q[iq][v]]) );
             val[ob->q[iq][v]]  ; // add up valences
       }
  // now construct four new quads
for (uint k=0;k<4;k++  ) addQuad (ob, ob->q[iq][k], eid[k], cni, eid[(k-1)&3], selected(iq));
}
// now displace all vertices...face points will be unaffected
if (smooth) for (uint v=0; v <q->nv; v++  ) {
  if (v < onv) { // this must be an original point     
     smul (&(disp[v]), 1.0f/val[v]);     // average the displacement values     
     smadd  (&(ob->v[v]), val[v]-3.0f, &(disp[v]), &(ob->v[v]) ); // correct for extraordinary vertex
     smul (&(ob->v[v]), 1.0f/val[v]);     // divide through by valence
  } else add (&(ob->v[v]), &(disp[v]), &(ob->v[v]));
}
for (uint iq=0; iq<onq; iq++  ) delQuad(ob,0);
}

Well depending how you count lines of code its 20-25. addVert and addQuad make it 25-30. So lets call it 30 lines of code Catmull Clark in C. C++ operators would make this a bit shorter. IQ claims 50 lines of code but if counted in the same way, his code is about the same 30-35.

The way the code works is a two pass algorithm first over quads of the original model and secondly over the vertices of the new model. The first pass subdivides and accumulates displacement in a seperate vector. This enables the first pass to calculate all the valences and store them before averaging the final displacement and applying it in the correct manner depending on the type of point (original, edge or face). There are a couple of gotchas but thats the basic idea. No winged edge, infact no edges at all.

Coding style sucks. Happy with result so thought I'd publish it.

One cool thing is the model pictures is about 22 bytes to store. A champfered cube is about 12 bytes and a sphere similar. It means we are looking at qoob providing a library of demo type objects in a few hundred bytes. The spheres are made of quads and do not suffer from peaks at top and bottom. Ther qoob library is a few kilo unfortunately. DX would help but I think I'll target 64k so not to worry.

Qoob Progressing

2010-07-01T01:42:00.003+02:00

My modeller is progressing. Heres a screen shot:

The model in the picture takes about 30 bytes to store. Smoothing is next up.
Organic stuff is escaping me right now but I'll work on that.

stupid idea 247: worlds smallest vector maths library

2010-06-30T00:00:00.009+02:00

Here is a tiny 3d vector maths library:

typedef float vec3[3];
vec3 *vec(vec3 *v, float x) {v[0]=v[1]=v[2]=x;return v;}
float *mav(vec3 *v1,vec3 *v2,vec3 *v3,vec3 *v4,vec3 *v5){
  for (int i=0; i!=3; i++) v3[i]=v1[i]*v4[i]+v2[i]*v5[i];
 return v3[0]+v3[1]+v3[2];
}
vec3 VZERO={0,0,0};  vec3 VONE={1,1,1}; vec3 VMONE={-1,-1,-1};

Thats it. It can do zero, set, add, sub, length2, dotprod, negate, lerp, centroid. e.g add is :
mav(&v1, &v2, &v3, &VONE, &VONE ); // v3=v2+v1

Lerp means that centroid (the centre vertex of a quad) can be found without a division by using two lerps. For a moment it seems cool until you realise the calls to it dont compress all that well.
The challenges remaining are xprod, normalise and max/min. then I have everything for handling my 3d modeller qoob.If I can make minor adjustments to get those, this might be worth persuing.

Very .cool

2010-06-16T18:03:00.001+02:00

GLSL Minifier.

"GLSL Minifier is a tool to pack GLSL shader code. It generates a code as small as possible that is equivalent to the input code. The generated code is also designed to compress well. It has been optimized for use with Crinkler, but should perform well with any other compression tool. GLSL Minifier generates a C header file you can include from your code."

Very .cool

3d modelling for Intros ? qoob.

2010-06-14T08:32:00.008+02:00

I'm investigating meshes for a while. First attempts with Pohar from Rebels resulted in some pretty detailed modelling for 4k. It was the usual way. Create a mesh in a modelling tool, compress it, load it, smooth it, just the same as iqs approaches to the problem. As dx provides smoothing (loop I think), this results in tiny code and models of 500bytes or more as seed meshes. One of the problems with this technique is the model is equally "smooth" all over at the end. Its hard to have smooth parts and rough parts. Iq overcomes this by coding displacements.

This image fo a dragon was done using this technique and the result (with crinkler, shader, mesh and mesh code) was just over 2k...

Theres a good read about meshes in intros at Pouet.

I once did a 1k with several curved "lathe" objects, but it was com dropping and thats unreliable. I haven't fixed that so no code on Pouet right now. Maybe i'll try again with crinkler at some point. Lathes seem to be an option for modelling at 1k/4k. In the code I developed for gcc the models were just 8 bytes each before compression. The code to create the objects was around 350 after compression and the objects are curved: there is non-linear interpolation between points in the model. Click on the image to see what I mean.
But Lathes are limited.

Another technique I looked into was intersections of regular primitives. This can often produce surprising results. The idea is simply to rotate/translate a single primitive. The two screenshots below illustrate some results. The first is a rotated cone, resulting in a star. The second is a very small routine (180 bytes after compression) to generate organic like structures. Again no randomness, just rotate, translate, rotate stuff.

You can see the last one live in the second half of the awesomely coloured :-) 4k intro Fruit of the Loop.

But my goal is always to get away from embarressingly geometrical to something that looks modelled. It occurred to me that crinkler is very successful because it works at compile stage for compression, its not simply an exe packer. Thus my latest project is a modeller, the idea being to use the modelling commands to better compress the end model. qoob is a simple subdivision modeller based on wings3d functionality but very cut down. Its a fresh project but already I can see that no way will this be useful for 4k, only 64k. Thats disappointing but it comes from the fact that the library used to reproduce objects is 2-3k. An early screenshot is not impressive:

The idea remains right though: this is the modelling equivalent of a texture builder.

FRequency To the Road of Ribbon in 1k for win32

2009-11-05T00:46:00.004+01:00

Instead of producing my own stuff, I've spent time crunching down the original Linux 1k from Frequency. Mainly I did it to see it on my ati card (the original was messed up) but also to see if I could get a win32 version, written in C, down to 1024 bytes.

During the crunching it became obvious I'd have to make a few compromises:

The colour of the ribbon is the same as the walls. This is the biggest artistic compromise and definitely it can be criticised as compromising the original. To compensate I added a more dramatic camera path that gets very close to the ribbon.
Clock is less accurate and resets, causing a jump to a new viewpoint. This is not as good as the original.
View angle is smaller - caused by a new method of calculating view vectors. Not a big issue.

Thats really it. On the plus side, I've cured a bug that caused the ribbon to be reflected many times and I made the new version run a bit faster enabling a higher resolution. I've completely rewritten the code that generates the olour but I've stayed as close to the original as I could. I hope its not noticeable too much. However, mine is darker, perhaps I can cure this later.

This is a fantastic intro and not one I thought could be done in 1k in win32 in C when I started. Linux 1ks have smaller frameworks and so have more space available for the intro; and asm is of course more space efficient than C.

Here is the source code and an exe to try out. I hope you agree it has kept the essence of the original whilst being 1k in win32. I used crinkler 1.1 (even though 1.2 would produce smaller code) as 1.2 doesn't work for me. So the intro wont work under win7!!

Respect to FRequency from auld^titan.

Frequencies To The Road of Ribbon Reactivated

2009-11-01T09:56:00.005+01:00

Frequency did a really great Linux 1k recently. To the Road of the Ribbon is a classic labyrinth but (to my knowledge) for the first time with reflections and even a ribbon added. It fits in Linux at 1k nicely but is about 1240 bytes under windows, though xt95 made no attempt to make it smaller under windows, it was small enough under Linux. For some reason it was buggy on my ATi box so out of interest I converted the Linux assembler to C and ported to windows.

I couldn't quite get the code down to 1k using crinkler under windows (setup for windows is larger). Perhaps some jolly fellow can convert it back to asm? You can get my C version here, with a much compressed shader. Its around 1070 bytes using crinkler.

There are some nice tricks in this intro. I like the hi-res clock passed in through glColor4ubv:

t=timeGetTime();
glColor4ubv((unsigned char *)(&t));

and then in the shader (my version):

float w=dot(vec3(gl_Color),vec3(256/256,256,256*256))*.256;

The dot product was a great idea to get a hi-res clock, not sure if its original to Frequency but its very cool. I optimised the size a little by making the original vec3(1,256,65536) into the form above.

Bad intro year

2009-10-21T22:53:00.003+02:00

I started this year trying to code a full blown demo which is a long term work in progress now. In the mean time work took over and coding hasn't been possible. The hiatus has given me two very clear ideas for intros. I'll see if they come out as 4ks or something bigger later.

GLSL Shader Creation: Geometry, Vertex and Fragment

2009-01-20T23:37:00.006+01:00

To the point, I recently expanded my tiny shader creation framework to include geometry shaders. Not much to say about it. Notice that Geometry and Vertex shaders are optional. The code is getting quite long so it might be worth testing if loading the function pointers in a loop and indexing them would be smaller, nontheless its highly repetitive so crinkler should cope well.


GLuint ShaderCompile(const char *gs, const char *vs, const char *fs) {
GLuint p,s;
  p = ((PFNGLCREATEPROGRAMPROC)(wglGetProcAddress("glCreateProgram")))();
  if (gs!=NULL) {  
    //if there is a geom shader...
    s=((PFNGLCREATESHADERPROC)wglGetProcAddress("glCreateShader"))(GL_GEOMETRY_SHADER_EXT);
    ((PFNGLSHADERSOURCEPROC)wglGetProcAddress("glShaderSource")) (s, 1, &gs, NULL);
    ((PFNGLCOMPILESHADERPROC)wglGetProcAddress("glCompileShader"))(s);
    ((PFNGLATTACHSHADERPROC)wglGetProcAddress("glAttachShader")) (p,s);
  }
  if (vs!=NULL) {  
    //if there is a vertex shader...
    s=((PFNGLCREATESHADERPROC)wglGetProcAddress("glCreateShader"))(GL_VERTEX_SHADER);
   ((PFNGLSHADERSOURCEPROC)wglGetProcAddress("glShaderSource")) (s, 1, &vs, NULL);
   ((PFNGLCOMPILESHADERPROC)wglGetProcAddress("glCompileShader"))(s);
   ((PFNGLATTACHSHADERPROC)wglGetProcAddress("glAttachShader")) (p,s);
  }
  s=((PFNGLCREATESHADERPROC)wglGetProcAddress("glCreateShader"))(GL_FRAGMENT_SHADER); 
  ((PFNGLSHADERSOURCEPROC)wglGetProcAddress("glShaderSource")) (s, 1, &fs, NULL);
  ((PFNGLCOMPILESHADERPROC)wglGetProcAddress("glCompileShader"))(s);
  ((PFNGLATTACHSHADERPROC)wglGetProcAddress("glAttachShader")) (p,s);
  ((PFNGLLINKPROGRAMPROC)wglGetProcAddress("glLinkProgram"))(p);
  return p;
}

(I'll return to DirectX and OpenGL next post.)

How to Use D3Dx and OpenGL together : Part 1

2009-01-12T12:47:00.009+01:00

I love OGL but the OGL SDK is a shoddy collection of web links. Worse, although as size coders we have GLU, DX coders have a lot of advantages in the standard libraries they have access to. Fortunately, DirectX is quite well designed in the way libraries are broken down and from OGL its possible to use the d3dx support library without rendering using D3d. Its a little overhead of course compared to rendering everything in d3d, but in terms of bytes at 4k its almost nothing.

Inside d3dx are cool routines for getting normals to a mesh, smoothing meshes, raytracing (!) which can be used for collisions, splines for motion and camera paths, the elusive cube and torus, neither of which for some inexplicable reason appear in GLU, and a whole range of maths functions. In this little blog I'll show code to set up OGL and d3d together.


LPDIRECT3D9       pD3D;
LPDIRECT3DDEVICE9     pd3dDevice;

void initD3D(HWND hWnd) 
{
D3DPRESENT_PARAMETERS d3dpp;

    pD3D = Direct3DCreate9 (D3D_SDK_VERSION);
    d3dpp.Windowed = TRUE;
    d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
    pD3D->CreateDevice( 0, D3DDEVTYPE_HAL, hWnd,
                D3DCREATE_SOFTWARE_VERTEXPROCESSING, &d3dpp, &pd3dDevice );
}

The code above sets up D3D. To be precise, it initialises D3D enough so that we can use functions from d3dx. To be more precise, DirectX 9 functions. It may be possible to get smaller but I'm a beginner with d3d, so send me an email if you can beat it. As both pD3D and pd3dDevice are required by d3dx routines, we make them global. It may be possible to use a static declaration for d3dpp to make this smaller byt a few bytes.

Now we need some code to initialise windows and opengl and use this routine to initialise D3D:


static PIXELFORMATDESCRIPTOR pfd={
0, // Size Of PFD... BAD coding, saves bytes
1, PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER, 32, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 32, 0, 0, 0, 0, 0, 0, 0 
};

void WINAPI WinMainCRTStartup()
{
    HWND hWnd = CreateWindow( "EDIT", NULL, WS_POPUP|WS_VISIBLE|WS_MAXIMIZE, 
                          0, 0, 0, 0, 0, 0, 0, 0 );
    initD3D(hWnd);
    HDC hDC = GetDC( hWnd );
    SetPixelFormat ( hDC, ChoosePixelFormat ( hDC, &pfd) , &pfd );
    wglMakeCurrent ( hDC, wglCreateContext (hDC) );
    ShowCursor(FALSE);
    .
    .
}

The code above is a little larger than normal because the d3d initialisation requires the window handle as well as the GetDC call, so we have to store it in hWnd variable.

In this blog then, I've presented a tiny framework that initialises win32, opens a window, initialises d3d and initialises opengl. In the next Blog, I'll describe how to use mesh functions in d3dx and render using OpenGL.

Place to live

2009-01-01T19:48:00.001+01:00

Joined Titan. Good to have a home :-). Titan gets a lot of bad press. So much so I once decided to leave but luckily they are a forgiving bunch and let me back in. However, inside Titan there are fabulously talented people and its hard to see why Titan hasn't been more successful to this time. Anyway, thanks for letting me back in, I'm already enjoying myself.

Very small Code for Cornell Box

2008-12-29T11:30:00.003+01:00

I don't often just add links here (first time) but here is one worth seeing for size coders. Its a complete global illumination solution in 99 lines of C++ code. I notice the exe can be less than 4k.

Code for Moving Camera in GLSL Raytracer

2008-12-22T22:50:00.006+01:00

Suppose you have a "two triangles and a shader" program as iq likes to call them. Essentially, you cover the screen with a polygon and then draw everything with a shader. This might be raytracing, for example. The problem is this: how to move the camera around in very few bytes. Better, how to write a very small shader that lets us use OpenGL commands like gluLookAt and glRotate to control the camera?

A good solution hit me today so here is the code. First the main opengl loop to draw that polygon contains:


glRects(-1,-1,1,1);

This is one good advantage for size coding of OGL over D3D. A single polygon covers the screen. We cant use texture coords or colours at the vertices or we would have to define a quad or two triangles. So we are stuck with just the vertices.

Now the magical, tiny, Vertex shader which will give us a moving camera:


varying vec3 v,EP;
void main(){
  gl_Position=gl_Vertex;
  v = vec3( gl_ModelViewMatrix*gl_Vertex);
  EP= vec3( gl_ModelViewMatrix*vec4(0,0,-1,1) );
}

The first line, makes sure that the glRect still covers the screen in the Pixel shader. It does not transform it but leaves it where it is. The second line, however records the transformed vertex in world space as a vec3. This in effect will record the position in world space for every pixel on the screen.

The last line is recording the eye position. Arbitrarily, the eye position is hardcoded here to be one unit in Z away from the screen giving a filed of view of 90 degrees - quite normal for a camera. Note that eye point needs a homogeneous value of 1 as the fourth co-ordinate to work properly.

We could have used vec4 for both lines above and the code would be shorter, but as most raytracing will use vec3 later, yuo can chose to bite the bullet and make the code longer here and shorter in the fragment shader. Horses for courses.

Now in the fragment shader its easy to construct the ray to start tracing:


varying vec3 v,EP;
void main(){
vec3 Ro=EP;     //set ray origin
vec3 Rd=v-Ro;   //set ray direction

Its that easy. Now you can move the camera in your raytracer using normal OpenGL commands. To finish here is an image from YAST (yet another sphere tracer as I'm calling my glsl raytracer). I'm able to move around the spheres as I chose. As usual, click on the image to see a bigger version.

Out of interest, on an x1950, 1024x768, 30 spheres, one light, shadows and 3 levels of reflection, I'm getting around 50fps.

Getting OpenGL shaders even smaller

2008-12-21T11:20:00.005+01:00

Flow2 is a 1k of mine from over 12 months ago. It was 1022 bytes. Since then, several things changed. Firstly, ATi fixed their drivers for *some* cards so that you no longer need a vertex shader/fragment shader pair. As per the glsl spec only a fragment shader is necessary. Fearmoths exploited this in their Linux 1k You Massive Clod. Secondly, last January Crinkler 1.1a was released which compressed better (20 or so bytes). Thirdly, I got better at size reducing C code for crinkler.

So, it was time to revisit an old intro and try to size reduce it. As it happens flow2 didnt have a proper timer so I decided to add one, taking the intro way up over 1024 bytes. Nontheless the current exe is ... wait for it... 890 bytes!!
Thats extra timer code and still 130 bytes smaller. OK, some code. Flow2 is a "one polygon and a shader" style of intro. The point is now you don't need a vertex shader, just a pixel shader, the tiny glsl code can be even smaller:


void setShaders() {
GLuint p,s;
   s = ((PFNGLCREATESHADERPROC)wglGetProcAddress("glCreateShader"))(GL_FRAGMENT_SHADER); 
   ((PFNGLSHADERSOURCEPROC)wglGetProcAddress("glShaderSource")) (s, 1, &fsh, NULL);
   ((PFNGLCOMPILESHADERPROC)wglGetProcAddress("glCompileShader"))(s);
   p = ((PFNGLCREATEPROGRAMPROC)wglGetProcAddress("glCreateProgram"))();
   ((PFNGLATTACHSHADERPROC)wglGetProcAddress("glAttachShader"))(p,s);
   ((PFNGLLINKPROGRAMPROC)wglGetProcAddress("glLinkProgram"))(p);
   ((PFNGLUSEPROGRAMPROC) wglGetProcAddress("glUseProgram"))(p);
}

Now the big question...can you fit a synth and music in 130 bytes? Midi for sure but a real synth? The wav header alone is around 43 bytes after compression, add in PlaySoundA and already half the bytes are gone. It seems unlikely but ... well...

Tiny code for Using Multicore CPU Multithreading

2008-12-10T13:04:00.006+01:00

Its easier than most people think to use multicores, even with very small code.
The trick is to realise that a CPU, when given more than one thread, will try to run those threads on different cores where possible. I used multithreading (and hence multicore) in a 1k once. I wanted the music in a different thread because I had no space for a real timer for the music. So, the music was written as a function that played the next note. The function was called from the main loop. Timing issues connected to drawing the graphics meant the note was played slightly off beat at times and it was very disconcerting.

So instead I changed the music routine to be:


Loop:
 Issue notes
 Sleep for some time

Then I set it up in another thread before, entering the main loop, using:


SetThreadPriority(_beginthread( &addTune,0,0), THREAD_PRIORITY_TIME_CRITICAL);

(Watch out this was done using GCC - VC++ may need other, more precise, syntax)
beginthread kicks off a new thread with the function addTune as the first function called in that thread when it starts. SetThreadPriority ensures that even on a single core the music thread will have higher priority than the main graphics thread and the music will not suffer tiny stalls. The ear is more sensitive to this than the eye to the occassional graphics frame dropped.

You need to include process.h for the thread calls above.

On multiple cores this would now be configured by the O/S to be two threads running on two cores.

What about synch? In the 1k I synched the music to the graphics. This means communicating between the two threads (and cores). Again this is deceptively simple.
A variable is declared and the music thread assigns it each time is plays a new note. The drawing thread uses the variable (read only) to decide how to move the graphics just as normal. Globals can be used to communicate between threads and even to synchronise them.

Threads and cores can be very tricky beasts in true parallel programming (I used to work at Edinburgh Parallel Computing Centre on the supercomputers there) but they can also be used in even a 1k intro!

Addendum, to avoid linking with MSVCRT and use win32 functions instead, its possible to use syntax like this in VC++:


SetThreadPriority((HANDLE)CreateThread( NULL, 0, 
  (LPTHREAD_START_ROUTINE)&addTune,0,0,0), THREAD_PRIORITY_TIME_CRITICAL);

Intersecting a ray with spheres: GLSL

2008-11-03T23:01:00.003+01:00

To the point, here is a dump of some very small code to intersect a ray with N spheres. I used it for my wada rendering so its hardwired to four spheres. It is a function so can be dropped into anyones code. Its dumb and just does a linear search over the spheres. However, you can get reasonable speeds up to 20 spheres or so depending on your card. It is of course ps3.0.

p: the point of origin of the ray.
rd: ray direction.
si: OUTPUT, the closest sphere hit.
t is returned, the distance to the closest intersection point.

Assumption: spheres are passed in as vec4s into a uniform, in the normal GLSL manner. Each vec4 is (x,y,z,r2): centre and radius squared.


uniform vec4 sph[4];  // in this case 4 spheres

float isect (in vec3 p, in vec3 rd, out vec4 si){
float t=999.9,tnow,b,disc;
  for (int i=0; i<4; i++) {  //each sphere
    tnow = 9999.9;           //temporary closest hit is far away
    //next 4 lines are the intersect routine for a sphere
    vec3 sd=sph[i].xyz-p;    
    b = dot ( rd,sd );
    disc = b*b + sph[i].w - dot ( sd,sd );
    if (disc>0.0) tnow = b - sqrt(disc);
    // hit, so compare and store if this is the closest
    if ((tnow>0.0001)&&(t>tnow)) {t=tnow; si=sph[i];}
  }
  return t;
}

A couple of explanations:


disc = b*b + sph[i].w - dot ( sd,sd );

sph[i].w is already a radius squared so saves some code here. Also dot(sd,sd) is short for length(sd) - less bytes.


if ((tnow>0.0001)&&(t>tnow))...

tnow is the current intersection parameter, the distance along rd of the current intersection. If tnow is very small, we may be intersection with the sphere we are already on and must ignore it. 0.0001 is arbitrary.
Of course to get the actual intersection you need to do this in the main routine:


if (t!=999.9) inter=p+t*rd;

or something similar.

Returning to IFS

2008-11-03T22:40:00.003+01:00

A few years ago I posted on how to make IFS small over on in4k. Now fractals aren't that well received in the demoscene (a bit been there, done that). The fact is though they are amazing for graphics size coding. The following image was generated using only two (!!) transforms and some nice colour mapping. That would be about 150 bytes.

Click on the image to see it larger.

Now with geometry shaders, an IFS could be run in the geometry pipeline to create complex 3d structures from simple primitives ...lets say, oh I don't know....cubes, in exactly the same way traditional IFS fractal flames are created using points in 2d.

Anyone with geometry shading hardware care to try?

Disappointing Last 4k

2008-10-26T22:20:00.005+01:00

Last year I quit dbfinteractive forums, where previously I was very active. If you dont know it, I recommend it as a place to find interesting code snippets for beginners in the demoscene. I also did my last 1k. Largely, I felt I was going nowhere fast with my 1ks. The same is true of my 4ks now and Triangle Ted is my last 4k. TT was meant to be my first 100+ thumbs on Pouet, and my last 4k. Instead it turned out to be a backward step (in rating terms) but remains my last 4k. Disappointing but thats life.

I hope that you've enjoyed some of my 4ks and maybe even been inspired to try yourself.

I like the challenge of size coding so this blog will continue and when I produce anything useful it will go here. As a consequence of not competing in the scene I can be freer with code and what I do which is really what I need now. This means more code should be available on this blog than before. Hurrah!

4k Procedural Graphics

2008-10-19T22:02:00.002+02:00

A new category in size coding has been legitimised by the fantastic work of RGBAs iq: 4k procedural graphics. Unlike intros, procedural graphics draw a single image and stop. Usually the image takes from a few seconds to upwards of a minute to render.

Here are some of the best examples to date:
ixaleno
rgba_slisesix
godspeed
photon race
off the shelf

It occurs to me though that there is huge scope for innovation in this category. Here are some ideas:

- Image plus music. An image is drawn and accompanying mood music plays.
- Image plus movement. An image bigger than the screen could be drawn and scrolled or zoomed.
- Slide show. Several images are rendered and displayed with some transition one afetr another.
- Red-blue image. 3D images requiring red-blue glasses.
- RDS Images (random dot stereograms)
- Movies (perhaps this breaks the fundamentals of no animation)

It seems there may be lots of ways to expand this category. 2009 promising to be equally as interesting as 2008 has been in the sizecoding area.

New 4k finished

2008-10-18T09:33:00.009+02:00

Despite a very tough year for me, I've finally finished another 4k. This time the synth and music come from s!p and graphics and concept (yes, there is a concept!) from me. It was released tonight at TRSAC. Thanks go to Rbraz too for a piece of code he placed at dbfinteractive forum for all to use. As usual, click for larger versions.

The 4k is about my experience as an "oldskool" guy seeking work in a "newskool" environment. In a country where I don't speak the language too well. Requires PS3.0 card and quite a strong one (say x1800 or 7XXX class onwards). It runs under XP or Vista and also on Nvidia and ATi.

Watch out for it on Pouet soon: Triangle Ted Seeks a Job. Once again, Youtube succeeds in murdering the quality (the uploaded version was quite good) but here is the video anyway. It should whet your apetite to see the intro for real I hope.

Ati is dead in the Demoscene

2008-09-21T08:49:00.003+02:00

There are a precious few groups (the best groups) who are able to write shaders for both Nvidia and ATi cards. Weaker coders just code until it works on their cards and release, not knowing they are writing bad code. The worst of these will then blame bad drivers for their poor coding but the truth is they probably didn't even read the specification.

This situation was ok(ish) at the beginning of this year, before Nvidia demo boxes were sent out. However, now Nvidia dominates the demoscene (well done, it was great marketing by the way). Of the 4k teams out there, only TBC, RGBA and Fairlight are sure fire to work across many platforms. Notice how each group has a star programmer in there? ATi owners are left in the cold - few 4ks now running on their hardware.

Whilst 2008 seems to have been a good year for the quality and variation in 4ks, there is a darker side too. PC 4ks have become dramatically less compatible. Precious few run on ATi cards, PS4.0 has been used but runs on very few cards out there and, the winning 4k at NVScene doesn't even run on the XP operating system.

If you are new at this you probably don't know that being compatible costs bytes. It means your sound engine cannot use tracks available in one OS. It means shaders become slightly bigger, maybe even with multiple versions. It is not a level competition between the compatible and "works on one machine" 4ks. Not just this but producing compatible 4ks is harder - it requires more work. I spent a day recently debugging my shaders on Nvidia after size reducing them on ATi. Simply put, compatible 4ks should be given more credit. In a world where 100 bytes makes all the difference, exploiting OS specific advantages is a huge advantage.

Non-compatible 4ks usually claim to work on the "compo" machine. After all they wouldn't be released otherwise. This is fine except the bigger parties are now providing very high end machines (full HD, quad core, >2Gig of RAM, ps4.0 new graphics cards). Most people do not have access to this technology, creating an elite who do. Thank goodness for smaller parties with more modest machines for competition, yet even they this year got their hands on Nvidia demo boxes, temporarily (I hope) exaggerating the problem.

How far will we go with the non-compatibility? I suspect we will go all the way. The competition system is set up to reward those who do produce something that works on one machine. Nothing else matters.

What if it changed? What if competitions DID NOT announce the hardware or OS? Imagine a 4k intro competition with these rules:
*...
* OS will be XP or Vista
* Card will be ATi or Nvidia but will support PS3.0
* Organisers will run entries on compo machine and report results to competitors but no information about the compo machine will be released even at the party
*...

Isn't that the problem solved? If nobody knows the machine, it forces competitors to try to be compatible, not use too much CPU, be conservative on memory use. 4ks will run no a wider range of platforms and within one year we will all know how to write shaders properly.

I saw once someone suggesting we have a standard competition machine. I think this is unworkable. How will, say Riverwash, be able to access the same tech as Breakpoint? Its unlikely. In addition it doesn't solve the real issue. It just means every 4k will run on that platform (much like the Nvidia demobox problem of 2008) and no other.

Another possibility is to allow remote voting. Provide the entries live at the party for download. We at home can try them and vote. If they dont run we can give bad votes. The problem with this is (I suspect) it is open to abuse too much. It would be a brave party organiser who tried this.

No, the real solution is to make the target platform anonymous. Though, wait! If the platform is anonymous, some people will fail to get their precious 4k working. This will reduce the number of entries shown at parties. The smaller parties in 2008 struggled anyway to compete with the bigger ones for number of entries. So there is a downside.

Well, it seems the solution is simple then. Buy nvidia, upgrade to vista, replace that 2 year old PC with a new one and add lots of memory.

I know a good bank manager...

Glass tile distortion shader

2008-09-13T08:34:00.003+02:00

Occassionally, I will post tiny shaders, useful for effects in 4k intros (eg kaleidoscope). I discovered recently how to do glass tiles as a post process overlay in very little code. Distortion shaders require you to render to copy to texture first. I have done other blogs about this. However I would guess most 4ks already do this for blur, AO, rgb distortion or whatever already, so the extra bytes of this shader are absolutely tiny.

Here is the shader pair:


varying vec4 v;
void main(){ v = gl_Position = ftransform(); }

The vertex shader assumes something is drawn on the screen (a quad say) and covers the screen as a surface for the distortion shader. This means v will hold co-ordinates -1.0..1.0


uniform sampler2D s;
varying vec4 v;
void main(){
  vec2 x = v.xy/2.0 + 0.5;
  gl_FragColor = texture2D( s, x + 0.1*tan(x*5.0) );
}

Firstly v is mapped to 0.0..1.0 range of normal texture co-ordinates. The glass tile effect is then simply that tan distortion! Here is an image of what it can produce - ignore the background, thats just something to be distorted.

If you want to "waste" bytes, its a good idea to do something like:


  gl_FragColor = texture2D( s, x+min( 0.1*tan(x*5.0), 0.2 ) );

This helps to prevent "sparklies" in the distortion by keeping that tan under control.

Float casting in GLSL (today)

2008-08-20T10:07:00.009+02:00

Boring but may be helpful.
According to the GLSL spec version 1.2, ints can be cast to floats automatically. Ati has always held back on casting, nvidia being far more forgiving. However recently ATi made some advances in their compiler and now it works - almost. People programming small shaders, should be very careful in one particular case: functions.
Since the July driver update from ATi, the following are now all valid on Ati (verified with x1900, no version of shaders declared):


float a=1;
vec3 a=vec3(1);
float a=1/128;
a=max(a,0);  //warning:invalid on NVIDIA..do not use
a=pow(a,8);  //warning:invalid on NVIDIA..do not use
if(a>0)...

Previous Ati drivers required (in most cases above) to use a "." in the number eg:


a=max(a,0.);
if(a>0.)...

However, even on ATi, one exception still remains: user defined functions.


float f(float x) {return x+1;}  //valid
f(1); // INVALID
f(1.); // valid

Also:


float f(float x) {return 0;}  //INVALID
float f(float x) {return 0.;}  //valid

So, essentially, values passed to and back from a user defined function must still be explicitly typed. This is the only exception I have found so far on ATI. Intrinsic functions operate by implicitly casting (eg max). However on Nvidia, intrinsic functions must also be strongly typed. So the only safe way forward as of today is to make sure that all parameters into and out of *any* function are strongly typed (use the "." form) and do not rely on implicit casting.

The GLSL spec says that functions may be overloaded just by changing the types input. Therefore, the cards are trying to show the correct behaviour. The only hiccup is that ATI have decided that intrinsic functions are known and the user has not provided an overloaded version themselves so the implicit cast will go ahead. This seems to be an open (but known) issue in the spec.

Thanks for credits

2008-08-13T19:27:00.004+02:00

I wanted to say quickly that that I had credits/greets in two recent 4ks. This really encouraged me to continue posting "useful" snippets here even though sometimes my ideas get used before I get chance to finish a 4k! Thanks guys.Nucleophile which won at Assembly and fractoblob which uses the wada idea from a previous blog but successfully removes the sparklies that I suffered.

Isosurfaces in GLSL

2008-08-13T18:56:00.006+02:00

To render an isosurface in GLSL, you'll need:
* a fast graphics card
* ps 3.0

The basic algorithm is simple:


For each pixel
  Step along ray until surafce is hit
  Find normal
  Light and output colour

There are two complications though. Firstly when you ray march, you need to step a certain amount along the ray. Of course when you step, you may go through the surface, not exactly hit it. The smaller the step, the less this is important but the more compute power is required. The solution is a root finder. Essentially a root finder is required (eg secant, newton etc) so the steop along the ray is acceptably large (for performance) but a close enough approximation to the surface can be found (for visual integrity). When the ray passes through the surface a root finder is used to find the EXACT intersection.

Here is a very simple root finder function in glsl:


float rootfind(in float a,in float b,in vec3 eye,in vec3 raydirection){
float exact;
  for(int i=0;i<9;i++){
    exact=(b+a)/2.0;
    if ( func(eye+exact*raydirection)<0.0 ) b=exact;
    else a=exact;
  }
  return exact;
}

In the above example the function "func" is the isosurface we ar trying to intersect.

Here the algorithm is simple and tiny. a and b are parametric values for points either side of the exact intersection (you have these from ray marching). The rootfinder iterates a fixed number of times. Each time, the exact answer is approximated by the value half way between the previous two best guesses (initially a and b) which are an upper bound and a lower bound of the exact value. If the function value at "exact" is negative we must make the lower bound (b) equal to "exact", if its positive we update the upper bound instead because the intersection is when the function is equal to 0.

This is inefficient but its the simplest root finder to understand and can be coded very small.

So assuming we find the exact intersection using this method, mow what is the Normal to the surface? The normal is the rate of change of the function in x,y and z. We already have the value of the function at one point (the intersection point). So we need to call the function three more times, offset in each of x,y and z, find the differences and , optionally, normalise the results.

Here is a simple function in glsl to find a normal of an isosurface:


vec3 isonormal (in vec3 v, in float val)
{
  return normalize(vec3(val-func( vec3(v.x+.01, v.y, v.z) ),
                        val-func( vec3(v.x, v.y+.01, v.z) ),
                        val-func( vec3(v.x, v.y, v.z+.01) ) ) );
}

The function above takes the intersection point and the value of "func" at this intersection point as input and returns the normalised normal as a vec3. Notice how a small delta is added to each of x, y and z for the intersection point to get a new position in space. e.g.


val-func( vec3(v.x+.01, v.y, v.z) )

is a single float representing the change in "func" between the intersection point a a new point just a little to its right in x.

New 4k coming, Nvidia Zero

2008-08-08T10:51:00.005+02:00

Real life has kept me from programming for a long time. Fortunately things are sorting themselves out so I have a new 4k coming up (in conjunction with s!p this time). This one is heavy on the shaders and Pohar has challenged me to get 20 shader pairs into a single 4k. So be it Pohar - 20 shader pairs it is ;-).

However, blogs with no useful stuff in them suck so here goes.

Mentor recently pointed out on Pouet that he used the "noise" function for his brilliant Himalaya 1k. Only noise does not work on graphics cards at hardware speeds. He used it in software! This started me to thinking that it would be possible to pre-render cool textures using shaders in SOFTWARE during the pre-calc of a 4k/64k. The idea was simple, write shaders as normal but use the powerful functions that drop back to software (noise, dfdx etc), have them render to a back buffer slowly during the "loading" section of hte product, capture the texture, and then use the textures in real time shaders later.

A simple example:


const char *vsh="void main(){gl_Position=ftransform();}";
const char *fsh="
void main(){
  gl_FragColor= vec4(
    sin(30.0*length(noise2(gl_FragCoord.xy*0.01)))
  );\
}";

Results in:

Great - finally a way to do interesting textures at 4k in very few bytes (assuming you are using shaders anyway).

Only. No. This is OpenGL, not directx texture rendering. Nothing works the way it should. In this case the correct results (as per the GLSL specification) are achieved on ATi. On Nvidia, the rules break and Noise - the key to these textures - returns a big fat zero. This renders (you see what I did there :-) the whole idea useless.

ATi 1 - Nvidia 0.

So, noise on Nvidia cards returns 0 in GLSL. Sigh.

Iss3 - another 4k, while I slept

2008-07-16T13:28:00.006+02:00

Real life has prevented me coding for a long time now. But something as simple as not coding shouldn't prevent you making releases. Pohar of Hardread had some of my shader code lying around and, in deadline desperation I suspect, threw it into his new intro and gave me some credits. Inno from Conspiracy did the music and the synth is Pohars too. The 4k came second at SceneCon08 in Hungary.

Get iss3 here.
Requires ps2.0

The video really doesnt do the shaders justice, I recommend trying the original.

Hungarian Television also did a piece about SceneCon demoparty in which the intro in shown. Its 40 minutes of mainly Hungarian but I know quite a few visitors to this page are from Hungary so there it is.

The end of an era: no more 1ks

2008-04-24T23:32:00.003+02:00

Well its time to confess. The Riverwash 1k invitro will be my last 1k. I've been doing 1ks for over 2 years now and its time to move on. Thanks to everyone who voted for it and thanks to Riverwash organisers for asking me. Although I said I wouldn't publish code anymore, I can't think of a better way to bow out of 1k coding than to publish the last one so you can download the code here.

I hope in the last 2 years, my efforts at 1k and my publishing code have encouraged and enabled a few people to get going with 1ks.

Chip Magazine

2008-04-16T13:11:00.003+02:00

Today Chip Magazine was released so I can finally put an image here from the magazine. It basically says that the 1k intro collection by auld (me) is on the DVD together with some coding frameworks.

If you find your way here from reading Chip and are completely confused about the demoscene or how 1k intros are developed, I have set up an email address to contact me:

auld67 .at. gmail.com

You should also know that the framework included is old and non-optimal as there are license issues distributing the new one which includes a special compressor called "crinkler". So if you get into size coding, contact me and I'll explain how to get set up with crinkler.

Riverwash 1k invitro

2008-04-09T07:30:00.007+02:00

I've just finished a tiny (1k) invitro for the Riverwash party as an experiment. It was a real challenge to squeeze in all the usual text for an invitro (name, date, place, compos, website) into a 1k and present it in an interesting way. Its no work of art but it does the job quite nicely. I don't know any other invitros of this size so I think its the smallest one ever done.

The concept is very simple: an infinite zoom on text. At Evoke 2006,'Die Ewigkeit schmerzt' by neuro won the demo compo using a version of this technique. Neuro and Farbrausch then won Breakpoint 2008 demo competition with a very advanced and beautiful version.

Getting it into 1k would have been impossible without the '+' sign. The technique relies on one item being displayed inside another as you zoom. So things have to be carefully placed. However, by using the plus sign, I was able to guarantee a character in an area of the screen that would always be placed correctly for the next text. Its not always necessary (capital P, R and so on do not need it as they have horizontal bars in the right place), but it often is. This simple trick meant I did not need to store text co-ordinates or interpolate as I zoom from one place to another.

Download it here.

Incase you are wondering, the extreme colours are because Riverwash takes place in Poland.

Chip Magazine

2008-04-09T07:27:00.002+02:00

Polish Chip Magazine will be publishing all my 1 kilobyte intros in next months edition (available from 16th April). The good ones and the bad ones!

Raytraced spheres (again)

2008-03-30T22:45:00.005+02:00

The image here shows a snapshot of an animation through a cloud of 40,000 raytraced spheres. I was able to get 2.6million raytraced spheres per second from an x1900, 2.2 Ghz core duo PC at 1024x768 resolution. In fact, the rate was limited by the host PC. The method used was to render a quad billboard for each sphere and send a single spheres details (centre, radius) to the raytracing shaders using a glColor4f call. Sounds odd, but it saved on extensions code. The billboarding is calculated by hand, as it were, on the host and each quad uses four glVertex calls. Switching to submitting a vertex buffer and calculating the billboarding in a vertex shader would probably speed things up but as my graphics card is already melting, I gave it a break.

There are no shadows or reflections so technically this is raycasting only. Nontheless seeing 40,000 perfectly shaped spheres (even close up) drifting by, is quite a joy. I also went to the trouble of uploading camera co-ordinates to the shader and created a free roaming camera - all my raytracing so far has been from a fixed point of view.

One last point, look at the picture and you can see spheres intersect. This is because the z value output in the shader is not the z-value of the billboard but the real z-value of the sphere. This shows that the image isnt constructed from a simple point sprite system or a particle system using texture mapping but uses real raycasting on each sphere.

The spheres are per-pixel lit and bump-mapped. Click on the image for a larger version.

Shader Programming is Bad for your Health

2008-03-16T15:26:00.003+01:00

Well OK, the health of your PC graphics card. Here is an error message I got from one of my 1ks today:

Click on it to see a bigger version. The fans are fine, there is no blockage. Think I better buy a backup card...

Very small logos for 4k?

2008-03-14T20:13:00.008+01:00

There was a topic on Pouet recently of doing logos in 256bytes. I didn't even know this was possible so I gave it a go. The logo below is 183 bytes.

I learnt a few things. Firstly, PNG tends to be smaller than JPEG at this level of compression so PNG is best. Second, I used Paint Shop Pro (can't afford photoshop) and switched on all its optimising and the image was well over 300 bytes. However I then downloaded irfanView and the available plugins for it. One of the plugins is called PNGOUT and its great at compressing.

One thing, make sure you set save chunks to NONE. Heres another example, much larger, and only 227 bytes. Obviously the black helps...

So it would be possible to make a logo for a 4k intro for 150-200 bytes. PNG loading is easy too, simply load the image using d3dx - very few bytes. It can be read into an array and passed to OpenGL textureing if required...at least I hope so - the logo is 1 bit per pixel, I'm not sure how it will appear in memory when loaded. One way to find out...

In more tests, I did 16x16 images to see if texturing would be possible this way. Once you have the code to load a PNG it makes sense to use it as many times as possible. However the file over head is such that even the simplest of 16x16 images is around 100 bytes. So there is no significant advantage in going very small and really any PNG image looks like it is going to be 100-200 bytes as a minimum. At this size it makes more sense to encode the 1-bit bitmaps into the code itself and use GL_BITMAP type for the texture (16x16x1 = 32 bytes).

A couple more tries, close to 256bytes each.

Traditionally Sceners Dont Publish Code

2008-03-12T22:20:00.006+01:00

I read that in a scene magazine recently. Since I started I've been publishing code and trying to help people newer than myself to improve. I was naive and thought that was just the right thing to do. Dumb or clever, I shared my code. Some of it useful, most not so much, but I shared it. However, lately its been more trouble than its worth. Actually no, right from the start. I published code then removed it only to receive nasty emails about the removal, as if people had a right to my code. I've had my code ripped with no credits. I've had people contact me very late at night to fix their code and been angry that I don't want to help at midnight. I've helped people as much as I could and then not received any credit. People have been angry at me that I size optimised their code: one guy even seems not to want to share code anymore.

Real-life is enough hassle without all this. So, after a lot of thought, I've decided to restrict this blog to the usual boring stuff like what I am working on and so forth. No more code here: I'll do it the traditional way from now on.

Now Ill just wait for someone to be angry at me because I stopped sharing code...

The Best (sur)Prize!

2008-03-11T18:46:00.004+01:00

Well, lifes a bit rough now and then (more sort of now than then) but sometimes you get really cheered up. This package arrived today from Pohar of Rebels. So opening it, I found s cool Rebels t-shirt. I did a couple of 4ks for rebels with Pohar last year, so this is my prize and I have to say - its a good one. Heres a piccie especially for my mates over at Rebels - in my opinion, the group improving most all the time in the demoscene.

Go Rebels!

All my 1ks (1024byte) intros

2008-03-07T16:31:00.006+01:00

Again, I published a lot of these under different names but incase there is any confusion, all these tiny intros are my own work. Its clear to see from these that I got better and better: well as a general trend anyway. Its good to see such a progression over the last two years. I'd advise anyone entering the scene, no matter how much experience you have that it will take a few years to get good. I still haven't made a 4k I'm happy with but I do like my latest 1k chocolux. This one turned out well and for once I'm happy. Anyway to the list. They are in (roughly) reverse order, so the most recent one is first.

Chocolux (PS3.0 required)
Comment: Recursive raytracing of spheres.
Personal Rating: 9/10. Colours right! At last 9/10 - one I like.
Labyrinth1k (FAST PS3.0 required)
Comment: Raymarching.
Personal Rating: 7/10. Colours wrong! Camera path and animation synched in 1k isnt bad though. I feel this one is underrated. I can see why though. Slooooow.
Flow2 (PS2.0 required)
Comment: A corrupted mandelbrot set with two merging rendering schemes.
Personal Rating: 8/10. Its really very nice to look at.
Annoying Blue Circle (PS2.0 required)
Comment: A sphere with displacement shader and cool colours.
Personal Rating: 8/10. It works, its fun and has good sound by ampli.
Mandelflow (PS2.0 required)
Comment: A corrupted mandelbrot set with candy colour scheme.
Personal Rating: 7/10. Its nice to look at but not quite as advanced as flow2.
Morpheus (PS2.0 required)
Comment: A sphere with displacement shader.
Personal Rating: 7/10. It works, it has sound and texture.
Trinity (PS2.0 required)
Comment: A sphere with displacement shader and noise.
Personal Rating: 8/10. This is my fav of the matrix trilogy. This one feels like trinity to me. No sound loses it points ut the presentation works very well.
MrAnderson (PS2.0 required)
Comment: A sphere with displacement shader.
Personal Rating: 7/10. The first OGL and shader 1k anywhere!
Ah Bollocks
Comment: A sphereflake (sortof) with a cool animated texture by mind.
Personal Rating: 4/10. I dont like it. Its rough and colours are depressing.
Grail1k
Comment: Curved, animated, 3d models in 1k!
Personal Rating: 6/10. OK it looks rough but curved 3d models gives it points for me.
Scotland the furball
Comment: Fur in 1k.
Personal Rating: 4/10. The fur should animate and its way too slow. Still - fur!
Revolver
Comment: A tenticular monster, animated.
Personal Rating: 4/10. Very low tech but it works ok, the animation is nice.
Hive
Comment: A proper intro (start, middle, music, textures, 3d model, camera move)
Personal Rating: 6/10. It looks rough again (why do I do this) but its got so much in it I have to rate it well.
Abscrapt
Comment: An interpreter language in 1k drawing some abstract rubbish.
Personal Rating: 3/10. Just awful colours destroy this one.
Mus1k
Comment: a real synth in 1k.
Personal Rating: 3/10. It just didnt work.
Hypnot1k (WinXP SP2 ONLY)
Comment: Music, speach, text and graphics in 1k.
Personal Rating: 2/10. My god what was I thinking - the colours - the sound.
Kagazoon (WinXP ONLY)
Comment: Watch your screen spin in 1k.
Personal Rating: 7/10 the first time. 5/10 thereafter. Its not bad looking but its a gimmick.
Rad1kal
Comment: 6 or seven scenes in 1k!
Personal Rating: 6/10. The scenes are too long and a bit ugly but damn thats a lot of effects in 1k! Show me any 1k with even half this many scenes.
Debut1k
Comment: A texture gen engine in 1k.
Personal Rating: 5/10. Not bad, not too ugly. Texture gen in 1k is not so easy.

Phew I think thats all. These days even a 1k takes me more than a month to find a good idea and nail it so it works on Nvidia, ATi and fits inside 1k.

My 4ks

2008-03-06T18:28:00.005+01:00

I thought it was worth listing all my 4ks so far here. Not all credits in files say Auld. Thats because I liked to use different names to publish code under. These days I only use Auld.

Spheres Dream.
Requirements: PS2.0, OpenGL 2.0
Comment: Done for Rebels demogroup. Voted best Mac intro of 2007. Second at Function 2007. Mellow, dreamy, spherey.
Credits: Auld (code and design), H20 (design), Pohar (synth), Vincennzo (music).

Fruit of the Loop
Requirements: PS2.0, OpenGL 2.0
Comment: Done for Rebels demogroup. Second at Kindergarten 2007. A bit weird.
Credits: Auld (code and design), Pohar (code and synth), Vincennzo (music).

Inferno.
Requirements: OpenGL 1.4
Comment: Done for Titan demogroup. Winner Evoke 2006 4k intro. Dantes trip to Hell, re-interpreted and set to hard music.
Credits: Auld (code, synth, design), Saida (tools, synth), Strobe (music), Alien^pdx (design)

GS.
Requirements: OpenGL 1.4
Comment: Done for MUPS demogroup.
Credits: Auld (code, synth, "design" :-)), Saida (tools, synth), SOR (nfo file), ampli (music)

Halls o' Halloween
Requirements: OpenGL 1.4
Comment: done for DBF Halloween competition 2006. Won 1st place. Lots of geometry for 4k.
Credits: Auld (code, synth), Saida (tools, synth), Ampli (music)

To Vertex Shade or not to Vertex Shade

2008-03-01T17:59:00.003+01:00

The GLSL specification says that it is legal to create a shader that has one instance of a fragment shader and no vertex shader. Under these conditions, the default vertex pipeline should run. This worked on Nvidia and ATi - sort of. ATi allowed it but did not set up gl_FragCoord correctly - effectively making the fragment shader useless. In other words, it didn't work.

However, on Feb 13th 2008 ATi released new drivers which cured the problem. So its now possible to write tiny glsl code without a vertex shader.

Only tested for sure on x1950 so far but will test on other cards soon...

Chocolux 1k intro

2008-02-26T22:41:00.007+01:00

Chocolux is a real-time recursive raytracer using four spheres. Lighting and intersections are all approximated to fit the 1024 bytes boundary. I used crinkler 1.1 for compression. The executable can be downloaded at Pouet or Intro Inferno. For those with no PS3.0 card is a video:

The code can be downloaded here.

Probably the best space saving trick in the code is:


t=GetTickCount();
glRecti(t,t,-t,-t);

This allows the time to be passed into the shader without either using glGetProcAddress calls for the extensions or using glColor3f which is smarter but still not as good. So long as t is bigger than 1 (it will be as GetTickCount is a millisecond counter from boot time of the PC) the screen will be drawn and the value of the vertex can be used for the timer.

The recursive raytracer is no use to anyone outside this code as the maths is corrupted to give a more detailed image and smaller bytes. However, Pohar found a trick worth mentioning. The nested loops in the fragment shader both use i as the variable (rather than say i and j). This allows crinkler to really go to work and compress this code down. Its legal in shaders and, I'm told, C too.

One other byte saving trick I haven't seen anywhere else is I have no background test in the code when rays do not intersect objects. Normally this would be an if and some calculation to assign colour for the background. Instead, I place the scene inside a sphere so I know the ray will always hit one object. This also adds a lot of visual complexity to the scene.

There are pragma statements like:


#pragma data_seg(".shad2")
.
.
.
#pragma code_seg(".compile")

scattered through the code. These are to assist crinkler as it may reorder the code more, saving here, 6 bytes. These are placed just before data and just before every function and the main entry point.

POVRay 2008 Short Coding Compo Results

2008-02-17T20:24:00.003+01:00

All I can say is wow, some of these animations are amazing. Congrats to all the winners. My personal favourite is second place. It lacks a little of the visual artistry of the winner but the technical aspects are amazing. Shaking camera, explosion of light, nuclear cloud. Animated. IN 512 bytes? Awesome work. The idea to use a sphere instead of a sky sphere so the sky glows for an instant when the explosion happens is really inventive.

Wada updated

2008-02-17T10:13:00.006+01:00

I finally got around to fixing the colours and fixing the distortion in the wada fractal. The wada, as a reminder, is a non-self similar fractal formed by placing four reflective spheres touching each other in a kind of pyramid. Although I didn't size crunch, I guess the whole thing would be sub 1.3k. Its hard to crunch it as the wada is very sensitive to things like ambient, diffuse and specular contributions so a full raytracer has to be implemented, not just a fake approximation.

I'm rapidly coming to the conclusion that there are a range of interesting special effects available with very simple, recursive, raytracing. I won't publish code yet as likely I'll do a 4k using some of the tricks I'm working on. The point is, the wada would be very hard for traditional polygon rendering to do. The reflections would be too hard to achieve accurately. So, tiny raytracers should concentrate on lots of reflection and refraction instead of doing a range of simple primitives (sphere, cylinder, planes etc) and using you bytes this way is a mistake. Such scenes are unimpressive.

Add to this the possiblity for traditional 2d post processing (blur, depth of field, glow) on top of raytracing and there is definitely room for overcoming the "spheres on chequer board" factor.

The wada images above can be clicked on for larger versions. They are real screen captures from a real time wada renderer. Hence the larger images have some artefacts. A small blur post-processor shader will overcome this.

Helping Crinkler

2008-02-11T14:32:00.000+01:00

There are two things to understand about crinkler that can help. Crinkler replaces your linker which means it has access to sections of code and data when linking. It can re-arrange these sections to achieve more compression. Even more, crinkler uses two different schemes for compression: one for code and one for data. The Crinkler manual talks about defining data and code blocks in assembler. However, its possible from C too.

#pragma data_seg(".name1")
#pragma code_seg(".name2")

The pragma statements can be and should be used just before every chunk of data and every new function. Any names can be used but meaningful ones are useful when Crinkler outputs its report.

POVRay short code contest now on

2008-01-17T20:30:00.000+01:00

The 5th POVRay short code contest is running. I'm not entering this year but here are my entries from last year, complete with code. I didn't win but had a lot of fun trying.

The Cave:


#macro A(f)finish{reflection{,f}} #end
union{plane{z,20}normal{wrinkles}A(2)}union{sphere{z*22-3,5}A(1)}
union{plane{y,-3}normal{agate.3}A(1)}sky_sphere{pigment{agate scale 3}}

X-Ray:


#macro A(f)cylinder{<9*sin(f),6*cos(f*f),6>,,1,2} #end
union{
blob {A(4)A(5)A(8)A(9)A(0)A(1)A(2)}  
pigment{wood}
finish {reflection{,6}}
}
sky_sphere{pigment{wrinkles}}

Another 4k Finished.

2007-11-21T20:55:00.002+01:00

Using the latham and kaleidoscope shaders, I've done another 4k. This was done with Pohar (code) and Vincenzo (music) of Rebels. You can get the executable here. It requires ps2.0. There is a final and a party version with wildly different colours. The key pieces of code are already on this blog further down. Hope you enjoy it.

Kaleidoscope shader

2007-11-17T06:58:00.003+01:00

The images above are created by rendering some graphics to the back buffer, capturing this as a texture and then using that as input for a kaleidoscope shader. The kaleidoscope shader is trivially. I'm assuming you have drawn your scene and captured it to texture (see previous articles).

First the vertex shader.


varying vec4 vertexcoord;
void main(){
vertexcoord = gl_Vertex;
gl_Position = gl_Vertex;
}

First line 2. It sets the position to be the input vertex (not the more usual ftransform()). This ensures whatever object we draw ignores the transformation matrix. It just makes it easy to draw an object covering the screen. The important line is : vertexcoord = gl_Vertex; Vertexcoord will be used as texture coordinates in the fragment shader.

Now the fragment shader...


uniform sampler2D tex;
varying vec4 vertexcoord;
void main() {
gl_FragColor = texture2D ( tex, abs(vertexcoord.xy) );
}

So an input image is drawn on the screen using the vertexcoord set in the vertex shader. Theres a trick here: abs. This is the kaleidoscope effect - this simple! Now in the main code we just draw a rect...


glRecti(-1,-1,1,1);

A Kaleidoscope shader in very few bytes.

New Layout

2007-11-12T14:15:00.001+01:00

Site quickly redesigned to allow for wider and more readable code segments and fit the minimalist theme, so useless information has been removed. Comments (due to some trolling) removed. Most people seem to contact me by email anyway. Hope its cleaner and more useful for you.

Read shader from file without stdlib

2007-11-04T18:22:00.000+01:00

Over at Lighthouse there are some useful tutorials and some example code. One piece of code I've found all over is the "read a shader from a file" code. Unfortunately its not much use for size coders as it uses stdlib. Essentially it allows you to write shaders in a normal text file and load them as a string.So here I've done a conversion using win32 equivalent functions. It doesn't check error codes (wasted bytes) so be careful to pass in the right filename. I'm not sure this is the smallest way, its just a translation of Lighthouse code.

Essentially adding this code to your intro allows you to develop the shader without constant recompiles.

#include "windows.h"

 char *textFileRead(char *fn) {

 char *content=NULL;
 DWORD dummy;

 HANDLE fp = CreateFile (fn, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
 DWORD count=SetFilePointer (fp, 0 ,NULL, FILE_END);
 SetFilePointer (fp, 0 ,NULL, FILE_BEGIN);
 content = (char *)GlobalAlloc(0,(SIZE_T)(count+1));
 ReadFile(fp, (LPVOID)content, count, &dummy, NULL);
 content[count] = '\0';
 CloseHandle(fp);
 return content;
}

Wada basin in real time

2007-11-03T11:58:00.000+01:00

My raytracer works well enough to set up something never seen before (I think). This is a shot of a real time animation of a Wada Basin fractal. It runs around 30 fps with no attempt to optimise. Its early days yet but I'm hoping this will really pay off. The slightly wrong shape is due to a severe perspective distortion. I'll fix this and publish better images soon. As usual bigger images are available by clicking on small images.

If you are unsure what a Wada Basin is and why a real time one is quite a novelty, have a look here at Paul Bourkes superb web pages.

I'm not happy with colours or shape yet but in motion, it looks great.

Real Time Raytracing

2007-10-30T07:12:00.002+01:00

I've decided to make a tiny PS3.0 raytracer. It will take some time to get it working on lots of platforms and size optimised but here are the first two buggy but pleasing images. I'll add updates and later publish the code. Click images for larger versions. It runs at about 50-60fps on my x1900 at 1024x768 resolution with six levels of reflection.

Shaders to render normals : NOT!

2007-10-27T15:45:00.001+02:00

A useful debugging tool is to get a colour representation of the normals in a scene. With a bit of maths, it can also produce some nice, free colouring for an intro. Above is a correct image. It shows a whole bunch of spheres. Red is the x component of the normal, green the y and blue is z. Study it and you'll see its right. Only it took me a few hours to get this right. I made a very simple error, which maybe others do too so I thought I'd document it here.

Hmmm, this is what I actually got:

Pretty,yes. Wrong, definitely. Here is the WRONG CODE. This code has a serious bug:


const GLchar *normalsvsh="\
varying vec3 n;\
void main(){\
n = normalize(gl_Normal*gl_NormalMatrix);\
gl_Position=ftransform();\
}";

const GLchar *normalsfsh="\
varying vec3 n;\
void main(){\
gl_FragColor = vec4((n+1.0)*0.5,1);\
}";

Can you spot the error? Heres a clue, the spheres are rotating about their centres at different speeds.

The solution is...



n = normalize(gl_NormalMatrix*gl_Normal);\

Tiny OpenGL Windowing Code

2007-10-25T10:41:00.000+02:00

Time for another framework update. Most of the framework stuff I have posted over on in4k was developed and optimised for dropper/apack. Last year hitchhiker released the first 1k using crinkler which is now the standard for 1ks (until Mentor releases a better compressor). So its time to update the OpenGL in a window framework code. Here it is. It opens an OGL window and also handles DEVMODE. I've added the DEVMODE bytes because shader performance varies so much on cards currently that its critical to control the screen size of the PC your into runs on. Besides, at 4k who would ever not use DEVMODE?

Tested under XP...Vista I don't know yet. If you try it, let me know OK?

So, Full screen, any resolution, ultra cheap GL window:


#include < windows.h >
#include < GL/gl.h >

static PIXELFORMATDESCRIPTOR pfd={
0, // Size Of This Pixel Format Descriptor... BAD coding, nothing new, saves 6 bytes
1, PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER, 32, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 32, 0, 0, 0, 0, 0, 0, 0 
};

static DEVMODE dmScreenSettings={
"",0,0,sizeof(dmScreenSettings),0,DM_PELSWIDTH|DM_PELSHEIGHT,
0,0,0,0,0,0,0,0,0,0,0,0,0,"",0,0,1024,768,0,0,0,0,0,0,0,0,0,0
};

void WINAPI WinMainCRTStartup()
{
   ChangeDisplaySettings (&dmScreenSettings,CDS_FULLSCREEN);  
   HDC hDC = GetDC( CreateWindow("edit", 0, WS_POPUP|WS_VISIBLE|WS_MAXIMIZE, 0, 0, 0, 0, 0, 0, 0, 0) );
   SetPixelFormat ( hDC, ChoosePixelFormat ( hDC, &pfd) , &pfd );
   wglMakeCurrent ( hDC, wglCreateContext(hDC) );
   ShowCursor(FALSE); 
   do {
        // insert breakpoint winning 1k here
        // pohar insert breakpoint winning 5k :-)
         SwapBuffers(hDC);
    } while ( !GetAsyncKeyState(VK_ESCAPE) );   
}

Tiny code to Setup GLSL Shaders

2007-10-24T12:14:00.000+02:00

I posted code some time ago on in4k to load GLSL shaders. The code was small but it could get smaller. Using crinkler 1.0a, this code is about 20 bytes smaller than before after compression. Not much, but enough for one more line of shader code.
OpenGL still doesn't compete with DX at this level (1k) of shader coding but I noticed that loonies recently used the framework so I thought it was worth an update.


static void setShaders(){
GLuint p,s;
  p = ((PFNGLCREATEPROGRAMPROC)wglGetProcAddress("glCreateProgram"))();
  s = ((PFNGLCREATESHADERPROC)(wglGetProcAddress("glCreateShader")))(GL_VERTEX_SHADER);
  ((PFNGLSHADERSOURCEPROC)wglGetProcAddress("glShaderSource")) (s, 1, &vsh, NULL);
  ((PFNGLCOMPILESHADERPROC)wglGetProcAddress("glCompileShader"))(s);
  ((PFNGLATTACHSHADERPROC)wglGetProcAddress("glAttachShader")) (p,s);

  s = ((PFNGLCREATESHADERPROC)wglGetProcAddress("glCreateShader"))(GL_FRAGMENT_SHADER); 
  ((PFNGLSHADERSOURCEPROC)wglGetProcAddress("glShaderSource")) (s, 1, &fsh, NULL);
  ((PFNGLCOMPILESHADERPROC)wglGetProcAddress("glCompileShader"))(s);
  ((PFNGLATTACHSHADERPROC)wglGetProcAddress("glAttachShader")) (p,s);
   
  ((PFNGLLINKPROGRAMPROC)wglGetProcAddress("glLinkProgram"))(p);
  ((PFNGLUSEPROGRAMPROC) wglGetProcAddress("glUseProgram"))(p);
}

Real Time Ambient Occlusion of Spheres

2007-10-17T13:03:00.000+02:00

Well, with SSAO (see article below), this trick is a little redundant. However, I'll put it here for my own records as much as anything else.

I was looking for a trick to squeeze ambient occlusion in real time into 1k. It turns out that the occlusion of a sphere on another sphere can be calculated analytically. Similarly a sphere and plane can occlude each other and the result is analytic. This means it can be calculated using a simple equation for every pixel on the screen.

Fine, so a fragment shader would do?
Yes. And no. I couldnt get it to below 1k. 4k yes, but 1k no. So I started to examine the equations. To my amazement, traditional OpenGL lighting can be set up to model ambient occlusion of spheres on spheres and planes on spheres!

Inside each sphere we place a dark light, a light with negative colour! This is a point light source. Then we set the light attenuation, how the light fades with respect to distance, to exactly that required by the ambient occlusion equations. Lastly we assume all spheres have radius of 1, which simplifies the setup and equations.

Now draw all the spheres cast darkness onto each other correctly. Oh one trick to watch for is to switch off the light inside a sphere when drawing that sphere - a sphere does not occlude itself.

Here is the image:

Not bad. Notice all the shadows. We need one light per sphere and OpenGL allows us 8 lights so we can have 8 spheres. The spheres can also occlude a plane:

Lastly, the plane can also occlude the spheres. This is trickier. In essence one light source is used for the plane and as each sphere is drawn, this light source is moved onto the plane directly under the sphere. I used a point light source which is incorrect (the plane is infinite and requires a directional light but this is not then attenuated correctly). Here is the final result:

Notice the dark patches at the bottom of spheres now from the plane below them. Lastly here is an image where I've used the technique for real. The image was created for Rebels demogroup, but I dont think they will use it. M:ET gave permission to use the Rebels logo here, originally by H2O. The background image is a greeble image created by alien^pdx. I used two passes, the first to draw ambient occlusion, the second to draw the glossy surface. It could be done in one pass, but really 7 or 8 spheres are not hard for PCs now.

(Click any image to see a larger version)

Finally some code to implement the dynamic sphere occlusion...


const float white[] = { 0.75, 0.75, 0.75, 1 };
const float black[] = { 0, 0, 0, 1 }; //doubles as position of lights
const float darklight[] = { -2.0f, -2.0f, -2.0f, 2.0f };

void drawAOSpheres(){
int i;

  // we skip the first light as this has its own initial rules
  // by ignoring it, the code gets smaller...half size infact
   glDisable(GL_LIGHT0);
   // everything in the scene will receive white ambient light
   glLightModelfv(GL_LIGHT_MODEL_AMBIENT, white);
   // set the lights in position and switch them on
   for (i=1; i < 8; i++) {
        moveSphere(i);
        // lights are set with NEGATIVE colour!
        glLightfv(GL_LIGHT0+i,GL_DIFFUSE,darklight);
        // black is 0,0,0,1, which are the values we need for
        // a point light at the origin.
        glLightfv (GL_LIGHT0+i, GL_POSITION, black);
        // a quadratic falloff of light power is needed
        // attenuation is 1/(constant + linear*dist + quadratic*dist)
        // we want 1,0,1, default is 1,0,0
        glLightf(GL_LIGHT0+i, GL_QUADRATIC_ATTENUATION,  1.0f);
        glEnable (GL_LIGHT0+i);  
   }
   // draw the spheres being careful not to draw a sphere occluding itself   
   for (i=1; i < 8; i++) {
        //glColor4f (1.0f-(i/5.0f),0.7f+(i/20.0f),1.0f,1.0f);
        // a sphere should not occlude itself so switch off its own light
        glDisable (GL_LIGHT0+i);  
        moveSphere(i);
        mySphere(1,60); //gluSphere(q,1,60,60);
        glEnable (GL_LIGHT0+i);
   }
}

13 lines of code and some constants!!

Screen Space Shading

2007-10-14T22:27:00.000+02:00

One new technique in size coding is screen space shading. The idea is to avoid lots of shader code or even host code and produce shading code purely in screen space in the fragment shader.

For example, suppose we wish to do phong shading. Normally we would need to do the following:

1. Submit vertex normals
2. Write a vertex shader to output normals at vertices and the eye position
3. Write a fragment shader to normalize these
4. Calculate lighting

Instead though, steps 1,2 and 3 can be avoided and the normal recovered just from the pixels in the screen. GLSL offers a couple of functions dFdx and dFdy. These tend to work on cards supporting PS3.0 and later. In essence they give us the rate of change of a value across pixels. So recovering a normal in screen space can be written in GLSL as:


vec3 n=normalize(vec3(dFdx(gl_FragCoord.z),dFdy(gl_FragCoord.z),1));

If you are familiar with height maps and deriving normals, thats exactly this equation. There are issues with borders of objects which can result in a black border round the object, but this can also be exploited as a special effect.

Another effect that can be done in screen space is Ambient Occlusion. Iq of rgba has published a few articles on this and the technique seems to have been first used by Crytek. Essentially, in the fragment shader, a number of points are generated around the surface normal in world space. These are samples for the AO. These are then projected into screen space again and their depths tested against the pixels they project to. If the point is further away in z, that sample is occluded. The results are summed as you might expect.

Here is an image from Kindernoiser by iq of rgba using this technique. It is amazing just how well it works! Its fast, dynamic and less code than traditional AO techniques.

There are drawbacks of screen space shading. For example, take a sphere subdivided into a number of flat polygons. With standard normal interpolation the sphere will look smooth as the normal is interpolated across the pixels as if the surface is curved. In screen space, we have only local information so the flat surfaces still look flat. Nontheless advantages in size can be worth it.

Slight update:
Here are some more images of screen space (or image space) illumination. Quite extraordinary. I must get an image space renderer written.

http://www.gamedev.net/community/forums/topic.asp?topic_id=465715

Organic Art

2007-10-11T12:31:00.000+02:00

Back at college I had a few heroes of computer graphics. One of them, Professor William Latham was creating fascinating organic art. The three images above are his work and are reproduced with permission. I strongly encourage you to see these images in higher resolution at Williams web site: www.williamlatham1.com

It recently occurred to me that such organic art may be possible in real time and in very few bytes using OpenGL. Whilst I can't hope to match the beauty of the images in very few bytes, I can get close in form.

Here are some images I'm working on. Each image is taken from a real-time program which animates the structure in a more or less organic way.

The structures above are mine. Aside fom the colours and lighting which needs work, I think the code is beginning to show promise. The "latham" routine to generate the shapes is less than 300 bytes after compression.

The code is a recursive, iterative and randomised. I think there is loads of potential here.


void latham (uint32 depth, uint32 n, uint32 seed) {
uint32 i;
float s;

#define OPENNESS 40.0f  // lower is more open
#define SPACING  2.0f   // distance between generated points...higher, more
#define TWISTINESS 10.0f // how weird the structure gets...lower, less
   
  if (depth==0) return;
    for (i=0; i < n; i++) {
        mirand = seed;
        s= my_sin(sfrand()*(seed+i)*0.04f);
         glRotatef ( s*OPENNESS, s*sfrand(),s*sfrand(),s*sfrand() );
        s= my_sin(s*TWISTINESS)*SPACING;
        glTranslatef ( s*sfrand(), s*sfrand(), s*sfrand() );
        if (i%(n/4)==0) {
            glPushMatrix();
            glScalef(0.5f,0.5f,0.5f);
            latham (depth-1, n/2, seed+1);
            glPopMatrix();
        }
        drawSphere(SPACING); // SPACING=radius of sphere
    }
}

sfrand() is a function that returns a psuedo-random number between -1 and 1. Mirand is used to set the seed for random number generation. Dirty: but this is size coding. The code iterates applying a random (but repeatable by seed) rotation and translation and drawing a sphere. At a certain iteration, a new random seed is passed recursively into the function in order to draw "branches" off the main creature.

I have removed the animation code here (which is tiny) but you can figure that out yourself.

Overall, through fortuitous randomness we can come close to resembling Lathams structures and animate them in real time. Now if only I had some artistic ability I could light them and colour them better!

Tiny Distortion Shader

2007-10-10T15:56:00.000+02:00

Whilst working on Spheres Dream, Pasy of Rebels gave me some code for a distortion shader. I used it to quite good effect but completely size reduced and rewritten. I'll present my distortion shader here but first what is a distortion shader? Well, imagine a lens floating infront of your graphics, it would distort the image behind. To do this in OpenGL we would:

Draw the image to be distorted to an offscreen buffer
Capture this to texture (see NPOT article)
Clear the screen
Enable a lens distortion shader
Draw a textured quad

The shader would distort the texture co-ordinates as if looking through a lens. Easy. However the lens can be highly complex, have a bumpy surface or even be a second texture.

The first image is a very flat image before distortion. The second image is applying a distortion shader and adds complexity and interest to the image.

I did not want to use a second texture to distort the image. Instead I used a simple trick. The image is drawn and the distort is calculated from the orginal image alone. Infact the distortion is a function of colour in the original image.

Here is the vertex shader:

const char *vsh="varying vec4 p;\
void main(){\
gl_Position=ftransform();\
p=ftransform();\
}";

So p is set to the co-ordinate of the transformed vertex. Which ranges between -1 and 1 in my screen space.

Here is the fragment shader:

const char *distortScreenfsh="\
uniform sampler2D s;\
varying vec4 p;\
void main(){\
vec4 t=p/2.0+0.5;\
float d=length(texture2D(s,t.xy).xyz);\
gl_FragColor=texture2D(s,t.xy+d*p.xy*0.3);\
}";

So t maps to between 0..1 and corresponds exactly to (0,0) in one corner of the screen and (1,1) in the opposite corner. This avoids having to define texture co-ordinates in the main OpenGL code and also, infact means one big trick. In the main code now we can use a gluDisk rather than define a real quad! This is far fewer bytes. If I had tried to use real texture co-ordinates in the shader I couldn't use a Disk as the texture co-ordinates would be wrong.

The real magic then is here:

float d=length(texture2D(s,t.xy).rgb);\
gl_FragColor=texture2D(s,t.xy+d*p.xy*0.3);\

We do a texture lookup in the original image using t as the texture co-ordinates. We read the rgb values and then take the length of this as a vector. So somehow d is a measure of the intensity of colour in the original image.

Then we finally do a texture lookup in the original image, adjusted by d and p. This is the distort right here (+d*p.xy*0.3).

The shader is tiny and produces a much richer feel to the image.

Quick NPOTs

2007-10-09T07:01:00.000+02:00

Most cards today support Non Power of Two Textures (NPOTS). In the old days textures had to be 64x32 or 256x512 or some such but screen resolutions are typically 800x600 or 1024x768 - non power of two. I know my card (x600) supports NPOTs but I had trouble getting them to work fast so I guess others may too. I wanted to

render the scene to the back buffer (800x600)
copy into a texture (also 800x600)
Use the texture in a distortion shader

The third step could be anything of course. The key is I needed this in real time. The problem is although NPOTs are supported on cards, they can be incredibly slow. The trick is setting them up correctly. First here is the code to read the screen and copy it into a texture:


void grabScreen(unsigned int tnum, GLubyte *p){
  createTexture(tnum,p);
  glCopyTexImage2D (GL_TEXTURE_2D, 0, GL_RGB, 0,0,800,600,0);
}

So I call a function to create a texture and then copy the whole back buffer into it. Nothing surprising here, its here for completeness. The real trick comes in the createTexture() routine. Here is where you can foul up pretty easily.


void createTexture (unsigned int tnum, GLubyte *p) {
   glBindTexture (GL_TEXTURE_2D, tnum);
   //commenting out any of these means it runs slow as hell
   glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR);
   glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR);
   glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
   glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
   glTexImage2D(GL_TEXTURE_2D,0,GL_RGB,800,600,0,GL_RGB,GL_UNSIGNED_BYTE,p);
}

You can see the whole trick is explicitly telling OpenGL that it never needs to worry about wrapping of texels across the border. Instead, explicitly clamp the edge of the texture. Its obvious why if you think about it. If the texture wrapped, a modulo maths step is required to find the right texel. For powers of two this is a mask and a shift but is far more complex for non-power of two.

So now its possible to capture the whole screen at real-time rates and use that for...next article.

The Beginning

2007-10-08T17:37:00.001+02:00

A quick note to say this Blog is open for business. Over the coming months I'll be posting bizarre and obscure ideas for intro coding: super small graphics programs. The example image is from "Spheres Dream" which is just 4k ..4096 bytes. 4 scenes, music and synthesiser in 4k. It requires pixel shaders 2.0 and a fast graphics card (series 6 Nvidia or x600 onwards from ATi). The graphics are mine and the synth is by Pohar of the demogroup Rebels.