. </edit>
A while ago I posted about bad collision with physics entities and terrain. http://www.conitecserver.com/ubbthreads/showflat.php?Cat=&Number=320317&page=5&view=collapsed&sb=5&o=&fpart=1#320317 You also may remember that I had previously believed the problem had to do with my function names - I was wrong. After much testing, I've come to the the conclusion that the last entity enabled in the physics engine will have faulty collision detection on terrain! Whats weird is that the entites which previously had faulty collision, will suddenly have perfect collision detection, when another entity is enabled into 3dgsPE on terrain. This problem is much more wide spread then I first believed. Upon further testing I noticed that no matter what, whether there is an constraint or no constraint the last entity enabled into 3dgs PE will have faulty collision detection with terrain. 
Hopefully this will be an easy fix for you Marco. Simply check why the engine gives faulty collision detection between terrain and models which were enabled in the physics engine last. 
If you have any questions please ask - I know a few others had this problem, and I'll soon release the vehicle code with the "cheap fix". Of course, I guess I can just apply the physics engine to some rock out in the middle of nowhere last, that way it will have the faulty collision and everything else will be good. 
I dont understand why it's not showing up for you like it is for me. Quote:
You may have different results with the same code on different systems because of the speed of the systems? Where the faster system is drawing more FPS so objects change position in smaller increments than with the slower system?
Quote:
By default PH_FPS_MAX_LOCK is set to 70 fps. If FPS_LOCK is enabled and FPS_MAX is also set to 70 fps the simulation time will be synchronized. Setting FPS_MAX to, say, 35 will make the objects move at half their speed instead.
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
Quote:
btw, I was thinking about this and had to ask, why 70???
Quote: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 ?
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.
Quote: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.
Hehe, if you change anything on ODE itself be sure to post it on ODEs pages.
Quote: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.
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?
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));
}
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.
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.
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.
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.
Quote:
Check for EVENT_FRICTION and reduce forward motion while the car collides with the block.
Quote:
(remember that small penetration is good, large penetration is bad).