Flipper question (not the dolphin)
by David Smart · in Torque Game Builder · 03/07/2005 (2:39 pm) · 13 replies
I am trying to make a pinball flipper and it's not clear how to implement the rotation of the flipper to interact correctly with the pinball. I have an image of a pinball flipper that has the actual flipper centered on the correct pivot point and I have defined a custom collision poly for the flipper. I can simply rotate the flipper but this doesn't work with the physics since it is just instantly changing it. I am trying a scheduled method to rotate the flipper over time but I get really weird physical reactions with the ball when I do this. Maybe applying some angular velocity would be better? Are the physical complexities of a pinball machine outside the standard capabilities of the physics engine? (I.e. should I start pouring over the source code?) On the other hand, there is SO MUCH stuff to play with in T2D that I should probably just keep tinkering, it's incredible really.
#2
03/07/2005 (6:22 pm)
Yeah, would be more like a pinball level editor lol :)
#3
03/07/2005 (8:32 pm)
The angular velocity works great for the physics (perfect actually) but my big issue now is how to make it stop at a certain rotation. Also, since I have gravity on (a constant force applied at the scenegraph) my flipper falls off the screen. I'm playing around with the world limits to get the flipper to stay in one spot but this messes up. I need to be able to "lock" the X, Y position but still allow rotation but I'm not finding a way...
#4
03/07/2005 (8:35 pm)
Hmm, could you mount it to a static tile ? or a static sprite not using physics, then apply the rotation... 
#5
First up is that applying a constant force to the scene is quite severe. It's actually much more efficient to apply the constant force to specific objects, particularly in a pinball game where only the ball needs processing. If you don't do this then you have to set all your other objects to be immovable which is alot of work.
Next, this is a perfect example of how the ability to send and not receive collisions can help. You want the flippers to dish-out forces but not be affected by them. Using "setCollisionActive(true, false);" does this. The pinball should be configured to send and receive collisions so that it can hit bumpers as well as have things hit it.
Next, there have been a number of requests to be able to tell an object to move to a certain rotation and then stop as well as the ability to move to a position and stop. When I've finished this round of bug-fixing, I think it's been asked for so many times that we'll just have to add it. In the meantime though, the physics of the flipper would suggest that you should have fine increments of rotation, simply jumping 10 degrees at a time is quite severe.
The reaction of a pinball against a rotating flipper involves some pretty subtle settings for the collision materials. Restitution, friction and density of the ball are very important here. The thing to remember here is that the ball, after colliding with the flipper, will rebound correctly off it using its own collision-polygon (which should be a regular-sides poly, at least 18+ sides, probably 24) against the flippers'. The other way around, where the flipper collides with the ball due to rotation will only cause the ball the move moved with the flipper as a result of an overlap (this is handled automatically by the physics system). What will happen is that the ball will then collide with the flipper and rebound correctly.
Also, you want to allow the pinball to rotate, don't restrict the angular velocity at all. If this becomes a problem because the pinball art is something like a shiny metal ball, there are different ways to achieve some cool effects like fake specular effects. Have an amorphous diffuse ball that is the actual collision-object but mount (but not inherit rotation) an alpha specular/reflection it it. Another way, and probably much easier, is to use a fxSceneObject2D (which doesn't render anything but has all the core T2D capabilities) for the collision-object but mount another sprite which renders the ball, onto it and again, don't inherit rotation. I did this in a test Pachinko demo we were doing. This stuff does work, well within the capabilities of the physics engine. Our pool demo will eventually show that. :)
One of the improvements to the physics at a later stage is to factor-in velocity changes to objects at rest as a result of an impact of another object at rest but rotating. This is a slightly more complex calculation but most of the time isn't a problem.
With regards to "locking" the X/Y, you don't need to lock it if you don't apply forces to it. It sounds like you're having problems altering the pivot-point? If so, then try reading this or this.
I will finally add that although this all sounds complex, customisation of your physics solution is nearly 99% the configuration of the respective collision materials. Apart from setting the collision-polygon and enabling the collisions/physics, the details are all in a single datablock setting. There's very little else you can do wrong with the rigid-body physics although it is confusing as we've not yet done the tutorials for it. Soon!
If you still don't get the results you want then come back and we'll see how we can help further.
- Melv.
03/08/2005 (1:15 am)
@David: Couple of things here that might help...First up is that applying a constant force to the scene is quite severe. It's actually much more efficient to apply the constant force to specific objects, particularly in a pinball game where only the ball needs processing. If you don't do this then you have to set all your other objects to be immovable which is alot of work.
Next, this is a perfect example of how the ability to send and not receive collisions can help. You want the flippers to dish-out forces but not be affected by them. Using "setCollisionActive(true, false);" does this. The pinball should be configured to send and receive collisions so that it can hit bumpers as well as have things hit it.
Next, there have been a number of requests to be able to tell an object to move to a certain rotation and then stop as well as the ability to move to a position and stop. When I've finished this round of bug-fixing, I think it's been asked for so many times that we'll just have to add it. In the meantime though, the physics of the flipper would suggest that you should have fine increments of rotation, simply jumping 10 degrees at a time is quite severe.
The reaction of a pinball against a rotating flipper involves some pretty subtle settings for the collision materials. Restitution, friction and density of the ball are very important here. The thing to remember here is that the ball, after colliding with the flipper, will rebound correctly off it using its own collision-polygon (which should be a regular-sides poly, at least 18+ sides, probably 24) against the flippers'. The other way around, where the flipper collides with the ball due to rotation will only cause the ball the move moved with the flipper as a result of an overlap (this is handled automatically by the physics system). What will happen is that the ball will then collide with the flipper and rebound correctly.
Also, you want to allow the pinball to rotate, don't restrict the angular velocity at all. If this becomes a problem because the pinball art is something like a shiny metal ball, there are different ways to achieve some cool effects like fake specular effects. Have an amorphous diffuse ball that is the actual collision-object but mount (but not inherit rotation) an alpha specular/reflection it it. Another way, and probably much easier, is to use a fxSceneObject2D (which doesn't render anything but has all the core T2D capabilities) for the collision-object but mount another sprite which renders the ball, onto it and again, don't inherit rotation. I did this in a test Pachinko demo we were doing. This stuff does work, well within the capabilities of the physics engine. Our pool demo will eventually show that. :)
One of the improvements to the physics at a later stage is to factor-in velocity changes to objects at rest as a result of an impact of another object at rest but rotating. This is a slightly more complex calculation but most of the time isn't a problem.
With regards to "locking" the X/Y, you don't need to lock it if you don't apply forces to it. It sounds like you're having problems altering the pivot-point? If so, then try reading this or this.
I will finally add that although this all sounds complex, customisation of your physics solution is nearly 99% the configuration of the respective collision materials. Apart from setting the collision-polygon and enabling the collisions/physics, the details are all in a single datablock setting. There's very little else you can do wrong with the rigid-body physics although it is confusing as we've not yet done the tutorials for it. Soon!
If you still don't get the results you want then come back and we'll see how we can help further.
- Melv.
#6
Don't expect this immediately though. ;)
- Melv.
03/08/2005 (3:20 am)
@Rob: Yes, I already discussed this before as part of the potential feature-set for T2D when I discussed animatable properties that work similar to the particle engine.Don't expect this immediately though. ;)
- Melv.
#7
- Melv.
03/08/2005 (3:27 am)
@Rob: This is a bit of a thread hijack so it's probably best to discuss this on the other thread although it's work for the future. There will be different editors, it's these that make it intuitive really. The ones we've got are only placeholders to get you going. There's also documentation to come on this system.- Melv.
#8
03/08/2005 (9:27 am)
Thanks to everyone, especially Melv. I did manage to get everything working last night just by trying different combinations of things, which in my experience is the mark of a good API. I was really skeptical that I could get a decent pinball physics simulation from T2D but its actually working out better than expected.
#9
Seriously though, really happy that you got it working. For the future, we'll be looking at making the physics much more powerful. I think if you can do platformers, pool and pinball games in a single physics API then you're doing well, easpecially at EA1.
- Melv.
03/08/2005 (9:30 am)
Oh now you can't say that without showing a screenshot or movie, that's just teasing us!Seriously though, really happy that you got it working. For the future, we'll be looking at making the physics much more powerful. I think if you can do platformers, pool and pinball games in a single physics API then you're doing well, easpecially at EA1.
- Melv.
#10
03/08/2005 (9:56 am)
Pinball was one of the games on my list to try with T2D
#12
04/03/2005 (1:44 pm)
Pinball sounds like a good distraction while waiting for the update. Here goes nothing...
#13
I'll post what I have tomorrow. I need to call my clients and tell them I have a case of "pinball flu" coming on :-)
04/05/2005 (7:52 pm)
Well, I got stuck doing "real" work for the past two days, but I was really surprised at how far I was able to get in a couple of hours of tinkering.I'll post what I have tomorrow. I need to call my clients and tell them I have a case of "pinball flu" coming on :-)
Torque Owner Seth Willits
I'd say a pinball machine is a perfect way to use the physics in Torque. Why? Because you don't have to write the code at all! Just get the rotation on the flippers working correctly and the rest is automatically handled. How cool is that?