|
3 registered members (AndrewAMD, Quad, M_D),
1,217
guests, and 1
spider. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: Please submit bugs and omissions here
[Re: fastlane69]
#24620
04/29/04 07:46
04/29/04 07:46
|
Joined: Sep 2003
Posts: 3,236
San Diego, CA
Marco_Grubert
OP
Expert
|
OP
Expert
Joined: Sep 2003
Posts: 3,236
San Diego, CA
|
Quote:
However, Point 3 is still valid; The PE has a static stepsize. Assuming the PE is doing some sort of ODE integration, every Physics simulation I have ever programmed takes an ADAPTIVE stepsize in order to better integrate the physics behaiviour and reduce error. For eg, (straight from "Numerical REcipies in C") 4th order static stepsize Runge-kutta has a error O(h^5). A naive adaptive routine, say Runge-Kutta-Felberg method have errors of O(h^6) and this error can be imporved upon further by more intelligent adaptive procedures (Richardson Extrapolation for eg). In my experience, a locked-in stepsize is asking for trouble no matter what stepsize you choose
Please keep in mind that Numerical Recipes (got it here in the office) was not written with game programming in mind. One of the design flaws Doug and I have been battling with regular A6 collision detection is that movement step sizes are scalable and not fixed. This makes it hard to have reproducable behavior (think game replay or consistent gliding) in certain situations. IMHO fixed step sizes with occasional frame skipping is the way to go. If I remember correctly there was a similar argument in Game Developer's Magazine concerning Havok about a year ago.
Your original criticism however is valid: if the framerate drops because of physics calculations being too slow then for the next frame it will be even slower, etc. until the system comes to a halt or whatever bottleneck exists (e.g. collision detection, constraint solving) is overcome. Currently no frame skipping is done because I have not run into this problem very often, but this is definitely something that I should add: if physics processing takes longer than a certain amount of time freeze the objects for a few milliseconds. That will lead to hickups in the objects' motion but keeps the system from stalling.
|
|
|
Re: Please submit bugs and omissions here
[Re: Marco_Grubert]
#24621
04/29/04 14:07
04/29/04 14:07
|
Joined: Mar 2003
Posts: 5,377
USofA
fastlane69
Senior Expert
|
Senior Expert
Joined: Mar 2003
Posts: 5,377
USofA
|
btw, I was thinking about this and had to ask, why 70???  At ph_fps_maxlock=70, the stepsize is 0.0142857142857... s. It's trancendential and I don't know about using trancendentials as a stepsize, is there advantages? Even if you round it, it still bring images of zenos paradox to mind and a trancendential stepsize that never "steps".  I would argue that another choice might tidy up your ODE system a bit? In the range of 70, 64 gives a better alternative with a stepsize of 0.015625 s. I prefer 80 though with a tidy stepsize of .0125 s. Just curious.
|
|
|
Re: Please submit bugs and omissions here
[Re: fastlane69]
#24622
04/29/04 14:48
04/29/04 14:48
|
Joined: Sep 2003
Posts: 3,236
San Diego, CA
Marco_Grubert
OP
Expert
|
OP
Expert
Joined: Sep 2003
Posts: 3,236
San Diego, CA
|
Quote:
btw, I was thinking about this and had to ask, why 70???
It's an empirical value ;-)
I was testing various framerate settings and this was the lowest one giving acceptable behavior in terms of penetration detection and speed (lower -> objects pass through each other, higher -> too slow).
Since ph_fps_maxlock is queried every frame you can set it to whichever value you like at any time. That it's transcendental does not matter since it's chopped off to 32-bit floating point anyway. What would make sense though is to pick a value that can be represented exactly in IEEE754, so that N iterations of stepsize 1/N does yield 1.0.
|
|
|
Re: Please submit bugs and omissions here
[Re: ventilator]
#24626
05/05/04 09:06
05/05/04 09:06
|
Joined: Sep 2003
Posts: 3,236
San Diego, CA
Marco_Grubert
OP
Expert
|
OP
Expert
Joined: Sep 2003
Posts: 3,236
San Diego, CA
|
Quote:
after version 6.00.6, physics entity vs. non-physics entity collision wasn't as reliable as before. no matter if my.polygon is on or off for the hit entity, physics entities often rocket around much too extreme after a collision.
I fixed a bug related to that a couple of weeks ago. Don't know if this is what you were experiencing. Can you retry with the beta to be released tomorrow ?
Quote:
Hehe, if you change anything on ODE itself be sure to post it on ODEs pages.
Occasionally I contribute to ODE (e.g. I provided a solution to the stack crash problem) , but one reason why I picked this system is that they are not using this horrible GNU license but instead a developer-friendly BSD one.
Quote:
At one point I attached a Ball Constraint to the player and to the world. Point where it was fixed to the world was a few quants to the right of my object. What I expected to happen, happens...I swing. Problem is, if I take out all drag and friction, I should reach my starting height again, right?
Yes ideally you should reach the starting point again. Ideally adding 10,000 0.0001's should result in a value of 1.0, unfortunately it does not work that way. I did create a test script with a 16 quant sphere attached to (0,0,0) and starting 464 quants along the x-axis. It lost about half a degree per minute of swing time and still looked acceptable after 5 minutes. I can see though, why you would need a perfect swing for your MMUSCLE education. Maybe you can fake it by re-initializing the sphere after each cycle- just check whether the maximum displacement has been reached and call the init function again.
Here's the code used:
Code:
action InitSwing {
phent_settype(my, PH_RIGID, PH_SPHERE);
phent_setmass(my, 0.01, PH_SPHERE);
phent_setelasticity(my, 0, 0);
phent_setdamping(my, 0,0);
phent_setmaxspeed(my, 99999,99999);
var cons;
cons= phcon_add(PH_BALL, my, 0);
phcon_setparams1(cons, vector(0,0,0), nullvector, nullvector);
ph_setgravity(vector(0,0,-380));
}
Some more information on how the update is progressing:
* Add some sort of softbody physics based on springs
The beta will have experimental water surfaces that exhibit spring-mass like behavior.
* auto rest feature
Implemented.
* fix wheel bending
Done. (Reduces wheel bending in most cases- you can still make them bend by applying large forces).
* Movement of a vehicle using the physics engine on terrain. Currently when a vehicle moves over a terrain it is tossed all over the place
There was a bug which caused collisions to be missed on terrain, e.g. only three of four wheels would report terrain contacts at any given time.
* Allow events to be used with entities enabled in the physics engine.
What about EVENT_FRICTION? Which event types do you need?
Last edited by Marco_Grubert; 05/05/04 09:47.
|
|
|
Re: Please submit bugs and omissions here
[Re: Marco_Grubert]
#24627
05/05/04 19:57
05/05/04 19:57
|
Joined: Feb 2004
Posts: 39
Stuttgart, Germany
Rocko75
Newbie
|
Newbie
Joined: Feb 2004
Posts: 39
Stuttgart, Germany
|
Quote:
Some more information on how the update is progressing:
* auto rest feature
Implemented.
* fix wheel bending
Done. (Reduces wheel bending in most cases- you can still make them bend by applying large forces).
* Movement of a vehicle using the physics engine on terrain. Currently when a vehicle moves over a terrain it is tossed all over the place
There was a bug which caused collisions to be missed on terrain, e.g. only three of four wheels would report terrain contacts at any given time.
Perfect! Some problems less to worry about I hope - but one big Question stays open:
What about physik-enitys getting stuck in Level-Blocks? I'm working on a Racing Game and my Cars get very oft stuck in Level-Blocks (i.e. Edges of walls etc.). Once its stuck, it starts to move randomly inside the block, jump wildly and after a while is thrown at massive speed somewhere near Jupiter or Mars.
Can this be solved... or in any way be detected by my game? Currently I see no way, to detected if my car is stuck or not - so the user has to realize he can't move anymore and manualy reset his car to the last position. This very anoying and I haven't found any workaround yet!
Any solutions?
Thanx, Arnim.
|
|
|
Re: Please submit bugs and omissions here
[Re: Rocko75]
#24628
05/06/04 05:08
05/06/04 05:08
|
Joined: Sep 2003
Posts: 3,236
San Diego, CA
Marco_Grubert
OP
Expert
|
OP
Expert
Joined: Sep 2003
Posts: 3,236
San Diego, CA
|
Quote:
What about physik-enitys getting stuck in Level-Blocks? I'm working on a Racing Game and my Cars get very oft stuck in Level-Blocks (i.e. Edges of walls etc.). Once its stuck, it starts to move randomly inside the block, jump wildly and after a while is thrown at massive speed somewhere near Jupiter or Mars.
I ran some tests on that yesterday but it was working fine. I still have to find a way to reproduce this problem in a reliable way.
|
|
|
Re: Please submit bugs and omissions here
[Re: Marco_Grubert]
#24629
05/06/04 07:11
05/06/04 07:11
|
Joined: Feb 2004
Posts: 39
Stuttgart, Germany
Rocko75
Newbie
|
Newbie
Joined: Feb 2004
Posts: 39
Stuttgart, Germany
|
Quote:
I ran some tests on that yesterday but it was working fine. I still have to find a way to reproduce this problem in a reliable way.
I was quite successful, in reproducing this "explosions" in one of my levels. In this particular case, we asume a car, with four PH_WHEEL constrained wheels. Now we take alevel-block a litle above the floor, so the space below is to small for the car to enter, but on the other hand high enough for the engine hood of the car to go below. (Of course the engine hood is low at the front of the car and higher near the front-window) If you drive slowly under this block there is no problem, the car stops when the engine hood touches the bottom of the block. But if you go faster you get the problem, 100%, the car hood goes bellow the block, runs into its wheel constraints, everything gets stuck and volia, one big explosion and the car flies wildly into space.
|
|
|
|
