How would you go about fading out an object (for example making an object more transparent as the camera gets closer to it so that you can see through it)?
I read somewhere that you can set the Shader of the materials to Transparent/Diffuse but that does not work cause then I see right through the character in many spots so there has to be another solution? I also tried iTween which didnt work at all.
I get aliasing when using any “Transparent” shader-modes. When it’s fully non-transparent I still see right through the character on some areas of the texture. I want the object to fade from fully visible to invisible using scripting.
Youre using the built in GUI class there and thats not what im after. Also I dont want to fade based on time but based on distance.
Probably not, what he wants is for the character to fade when the camera is close, so that he doesn’t get low end cutoff of polygons. “Seeing through a character” in his eyes is actually cutting the geometry on the minimum view pane.
You’re running into the classic transparency sorting problem, which is highly non-trivial. Even AAA commercial games have transparency sorting glitches, they just try to hide it (usually by not using transparency as much as possible). To minimize it, you should use a non-transparent shader when the object doesn’t need to fade, switch to transparent when fading. and switch back when not fading. Also it’s better for performance to not use transparency when you don’t need to.
Okay so how can I change the shader and the alpha of it during runtime (with C#)? The character is built of a hierarchy. The “root” only has a transform, animation and character controller nodes as well as the scripts applied to it. It’s child has the actual Skinned Mesh Renderer node and the textures. How can I access these so I can change them?
Once you have a reference, you can access the material… gameObject.renderer.material (Check the docs for detail and feel free to ask questions if you can’t sort it out)
If you use sharedMaterial all objects with the material will change (because you are changing the ‘source’ material, not the instance on each object. This way, (assuming you have an atlased character where all child objects use the same material but it isn’t shared with other 'characters) you only need to set it once to get everything to fade.
The best way to get access though, is to add a reference in your script and drag and drop in the inspector:
Material fadeMtl;
Switching shaders on the material, when you get close, sounds like a good solution. Some shaders don’t need to use alpha, you can fade the base color from white to black. Check out the new(?) Mobile/Particle/Add… (I forget the actual name…something about culling back-faces though). This might give you an interesting effect if it fits your game’s look.
I think you guys are over thinking this a bit too much.
What I would do is I would have an animation for the object called “FadeOut” and “FadeIn” and then just have a variable isCloseToCamera. The fade out and fade in animations will not fade completely out, just half way or three quarters, using Unity’s animation system. You’ll want to animate GameOblect.renderer.material.color.a (which stands for color.Alpha)
And then if isCloseToCamera, then play “FadeOut”, or else if not isCloseToCamera, play “FadeIn”.
In Javascript, it would look like this:
function Update ()
{
if (isCloseToCamera)
{
FadeOut();
}
else
{
FadeIn();
}
}
function FadeOut ()
{
animation.CrossFade ("FadeOut");
}
function FadeIn ()
{
animation.CrossFade ("FadeIn");
}
Always cache references in Awake() if possible. This searching/find stuff can be expensive and you don’t want your game to lag
You can iterate through children using (C#) foreach (Transform child in <any transform>) {...}
You shouldn’t need to if your textures are setup correctly (assuming you don’t have atlasing issues). Simply store a reference to the material (and cache the shaders in Awake), then all you need to do is switch when the camera gets close and set the alpha based on the distance.
So you need:
A) Awake() for caching variables so you can find stuff only at game start (I assume the model is in the game at the start)
B) Something to trigger all this: You might try a collider on an empty game object (that is a child of the model that needs to fade). The collider, set to trigger, can detect when the camera enters it, this way it is passive and you can use the OnColliderEnter and Exit functions to trigger the shader switch.
C) When you trigger the shader switch, also turn on a boolean variable such as bool isFading then start a coroutine to handle the actual distance detection and fading. Set it to quit when isFading becomes false (which should be triggered by the camera leaving the collider)
If you don’t know how to do any of this, it would be excellent to run through it as a learning experience. This is all standard stuff you should know and is fairly easy to research online. Of course I, and others, won’t mind helping if you take the first step.
I always forget about this nice feature in Unity (recently started to learn Unity).
SomeGuy22:
I have no experience with any 3d Applications (im a programmer) so I’m just using a finnished character that I got from a tutorial so I cant modify and create any fade animations.
Rafes:
I’m an intermediate C++ programmer but im new to the Unity scripting “architecture” and C# syntax as well as the whole “scripting” conecept in general. Im studying game programming at University (only first year completed) and we have only used “text based” engines like HGE, SFML…not IDE’s like Unity, UnrealEngine where you have to think a little different (we will do this during our next game project).
Also I managed to get the fading to work as I wanted it to be. Next step is to switch from my 3rd person camera to a FPS camera when the distance between the character and camera is very small, for example when the characters back is towards a wall and camera is behind it (the camera takes collision/occlusion into consideration). This is something I wont do right away, cause I imagine the whole system will break if I suddenly start changing the camera without taking lots of stuff into consideration.
Glad you got it working. I would still consider using a collider even for the camera switch. They are great because you don’t need anything to run every frame. They just sit there until something enters or exits, then they trigger an event you can use. Just wait for OnTriggerEnter to be called then start a coroutine to LERP your 3rd person camera to the center of the head and switch to the FP camera at x% to destination.
You could even use a second collider for the camera switch I suppose, that way if you want to adjust the behavior, you can edit the size and position of the collider and your code need not change.