fading two canvases simultaneously.

[JimWebs]

I’m doing this:

 canvas1.GetComponent<CanvasGroup>().alpha = 0.0f;
infobox_Canvas.GetComponent<CanvasGroup>().alpha = 0.0f;
  
   while (canvas1.GetComponent<CanvasGroup>().alpha <1)
{
   canvas1.GetComponent<CanvasGroup>().alpha += fadespeed * Time.deltaTime;
   infobox_Canvas.GetComponent<CanvasGroup>().alpha += fadespeed * Time.deltaTime;
 
    yield return null;
}

The problem is, canvas one fades in fine, but the box which display my information as an inset overlay doesn’t fade it at the same time or speed, it takes forever after canvas1 has faded in. ??? Any ideas why?

[Kurt-Dekker]

Generally don’t read from properties like .alpha. The reason is there’s absolutely no guarantee you get back the same number you put into it. This will profoundly break any notion of how fast you advance the number if you put in 0.12 and it gives you back 0.11, for instance.

Just keep your own notion of fadedness and drive it.

Fading, simple and easy:

How can I fade in/out a canvas group alpha color with duration time ?

Don't use Mathf.Lerp(). Use Mathf.MoveTowards(). And definitely DO NOT USE COROUTINES (see my post above). make some member variables: private float desiredAlpha; private float currentAlpha; The work: void Update() { currentAlpha = Mathf.MoveTowards( currentAlpha, desiredAlpha, 2.0f * Time.deltaTime); } Now, wherever you need to set fadedness of any object, use currentAlpha. colorProperty.a = currentAlpha; When you want to change fadedness, only set desiredAlpha equal to 0 or 1…

ALSO, watch out for the crazy ninja GetComponent nuttiness. That’s always a recipe for disaster.

Keep in mind that using GetComponent() and its kin (in Children, in Parent, plural, etc) to try and tease out Components at runtime is definitely deep into super-duper-uber-crazy-Ninja advanced stuff.

This sort of coding is to be avoided at all costs unless you know exactly what you are doing.

Botched attempts at using Get- and Find- are responsible for more crashes than useful code, IMNSHO.

If you run into an issue with any of these calls, start with the documentation to understand why.

There is a clear set of extremely-well-defined conditions required for each of these calls to work, as well as definitions of what will and will not be returned.

In the case of collections of Components, the order will NEVER be guaranteed, even if you happen to notice it is always in a particular order on your machine.

It is ALWAYS better to go The Unity Way™ and make dedicated public fields and drag in the references you want.

OTHERWISE, just the usual debugging steps, applicable to ALL code:

Time to start debugging! Here is how you can begin your exciting new debugging adventures:

You must find a way to get the information you need in order to reason about what the problem is.

Once you understand what the problem is, you may begin to reason about a solution to the problem.

What is often happening in these cases is one of the following:

• the code you think is executing is not actually executing at all
• the code is executing far EARLIER or LATER than you think
• the code is executing far LESS OFTEN than you think
• the code is executing far MORE OFTEN than you think
• the code is executing on another GameObject than you think it is
• you’re getting an error or warning and you haven’t noticed it in the console window

To help gain more insight into your problem, I recommend liberally sprinkling Debug.Log() statements through your code to display information in realtime.

Doing this should help you answer these types of questions:

• is this code even running? which parts are running? how often does it run? what order does it run in?
• what are the names of the GameObjects or Components involved?
• what are the values of the variables involved? Are they initialized? Are the values reasonable?
• are you meeting ALL the requirements to receive callbacks such as triggers / colliders (review the documentation)

Knowing this information will help you reason about the behavior you are seeing.

You can also supply a second argument to Debug.Log() and when you click the message, it will highlight the object in scene, such as Debug.Log("Problem!",this);

If your problem would benefit from in-scene or in-game visualization, Debug.DrawRay() or Debug.DrawLine() can help you visualize things like rays (used in raycasting) or distances.

You can also call Debug.Break() to pause the Editor when certain interesting pieces of code run, and then study the scene manually, looking for all the parts, where they are, what scripts are on them, etc.

You can also call GameObject.CreatePrimitive() to emplace debug-marker-ish objects in the scene at runtime.

You could also just display various important quantities in UI Text elements to watch them change as you play the game.

Visit Google for how to see console output from builds. If you are running a mobile device you can also view the console output. Google for how on your particular mobile target, such as this answer for iOS: How To - Capturing Device Logs on iOS or this answer for Android: How To - Capturing Device Logs on Android

If you are working in VR, it might be useful to make your on onscreen log output, or integrate one from the asset store, so you can see what is happening as you operate your software.

Another useful approach is to temporarily strip out everything besides what is necessary to prove your issue. This can simplify and isolate compounding effects of other items in your scene or prefab.

If your problem is with OnCollision-type functions, print the name of what is passed in!

Here’s an example of putting in a laser-focused Debug.Log() and how that can save you a TON of time wallowing around speculating what might be going wrong:

Coroutine missing hint and error

This is so unnecessary. Use the beauty and power of instantly and immediately putting a Debug.Log() statement into the very start of the coroutine, right at the top. Do this always at the very first sign of trouble or question in your mind. The instant you did this you would see “Oh man, this code is simply not getting run!” And you could LASER-FOCUS 100% your efforts on studying what you expect to run it, eg., the call location, and isolate why it is not running. You would look at literall…

“When in doubt, print it out!™” - Kurt Dekker (and many others)

Note: the print() function is an alias for Debug.Log() provided by the MonoBehaviour class.

[JimWebs]

Thanks. Still trying to find a way to apply this to my needs, having a specific image fade in and stop fading if fade is interrupted.

[spiney199]

What they’re saying is rather than checking the alpha of canvas1, just loop a float from 0 to 1.

Also you really don’t need to be using GetComponent every single time you need to access a value. Just cache it and use that.

var group1 = canvas1.GetComponent<CanvasGroup>();
var group2 = infobox_Canvas.GetComponent<CanvasGroup>();

float a = 0f;

while (a < 1f)
{
    a += fadespeed * Time.deltaTime;
    group1.alpha = a;
    group2.alpha = a;
   
    yield return null;
}

group1.a = 1f;
group2.a = 1f;

Way cleaner.

[zulo3d]

Is it possible that one of your canvas groups is a child of the other and as a result it’s already being faded with the parent and so fading it again just results in the child fading much faster than the parent?.

[JimWebs]

@spiney199

What they’re saying is rather than checking the alpha of canvas1, just loop a float from 0 to 1.

Also you really don’t need to be using GetComponent every single time you need to access a value. Just cache it and use that.

var group1 = canvas1.GetComponent<CanvasGroup>();
var group2 = infobox_Canvas.GetComponent<CanvasGroup>();

float a = 0f;

while (a < 1f)
{
    a += fadespeed * Time.deltaTime;
    group1.alpha = a;
    group2.alpha = a;
  
    yield return null;
}

group1.a = 1f;
group2.a = 1f;

Way cleaner.

Thanks for this

[JimWebs]

@JimWebs

Thanks for this

@zulo3d

Is it possible that one of your canvas groups is a child of the other and as a result it’s already being faded with the parent and so fading it again just results in the child fading much faster than the parent?.

I think that was the case, but I have other problems now so I’ll have to find another way of doing what I wanted. Spiney’s way of doing it looks good.