Difference between revisions of "Creating HUDs"

From Second Life Wiki
Jump to navigation Jump to search
(Not all HUDs are control panels)
m (Added a note about mesh use in constructing HUDs.)
 
(49 intermediate revisions by 13 users not shown)
Line 1: Line 1:
{{Help |Glossary=*|BugFixes=*}}
{{TOCright}}


[[Image:Attach HUD.png|frame|Right-click an object in inventory and choose '''Attach to HUD''' > ... to make it a HUD]]
This article describes how to create your own HUDs. For basic information about HUDs, see [http://community.secondlife.com/t5/English-Knowledge-Base/Heads-up-displays-HUDs/ta-p/700083 Heads-up displays (HUDs)]


In Second Life, every [[object]] can become a '''[http://en.wikipedia.org/wiki/HUD_%28video_gaming%29 heads-up display]''' ('''HUD''' for short) by attaching it to one of the eight HUD attachment points. Other than objects [[attachment|attached]] to "normal" attachment points, HUDs will not show up on the Avatar's body, but instead on the user's screen. Only the user wearing them can see them, but chat [[:Category:LSL_Chat|emitted]] by them will be visible to other users and other objects.
=== Building and Texturing HUDs ===


== Common Uses ==
It is easiest to keep the root prim rotation at <0., 0., 0.> while building. That way, you can know that the west side of the object will be the one facing the screen when attached. For a box prim, that is [[face]] 4.
HUDs are often used as informational displays (e.g. a sim radar, or a health-meter for inworld combat systems) or as control panels for [[Animation_Override]]s, scripted attachments (e.g. recolorable prim clothes/shoes/hair, animated neko tail/ears) or other devices.


== Scripting HUDs ==
Since an update about 2012 ({{JIRA|SH-2646}}), HUD attachments are always rendered as full bright.
Most scripted functionality works with HUDs, with the following exceptions. (The list is not exhaustive!)


* Particles do not work. Don't have HUD [[prim]]s generate them. If a HUD attempts to generate particles, they appear at <0,0,0> in the current sim, annoying your neighbors.
Prim alpha and texture transparency work as expected. If you want your HUD to be totally transparent, consider making only the front faces that way. The flat projection will keep the other sides hidden, and it will be easier for residents to find the object if accidentally dropped or forgotten on the ground.


* If a sound is triggered using [[llPlaySound]](), only the HUD wearer will hear it. If the land parcel they're over restricts sound entry/exit, the sound will not play.
HUD objects will capture mouse clicks, even on their transparent parts. If you are using a round interface element, a cylinder would not be a bad choice of prim, so it does not use more space than it needs.
** If a sound is triggered using [[llTriggerSound]](), the wearer and any bystanders will hear it.
* The [[Sensor]] will not detect the avatar wearing the HUD.


Scripted movement of HUD pieces is relative to the attachment points. The position vector used by [[llSetPos]]() is interpreted as [DESCRIPTION MISSING!]. A depth of -1 will render in front of a depth of 0.
Shiny works on the HUD, this can help to give an almost-3D appearance to some shapes, like spheres or sculpts. Not everybody enables shiny, so textured shading could still be your best bet.


Since HUD attachments cannot be clicked thru even if they're invisible, the common solutions to getting them out of the way are moving them and shrinking them.
=== Scripting HUDs ===


If you are trying to move the HUD around relative to its current position, use [[llGetLocalPos]]() rather than [[llGetPos]]().
Most scripted functionality works with HUDs. They mostly work like any other attachment, but there are some special exceptions. A page with an [[HTML_HUD_Demo]] can be found on this wiki as well.


example:
==== Differences in behavior ====
* If a sound is triggered using [[llPlaySound|llPlaySound()]], only the HUD wearer will hear it. If the land parcel they're over restricts sound entry/exit, the sound will not play.
** If a sound is triggered using [[llTriggerSound|llTriggerSound()]], the wearer and any bystanders will hear it.
* Like with all attachments, [[llSensor|llSensor()]] will not detect the attachment or its wearer.
* Particles do not generally work. Since Viewer 1.23 there is an experimental debug setting '''RenderHUDParticles''' that you can try, but it is incomplete and switched off by default. On very old viewers (before 1.23) HUD particles would show in world, at (0, 0, 0) globally within the region (the southwest corner). <sup>{{Jira|SVC-2396}}</sup>
* [[Glow]] is not supported on HUD attachments. <sup>{{Jira|VWR-3167}}</sup>
* [[llSetText|llSetText()]] is supported, but be aware that the text does not scale with the HUD or screen size, and the text size is under user control. Despite the limitations, some HUD objects use it to great advantage.
* [[Shared Media]] works on the HUD in Viewer 2.2 and later. On earlier 2.x viewers, clicks and audio may not be available.


<lsl>llSetPos(llGetLocalPos() + (<0.25,0,0> * llGetLocalRot()));</lsl>
==== Differences in coordinates ====
[[Image:HUD-center-coordinates 2.jpg|thumb|300px|HUD center coordinates]]
[[Image:300px-HUD-bottomright-coordinates.jpg|thumb|right|300px|HUD bottom right coordinates]]
HUD attachments are rendered with an orthographic projection, meaning that everything looks flat and there is no perspective. The objects are still 3D, and they can move in XYZ space and be rotated.
* The X coordinate moves away from and toward the wearer, a higher number is farther away and can hide a HUD prim behind others. You can use X changes in a single HUD object to reveal and hide buttons, for one example. There is no good way to grab the red X axis with the viewer editor, but scripts do not have this problem.
* Y moves right to left on the screen; a higher number is more to the left.
* Z moves bottom to top on the screen; a higher number is, well, higher up!


In HUD space, 1 meter is the height of the viewer window, ''including'' the menus and tool bar.  The (0,0,0) position depends on the HUD attachment point. For the Center and Center 2 points, zero is the center of the screen. For the four corner HUD points, zero is that corner of the viewer window. Zero for the top and bottom is centered on the window, again hidden behind the menu or toolbar. There is no way provided to learn the ''width'' of the viewer window, or the pixel dimensions. (The [[FindScreenWidth]] script example can return the display width on touch, if the attachment is on one of the corner HUD slots.)


== Solving problems with HUDs ==
If '''Move & View''' > '''Automatic position for: Sidebar''' is ''checked'', the HUD coordinates will automatically be scaled to exclude the sidebar when it is open. If this feature is ''unchecked'', the entire window width is used regardless. (Some third-party themes may ignore this setting.)


==== HUD is invisible ====
Since standard prim HUD attachments cannot be clicked through even if they're invisible, the common solutions to getting them out of the way are moving, shrinking, or rotating.
This problem arises when the person who made the HUD (or gave it to you) has a screen resolution greater than yours: The HUD is attached at the position that it had on their screen, but that is outside your field of view. The solution is:
# Attach another HUD (one that you know works properly for you).
# Right-click it and select "Edit".
# Zoom out until you can see the other HUD.
# Left-click on the stray and move it back within the white rectangle marking your viewer's screen size. '''Note''': use the arrowheads to move the HUD, clicking on the arrows' tails sometimes drops you out of edit mode.
# Close the Edit window to return to normal viewing.


This will only bring the HUD back into view temporarily. Once you close the HUD and reopen it, the problem will repeat itself.
HUD attachments can be made from mesh in such a way as to have a side that will present no face to the screen when rotated, which allows them to be clicked through. Small buttons can be included in their construction to trigger the rotation.
 
Use [[llGetLocalPos|llGetLocalPos()]] to learn an attachment's position on the screen, [[llSetPos|llSetPos()]] to move it. ([[llGetPos|llGetPos()]] looks tempting, but for attachments that tells us the ''avatar's'' position.)
 
