Le lundi 3 janvier 2011 14:29:05, Pierre-Yves David a écrit :
> 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
>
Hi Pierre Yves !
Hope you enjoy your vacation break, and best wishes for this new year too !
Yes, I am french (Toulouse). Do not thank me for my soya interest, it is easy
to be interested by this good game engine ;) ! It is rather me to thank you
(and jiba and other developer) for your work !
Just for introduction, this project is just for "fun" for me, my children and
my nevews (playing and doing it, so no stress). The idea is mabrle racing
game, a turn game where players shot a marble to advance their car on the
terrain track, followers can bounce on other cars to turn, or shot othre
marble to push them offtrack, I plan to use bonus or traps like Maria kart
racing, so the gameplay is between foo billard and mario kart ;) . Idea seems
promissing to me, could be also a net game... But I am a poor coder and I do
not know python very well, nor 3D concepts (used to code, but a stopped for a
while). I am pretty sure I've done some coding mistake (Its an old code -
coded with different soya version" , and I learned meanwhile coding, so it's
messy and patchy). There is something stange (random) that seems to become
worse with time, or when number of player increase. But error is "silent" (no
error message). Like something not well intialized (for example ode binding)
or drifting with time (like looping on object creation). I need to clean up or
use simplified testcase to find out, will tell you...
But some specifics things I can tell you now (if you have any idea) :
It is possible I have an incompatibility between soya (15rc1 straight compile
with setup and without Pyrex) and precomiled libode (11.1). But, this is an
old code, and I already had this pbs before (with various soya / ode
combinatory), so more probable this a soya bug for me and related to terrain
collision. All other ode tutorial or basic test but terrain seems to work !
For terrain collision, just turn renderer to wireframe (to see what hapens
behind the terrain) in the tutorial, on my system, I sometime see ball falling
or boucing abnormally, do you on yours ?
Then, throw a sphere on a terrain with auto-disable feature on. Set up
angular_velocity threshold, for example 0.1, you see ball rolling, then stop
when disabled ! Do the same thing replacing angular velocity by linera
velocity threshold (for example 0.1 or even 100, or 1000, or any velocity you
are sure you never exceeds), in my case, the sphere never stops.
Then, I tried "contact_max_correcting_velocity", idea was. Ok in case of
violent poping, the speher is ejected with a linera velocity >1000, so I
decided to set max velocity at 1000 (and even less), but the sphere continued
to pop with the same velocity, perhaps I misunderstandood the parameter ?
For the "NaN" values, it is because I use an home made "rolling" damping
(proportional to angular velocity), and another drag damping (proportional to
sqare linera velocity) ("resistance de roulement et resistance de trainée
aerodynamique" in french). And when the sphere were disabled and ask velocity
for damping computation (retrun a Vector), velocity was null, and created
damping Vector was inited with "NaN" values, which make ode crash, when I
called AddForce, or AddTorque with this vector as parameter !
And I also see, that bounce (bounciness) is not managed the same when
colliding object are regular geom, and when it is "terrain" geom (the general
attribute "bounce" is not used to preset bouncyness of contact).
Another thing i found "weird" is that you code geom.attribute=value, and if
attribute does not exists, it will silently create a new attribute (so syntax
error are not easy to find).
Ok, will do my home work and give you more prrecise inputs.
Regards
Jacques
_______________________________________________
Soya-user mailing list
Soya-user@gna.org
https://mail.gna.org/listinfo/soya-user
