Reproducing Blender animations in Codea (Now with code link, new video)

B-)

OK, the second post is up with a link to the code:

https://puffinturtle.wordpress.com/2015/05/16/animating-a-3d-blender-model-in-codea-part-2/

Part 3 is up, with discussion of how spline interpolation methods can be used on the vertex shader:

https://puffinturtle.wordpress.com/2015/05/16/animating-a-3d-blender-model-in-codea-part-3/

comments, criticism, questions welcome.

wonderfull, awesome :)>-
it makes me think the marches Cannes
it’s very very fast
60 FPS with 1 character
18 FPS with 60 characters, we are in the matrix
^:)^
i like panz but why there is no pany ?
i find hands are little big and i don’t see eyes
i imagine climbing stairs
very very good work for FPS Games
Thanks for sharing

especially fighting games

with ipad air and ios 8.1 last codea
limit 16 characters with 60 FPS ( wich is more than enough )
limit 30 characters with 30 FPS
and 44 characters with 24 FPS

@yojimbo2000 - I thought you might be able to do something like this in the vertex shader

//all the uniform, varying declarations as before

//before main, do this
//it will be executed before OpenGL loops through the vertices, ie just once
//create a function for each position buffer
vec4 P1() {return position;}
vec4 P2() {return position2;}
//etc

//assign the function to a pointer
vec4 Point;
if (no==1) Point = P1;
else if (no==2) Point = P2;
//etc

//then in the main function, for each vertex
//just use Point() to get the position value

The idea is that if you can set a pointer to one of the 4 position uniforms, on entering the vertex shader and before looping though the vertices, you only do the if tests once.

The problem is that it doesn’t work (NB not just because my example above may have typos). It doesn’t seem possible to assign a function pointer inside a shader.

EDIT - pointers don’t work in OpenGL ES, unfortunately.

I got excited when I read about OpenGL “subroutine” functions that specifically do the above, but they are for OpenGL 4.0+.

@yojimbo2000 - there’s another kludge you can try, which will work, which is to have a different version of your vertex shader for each animation position, and assign the correct one at each frame. That should be very fast.

With respect to multiple textures, the problem with having to combine them into a single spritesheet is, of course, that all the texture coordinates are messed up.

There is a way round this, which I wrote about here. It allows you to define your texture coordinates as though they were separate images, and all you need to do is pass through a vec4 to the shader to give it the offsets on the spritesheet.

@Ignatz thanks for those suggestions. Yeah it’s a shame about pointers not being possible in SL1.0.

I don’t think the shader switching suggestion would work though, because the data that is in the custom attribute buffers for the extra frames seems to get erased when you switch shader (even if the shader you’re switching to has the same custom buffers defined). I tried switching between the linear and spline shader on the fly, and it produced very strange results.

Also, I think it would be useful being able to interpolate between two arbitrary frames. ie, say if the player presses the kick button mid-way through the walk-cycle, and in the interest of quick response, you don’t want to wait until the end of the walk cycle but launch the kick straightaway: so you blend straight from walk-frame 2 into kick-frame 1 or whatever. So I think it’s good not to have the actual transitions hard-coded into the shaders, because you would end up with too many permutations.

btw, is there any point using elif if you have a series of if (x==1) return x1;? My guess is no, because if the condition is true, you return without executing the rest of the conditions, right?

@hpsoft thanks, I’ll share the blender model soon. It’s not mine, but it’s public domain so should be OK. If I were modelling it myself, for most games I wouldn’t bother with individual fingers on the hand (just go with “mittens”), and would put more vertices on the head. It’s still 5904 verts (mid-poly?) but the head looks quite lo-poly. I don’t think it distributes the verts very well.

@yojimbo2000 - I think the way you’ve done it is fine. However, if you’re going to include multiple animations in there, not only will you have bucket loads of vertex positions, but more if statements to decide which animation to use. I don’t think it’s going to scale well.

@Ignatz yes the lookup functions are going to get long. And I need to check if there’s a limit on the number of attribute buffers you’re allowed. I was thinking about writing a kind of shader printer, similar to the one you made for different types of lighting. It would create shader strings with enough attribute variables for the number of key frames that the model requires.

Ok, regarding scaling this technique: apparently GLES 2.0 on iOS only allows 16 vertex attributes. I’ve tested this, and as soon as you declare more than 16 there’s no shader compile error, but setting the attribute stops working. I tried setting gl_MaxVertexAttribs to a higher number, but you get his error: ERROR: 0:2: Regular non-array variable 'gl_MaxVertexAttribs' may not be redeclared

So, that means a maximum of 7 key frames with this method (7 positions + 7 normals + 1 colour + 1 texCoord = 16 attributes).

You could try packing two vectors into one variable (placing them either side of the decimal point, unpacking them with modf). First I’m going to experiment with setting the entire vertex table every few frames

It’s one more factor in favour of GLES 3.0 as a Codea feature request.

@yojimbo2000 - or you could try the superior (#ahem#) method of using bones 8-X :))

I don’t fancy trying to write an importer for one of the formats that export the bone data and animation though. I did find an importer for the .fbx ascii format written for LÖVE, so that could be a candidate. By the way, now that we have UTF-8 support in Lua 5.3, does that mean that we could write parsers for files in xml format?

you could parse xml before

It turns out that uploading new frames to the mesh buffers isn’t as expensive as I thought it would be, and can be done on the fly. I reckon the spline interpolation is still best done in the shader, on the gpu. Here’s a rig with a couple of different actions, the walk cycle, and a high kick. The action’s frames are loaded into the shader when the action starts.

I’m still cutting my teeth when it comes to animation, and my research into martial arts didn’t stretch beyond googling an image of a karate kick.

I’ll blog this at some point.

Captain Codea discovers his violent side:

http://youtu.be/l61bd68olLo

OK, the code for the above video is now up, along with an explanation in the blog:

https://puffinturtle.wordpress.com/2015/05/26/animating-a-3d-blender-model-in-codea-part-4/

Up next: a toon shader!

toon

It’s hard work, isn’t it? I can’t imagine creating a full sequence of actions.

And that is just one character!

It struck me that when creating enemy characters, most of the time they are running straight at you, so you don’t really need 3D for that. A spritesheet would do.