OpenGL smooth camera movement with computations slower than rendering
I'm very confused with camera movements in OpenGL. As an example I've read [0], but I'm not sure about which solution is the best fitted for me. Here is what I want to achieve :
The last point require heavy computations (around 20 seconds for the moment ! hopefully this will decrease with further optimizations) but most of the tutorials about movements I read are usually based on the assumption that the rendering is the most time consuming step.
Now (at least as first) I want to move the camera from one position to another such that it seems to be a linear movement. I can decompose the deplacement (rotation/translation) of the camera in any number of steps I want, but I don't see how to arrange this in a main loop so that I don't have any pause in the rendering. Do I need to parallelize the computing and the rendering ?
Also a lot of camera movement examples I saw use the gluLookAt function, but changing the modelview matrix seems enough for me, is there any limitations to this ?
[0] http://dewitters.koonsolo.com/gameloop.html
It sounds like your computation will always be slower than real-time rendering, so the design that most makes sense to me is a separation of a "real-time" working rendering and a "production" rendering. For example, you can have a thread that does the heavy calculations and stores the result in memory or in a file for quick lookup. You can have this thread replacing less accurate models while you're rendering them in a separate thread.
The name of the game with any sort of real-time interaction - that is, any interactive moving through your model - is to move as much computation out of the rendering thread as possible. You want your rendering to be only looking up data from a model and have that model updated in parallel.
The reason that all the tutorials focus on the rendering speed is that they're ignoring (for the sake of scope) how the model is generated - they just use the teapot or a model from a file for brevity's sake, and focus on rendering performance only. For any task that requires computation or a changing model - a 3D game where objects are moving and have physics, for example - it's standard to compute everything out of the rendering loop so that the rendering can be as smooth as possible, even if you're rendering a stale model.
If you don't want to mess with threading, you can do a poor-man's version by including a "loading" or "compiling" step where you usually skip rebuilding your model, but on a keypress or menu action, you rebuild the entire model while making the user wait. After the model is built, they are free to navigate around, skipping the computation until another gesture re-loads or re-compiles the model. This is a good intermediate step, because it can lead incrementally to dealing with threads later if you decide the long pause is not acceptable by your requirements.
FYI, gluLookAt() operates on the modelview matrix.
If you have a function that is freezing the rendering procedure, you might want to consider moving that function to a 2nd thread, so the rendering is not affected while your custom function is processing.
链接地址: http://www.djcxy.com/p/60418.html