On Fri, Dec 31, 2010 at 02:35:28PM +0100, Jacques Rebourcier wrote: > Nobody here ? Every one disconnected for christmas holliday season ?
Exactly I'm just back from holliday > I am struggling with my simulation game. This is a marble racing game that > looks like ode-collision-8-terrain.py tutorial. > > Actually, if you toggle this turial in wireframe mode, you will see some of > my > issues (let simulation lasts a while). > > 1) Slow : > The simulation is too slow, as in a planet with low gravity. I noticed ode > stepsize = soya round_duration. Effectively, reducing round_duration under > 0.005 is better but still not perfect (seems to be less stable). I suspect > that visting world during each round (begin, advance, and end) make a latency > between ode stepping, and so fluidity/realism of simulation is bounded by > this > round visiting mechanism. Correct or not ? If the ODE simulation is too slow (but that the soya rendering is fine). you just need to change physic value of your simulation. For example increasing mass of you object of gravity of the system. I would be possible to have a stepsize != soya round duration but I don't think this is necessary. If the soya simulation is too slow you need to optimise you code or to check compilation flags used when building soya. > 2) Jiterring : > > 3) Violent popping : > > 4) Falling : > > => I suspect matrix random computation insatbility (error margin), or Terrain > Collider weird integration with ode that could be at the heart of problem, > but > the code seems to complicated for me. In another message you pointed NaN value in ODE matrix which look suspiscious. Investigation and fix of this issue will probably fix most of this issue. Anyway, the current terrain collider if weird and complicated. It was a "necessary" evil when the original ode integration stuff have been written. However ODE now provide and heighfield terrain shape that could be used in soya instead. If the old terrain implementation is too buggy it might be a good reason to switch. > => All these are show stopper for my game idea (except 1) that could be Ok). > I > tried several stability tricks from ode documentation, some seems to work a > little, some time i didn't notice any effect (as if ode binding was > "silently" > broken), but never achieved something really stable. Ok, do you have a strick list of the one you tested but didn't seems to have any effect ? Can you provide simple testcase showing the issue. (if possible with the python's unittest framework so we can integrate them to the soya test suite) > => I don't know how to debug/help, we are in Pyrex and ode binding black > magic. > > => Could someone help me ? I can help you. I'm the one who integrate the old ODE binding into soya mechanism therefor I know the internal pretty well. (or at least I knew). The main issue is that I'm currently not very available at the moment. you have several options: - Make clear bug report and wait for fix I could provide in the following months (can't grantee sooner). - Ask for pointer or help on specific subject and use them to try to fix it yourself with me as "support". I'm available using, email, irc, jabber/xmmp, or real live meeting if you are in the Paris Area (as you seems to be french). Thanks you for you interest in soya and I hope we'll be able to fix the annoying small issue you encounter. Happy new Year. -- Pierre-Yves _______________________________________________ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
