There’s no built-in function for that, so you have to code it, so it will be slightly more complex than two lines. 
Of course, you can do whatever you want with code. There are any number of ways to do it…you’d need a fading routine for the alpha value of the gui texture, and some variables to tell which direction to fade, how fast, and whether the fade routine should be going.
Well, let’s just do it:
var fadeSpeed : float = 1;
var maxFade : float = 1;
private var opacity : float = 0;
private var isFading : boolean = false;
private var fadeDirection : int = -1;
“fadeSpeed” is pretty self-explanatory…bigger for a faster fade, smaller for a slower fade. “maxFade” will be how much it fades in…1 is 100% opaque, but you could set it to something less. Like .5 if you wanted it to fade in to a max of 50%. The private variables won’t be exposed because they don’t need fiddling with in the inspector. “opacity” will be the current amount of the alpha value at any given time, “isFading” says whether the fade routine should be running, and “fadeDirection” says whether it should fade in or out…-1 would be going down (out) and 1 would be going up (in).
Then we’ll have a start routine, so the code will work if the gui texture is enabled. Right now the variables are set up so the code will work right only if the gui texture is disabled to begin with, so let’s fix that:
if (guiElement.enabled) {
fadeDirection = 1;
}
opacity = guiElement.color.a;
We need an initial value for “fadeDirection”, and since it gets toggled, it should be the opposite of what we’ll want to start out with. We want it to go up for fading in and down for fading out. “opacity” is set to the alpha value of the color, so if you start with the gui texture disabled, you should also set the alpha to 0. Otherwise, the HUD would “sproing” into view the first time instead of fading in. On the other hand, if you start with the gui texture enabled, then the alpha of the color should be set to the same value as “maxFade”.
Then, for the update routine:
if (Input.GetButtonDown("HUDControl")) {
fadeDirection = -fadeDirection;
isFading = true;
guiElement.enabled = true;
}
Check to see if the user hits the HUD control key/button. If so, toggle “fadeDirection” and set “isFading” to be true so the fade routine will run. Also, turn the guiElement on. This part could be omitted, because if you have a 0% opacity, you won’t see the HUD. But my sensibilities say that it should be turned off entirely because that’s a bit faster…if the opacity is 0, it still has to be drawn even if you don’t see anything.
This works so that the user can toggle the HUD while it’s still in the middle of fading in or out. Probably it would be potentially annoying if you waited until it was fully faded in/out before allowing a toggle.
Also in the update:
if (isFading) {
opacity += fadeDirection * fadeSpeed * Time.deltaTime;
If “isFading” is set, then fiddle with the “opacity” value. We want to multiply “fadeDirection” by “fadeSpeed” to either increase or decrease the value, depending on whether “fadeDirection” is 1 or -1, and then multiply by Time.deltaTime so it’s framerate independent.
if (opacity < 0) {
opacity = 0;
isFading = false;
guiElement.enabled = false;
}
Once we’ve changed “opacity”, then check to see if it’s gone below 0. If so, first explicity set it to 0. That’s because it’s possible, depending on the frame rate, for the value to end up enough below 0 that the next time you toggle the HUD and the “opacity += fadeDirection * fadeSpeed * Time.deltaTime;” line runs, it will still be below 0, so it will never fade in again. And that would be bad. Then set “isFading” to false, so the fading routine won’t run the next Update. Finally turn off the guiElement altogether (the reason for that explained above).
if (opacity > maxFade) {
opacity = maxFade;
isFading = false;
}
Now check to see if “opacity” ended up above our “maxFade” value instead, in which case explicitly set the value to maxFade (same reason as setting it to 0), and set “isFading” to false so the fade routine stops. No need to set guiElement.enabled to true, since we already did that when you hit the HUD toggle button.
And finally:
guiElement.color.a = opacity;
That sets the alpha value of the guiElement to whatever “opacity” is this frame.
All together now:
var fadeSpeed : float = 1;
var maxFade : float = 1;
private var opacity : float = 0;
private var isFading : boolean = false;
private var fadeDirection : int = -1;
function Start () {
if (guiElement.enabled) {
fadeDirection = 1;
}
opacity = guiElement.color.a;
}
function Update () {
if (Input.GetButtonDown("HUDControl")) {
fadeDirection = -fadeDirection;
isFading = true;
guiElement.enabled = true;
}
if (isFading) {
opacity += fadeDirection * fadeSpeed * Time.deltaTime;
if (opacity < 0) {
opacity = 0;
isFading = false;
guiElement.enabled = false;
}
if (opacity > maxFade) {
opacity = maxFade;
isFading = false;
}
guiElement.color.a = opacity;
}
}
Sorry. 
If you look at the camera values in the inspector, you’ll see “Normalized View Port Rect”, and four values for that: Xmin, Ymin, Xmax, Ymax. Those set the relative coordinates for, respectively, how far in from the left side to start rendering, how far up from the bottom, how far from the left side to stop rendering, and how far up from the bottom to stop rendering.
So a little square in the top left corner would have values of 0, .7, .2, and 1 (or at least, that results in a square on a 4:3 monitor). So you can have a second camera with those values, and set the Depth to something greater than the depth of the main camera so it appears on top (the default is 0, so have the depth of the main camera be 0 and the depth of the secondary be 1).
You wouldn’t want the minimap camera to be parented to the main camera, because then it would rotate when the player looked up and down and stuff. So you’d just make the camera be a seperate object on its own, and attach this script:
var objectToFollow : Transform;
var distanceAbove : float = 100;
function Update () {
transform.position = objectToFollow.position + Vector3(0, distanceAbove, 0);
}
It doesn’t matter what the position is since the script sets that. But change the rotation so it’s rotated 90 degrees on the X axis and 0 for Y and Z; that way it points down.
Then drag an object from the first person controller (if that’s what you’re using) to the “objectToFollow” slot, and change distanceAbove to whatever value works best for how high up the minimap camera should be.
Of course, that’s pretty quick&dirty. One possible problem is that if the player goes up, the minimap zooms out (and zooms in if the player goes down). But maybe that’s desirable. If not, that’s easy enough to fix, just by using the X and Z values from “objectToFollow” and setting the Y value to something constant.
Oh yeah…and turn the GUILayer off for the minimap or remove it. Otherwise the HUD stuff would show up. I suspect that might be the problem you were running into even with the render to texture method. But this way might be a bit faster (and it works with Indie as well as Pro).
–Eric
