Jump to content
  • Advertisement
Sign in to follow this  
vinnyvicious

OpenGL Rendering MD3 in Modern OpenGL

This topic is 1091 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement

An interesting idea could be to store your all the vertex positions for your key frames in a texture, with a single row storing all your positions, and each subsequent row is a single key frame. When you come to draw your animated frame, you can set a single float uniform for which frame to use, and then sample all your vertex data from the texture using this float as the y coordinate, and then use gl_VertexID as the x coordinate. That way you get your frame interpolation for free through the bilinear texture filtering.

Edited by Xycaleth

Share this post


Link to post
Share on other sites

An interesting idea could be to store your all the vertex positions for your key frames in a texture, with a single row storing all your positions, and each subsequent row is a single key frame. When you come to draw your animated frame, you can set a single float uniform for which frame to use, and then sample all your vertex data from the texture using this float as the y coordinate, and then use gl_VertexID as the x coordinate. That way you get your frame interpolation for free through the bilinear texture filtering.

 

I'm not sure if i follow... you mean, storing all the vertex positions for keyframes in glTexImage2D?

Share this post


Link to post
Share on other sites

Xycaleth means to use the texture as a LUT/lookup table, where each "pixel" contains the vertex position, i.e. R,G,B correlate to X,Y,Z
mrwonko pointed out the MD3 format has 16-bit integer coordinate, so the texture format should be GL_RGB / GL_SHORT. The maximum number of vertices per surface is 4096 (typically < 1k verts) which is scraping as large as you'd want to go, at one texture per surface (maximum of 32 surfaces, typically 1 or 2 surfaces)

If you required any other information, it wouldn't be difficult to pack that further down in the texture and give/calculate the offset.
You can exploit bilinear filtering by sampling between texels in the vertex shader. Texture filtering will interpolate the values, hence smoothed animations.

Edited by KMcDevitt

Share this post


Link to post
Share on other sites

True, it won't actually be blending animations. You could probably get fancy and construct a histogram for blending between sequences.

This is the point where you'd reconsider your decision to render MD3s in modern OpenGL, and write a tool to convert the format offline to something that complements modern OpenGL.

Edited by KMcDevitt

Share this post


Link to post
Share on other sites

True, it won't actually be blending animations. You could probably get fancy and construct a histogram for blending between sequences.

This is the point where you'd reconsider your decision to render MD3s in modern OpenGL, and write a tool to convert the format offline to something that complements modern OpenGL.

 

MD3 (and keyframe animation in general) is so easy in modern OpenGL that there's no need to even think about doing anything fancy.  It's just one VBO, two glVertexAttribPointer calls - one for previous frame, one for current frame - then send the interpolation factor as a uniform and blend the frames in a single line of shader code.  Do the same for normals, boom, done, next.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!