Rolling sphere over generated mesh

[Jake]

Splitting execution over several frames is a good idea, I'll see how this feature can be added for 2.0.4. But in my experience the "big chunks" are operations I can't slow down or split, e.g. setting mesh collider or calculating caps triangulation.

Did you checked what module is taking the frametime? Enable CG debug output in the graph's toolbar and doublecheck and/or play with the settings and try to find the time consuming ones. Some ideas:

- try disabling mesh colliders
- disable Optimize for shape and path
- play with "Make Static" enabled/disabled

Also, there's nothing wrong with having a set of CG's, each handling a small portion of your track.

Oh, one idea comes to my mind: If I remember right it may be the case that adding CP's will trigger a spline refresh, thus triggering a Path refresh of all CG's using the spline. I'll have a look and will prevent that behaviour if the path range is clamped and the changes are outside that range. But that may result in some serious coding. As a workaround, disable AutoRefresh on the CG components that are not changed.

Don't worry, we'll get this running in a speedy way. I've definitely planned to do an example scene handling your scenario, will need that to run some tests anyways.

[ioanma]

I have used the Profiler.. and looked into some things.. here is what I have just checked a few minutes ago:

- went into "CreateMesh.cs" - changed createMeshes() to coroutine - updated this part as such:

Code:

for (int vm = 0; vm < MY_MESH.Count; vm++)
{
      if (MY_MESH[vm].Count < 65535)
      {
            CGVMesh vmesh = MY_MESH[vm];
            writeVMeshToMesh(ref vmesh);
       }
       else
            exceededVertexCount++;
       yield return new WaitForSeconds(.2f);
}

- after that, same thing done to UpdateColliders() - updated to this:

Code:

for (int r = 0; r < m_MeshResources.Count; r++)
{
    if (!m_MeshResources.Items[r].UpdateCollider(Collider, Convex, Material))
         success = false;

    yield return new WaitForSeconds(.2f);
}

These changes already diminished the problem by a large margin. It also did implicitly create a visible update sequence (I could see parts of the road being updated, one after the other - instead of the whole thing - makes sense).
There's other places that could benefit from the same idea I guess, but I don't really have a good enough overview of how everything is put together, so.. if I for instance change the WaitForSeconds to ".4f", there's a big delay to setting colliders.. clearly there's more synchronization needed for everything to work.
Anyways, based on the current results, I do believe it is the way to go for better performance.

[ioanma]

I only checked with the Profiler, as I didn't know how CG debug works.

I'm sure disabling mesh colliders will provide a boost but I could not easily test that yet. Will try later today.
If I remember correctly, disabling Optimize, made the stutter much worse.
Enabling "Make Static" somehow stops the road from.. appearing

BTW, I am calling Refresh() on both the "path" spline and the CG, not sure if that is how it's supposed to be done, but it's the only way it worked. And it looks like the entire spline is refreshed. Both Refresh() calls are taking their time..

I'll wait for Curvy 2.0.3 and focus more on other things I've delayed, but will try any ideas or fixes.