Post by Pierre-Yves DavidPost by Jacques RebourcierNobody here ? Every one disconnected for christmas holliday season ?
Exactly I'm just back from holliday
Post by Jacques RebourcierI 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).
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.
Post by Jacques Rebourcier=> 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.
Post by Jacques Rebourcier=> 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)
Post by Jacques Rebourcier=> 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
- 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
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