This example moves the HUD away from the wearer, possibly behind other HUD attachments:
 
<syntaxhighlight lang="lsl2">llSetPos(llGetLocalPos() + (<0.25, 0.0, 0.0> * llGetLocalRot()));</syntaxhighlight>
 
 
[[Category:Content creation]]

Latest revision as of 16:55, 27 July 2024

This article describes how to create your own HUDs. For basic information about HUDs, see Heads-up displays (HUDs)

Building and Texturing HUDs

It is easiest to keep the root prim rotation at <0., 0., 0.> while building. That way, you can know that the west side of the object will be the one facing the screen when attached. For a box prim, that is face 4.

Since an update about 2012 (SH-2646), HUD attachments are always rendered as full bright.

Prim alpha and texture transparency work as expected. If you want your HUD to be totally transparent, consider making only the front faces that way. The flat projection will keep the other sides hidden, and it will be easier for residents to find the object if accidentally dropped or forgotten on the ground.

HUD objects will capture mouse clicks, even on their transparent parts. If you are using a round interface element, a cylinder would not be a bad choice of prim, so it does not use more space than it needs.

Shiny works on the HUD, this can help to give an almost-3D appearance to some shapes, like spheres or sculpts. Not everybody enables shiny, so textured shading could still be your best bet.

Scripting HUDs

