I just created an particle system where you see a blinking add-icon. The problem is that if something gets behind the particle system, it gets transparent and I dont know why. I read that changing the shader could fix it, but it didnt work. I tried every shader in "Particles/..."
Here you how it looks like:
I seems that your object doesn't get transparent, but rather that it is being covered by the other object even though it should be in front of it.
Sorting is a common problem with objects that use some sort of blending:
In this case this is probably due to the other object being in a ui element. You could try to enforce the draw order by modifying the render queue in the material, or force it to use depth testing by using an alpha cutout shader instead (but its edges will not look as nicely anti-aliased without an extra MSAA or FXAA)
Related
I just started using URP in Unity for a game in progress. I'm doing a sort of sprites-in-3d thing, so I'm rendering some sprite sheets on quads. To do this, I create a Material with the sprite sheet and use tiling/offset to render the proper frame of animation by making a call like:
CombatMaterial?.SetTextureOffset("_BaseMap", new Vector2( (AnimationDefinitions[animationDefinition] % 16) * .0625f, CombatMaterial.mainTextureOffset.y));
I'm currently trying to add some feedback into my game for when characters use abilities or get hit by flickering the material. Because the base color starts at white and goes to black, that won't really work; the only other thing I seem to have available to me is emission, which looks great. Using a 0xAAAish color achieves the effect I'm looking for. I've been using the Feel Unity asset to do this, but I've also attempted using something like this:
CombatMaterial?.SetColor("_EmissionColor", Color.white);
The problem is, once I've set the _EmissionColor, the main texture offset no longer updates in game, thereby ruining all animations. If I change the texture offset manually through the inspector at runtime, animations don't work AND the _EmissionColor flickering stop working. If I mess around with the color of the _BaseMap in the inspector, _EmissionColor flickering starts working again.
Before I start diving into some unsightly color adjustments in an attempt to make this work again, I would love to know if I'm doing something that is simply unsupported by URP/Materials/whatever, or if there is some alternative to what I'm doing that's a little more straightforward.
Thank you!
After trying a bunch of random stuff, I don't have a "real" solution, but the game IS working how I want it to.
What worked for me was setting the _EmissionColor on the Material to (1,1,1). For some reason, when the _EmissionColor is set to (0,0,0) it's a black (ha) hole and won't accept future changes to the _EmissionColor. I assume this is some shader nonsense (with the base Lit Shader that URP uses) that I am clearly unfamiliar with.
Hopefully this helps anyone doing something as pointlessly against the grain as I am!
I made an endless runner game where the horse runs in a canyon. So i noticed that in the walls makes shadows on theirselves so i wanted to remove it beacuse it's ugly. So my problem comes here, how can i remove that shadow even if i disabled the shadow casting from the mesh renderer of that walls? I also tried to place a light point near the walls but it still don't work. How can i resolve this. I attach a photo so you can understand what i am talking about.
Picture
Those are most likely just objects interacting with a directional light in the scene. Instead of shadows, those are just sides of objects that as less illuminated.
I can throw in two potential solutions:
Solution1:
Go to Window->Rendering->Lighting, select Environment, change the Environment Lighting Source value and modify the color values to your liking.
Solution2:
Add a material which changes how the objects interact with lighting. One option could be to just add a standard material with some emission.
I'm using Unity 2020.1.3f1's URP, with the new 2D renderer system.
As of right now, I have objects that change between the built in "Sprite-Lit-Default" material, and a material with the custom built pixel outline shader detailed here: https://danielilett.com/2020-04-27-tut5-6-urp-2d-outlines/
This worked well and good, but I recently added lights, and a normal map to my sprites as a secondary texture in the import settings. The default lit texture has no problems displaying the normal map, but when I attempted to modify my shader graph to include the normal map, it doesn't import like the sprite texture does when _MainTex is set as the reference.
I've tried _NormalMap (which is the name of the secondary texture in the importer!) as well as _NormalTex, but it always ends up not importing the normal map. I even attempted changing _MainTex to a Texture2D, but given that kept sparking an error, I didn't think it was the right way to go about it. (This one to be specific.)
Error assigning 2D texture to 2DArray texture property '_MainTex': Dimensions must match
UnityEditor.EditorApplication:Internal_CallUpdateFunctions()
Am I missing something here? All the tutorials I can find online only show people dragging the normal map in through the inspector, but this material is going to be used by many different sprites, so that seems...counterintuitive.
On top of this, the default material/shader has no issues with this, so I feel like I'm either missing something, or I'm going to end up having to code my sprites to change material through code instead of the animator, just for this small, annoying quirk..
Blackboard Properties, and nodes. This just goes into the normals input.
Inspector panel showing the missing normal map slot.
And the Secondary Textures in case I somehow misnamed it, why not?
(EDIT)
So, an update on this, for anyone else who runs into this same issue.
I managed to find a section of the shadergraph documentation that seems to be the only part talking about this:
It is required to name the reference for MainTex as _MainTex to render Sprites. It is also recommended to name the references for Mask as _MaskTex and Normal as _NormalMap to match the Shader inputs used in this package.
So from what I gather from that, _MainTex is the only one that's automatic in ShaderGraph.
After a full day of looking up tutorials, I've noticed that every single one of them simply set the normal map and extra textures as the default textures so they'll show up without being assigned manually.
I think this is possible with hand-written shaders, but I've decided to just go with a simple unlit shadergraph on a hand-drawn sprite outline, displayed on a separate gameobject parented to the main object.
I'm not posting this as an answer in case someone else finds a solution to it in the future, and since this isn't...really a solution in my eyes.
I don't know if you have figured this out yet but I'll try to answer since I had the same problem. Create a new Texture2D node, convert it to a property, and have the reference as _NormalMap, connect that to the sample texture 2D node as normal, and plug that into the sprite lit master. Now go into the sprite editor, assign the normal maps as a secondary texture, and make sure the name is the same as in your shader, _NormalMap (or something else, as long as it's the same). This currently has worked for me, shader graph detects the normal map texture by reference automatically. Attached below are some images to help and the finished result on the character sprite, which uses a custom shader I picked up from a tutorial and added the normal map to.
Shader Graph Sprite EditorSprite Editor 2 Normal Map result
I am new to Unity and having problems with the textures. Whenever I import a texture and apply it to the terrain it doesn't look the same, sometimes it's for example way too dark and sometimes it's way too shiny. Here is an example:
I have been googling for a while without finding much about it, does someone know what is causing this and how I can fix it?
The reason for this, I expect, is because you are just dropping a texture image onto an object without changing anything. By default, this will create a new material asset, which is what is actually added to the object.
Look up Materials if you don't already understand how they work. The default settings are the Metallic slider at 0 and the Shininess slider at 0.5. Obviously these settings need to be changed depending on the texture, as not every texture is going be a non-metallic, kind of shiny substance.
It is also in these settings that you can add things like Normal Maps, Bump Maps, etc, to make them look more realistic.
Reasons for it being too dark might simply be that the your lighting isn't reaching that particular surface. In order to have a global light source, add a Directional Light to your scene.
In OpenGL which one would result in a better performance. To change the culled face or to rotate my object?
The scenario is the following:
I compute the matrix to feed into my shaders, this will draw texture A in a certain culling position (front). When I see the object from infront i can see it, but from behind i cant, this is my desired behavior. Now i would like to add "something" behind, lets say texture B, so that when the object is seen from behind this other texture will appear in the same position and orientation as was the texture A but now with texture B.
I thought that other than building a cube with 2 sides i could simply "redraw on top" of my previous object. If i were to rotate the object i suppose I can assume that OpenGL will simply not overwrite texture A since it will not pass the face culling test. This require one extra matrix multiplication to mirror mi object on its own axis. However what if i simply change the culling property and try to draw it? Wouldn't it have the same effect of failing the text from infront but passing it from behind?
Which of these 2 options is better?
(PD: I am doing this on the iPhone so every single bit of performance is quite relevant for older devices.)
Thank you.
I'm not sure if I understood you correctly, but it sounds like you are trying to draw a billboard here? In that case, you should disable backface culling altogether and in your fragment shader check gl_FrontFacing. Depending on this, you can flip your texture coordinates and change your texture (just bind both textures and send them to the shader). This way you have only one draw call and don't have to do any strange tricks or change the OpenGL state.