Jump to content
  • Advertisement
Sign in to follow this  
rileyriley

design dilemma: physics/graphics decoupling, and scripted cameras

This topic is 4517 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

I am writing a game that relies heavily on Lua scripts for its behavior. Up until now, I've been prototyping it with variable-length physics frames (e.g. one physics pass per graphics rendering pass), and that's been working great. Now I've decoupled the physics and graphics. The physics run at 30 Hz and the graphics run as fast as they can. To avoid jerking, the graphics engine renders a simple extrapolation every frame, just rendering objects at object.position + object.velocity * extrapolationTime. That works great as well; the physics runs at 30 Hz, but everything moves smoothly much faster than that. In my current design, the physics and scripts are run concurrently still - one frame of physics per one frame of scripts. I kept it this way so that if the script calls AddImpulse(obj, 10) every frame, obj doesn't get more impulse than it deserves. That is, if the script ran 4 times between physics passes, AddImpulse(obj, 10) would be called 4 times too many and the object would accelerate improperly. The problem comes in when I try to control the camera from my script. Up until now, I've basically just been calling gluLookAt with updated positions from the scripts every frame, which worked fine, and gave me a smoothly scrolling camera. Now, however, since the scripts are only running at 30 Hz, the camera jerks around, even though the objects in the scene are being rendered smoothly. This totally voids the whole "smooth" effect and actually makes me nauseas astonishingly quickly. I have alleviated the problem somewhat by allowing the user to attach the camera to objects, and then I can extrapolate camera position and lookAt as well as object positions. That works very well, for simple cases, but it won't solve the problem if the scripter wants the camera to move in a sin wave or some other pattern that's not easy to make an object follow. I write this intending it to be a general discussion of this sort of problem. What would you do?

Share this post


Link to post
Share on other sites
Advertisement
Hi rileyriley,

I think the problems begins from the fact that you don't handle your camera as another type of object.

As you said, when you want to move an object around you add an impulse to it, implicitly changing its velocity. I think you should do the same thing for the camera. Instead of setting the position directly, you should apply an impulse to the camera, or change it's velocity directly. Of course sin waves will be approximated with oscillating lines (is this correct?) (because of the large delta time between keyframes), but this way you can move your camera around without the need to attach it to an object.

I had a similar problem when handling camera position through input. Because input messages from windows aren't sent every frame, i have to keep a camera velocity (which change based on input) and update camera position every frame with it. When a key is released i remove the corresponding direction from the camera velocity and the camera stop moving at that direction.

Hope that helps. I'm interested what others have to say on the subject too. :)

HellRaiZer

EDIT: Now that i thought of it again, isn't camera another physics object? Don't you have somekind of collision shape attached to it, in case to collide with the rest of the scene? If you do, i think it's natural to move it around using impulses instead of changing its position.

Share this post


Link to post
Share on other sites
I've been thinking about REQUIRING the camera to be attached to an object, as you're suggesting. That does solve some problems, but it still doesn't address the case in which the user wants to move along some arbitrary parametric path (which, before now, was very easy to do).

I suppose I could just differentiate the last several positions to guess at a velocity. I'll try that and see how low I can get the error.

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!