Newbie Question

Okay, thanks. I'm just in the very early design phase on this one. So if anyone has some experience with putting lots of bouncing balls in their game, please let me know what would be a realistic number to have going at one time.

Ideally I'd like every ball in the machine to have a physics action, but that could be thousands. If only the ones that are on the playing board at one time, then proabably less than 50. There would need to be quite a few pins on the board for them to bounce off as well. See illustration:

Really, just take the AUM25 example and change a couple of lines so that you can add more spheres at random times. This takes less than 30 minutes of coding and you can see if the results are okay or not (btw you also want to set friction to 0 and maybe lower ph_fps_max_lock to less than 70 for better performance).

Have you tried it ?

I just downloaded Newton Physics two days ago. Tuesday is my hell day at work when I have to work 12 hours, so I didn't get anything done today. I'm also being hounded to write a couple of tutorials.

Also, I'm considering using the pysics in the pro version of 3dgs. I was going to upgrade for some other features soon anyway. If anyone can shed some light on which way is the best to go right off the bat would be helpful (and if it even matters).

In physics class at school I spent more time staring at the walls than studying my books (so you see, these things really can turn out to be useful to you later in life).

I will try it very soon though, and post again.

<------Physics Professor at your disposal.

Honestly Russ, if I weren't so busy myself, I would whip this up for you.
This is really a trivial affair with the 3DGS PE and should be just as easy with the NGD.
In my MMO project, I had 100 physics objects running at the same time before things slowed down. I think this is plenty of Steel Balls to simulate what you want.

I'll be more than happy to help you with the 3DGS PE and with the RL PE.


"Ask Dr. Know. Theres nothing I don't!"
Robin Williams in "AI"

Thanks Fastlane. I will have a try myself first. I want to learn how physics works, and it will be very satisfying to do it myself. If I get stuck or you can improve on my bhest efforts, then I'll take you up on your offer.

I still have some research to do on this (i.e. I'm going to go and play some pachinko), but if the physics really isn't that hard (???), then I could get that part done then come back to the design of the board later.

I don't only want the balls on the playing field moving. One of the most exciting aspects of Pachinko is that when you start winning, you keep winning and balls start spewing out everywhere. (Funny thing is the Japanese one armed bandits do the same thing with coins, but that's another story). Eventually you have buckets of the things. I have to work out a way simulate that. ONce balls come to rest, they won't need a physics action applied to them, and the balls themselves could be represented by 2d sprites.

I put my order in for 3dgs pro this morning.

Okay. while I didn't have much to do at work today I planned this pachinko simiulation a little more and read the physics commands in the manual.

