Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think the main problem is the manipulation of <code>Rigidbody</code>'s <code>velocity</code>. I would try the following to solve the problem.</p> <ol> <li>Redesign your code to ensure that <code>IncreaseBallVelocity</code> and every other manipulation of <code>Rigidbody</code> is called within <code>FixedUpdate</code>. Check that there are no other manipulations to <code>Transform.position</code>.</li> <li>Try to replace setting velocity directly by using <code>AddForce</code> or similar methods so the physics engine has a higher chance to calculate all dependencies.</li> <li>If there are more items (main player character, ...) involved related to the physics calculation, ensure that their code runs in FixedUpdate too.</li> </ol> <p>Another point I stumbled upon were meshes that are scaled very much. Having a <code>GameObject</code> with scale &lt;= 0.01 or >= 100 has definitely a negative impact on physics calculation. According to the <a href="http://docs.unity3d.com/Documentation/Components/class-Transform.html" rel="nofollow">docs</a> and <a href="http://forum.unity3d.com/threads/105468-Mesh-scale-factor-vs-Transform-scale" rel="nofollow">this Unity forum entry</a> from one of the gurus you should avoid Transform.scale values != 1</p> <p>Still not happy? OK then the next test is starting with high velocities but no acceleration. At this phase we want to know, if the high velocity itself or the acceleration is to blame for the problem. It would be interesting to know the velocities' values at which the physics engine starts to fail - please post them so that we can compare them.</p> <hr> <p><strong>EDIT: Some more things to investigate</strong><br> 6.7 m/sec does not sound that much so that I guess there is a special reason or a combination of reasons why things go wrong.</p> <ul> <li>Is your <a href="http://docs.unity3d.com/Documentation/Components/class-TimeManager.html" rel="nofollow">Maximum Allowed Timestep</a> high enough? For testing I suggest 5 to 10x <code>Fixed Timestep</code>. Note that this might kill the frame rate but that can be dfixed later.</li> <li>Is there any difference between running the game in editor player and on Android?</li> <li>Did you notice any drops in frame rate because of the <code>0.01</code> <code>FixedTimestep</code>? This would indicate that the physics engine might be in trouble.</li> <li>Could it be that there are static colliders (objects having a collider but no <code>Rigidbody</code>) that are moved around or manipulated otherwise? This would cause heavy recalculations within PhysX.</li> <li>What about the layers: Are all walls on the same layer resp. are the involved layers are configured appropriately in <a href="http://docs.unity3d.com/Documentation/Components/LayerBasedCollision.html" rel="nofollow">collision detection matrix</a>?</li> <li>Does the no-bounce effect always happen at the same wall? If so, can you just copy the 1st wall and put it in place of the second one to see if there is something wrong with this specific wall.</li> <li>If not to much effort, I would try to set up some standard cubes as walls just to be sure that <code>transform.scale</code> is not to blame for it (I made really bad experience with this).</li> <li>Do you manipulate gravity or <code>TimeManager.timeScale</code> from within a script?</li> <li>BTW: are you using gravity? (Should be no problem just </li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload