[ODE] Question about variable step size and collision detection

[Per Bull Holmen]

--- "Daniel K. O." <danielko.listas at gmail.com> skrev:

> Per Bull Holmen escreveu:
> > of camera angles etc. This means that when
> colliding
> > objects penetrate each others, it will be all too
> > visible - 2D graphics must be pixel perfect.
> >   
> I think you are exagerating a bit here. :)
> Other than Tetris, "pixel perfect" response is
> unnecessary.

/.../

> Maybe your audience are super heroes who can detect
> "hey that bullet 
> killed the enemy only when it entered 3 pixels
> inside the enemy". :P
> 
> Unless you plan to make the bullets reflect on
> something, like a pool 
> game (and even on a bullet-pool game ODE would be
> OK), you won't care 
> for penetration.

/.../

> Why don't you show us a more specific scenario you
> think ODE may cause 
> problems? Then we can suggest more specific
> solutions.

Good point. Just to briefly explain my ideas, you can
think of something like Arkanoid meets flipper. Like
arkanoid, there will be much bouncing of a (hard)
ball, hitting all kinds of walls and objects, and it
may go slowly at times, fast or very fast at other
times. More like flipper, these objects hit may not
always be rectangular and static, but arbitrarily
shaped, dynamic, sometimes on hinges. I'll need a
physics engine to handle all of this. Most objects in
the dynamics world will be resting throughout most of
the game.

I've played around with making an arkanoid-like game
before. I seem to recall that letting the ball
penetrate a few pixels into walls etc. does not look
all bad, but it looks cleaner if it hits perfectly.
The physics of that game were so simple I did it
myself, so it never was a big issue. I just decided to
make it hit perfectly after a few tests.

> > Id like to avoid the very-small-timestep approach
> > because it would be inefficient, and though it
> might
> > work on my rather new IntelMac, it might not work
> on
> > older machines.
> >   
> Just wondering, how many objects would you be
> simulating? More than 100? 
> 500? 1000? All of them generating collisions like
> gas atoms moving 
> inside a closed box?

For the most part, very few "live" objects (maybe 2-4,
to be exact), will be manipulated by the engine. At
times, there may be 10-20, most circle-shaped, (I will
problably use cylinders for collision primitives) and
only constrained by the x/y-plane. ODE will probably
not have the slightest performance problem. I thought
maybe it might be a problem if I wanted to add other
sophisticated features like AI to the game. Also, I
once played an Arkanoid-like game where at times, more
than a hundred balls bounced around and it all went
smooth and fast... it was fun, though not at all an
important feature. It won't add much to the gameplay
experience.

I've had a few good suggestions on this list and by
private e-mail, I must try them out later. I probably
have enough background info now to pick an engine, it
will either be ODE or Bullet, I believe. I'll still be
happy to hear suggestions, but don't go out of your
way to figure it out... :)

Thanks,
Per


	
	
		
_________________________________________________________
Alt i én. Få Yahoo! Mail med adressekartotek, kalender og
notisblokk. http://no.mail.yahoo.com