'Image' overlays are always layered over 'text' overlays


They should be layered in order of creation. As you can see in this pic, these are 2 separate windows. The logo window was created first, and the login window was created last yet the logo image appears layered over the login window.


This is blocking me now as well. Would love to be able to layer text over images for hud panels and the like.


If it’s at least consistently-opposite of your expectations then you could create an appropriate number of placeholder overlays upfront – and then withdraw from the bottom of that deck to achieve a logical display ordering.

Also 3D Overlays like image3d/text3d/cube/sphere/model (and some others) have some interesting settings to consider, even if you have to do more math to use as-if 2D panels:

drawInFront: true
drawOnHUD: true
isFacingAvatar: true
ignoreRayIntersection: true


Images are always over text overlays no matter what. I tried that.


Hmm then.

How about leveraging WebWindows? I realize that isn’t ideal here, but did you know it’s possible to both dynamically position and size them after creation via scripting? There are also size and position signals that get fired if the user moves them around.

And it might just be possible now to roll your own 2D compositing layer from scripting – like generate an SVG (which is just XML text) or PNG (using a hidden WebWindow HTML5Canvas) and then upload/reflect the image into an Overlay using an Asset mixer atp:// URI. Either of those options if successful would likely provide you with superior font support too – more choices, styles, anti-aliasing, effects (like drop shadows), wider unicode, etc.

There’s also OverlayPanel’s, which at least sound relevant, but I haven’t looked much into them. To quickly see what other methods are lurking around you could type print(Object.keys(Overlays).join("\n")) from the script console.


The only thing I would use webwindows for are passwords. They won’t work too well with HMDs.

There’s really no reason to go through all that trouble when overlays could just be fixed to work well. I am sure they will look them over at some point to fix them. Really the bugs are just minor annoyances at this point.


Speaking of which, never use overlays for passwords because it is way too easy to capture keys without the user knowing. Use webwindows for that.


My latest merge introduces a new JS function OverlayWebWindow. It has the exact same API as WebWindow, but the web content is contained in a dialog on the overlay, so you can use it in the HMD. If you try the latest build you should notice that the Directory button (created by directory.js) now loads inside the app.

There is a PR in the pipeline to do the same for the marketplace window, and eventually the entity editing UI will be migrated as well. Right now this adds functionality for HMD users, although it reduces it for multi-monitor 2D users who like dragging stuff to other monitors (I fall into both categories). Eventually I’d like us to get to a point where if you’re in an HMD, elements appear inside the overlay, while if you’re not, they appear as windows on the desktop, without any code change required on the JS author. Not quite there yet though.

As for the Z-order of the overlays, I’m going to be honest: trying to build a good, cohesive UI out of the primitives we have available in the overlays is probably not possible, and is likely never going to be possible. Any serious UI library is either result of man-decades of design and implementation or is simply a wrapper resting upon same. If you want to be able to build a UI you can present to users, it’s probably going to have to be HTML or QML (support for QML UI launched from a script should be coming soon…ish).

I did float the idea of embedding a full Android instance inside of High Fidelity so that content developers could take advantage of android development tools to build UI and logic, but I’m pretty sure that if I weren’t a remote developer, I’d have been severely beaten and left for dead in a ditch somewhere.