Most scripted functionality works with HUDs. They mostly work like any other attachment, but there are some special exceptions. A page with an HTML_HUD_Demo can be found on this wiki as well.

Differences in behavior

  • If a sound is triggered using llPlaySound(), only the HUD wearer will hear it. If the land parcel they're over restricts sound entry/exit, the sound will not play.
    • If a sound is triggered using llTriggerSound(), the wearer and any bystanders will hear it.
  • Like with all attachments, llSensor() will not detect the attachment or its wearer.
  • Particles do not generally work. Since Viewer 1.23 there is an experimental debug setting RenderHUDParticles that you can try, but it is incomplete and switched off by default. On very old viewers (before 1.23) HUD particles would show in world, at (0, 0, 0) globally within the region (the southwest corner). SVC-2396
  • Glow is not supported on HUD attachments. VWR-3167
  • llSetText() is supported, but be aware that the text does not scale with the HUD or screen size, and the text size is under user control. Despite the limitations, some HUD objects use it to great advantage.
  • Shared Media works on the HUD in Viewer 2.2 and later. On earlier 2.x viewers, clicks and audio may not be available.

Differences in coordinates

HUD center coordinates
HUD bottom right coordinates

HUD attachments are rendered with an orthographic projection, meaning that everything looks flat and there is no perspective. The objects are still 3D, and they can move in XYZ space and be rotated.

  • The X coordinate moves away from and toward the wearer, a higher number is farther away and can hide a HUD prim behind others. You can use X changes in a single HUD object to reveal and hide buttons, for one example. There is no good way to grab the red X axis with the viewer editor, but scripts do not have this problem.
  • Y moves right to left on the screen; a higher number is more to the left.
  • Z moves bottom to top on the screen; a higher number is, well, higher up!

In HUD space, 1 meter is the height of the viewer window, including the menus and tool bar. The (0,0,0) position depends on the HUD attachment point. For the Center and Center 2 points, zero is the center of the screen. For the four corner HUD points, zero is that corner of the viewer window. Zero for the top and bottom is centered on the window, again hidden behind the menu or toolbar. There is no way provided to learn the width of the viewer window, or the pixel dimensions. (The FindScreenWidth script example can return the display width on touch, if the attachment is on one of the corner HUD slots.)

If Move & View > Automatic position for: Sidebar is checked, the HUD coordinates will automatically be scaled to exclude the sidebar when it is open. If this feature is unchecked, the entire window width is used regardless. (Some third-party themes may ignore this setting.)

Since standard prim HUD attachments cannot be clicked through even if they're invisible, the common solutions to getting them out of the way are moving, shrinking, or rotating.

HUD attachments can be made from mesh in such a way as to have a side that will present no face to the screen when rotated, which allows them to be clicked through. Small buttons can be included in their construction to trigger the rotation.

Use llGetLocalPos() to learn an attachment's position on the screen, llSetPos() to move it. (llGetPos() looks tempting, but for attachments that tells us the avatar's position.)

This example moves the HUD away from the wearer, possibly behind other HUD attachments:

llSetPos(llGetLocalPos() + (<0.25, 0.0, 0.0> * llGetLocalRot()));