the normal is the cross product of the vectors from the adjacent horizontal and vertical points.

The hight of the point in question is mostly irelevant, since I'm trying to fit a curve over a set of points to find out what the normal should be, and it turns out that it only really matters where the adjacent points are. This method isn't perfect, since the normal of the fitted curve would change slightly if suther away points were included, but it's a fairly good first-order match.

Here's a doodle to show what I mean:

(The normal is slightly out, I think it should be slightly more vertical, but it shows the principle)

In all 3 examples the adjacent points are in the same place, it's just the middle point that changes, but as you can see the curve fitted through all 3 points has the same normal, which is at 90' to the vector between the two adjacent points.

If the point we're calculating wasn't equi-distant between the two points, then it'd be more complex, but since it is in my code, it seems sensible to make use of it.

Now this isn't perfect, since you could argue that the curve that's been drawn isn't quite right, but it's fairly good, cheap to calculate, and gives consistent results.

Shiny!

After a bit too much work, and lots of headaches, I've maanged to sort of get multitexturing to work, and implemented a cool shader I found to give really shiny boxes..

http://www.hardcorepawn.com/Shiny/

However, I've pretty much exhausted my GL knowledge, and found that I was guessing at far too many things to try to get things to work, so I'm going ot have to wait till I get my hands on a huge OpenGL boox before I can work out how stuff works.

In case fry knows: does PGraphicsGL sit glMatrixMode in GL.GL_MODELVIEW mode on purpose, or is it just left at that after setting it to the identity, and I should be going back to GL.GL_PROJECTION before doing glRotatef(...) stuff?

Mu-ahahahaha.

13. Point 7. Million. Triangles per second.

(n.b. single light, vertex lighting, multiple copies of a single object)

I think I've got as far as I'm going to with mine. It's kind of a hybrid in that I've not changed all that much, it just means I can use processing to write pure OpenGL stuff, without it intefereing with the view matrixes etc.

And to show it off:
http://www.hardcorepawn.com/Speedy/

*Note* I had to update the drivers for my video card to get this to work, the ones my computer came with had a bug and would crash when doing some OpenGL operations, so if it breaks things, I'm sorry, but it's probably down to your drivers.

Texturing is sort fo already there.. the library needs no changes, it can all be done in the sketch, I've just not got any nice simple .obj format models with textures to test it out with.

Well, as far as I can tell, there's nothing in OpenGL to do that sort of thing, so there's nothing to be added to my library to support it.

My library should let you throw whatever OpenGL commands you want into a sketch, but that's about it, I'm trying to keep it fairly straightforwards.

Since you can do any GL calls, yes you can use vertex shaders.

In fact, I've already used them: http://www.hardcorepawn.com/Shiny/

And I've written a bit of a library to make loading them easier. I could probably just dump that into my GL library, and it should work fine.

Unfortunately I've had no time recently to do any more work on it, and kept hitting an odd issue with normals and pixel shaders that seemed to point to an underlying issue which I couldn't find.

I'm hoping to have some time this weekend, and I should be able to at the very least release a definately alpha, but at least clean-ish version, which is usable with certain caveats.

(e..g having to call perspecitve and camera at least once because the default processing settings don't happen automaticly, and I'm having issues trying to make them happen in the library)