I've never done any sort of vertex skinning before, but I'm in a situation where I think it's the best solution to my problem.

I'm going to be rendering moving tentacles (in 2D), and the only approaches I can think of are to render N lozenge shapes, one per tentacle segment, or to have a single VBO representing the tentacle and to use vertex attributes and a shader to skin it.

Does anybody have any resources I can read to get an idea of how to approach this?

My guess is that I'll have a single static vbo representing the tentacle, and a set of dynamic vertex attributes computed on CPU and updated per-frame which represent deltas from the computed position to the desired position for rendering.

Is that right? Like I said, I've never skinned so I don't know which direction to look quite yet.

P.S. I know "google is my friend", and I'll be googling. I just figure some people here will have done this already and can give me some pointers.

Thanks,

For the snake at the end of Outnumbered, and at least one other tentacle-y problem before, I've used bezier curves. They're easy to animate (just a few control points to move), easy to tessellate and render. You extrude them into 2 or 3D by differentiating the explicit evaluation formula to get a tangent formula, and using a cross product (or the 2D equivalent) to get a normal.

Oh I guess I should have been more clear. I'm less concerned about the maths, more concerned about how to optimally get/update vertices to the GPU. Most of the rendering I do (and have done in the past) involves static geometry, and I just update matrices to position and rotate it.

In this case, I've got a constantly deforming shape, and I want to render it efficiently.

I think I'm just going to compute it cpu-side and stream vertices unless there's some really efficient way to handle this.

note: while I'm developing this first and foremost as a mac game, I intend to port it to iOS. I've been keeping everything tight and light since the beginning with this in mind.

there's not much better you can do than ping-ponging a pair of DYNAMIC_DRAW VBOs. Using MapBuffer to update them should be more efficient than using BufferSubData.

I've never ping-ponged. Here's what I interpret you as describing:

Maintain two VBOs, call then A & B, having them mapped to CPU memory.

First, write current geometry into VBO A.

Loop
- Drawing frame N, render VBO A.
- Write new current geometry into VBO B.
- Drawing frame N+1 render VBO B
- Write new current geometry to VBO A.
end loop

I assume that since we're pushing geometry into the VBO that's not being rendered, this prevents a stall? Is there some way to notify GL that I'm not rendering a particular VBO at the moment so it doesn't stall?

BufferData(........., NULL) should orphan the current contents of the VBO, allowing you to get away with only one. It scares me a little though

Why is it that it scares you?

Trusting a bevy of OpenGL implementations to do the right thing on a call which doesn't intuitively mean what it says?