Since the entire playing field is no more than 50cm diameter, and there are a lot of small objects, I think the scale should be something like 1 quant = 0.5mm (a pin wouldn't be much more than 1mm diameter in any case).

If the scale were 1q = 0.5mm then gravity would need to be set to -7620 (381*1/0.05 -isn't that right?).

That being the case, should I use geometry for the pins, or entities (set up somehting like ph_settype(pin, ph_rigid, ph_cylinder) ?)

To shoot the balls onto the field, would I create the ball at its start position and use phent_adforcelocal()? This command is difficult for me to understand ,so some light on how this could be made to work would be useful.

I have no idea what the mass of a pachinko ball would be. I'll try and ask someone.

There are spinners in the machine too. I haven't got to thinking about how they would be made to act.

Firstly, if you physics' gurus could tell me if I'm on the right track so far as regards scale, I can go ahead and make a playing field for testing.

This physics thing is fun


Thanks Fastlane. I threw a level together today. As you suggested I used a very small scale of 1 quant=0.1mm.

However, I've run into a couple of problems.

The collision detection is terrible. Even though the walls are at least ten quants thick, the ball often goes through them. It doesn't even seem to matter what speed the ball is travelling at.

The ball performs better when I use a spherical model. When I try using a sprite, even though I have set it to behave like a sphere, it doesn't. Also, when it gets in a narrow place, it sometimes slows down then speeds up again -not very realistic.

I have another problem with the GSjanFX plugin, but that is a different story, and I'll post elsewhere.

in the meantime here is the code I threw together for testing:

Code:

---

// pachinko2.wdl





path "C:\\Program Files\\GStudio6\\template";	// Path to WDL templates subdirectory



include <GSjanFX.wdl>;



var ball_pos[3];





//function declarations

function create_ball();

function init_sphere();

function init_pin();

function set_pins();











//string pachinko2_wmb = <pachinko2.wmb>;





function main() 

{      

     level_load ("pachinko2.wmb"); 

     wait(3);

     

     

     camera.x = 0; 

     camera.y = -6500; 

     camera.z = 1500; 

     camera.pan = 90; 

     ball_pos.x = 900; // initial value, ranges from -95 to 105 

     ball_pos.y = 0; 

     ball_pos.z = -750; 

     

//     set_pins();

     create_ball();

}











//entity* ball_ptr; 

 



function create_ball() 

{ 

	

	ent_create("pachi_ball.mdl", ball_pos, init_sphere);

	



 

} 



function init_sphere() 

{ 

		my.scale_x=2.5;

		my.scale_y=2.5;

		my.scale_z=2.5;

		my.pan=90; 



     phent_settype(my, ph_rigid, ph_sphere); 

//    Enable physics for this ball; it will behave like a sphere when it comes to collisions 



     phent_setmass(my, 0.05, ph_sphere); 





     phent_setfriction(my, 30); 

//    Friction = 30 (could be 0...100) 



     phent_setelasticity(my, 60, 0); 

//    Bounce a little (value = 30, could be 0...100) 



     temp.x = 0; 

     temp.y = 0; 

     temp.z = -360; 

     ph_SetGravity(temp);  

//    Set gravity for the sphere (temp.z = -380 corresponds to the earth gravity factor, g = 9.81 m/s2) 



		//punch ball out shoot	

		phent_addforcelocal(my,vector(0,20000,0),nullvector);	



     while (my.z > -1000) {wait (1);} 

//    Wait until the ball has fallen off playing field



     phent_settype(my, 0, 0); 

//    Now stop the ball; A6 commercial allows us to use one object (ball) at a time 



		wait(1);

		ent_remove(me); 

} 



function init_pin()

{

	phent_settype(my,ph_rigid,ph_cylinder);

}

	

	





function set_pins()

{



//this doesn't work properly yet

  

---

Thanks for that advice Fastlane, I'll save my level as a map entity and set those characteristics.

The problem with using a 3d ball is that they require a lot of polygons, and to make the light spot on them stay in the right place would no doubt require some kind of shader as well (one I don't even know exists). The pachinko machine requires lots of balls. The bare minimum to be playable is 400, and I want to be able to show the balls in catch basin. A sprite that behaves like a ball is the obvious first choice.

The biggest problem is, the ball isn't even going especaially fast yet, and it can't handle collision. Certainly not as fast as they move in the real machines.

I'm going to try making smaller blocks for the invisible front ofthe machine as well, since that is where the balls most often exit the machine. Perhaps big blocks don't detect collision as well?


@ Marco: What's the story with collision detection? Should it be able to handle fast moving pinballs?

FYI, I've only ever had 120 physics objects max on the screen and I think I had the physics clock running in the hundreds of ms; needless to say, the simulation gound to a halt.

400 registered physical objects is, IMO, a bit too much.
I can safely vouch for 100 registered physical ents on screen.
Don't know about the rest of the users.

How about if they are just being used for their collision hull (cylindrical pins)? or their elastic, friction-free surface (the level itself)? For the balls that aren't in the playing field, perhaps I could use "Fake Fizziks"?

Anyway, it's all for naught if the collision system can't handle small steel balls wizzing around hitting pins and other small objects (ramps, spinners, rails). At any scale the pins have to be small in comparison to the balls. No pinball simulation is possible without that.

Though I haven't tried scaling the larger sized blocks down yet. Notably the invisable "glass" front.

I have some time tomorrow to test this again.

You are running into an issue with the current collision detection. Invisible blocks are not considered obstacles at all. Remove the invisible blocks in your WMP and replace them with a single large MDL cube set to invisible. While you are at it you might also want to change the machine backdrop into an MDL which will increase compile time and FPS, i.e. only leave the slopes and ramps as blocks.

The pins should not be physics entities, since they won't be moving anyway lots of CPU time would be wasted. Instead use regular MDL or WMB entities for them. Looking at the large number of pins you are likely to run into performance problems, using a sprite for the spheres might indeed be a good idea. Try playing with that scale, while larger scale makes collision detection more reliable it also makes it slower due to increased tesselation of level blocks.

Thanks, the model for the front glass works. I am not getting any more problems with the balls leaving the board.

However, I still can't use sprites for balls. It's hard to explain. They work, but they don't move as well, and they get stuck in the funnels. Models look natural and go through the funnels without a hitch. For both models and sprites I have the bounding box set to sphere. How do I make sprites perform like the models?

Yes, that must be what is happening, I think the sprites are behaving more like bouncy coins than balls.

It's going to be very difficult to keep the fps up with this.

Anyway, I made some progress today. I'll try and make the spinners tomorrow and maybe redesign the playing field.

Just some friendly advice...get your balls and playing field in order before you move on to spinners. I'm assuming that you want to maximize ball count in your project, thus the following scheme might benefit:

Every object you register with the engine will count against a Maximum number of PE registered entities you can field at once and keep the simulation "believable" (never realistic...just believable ). Your "quantum" object, the most basic physical object in your game is the steel ball; thus it seems natural to max out your playing field with no other physical objects and see how many balls you can field at once. This becomes you Bare Maximum.

You can now better analyze each new physical object you wish to introduce (spinners, gates, flippers) as counting against this Bare Maximum. In other words, how many balls would I have to take out to introduce this new physical object and keep my simulation running smooth.

This is not a hard and fast rule but rather something that might make your development a bit easier since it makes no sense to design a feature that has too large an impact on your ball count nor would it make sense to drop a feature if you only lose one or two balls by implementing it.

Right now, even forty balls onscreen at one time is pushing it. More than 60 and it will drop below 20fps, which in my opinion is unacceptable.

It's not just the balls. They are not the MOST important thing on the screen (though with a game like pachinko, the more the better, thousands are cool). The balls have to go through things like funnels and spinners to make it interesting, and to make it exciting they have to spit out the winning slot in the thousands!(litterally, when you win at pachinko, you have some big buckets of ball bearings to take to the counter -to take to that completely legal hole in the wall around the corner )

This thousands of winning balls spewing out troubles me, because it so important to the fun aspect of the game. For now I'll just concentrate on the main playing field. Just that is hard enough for now.

That's odd. Like I said, I had 100 entities onscreen @ 20fps no problem. Granted they weren't all moving very fast....hmmmm....60 might not be a unrealistic high end.

Here's how we can do this:
Finish the level...tweak it out real nice with all sorts of non-physics bells and whistles....don't do a lick of physics....send me your level balls included...I'LL tweak your physics settings and see if I can't get a few extra balls/fps.

Thanks Fastlane,

I think part of the problem is my level geometry. Trouble with BSB is that every damn thing needs to be a block. Once I start cutting into the backface to make holes for the balls to fall through and everything gets cut into triangles and the poly count rockets. I don't really want blocks since very little can really be hidden in this type of simulation anyway. Today, I did push my luck by making the pins eight sided. Realisticly, I think four sided is the minimum. Three sided and there is too much chance of a head on collision. I've had a bit of an attempt to search the internet for other pinball simulation development tips, but it hasn't turned up anything useful yet.

The physics are starting to look realistic. I'm starting to get the right number of balls on the screen and they are moving down at about the rate I'd expect from a real machine. Balls are still getting stuck in blocks (usually they find their way out again, but it looks funny). Balls are still getting stuck in funnels 'even if they are models). Also having a little trouble with SED's debugger showing me changes in some variable s (it doesn't like local variables, and some global ones too -don't know what is going on there).


I'm sure there are work arounds for all these things (dicking the balls when they stop moving, transporting balls in funnels, making goal entities instead of chopping holes...). However the more the physics engine can take care of without resorting to those measures the better. I've seen some pretty cool pinball simulations, and I wonder how they pulled it off.

I'm not going to give it up just yet, and the advice I'm getting from Marco and yourself is greatly appreciated.

Things are working much better now. I want to add a flipper to knock the balls out rather than just applying a force directly to them. I'm using a slider for this. I couldn't find an example of setting up a flipper and I'm having a little trouble with it:

Code:

---

function init_flipper()

{

   var constraint1;	



phcon_add(ph_slider, my, 0);

	ph_con_setparams2(constraint1, vector(50,0,0),nullvector,nullvector); //this gives an error

	

	while(my!=null)

	{

	

		temp.x=-spring+random(200)-100;

		temp.y=0;

		temp.z=0;

			

		//punch ball out shoot			

		phcon_setmotor(constraint1, temp, nullvector, nullvector); 

		

		sleep(1);

	}

}  

---

This wouldn't be a flipper, it would be the Ball Launcher...maybe they are known as flippers two in the "parlance", I don't know; I never was a pinball wizard



Seems like you haven't set you constraint axis vector:


Code:

---

 function init_flipper()
{
 	
  var constraint1[3]=1,0,0;	  



phcon_add(ph_slider, my, 0);
	ph_con_setparams2(constraint1, vector(50,0,0),nullvector,nullvector); //this gives an error
	
	while(my!=null)
	{
	
		temp.x=-spring+random(200)-100;
		temp.y=0;
		temp.z=0;
			
		//punch ball out shoot			
		phcon_setmotor(constraint1, temp, nullvector, nullvector); 
		
		sleep(1);
	}
}  
 

---

Okay, let's call it a ball launcher then. That is a better word. Thanks for that tip, though I'm still having trouble with my ball launcher. It behaves very strangely indeed:

Code:

---

//Ball launcher



constaint1[3]=1,0,0; //only allows movement on x axis?



function create_ball_launcher()

{

	temp.x=ball_pos.x+400; //put in position relativeto where ball is created

	temp.y=ball_pos.y;

	temp.z=ball_pos.z-130;

	

	ent_create("ball_launcher.wmb", temp, init_ball_launcher);	

}



function init_ball_launcher()

{





	phent_settype(my, ph_rigid, ph_box);

	phcon_add(ph_slider, my, 0);

	

	phcon_setparams1(constraint1, vector(1,0,0),nullvector,nullvector); // I thought that the second agument of this set the contraint axis?

	phcon_setparams2(constraint1, vector(-50,0,0),nullvector,nullvector);

	

	while(my!=null)

	{

	

		temp.x=-spring + random(200)-100;

		temp.y=1600000;

		temp.z=0;			

		//punch ball out shoot			

		phcon_setmotor(constraint1, temp, nullvector, nullvector);

		sleep(0.5);

		temp.x-=temp.x;

		phcon_setmotor(constraint1, temp, nullvector, nullvector);

		sleep(0.5);

	}

}

	

	  

---

The entity bobs around and spins.

Also, is there a way to stop the entity from spinning?

constraint1=phcon_add(ph_slider, my, 0);

Heh, I actually had that before. I'll set phent_maxspeed, and with any luck that'll do it.

pjhent_setmaxspeed didn't do anything. It still rotates around. When a ball hits the ball luncher, it gets bumped around to the wrong angle, and then goes all to hell bouncing and twirling all over the place.

To tell the truth, I don't understand about things like velocities and torque, so I probably have a few other settings off:

Code:

---

function init_ball_launcher()

{



	var constraint1[3];



	phent_settype(my, ph_rigid, ph_box);

	constraint1=phcon_add(ph_slider, my, 0);

	phent_setmaxspeed(my,10000,null); //this doesn't stop rotation (I tried with other values too)

	

	phcon_setparams1(constraint1, vector(1,0,0),nullvector,nullvector); //limit movement to the x axis

	phcon_setparams2(constraint1, vector(-50,0,0),nullvector,nullvector); //can't (shouldn't be able) to move more than 50 quants

	

	while(my!=null)

	{

	

		temp.x=-spring;//The amount of force to move the ball launcher

		temp.y=-1600000;//maximum force for the ball launcher

		temp.z=0			

		//punch ball out chute	

		//should make it so that it moves back and forth in 1 second intervals

                //seems to work okay until the ball launcher hits a ball and rotates around

		phcon_setmotor(constraint1, temp, nullvector, nullvector);

		sleep(0.5);

		temp.y-=temp.x;

		phcon_setmotor(constraint1, temp, nullvector, nullvector);

		sleep(0.5);

	}

}

---

a) phent_setmaxspeed(my,10000, nullvector );

b) keep constraint1 like you had it before; eliminate all instances of it being a vector (ie replace all constraint1[3] with just constraint1. This is a leftover from my mistaken solution.

Okay, I've done those two things. I actually did try it with nullvector, but it didn't work. For a start it does what it is supposed to, but eventually the balls knock the launcher over and it goes wonky:

I take it that it isn't possible to stop the rotation then. I'll just do away with the launcher and keep applying the force directly.

I'm getting back to making the spinners. I'm finding this very difficult, and don't really know how to approach it.

The spinners are not motorised, they should simply spin when balls hit them.

Here is a picture of the entity for the spinners:

I attempted to make the spinner from a hinge. It doesn't move at all. I assigned the spinner entities this action:

Code:

---

action init_spinner

{

	var constraint2;

	

	phent_settype(my, ph_rigid, ph_poly);  //ph_poly -polygonal collision?

	constraint2=phcon_add(ph_hinge, my, 0);  //a hinge would be all that is needed in case, right?

	

	phent_setmass(my, 0.5, ph_poly); //lighter than a ball

	phent_setfriction(my, 10); //not much friction

	

	phcon_setparams1(constraint2, my.x,vector(0,0,1),nullvector); //anchor point (origin is in centre of entity)

	phcon_setparams2(constraint2, vector(360,-360,0),nullvector,nullvector); //can spin all the way around

	

	while(my!=null) //didn't know if a loop was neccessary, so threw it in just in case

	{

		wait(1);

	}

	

}  

---

I've commented what I thought I was doing.

EDIT> Nevermind, fixed it. Amazing what a lunch break can do.

The spinners sometimes get knocked over by the balls if they are moving fast enough, like the ball launcher was. So, I'll try my luck again. Is there any way to stop this?

Just to make certain. Does the physics system only work with the new collision system (collisions with models polygons rather than collision hull)?

Well, I decided the answer should be yes.

So, I tried it out by making another level just using the model instead of the level geometry. I set the model's polygon flag on and ran it.

The balls don't move at all.

Why not?