Andrew Mihal schrieb: > I expect that nona-gpu will not be efficient for rendering the > previews, due to the overhead of compiling GLSL code for each input > image and transferring the data back from the GPU to the CPU before > drawing it in the preview window. The approach used by the GL preview > is superior in this situation.
I haven't looked into your GLSL code generation yet, but are the parameters (hfov, r,p,y etc.) also compiled into the GLSL code for each image? > This is related to the bug Yuval put in the tracker, which I attached > a comment to. > > If the frame rate and quality of the GL preview are determined to be > insufficient, it should be possible to adapt the nona-gpu approach to > produce vertex shader programs that would offload the mesh > transformation from the CPU onto the GPU. I apologize for not looking > at the actual implementation of the GL preview before making this > suggestion. This might be nonsense. The OpenGL preview is quite fast, even on systems without hardware acceleration, as the software texture mapping routines seem to be reasonably optimized. The main problem is that the GL preview uses a forward mapping to generate the mesh, and this complicates matters at zenith, nadir and the 360 deg seam. ciao Pablo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
