HUD Forge – bars, rings and pips in your palette
Scales 1x to 4x, and a pixel-perfect mode that turns anti-aliasing off entirely. ... Camera.main is a tagged search, and one per bar per frame is what turns thirty ... CHECKED BEFORE IT SHIPS
by Rasterloom
Price History +
Unity 6000.0 or newer. Built-in and URP.
No dependencies. Nothing is added to your project manifest, and no other asset is required.
16 C# scripts, a twelve-page PDF manual and three text documents. 53 kB. Full source, commented throughout.
A saved demo scene is included, built from sprites the generator writes on the spot rather than shipped as art.
Import settings are written for you: Full Rect, no compression, no mip maps, zero extrude, clamped wrap, and the nine-slice borders already in place. A sliced Image or SpriteRenderer simply works.
HUD FORGE
A generator and four small components, not an art pack. Give it a style, ten colours and a bar height; it writes the meter sprites into your project with the nine-slice borders already in their import settings, and the components drive them.
Change one colour and regenerate. The recipe is an asset you keep next to the sprites, so it goes into version control and produces the same bytes again.
- - -
A ROUNDED BAR LOSES ITS END THE MOMENT IT IS NOT FULL
Image.fillAmount fills a bar by clipping it. Clipping a shape with a rounded end cuts that end off square, so a bar that looked right in the mock-up looks wrong at every value the player actually sees. There is no setting for it. fillAmount also does not exist on SpriteRenderer, so a 2D game that is not built on a Canvas cannot use it without writing a shader.
Nothing here clips. The fill is resized. Its ends live in the corner blocks of a nine-sliced sprite, so resizing keeps both at their exact pixel size and stretches only the middle - and the same call works on a RectTransform and on a sliced SpriteRenderer.
Both end styles are generated: rounded at both ends, or square at the leading end for the classic revealed-groove look. Neither can lose its shape, because neither is being cut.
A RADIAL FILL CANNOT KEEP A ROUNDED END EITHER
Unity's radial fill masks by angle. The arc therefore ends square across the band wherever the angle runs out, and it is only exact at multiples of ninety degrees. The usual answer is a shader, which ties the ring to a render pipeline and rules out SpriteRenderer.
So the ring is not filled at runtime. Every step of it is drawn as its own sprite, with the end cap drawn round, and the component picks one. Thirty-two steps by default, eight to a hundred and twenty-eight if you want.
A sprite has no fill mode, no shader and no pipeline. The same ring works on an Image and on a SpriteRenderer, under Built-in and URP, and its ends are right at every value because they were drawn rather than computed.
- - -
WHAT YOU GET
Sprites, each already sliced where slicing applies: a track, a frame and a trail; a fill and a cut fill in health, mana, stamina, xp, shield and danger; vertical versions of all of them, drawn that way rather than rotated; full, half and empty pips for segmented meters; a ring track, a ring frame and every ring step.
Components: Meter drives a bar, with a smooth fill and a delayed trail, on a Canvas or in the world. RadialMeter picks a ring step. SegmentMeter draws pips with halves, swapping sprites and never spawning or destroying. MeterBillboard turns a world-space meter to face a camera you name.
Six styles - Line, Soft, Bevel, Notch, Frame, Ornate - the same six as UI Kit Forge, so a HUD and a menu made with both look like one game. Ten colours. Scales 1x to 4x, and a pixel-perfect mode that turns anti-aliasing off entirely.
- - -
TWO SMALL DECISIONS THAT ARE EASY TO GET WRONG
A segmented meter has to round, and rounding lies twice. A player on one hit point rounds down to an empty bar; a player one hit point short of full rounds up to a full one. Both say the wrong thing about whether the fight is over. So the rounding is clamped at each end.
MeterBillboard takes a camera as a field rather than calling Camera.main. Camera.main is a tagged search, and one per bar per frame is what turns thirty floating health bars into a frame-rate problem - and a scene with a second camera gives you a HUD facing the wrong way in one of the views.
- - -
CHECKED BEFORE IT SHIPS
Every sliced sprite is verified before it is written, and one that fails is not written at all. The same check runs in your project, on your recipe, from the window.
2,674 checks ran over 3,096 sprites during the build of this package - six styles, two palettes, three scales, with and without pixel-perfect - together with a negative control: a sprite is deliberately broken the four ways a hand-drawn one breaks, and the checker is required to catch each. A check that has never failed is not a check.
- - -
WHAT THIS DOES NOT DO
It does not draw illustrated meters. No boiling liquid, no filigree, no glow. Everything here is flat geometry in your colours, because that is what can be generated correctly at any size in any palette.
It is not a health system. Meter has a value and a maximum and it draws them. What damages the player is your code.
It adds nothing to your project manifest and depends on no other asset.
- - -
START HERE
Window > Rasterloom > Build HUD Demo
Press Play. The bars take damage on a loop, so you can watch the leading end stay rounded at every value, the trail fall behind and catch up, and the rings keep their ends at angles a radial fill cannot reach. Everything in that scene is a SpriteRenderer, not a Canvas.
