{"id":3511,"date":"2015-03-14T16:06:06","date_gmt":"2015-03-14T15:06:06","guid":{"rendered":"http:\/\/t-machine.org\/?p=3511"},"modified":"2015-03-14T19:50:23","modified_gmt":"2015-03-14T18:50:23","slug":"fix-unity3ds-broken-onmousedown","status":"publish","type":"post","link":"http:\/\/new.t-machine.org\/index.php\/2015\/03\/14\/fix-unity3ds-broken-onmousedown\/","title":{"rendered":"Fix #Unity3d’s broken OnMouseDown"},"content":{"rendered":"

This one has annoyed me for years: Unity’s OnMouseDown has never really worked. (NB: it works perfectly if you make a scene with a single cube; but that is not a game. It breaks completely as soon as you add multiple objects, colliders, etc to a scene)<\/p>\n

The main reason to use a 3rd party engine is to avoid re-inventing the wheel; it’s tragic that Unity can’t even do mouse-input out of the box. Let’s fix it!<\/p>\n

<\/p>\n

The problem<\/h2>\n

OnMouseDown is “supposed to” be invoked on all the Components of a GameObject whenever the player moves the mouse over that GameObject on screen, and clicks.<\/p>\n

In reality:<\/p>\n

    \n
  1. OnMouseDown requires the physics engine. WTF? Yeah, I know: bad design decision right there (*)\n
  2. OnMouseDown conflicts with the physics engine: you cannot have mouse-clicks without having physics objects. Workaround: you use-up some of your limited layers + tags to “isolate” the physics for clicks from physics for reality\n
  3. OnMouseDown randomly decides which GameObject to invoke<\/strong> — this is the Killer Bug. (**)\n
  4. OnMouseDown will only tell ONE GameObject that the mouse has been clicked<\/strong>. If there were multiple objects under the mouse, a RANDOM selection of them will be ignored. — this is the other Killer Bug\n<\/ol>\n

    In addition, there’s some obvious stuff that OnMouseDown needs in order to be useful. Without these, I’ve generally found it about as useful as a chocolate teapot:<\/p>\n

      \n
    1. If the “hit” object is marked as a trigger (i.e. it’s a NON PHYSICAL collider), then mouse clicks ought to “pass through” it to the objects behind. Unity ought to send events to BOTH objects\n
    2. Optionally, the “hit” object should be able to say “I am consuming this mouse click”. This has been standard behaviour for API’s \/ UI’s for decades. It’s disappointing that Unity doesn’t do it.\n<\/ol>\n

      (**) – Educated guess: this is because Physics.RayCast() is so badly named\/designed, and explicitly returns hits in “random” order. This is perhaps so counter-intuitive that even Unity’s internal programmers were confused by it<\/em><\/p>\n

      (*) – my guess is that OnMouseDown was never intended to be used by game developers<\/strong>. Rather, it was a quick hack that someone thought “hey, I could abuse our physics engine, and get a simplistic mouse handler for free! Let’s try it!”. I appreciate the hack; it’s a nice idea. But it’s out of place as the sole implementation for mouse-handling in a production game-engine!<\/em><\/p>\n

      The solution<\/h2>\n

      If you’re not used to fixing Unity, here’s the high-level overview:<\/p>\n

        \n
      1. Implement a Scene-wide hack that runs on Update (because we have to check this every frame!)\n
      2. Use a manual Physics.RayCast from the mouse pointer\n
      3. Check everything<\/strong> along the ray\n
      4. Check in order, starting from the nearest hit<\/strong>\n
      5. Allow each successive hit to optionally consume<\/strong> the hit\n
      6. Deliver to multiple objects\n
      7. For each object, the source code should be the same as OnMouseDown: i.e. you simply write a method with the right name, and everything is automatic\n
      8. Using Reflection, we look for the magic method name on each object\n
      9. When something is hit, don’t just check the object, check it’s parent and grandparents<\/strong>\n