## Bones, vertex skinning

Sage
Posts: 1,199
Joined: 2004.10
Post: #1
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,
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
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.
Sage
Posts: 1,199
Joined: 2004.10
Post: #3
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.
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
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.
Sage
Posts: 1,199
Joined: 2004.10
Post: #5
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?
Luminary
Posts: 5,143
Joined: 2002.04
Post: #6
BufferData(........., NULL) should orphan the current contents of the VBO, allowing you to get away with only one. It scares me a little though
Member
Posts: 227
Joined: 2008.08
Post: #7
Why is it that it scares you?
Luminary
Posts: 5,143
Joined: 2002.04
Post: #8
Trusting a bevy of OpenGL implementations to do the right thing on a call which doesn't intuitively mean what it says?