Hello,
I have written an MD2 3d mesh loader, everything works fine except for the animations.
Because the model save only the key frame for each animation the loader must interpolate the vertex position of the mesh to get a smooth animation.
My solution was to save the triangles vertices in a gl-array for each frame an then doing linear interpolation, something like that:
(defun lerp-gl-array (a b c count interpolation-factor) (dotimes (i count) (setf (gl:glaref c i) (alexandria:lerp interpolation-factor (gl:glaref a i) (gl:glaref b i)))))
but it seem to be too slow as shown by the SBCL profiler
seconds | gc | consed | calls | sec/call | name ----------------------------------------------------------- 264.554 | 8.189 | 8,307,049,792 | 2,870 | 0.092179 | CL-GL-UTILS:LERP-GL-ARRAY ----------------------------------------------------------- 264.554 | 8.189 | 8,307,049,792 | 2,870 | | Total
is this my fault? Any idea how can I improve performance?
Thank you. C.
On Sun, Mar 10, 2013 at 8:35 AM, cage cage@katamail.com wrote:
(defun lerp-gl-array (a b c count interpolation-factor) (dotimes (i count) (setf (gl:glaref c i) (alexandria:lerp interpolation-factor (gl:glaref a i) (gl:glaref b i)))))
is this my fault? Any idea how can I improve performance?
Most of the problem is https://github.com/3b/cl-opengl/issues/27 (glaref and (setf glaref) are slow).
Another problem is that the compiler doesn't know what types the values are, so has to call generic math routines instead of using CPU ops directly.
Storing the source arrays as specialized lisp arrays, and declaring types (and/or check-type) would help with both problems, though writing to the gl-array would still be slow until that bug is fixed. You could work around the bug by using cffi:mem-aref directly instead of glaref, or if you are using shaders, you could just do the interpolation on the GPU.
-b-
On Sun, Mar 10, 2013 at 06:24:34PM -0500, Bart Botta wrote:
Hi,
thank you for your reply!
[...]
Most of the problem is https://github.com/3b/cl-opengl/issues/27 (glaref and (setf glaref) are slow).
Another problem is that the compiler doesn't know what types the values are, so has to call generic math routines instead of using CPU ops directly.
Storing the source arrays as specialized lisp arrays, and declaring types (and/or check-type) would help with both problems, though writing to the gl-array would still be slow until that bug is fixed. You could work around the bug by using cffi:mem-aref directly instead of glaref,
I have just replaced all glaref calls with:
(cffi:mem-aref (gl::gl-array-pointer array) :float offset)
and the results are surprisingly good!
seconds | gc | consed | calls | sec/call | name ---------------------------------------------------- 3.924 | 0.000 | 0 | 2,500 | 0.001569 | CL-GL-UTILS:LERP-GL-ARRAY ---------------------------------------------------- 3.924 | 0.000 | 0 | 2,500 | | Total
or if you are using shaders, you could just do the interpolation on the GPU.
That's a good idea indeed! My fault is that i still stick with the old fixed pipeline opengl paradigm.
Thank you for your help! C.
cl-opengl-devel@common-lisp.net
-
Bart Botta -
cage