I have a weird line in the left of my grass texture I've looked far and wide, no solution works
Picture:
See that weird light green lines popping up near other grass? That's it too. Kinda hard to see on the grass right there, but the grass around it also has the lines The trees are black because my laptop is very slow and is still processing lighting I've tried:
Setting Wrap Mode to Clamp
Setting Filter Mode to Point
Made it 16 bit, which made the background a solid color
Turned off mipmapping, and played around with some of it's settings
and probably others i forget here, since i've been trying to fix this for so long' also, i tried this out on a different terrain and when there is no other detail meshes, there is no line, but if there is, there's a line also, that's the only grass texture and every other detail mesh is a 3D object and rendered as "Vertex Lit" instead of grass, so I don't know if those meshes can bleed into my grass texutre, like other posts have mentioned.
Tried just about every solution ive found on many pages of google, like the ones i listed above with playing around with the grass texture and the terrain. Nothing worked.
Other pictures of grass also had this bug
Original picture of grass as a png:
Check the texture itself, it seems to follow the texture of the grass and looks as though the line is actually in the texture. In which case, use a photo editing tool like GIMP to remove it.
Related
The attached picture sums it up. On the right is what I want. On the left is what I get. The colors are wrong. (left face image is from a captured screenshot from the game running in Unity. right face image is me pasting the correct art on top of the screenshot for comparison's sake)
The code I'm calling from OnGUI() to overlay the face image:
GUI.DrawTextureWithTexCoords(toRect, texture, fromRect);
The texture in question comes from a 1024x1024 PNG saved from Photoshop. This PNG has the right colors in it when I open it, but not when DrawTextureWithTexCoords renders it to screen. I've experimented with different Photoshop export settings and texture import settings, but to no avail. It would be nice if I missed something there, but I seem to have run out of knobs to twiddle.
For troubleshooting purposes, I dragged the texture into the scene, applying it as a material to a surface of a mesh. The texture displayed with correct, original colors on the mesh. (Note - this is not the thing I'm trying to do. I need the texture to appear in GUI, not in-scene.)
There is no code that I know of that is processing the texture or doing something that would affect the rendering. I tried turning off my post-processing as a test, but it doesn't affect GUI.
This is running Unity 2019.1.13f1 on a 2015 IMac. I've also included a shot of the Inspector on the texture import settings below. And the almost original texture PNG (watermark added).
How can I get the face art to render with the correct colors?
I found a solution. Answering my own question for posterity's sake.
I replaced the original code:
GUI.DrawTextureWithTexCoords(toRect, texture, fromRect);
...with:
Graphics.DrawTexture(toRect, texture, fromRect, 0, 0, 0, 0);
This fixed the issue. The code above is called from OnGUI(), and behaves exactly like the original code but with corrected colors.
#Erik Overflow, in addition to other helpful comments, pointed out that OnGUI() is called many times per frame. So I'll consider refactoring the above to a call from OnPostFrame() for the sake of performance.
How do I remove this "giggly" effect when slowly moving a sprite?
I have tried adjusting Antialiasing values in QualitySettings and Filter Mode in ImportSettings in the Unity Editor but that doesn't change anything.
Ideally, I would like to keep the Filter Mode to Point (no filter) and anti aliasing turned on to 2x
The sprite is located inside a Sprite Renderer component of a GameObject.
I have uploaded my Unity Project here: http://www.filedropper.com/sprite
I really don't know how to fix the problem... Can anyone help with my personal project?
I cooked up a quick animation to demonstrate what's happening here:
The grid represents the output pixels of your display. I've overlaid on top of it the sliding sprite we want to sample, if we could render it with unlimited sub-pixel resolution.
The dots in the center of each grid cell represent their sampling point. Because we're using Nearest-Nieghbour/Point filtering, that's the only point in the texture they pay attention to. When the edge of a new colour crosses that sampling point, the whole pixel changes colour at once.
The trouble arises when the source texel grid doesn't line up with our output pixels. In the example above, the sprite is 16x16 texels, but I've scaled it to occupy 17x17 pixels on the display. That means, somewhere in every frame, some texels must get repeated. Where this happens changes as we move the sprite around.
Because each texel is rendered slightly larger than a pixel, there's a moment where it completely bridges the sampling points of two adjacent pixels. Both sampling points land within the same enlarged texel, so both pixels see that texel as the nearest one to sample from, and the texel gets output to the screen in two places.
In this case, since there's only a 1/16th scale difference, each texel is only in this weird situation for a frame or two, then it shifts to its neighbour, creating a ripple of doubled pixels that appears to slide across the image.
(One could view this as a type of moiré pattern resulting from the interaction of the texel grid and the sampling grid when they're dissimilar)
The fix is to ensure that you scale your pixel art so each texel is displayed at the size of an integer multiple of pixels.
Either 1:1
Or 2:1, 3:1...
Using a higher multiple lets the sprite move in increments shorter than its own texel size, without localized stretching that impacts the intended appearance of the art.
So: pay close attention to the resolution of your output and the scaling applied to your assets, to ensure you keep an integer multiple relationship between them. The blog post that CAD97 links has practical steps you can take to achieve this.
Edit: To demonstrate this in the Unity project you've uploaded, I modified the camera settings to match your pixels to units setting, and laid out the following test. The Mario at the top has a slightly non-integer texel-to-pixel ratio (1.01:1), while the Mario at the bottom has 1:1. You can see only the top Mario exhibits rippling artifacts:
You might be interested in this blog post about making "pixel-perfect" 2D games in Unity.
Some relevant excerpts:
If you start your pixel game with all the default settings in Unity, it will look terrible!
The secret to making your pixelated game look nice is to ensure that your sprite is rendered on a nice pixel boundary. In other words, ensure that each pixel of your sprite is rendered on one screen pixel.
These other settings are essential to make things as crisp as possible.
On the sprite:
Ensure your sprites are using lossless compression e.g. True Color
Turn off mipmapping
Use Point sampling
In Render Quality Settings:
Turn off anisotropic filtering
Turn off anti aliasing
Turn on pixel snapping in the sprite shader by creating a custom material that uses the Sprite/Default shader and attaching it to the SpriteRenderer.
Also, I'd just like to point out that Unless you are applying Physics, Never Use FixedUpdate. Also, if your sprite has a Collider and is moving, it should have a Kinematic RigidBody attached even if you're never going to use physics, to tell the engine that the Collider is going to move.
Same problem here. I noticed that the camera settings and scale are also rather important to fix the rippling problem.
Here is What Worked for me:
Go to Project Settings > Quality
Under Quality Make the default Quality as High for all.
Set the Anistropic Texture to "Disabled"
Done, And the issue is resolved for me.
Image Reference:
enter image description here
Ok ill get straight to the point, here is an image of what i want to achieve:
And here is an Image of what my game looks like:
What I'm referring to is how the tiles seamlessly "connect". As you can see, on the first image there is a slight fade from one tile to the next one, for example where the sand and grass meet. On the second image, my game, there is not fade and no transition and it looks very bad. Like when the grass changes colors, there is no fade/filtering.
I assume this is a fairly common problem, so is there any assets from the asset store that solve this problem, or any built in solution within Unity? (Without writing own own custom script, of course) If there isnt any, how do I go about creating this filtering/transition between the tiles?
I suggest you to draw them on your own in some software and then importing it in Unity, other way to do it is to make them overlay where the transition is and put 50% opacity on both layers just where they are overlaping, this will give you small effect of transition.
I have little experience in writing a simple games on XNA, but now i dont have knowns to solve my problem.
So, i want to write simple racing 2d-arcade, and i dont know how i can do maps for this game.
I decided do this so:
I draw a picture-map in mspaint. Black - its grass, white color -
its road, red color - road markings, blue - water, green - forest,
etc.;
After the image is loaded, I override textures in XNA - on white
color i place texture of road, on black color i place texture of
grass and etc.
So i have 2 questions.
I think in the right direction?
How i can to know color in desired pixel and how i can pour all white color, not each pixel separately? Second question not required, because i can just do second image with normal textures, and place this on second layer, right?
Sorry for really bad english. And thanks for answers advance.
In MSDN forums, man with the nickname Mad Martin adviced do so:
Draw the final picture in paint with the mixture of textures like you
want it on the screen. Draw this texture directly. Now you'r game
logic needs to know where the road is in that texture. There are two
ways i can think of:
Make the road a spline and calculate the exact layout of the game. Probably a bit steep for beginners, but the most powerful.
Make a separate texture like yours with just two colors(black no road, white road). You can then check via the coordinates of the cars
whether you are on the road or not. You can do this either on the CPU,
by readign the texture into an array with Texture2D.GetData, or you
can do this on the GPU. Either way needs a little fiddling around, so
your cars dont hang on the edges of the road.
i think that it's quite useful answer, so i close question.
I am making an RPG game using an isometric tile engine that I found here:
http://xnaresources.com/default.asp?page=TUTORIALS
However after completing the tutorial I found myself wanting to do some things with the camera that I am not sure how to do.
Firstly I would like to zoom the camera in more so that it is displaying a 1 to 1 pixel ratio.
Secondly, would it be possible to make this game 2.5d in the way that when the camera moves, the sprite trees and things alike, move properly. By this I mean that the bottom of the sprite is planted while the top moves against the background, making a very 3d like experience. This effect can best be seen in games like diablo 2.
Here is the source code off their website:
http://www.xnaresources.com/downloads/tileengineseries9.zip
Any help would be great, Thanks
Games like Diablo or Sims 1, 2, SimCity 1-3, X-Com 1,2 etc. were actually just 2D games. The 2.5D effect requires that tiles further away are exactly the same size as tiles nearby. Your rotation around these games are restricted to 90 degrees.
How they draw is basically painters algorithm. Drawing what is furthest away first and overdrawing things that are nearer. Diablo is actually pretty simple, it didn't introduce layers or height differences as far as I remember. Just a flat map. So you draw the floor tiles first (in this case back to front isn't too necessary since they are all on the same elevation.) Then drawing back to front the walls, characters effects etc.
Everything in these games were rendered to bitmaps and rendered as bitmaps. Even though their source may have been a 3D textured model.
If you want to add perspective or free rotation then you need everything to be a 3D model. Your rendering will be simpler because depth or render order isn't as critical as you would use z-buffering to solve your issues. The only main issue is to properly render transparent bits in the right order or else you may end up with some odd results. However even if your rendering is simpler, your animation or in memory storage is a bit more difficult. You need to animate 3D models instead of just having an array of bitmaps to do the animation. Selection of items on the screen requires a little more work since position and size of the elements are no longer consistent or easily predictable.
So it depends on which features you want that will dictate which sort of solution you can use. Either way has it's plusses and minuses.