next »

[mihai]

Hi,

I have wrote an article on my blog about the challenges I had in using Unity Free for developing my game and I how I overcame some of those challenges. I'm posting this here because I think it might be of some help to people facing the same problems.

http://www.jungle-troll.com/2012/12/07/unity-optimizations-in-wisps/

Please feel free to share your opinions about the discussed issues.

[B_ill]

Thanks for the write-up; gives me plenty to think about in my next project!

[bateleur]

Using mesh colliders for the tree lines is probably a bad move in performance terms. It's usually better with that kind of thing to use multiple box colliders.

(And yes, Unity/PhysX has very weird spring joint behaviour at times. However, for some purposes they can't be replaced since if you roll your own solution it runs way less often since it will only be once per FixedUpdate instead of whatever your physics iterations are set to.)

[mihai]

Well, it is only one single mesh with very few polygons (one per straight line to say so, they are split only by junctions). In my case I noticed improved performance after using it, so no idea.

FixedUpdate is called at the same rate as the physics loop:
http://answers.unity3d.com/questions/20315/what-is-a-fixed-update.html

My understanding is that FixedUpdate is there exactly for this kind of frame-rate independent processing.

[bateleur]

Well, it is only one single mesh with very few polygons (one per straight line to say so, they are split only by junctions).

Fair enough, probably doesn't matter much then. In general, box colliders are way, way faster.

FixedUpdate is called at the same rate as the physics loop:
http://answers.unity3d.com/questions/20315/what-is-a-fixed-update.html

As the physics loop, yes, but joints use more than one iteration per physics loop.

My understanding is that FixedUpdate is there exactly for this kind of frame-rate independent processing.

For frame-rate-independent processing: yes, absolutely. But you can't, for example, roll your own joints very effectively. Suppose, for example, that you apply a penalty force for certain joint positions. The inbuilt joint solver would get called ten times, applying a different penalty force each time. Your custom joint routine will get called once at the end state of those ten iterations, so no algorithm you could possibly apply will give good results for the physics system as a whole.

For certain special cases - possibly including yours - you can get away with writing your own simulation. In general, though, you're forced to use the built in stuff if you want acceptable results.

[mihai]

I understand now, thanks for the explanation. Indeed, it must have worked for my case because I haven't noticed any problem in rolling my own solution.

[BorisTheBrave]

Actually, many sorts of attractor/repulsor don't really need to interact with the solver, they are just provided as joints for convenience. If you are just applying forces, then by all means do it manually in FixedUpdate. It's only if you are attempting to set velocities or positions that you'll discover you cannot write something as "solid" as the native joints.

[mihai]

Indeed this is my case, I only used forces to keep them at a minimum distance from one another.

[BorisTheBrave]

Well, enforcing a constraint (min distance) is something that would benefit from being inside the solver. I mean when you are applying forces of a known size (e.g. gravity, springs, etc), not penalty forces.

[mihai]

Hi,

I come back to this topic with an articles that is a continuation of the previous one in which I explain what I did to port the game from PC to Android, performance wise:

http://www.jungle-troll.com/2013/01/08/optimizing-wisps-for-android/

Again, please feel free to comment and share your experiences on the matter.