- Home /
uGUI Button without renderer
I need to have a uGUI (new UI) Button that functions without an image, or text, or any kind of visible object on it.
Currently, I can only get a button to work if it has an image or text attached or as a child. Has anyone managed to get this to work, or know if it's even supported?
There is something I don't understand. If the button has no view or visual representation, how are you even supposed to interact with it? I suppose it can work as long as you have the collider, but I think it somehow misses the point. Doesn't it?
The button will be represented by other (separate images). And in some cases the button will be invisible. The player will simply tap anywhere on the screen, or swipe anywhere on the screen.
Previously I achieved all of this with my own button system, that did work off simple colliders and thus didn't need an image. But uGUI buttons don't use colliders.
Could you sketch the idea out? Just a simple quickly made sketch to give a feeling of what you are trying to do. Honestly I'm having a hard time imagining it, therefore I can't really help you.
Answer by AyAMrau · Sep 02, 2014 at 02:49 PM
In the Image component of the object with the Button script, modify the Color field so that the Alpha is 0. This will make the image transparent, but the area occupied by it will still read input.
You could also make a panel with transparent image and use TriggerEvents if you want to read events beyond just button click.
This is the workaround I arrived at. But I'd rather not have to have an extra thing rendered if I don't need it.
It would soon become wasteful to have extra invisible textures.
It's not the prettiest solution, but after trying out different things it seems unless you have something that would actually render, the events pass right through the area.
Did anyone find an alternative to this hack solution? I notice that there is an extra drawcall occurring when rendering a blank texture (toggling the Image enabled checkbox reduces the drawcalls by 1)
On mobile this is an awful solution. It causes overdraw and other performance issues.
Have a look here: http://answers.unity3d.com/questions/801928/46-ui-making-a-button-transparent.html
works perfect
That also seems a bit hacky. This solution works best for me: http://answers.unity3d.com/questions/844524/ugui-how-to-increase-hitzone-click-area-button-rec.html
The API seems to change with every version of Unity, so check your log for obsolete warnings or check the Unity docs (http://docs.unity3d.com/ScriptReference/UI.Graphic.html) for your version of Unity to see which function you should use:
using UnityEngine;
using UnityEngine.UI;
using System.Collections;
using System.Collections.Generic;
public class Hitbox : Graphic
{
protected override void OnFillVBO( List<UIVertex> vbo )
{
vbo.Clear();
}
protected override void OnPopulate$$anonymous$$esh( $$anonymous$$esh m )
{
m.Clear( false );
}
// Unity >= 5.5 ?
protected override void OnPopulate$$anonymous$$esh( VertexHelper vh )
{
vh.Clear();
}
}
Answer by chmodseven · Apr 26, 2015 at 07:10 PM
I'm not sure what the OP's intended goal was, but for me the challenge was that I wanted my button to provide a more generous clickable "hot zone" around the visible sprites layered on it, and without adding to draw calls. First I found that the Color alpha technique above does work, but at the expense of a draw call, since the renderer still treats each invisible Image as an object to draw.
So I used the invisible texture approach also mentioned above (just a small blank texture 32*32 I created in Gimp that was entirely just an alpha channel) to use as my button's Source Image. And by saving it in the same ARGB format as my other sprites, I was then able to pack it into the same atlas as my other UI objects using Sprite Packer, and so achieved my invisible hot zone and did not accrue an extra draw call.
As mentioned, it's not the prettiest solution, but at least there doesn't need to be draw call wastage if you pack the blank texture.
Answer by WickedCube · Dec 05, 2017 at 05:57 AM
An empty text with a raycast target is a better workaround as it does not contribute to overdraw.