Archived

This topic is now archived and is closed to further replies.

glest

md3 normal interpolatio

Recommended Posts

Hi, how does quake 3 interpolate normals betwen keyframes, if linear interpolation is used modulus will result other than 1, and normalization is to slow I think. Thanks.

Share this post


Link to post
Share on other sites
i never delt iwth md3 before (ie code wise) but they are just newer version of md2, and in reality once in memory most file formats are the same when dealing with the normals.

if you do linear interpolation with your vertices and normals. everything works out fine (well noticably, its pobably not perfect but close enough). i know because i have done it and it works well enough. you just need to make sure that you interpolate from the last frame and current frame. thus a 5 frame animation would have pairings like:

0-1
1-2
2-3
3-4
5-0
0-1 etc.

the normals should stay close enough to 1.0 in magnitude since you cant help floating point round errors. the EXACT same method used for interpolating the vertices can be used on the normals. no scaling of the normals takes place things should work out great.

also you NEVER use values from previous interpolations and always caluclate the position based on the previous and current frame (or current and next depending on how you want to call it)with a weight.

ie

normal.x = currentNormal.x*(1.0-percentBetween) + nextNormal.x*percentBetween
normal.y = currentNormal.y*(1.0-percentBetween) + nextNormal.y*percentBetween
normal.z = currentNormal.z*(1.0-percentBetween) + nextNormal.z*percentBetween

ever frame, where currentNormal is the normal for the current frame and nextNormal is the normal for the next frame. normal in this case is the interpolated normal value you will use for the rendering.

there are better methods then linear inerpolation, but its the best one to start with since the results are ussually passable for concurrent frames that are similar.

[edited by - a person on July 16, 2002 2:46:10 AM]

Share this post


Link to post
Share on other sites
I don''t think your method is good enough, an example:

t= 0.5
n1= (1, 0, 0)
n2= (0, 1, 0)

ninterp= n1*(1-0.5)+n2*0.5= (0.5, 0.5, 0)
mod(ninterp)= 0.5 <--- this is far from 1


Share this post


Link to post
Share on other sites
it works fine for most of my lighting, i never said it was perfect. though

sqrt(0.5*0.5 + 0.5*0.5 + 0.0*0.0);
sqrt(2)
which is approx 1.4142135623730950488016887242097;
a bit off, but somwhat usable.

any linear interpolation scheme has this problem. even linear interpolation on vertices would appear funky. this is why is said the frames need to be similar. you will notice if you use more frames in your animation (which is required for linear interpolation artifacts to be less obvious). you would see its good enough.

you would never have such an extreme in frames. if you do, your vertices will move funky as well. again, you want better interpolation use a spline based interpolation.

a more correct example that appears (notice due to rounding errors its not perfectly 1.0 in magnitude to begin with).

1.00, 0.000, 0.0
1.06, 0.707, 0.0
1.03, 0.3535, 0.0 = 1.089 magnitude.

pretty close to one 1.0 say. this is using 0.5 as the weight.

if you use a spline the values will be closer to one but more cpu intensive as well as use 3 or more frames as input instead of 2.

remeber, linear inerpolation is only good if the frames are similar enough so you wont notice the linear movement. if things are too far apart you will notice that motions that should be curved are shown as line segments between the key frames. you will notice that you cant go from one frame to a completly different key frame. splined interpolation is better (EXACT same concpet but more accurate interpolation algorithm). the best is a boned animation system since you actually perform the rotation trasnformations directly to the normals and vertices, thus can EASILY interpolat correctly between all the frames. however it comes at a cpu cost and complexity in implementation. as well as requiring your models to be boned.

quake2 used linear inerpolation and it works fine and looks ok. i use it and it looks fine. remeber interpolation is not meant to fix animations that are missing required key frames. its meant to enhance an animation that looks fine but slightly choppy without interpolation.

if you go ahead and use bone animation, then interpolation is as simple as applying the matrices that you get from the interpolations of the rotations. you would use quarternions for interpolation the rotations in spherical space, thus little if any damage to the length of the normals will occer beyond rounding errors.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You could also try to not interpolate the normals in their vector form. MD3 delivers normals as polar coordinates (two angles). If you interpolate those angles instead of the vectors, you have no problems with shortened vectors.
Just do your interpolation in fixpoint-arithmetic and use the final result as lookup address in a precalculated polar-to-vector table.

skynet

Share this post


Link to post
Share on other sites
yes, linear interpolation is not a good idea for normals, spherical interpolation would be fine, but this can''t be done o realtime, so i''ll think i''ll just dont interpolate normals, if keyframes are enough this sould look well enough

thanks for you help.

Share this post


Link to post
Share on other sites