Is there any way to get rid of the interpolation seam caused by using Frac or FMod? Coming from writing actual fragment shaders, I find it odd that this seam even exists (why is interpolation happening in the pixel sampling?)
Example, say we have this super simple texture
And we want the top right corner to loop instead of the whole texture, something that's easy to accomplish with an FMod.
As you can see, an artifact is now present from when the UV jumps from 0.25 to 0 and I'm not sure why. Is there a way I can disable this interpolation? With the power of MSPaint, here's what I expected to see:
I've found an okay temporary solution. If you disable mip-mapping (via the properties on the texture themselves) then the artifacts disappear. Would love to have another answer that describes how to do this while maintaining mipmaps.
Related
I have this quad in the 3D scene:
I need to get the local positions of all painted (non transparent) pixels of this quad. Already tried to use GetPixels() and filter the result by the alpha value to get only pixels with a valid color in it. But then I noticed that it isn't possible to get the pixels' local positions using this method, cause it returns a Color array, which doesn't offer a way to retrieve that information. Already tried to google and nothing came up, maybe the only way to get what I want is to build something at shader level, but I don't know much about this subject either. I can offer more context to my doubt if needed, but I'm trying to keep things short here. Also, there's no code to show except for the wrong one using GetPixels(), which doesn't work for my case as far as I know.
Any help is appreciated!
I am tinkering around with cubes trying to build variations of 'block types' (in an effort to get more familiar with Unity's abilities, shaders, editor tools etc).
I have a generic cube:
That I want to add a material/shader.. which I have done (no problem there):
Which looks well enough (for my purposes) when it's just one block, but when I stick them altogether, I don't like the effect; you can see the individual boxes and the shader (which you can't see in the still image) is actually animated water, so when it's animating it looks ... pretty ugly.
(Bad/undesired)
I am trying to STRETCH or share the shader/material across all the selected blocks. See the below example (in this case, I have taken a SINGLE block and stretched it, but that's not keeping with the spirit of having individual blocks, so also not what I want).
(better/more desired)
I have thought the following may help, but they all seem overly complicated (aka I think I'm going about it incorrectly)
Have the individual blocks, but stretch a single plane across them and then apply the material.
I have found examples of programmatically joining meshes, and then apply the material/shader to the single object.
Take a single block and stretch it to the dimensions needed.
Maybe (not sure if I can), but have a plane with the water material applied to it and use the blocks as masks to only display water for those blocks? Not sure how that works...
In the end I am hoping to have the following:
Individual blocks (so I can interact with them.
Shader animations/colors are shared across the shared/connected blocks.
It won't always be a 2x3 grid... it could be diagonal, or contain odd shapes of connected blocks...
(this is all in EDITOR mode).
Any thoughts on how I might approach this?
Phrases you could try searching are "converting from world space to uv space", "transforming uv coordinates", "uv math". UV is the name for coordinates in textures that a shader samples from, and if you take already existing shader code, you can do interesting things by changing the UV(s) it uses. One of those things is letting you "stretch" it.
In your 2x3 cube example you could tell each cube to treat its U value as going from 0 to 0.5 or 0.5 to 1 and the V as going from 0 to 0.33 or 0.33 to 0.67 or 0.67 to 1 depending on where it is instead of each one going from 0 to 1. You could do this by having a property on the shader to tell it where to start the uv (a) and where to end its uv (b), and you lerp from (0,0) - (1,1) to a - b.
My answer to a different question uses some similar logic to that by comparing the world position of the pixel vs a range of world positions to get a UV. The relevant shader code is:
fixed4 colorizedMapUV = (IN.worldPos.xz-_WorldSpaceRange.xy)
/ (_WorldSpaceRange.zw-_WorldSpaceRange.xy);
Another option is to only look at the world position, and completely disregard a notion of where the "corners" of the uv should be. A method called "triplanar mapping" might guide you to a solution that does this
I'm trying to write a simple frag/vert shader that, depending on whether it is in the range of a light, will paint the appropriate colour from either the 'lit' texture or from the 'unlit' texture.
Therefore, I need to compare the distance between the light to the range of the light.
I've been googling all kinds of things, but I can't seem to find a way of accessing the range value of the light. Is there a way to do so? If not, is there some kind of derived data I could use as an alternative?
Update
I was able to find this method here, which seems to be the most promising so far, however after playing around for a bit, I still can't seem to get what I need. There's some talk about _LightMatrix0 not being populated. Can anyone confirm?
Update 2
I found the variable unity_LightAtten in the Unity Shader Variables documentation. However, this is only used for Vertex Lit shading, which isn't exactly ideal, especially considering the lack of console support.
Could there be a way to pipe this variable to Forward Rendering?
You can pass Light.range into the shader using Material.SetFloat. You need to attach a script to do that.
So, I'm attempting to create a simple dynamic endless terrain using simplex noise.
So far I've got the noise working just fine - however I am having issues with the terrain having discontinuities at the edges. At first I thought this was due to the fact that I was not calling SetNeighbors on the Terrain objects, but adding this did not seem to yield any improvement.
terrain.GetComponent<Terrain>().SetNeighbors(left, top, right, bottom);
This problem seems to be caused by the slight differences in height between each terrain position - but making these set the same will effect the terrain quality (will reduce how jagged the terrain can be in certain cases) and generally seems inelegant. I've been going through the unity docs trying to find how to address this, but have yet to find anything.
Is there something I'm missing? Or is my only option to fiddle the heights on one of the sides to match the other?
Thanks for reading, appreciated as always.
Terrain image for reference
A couple things-
First, make sure you're setting SetNeighbors() on ALL the terrain objects, not just one.
Secondly, if the terrain don't match up exactly, it either means that the terrains aren't calculating their data quite correctly, or there's some floating point error going on. However, I have a suspicion that it's the first one, given that manually changing the points affects the quality. Make sure you know that terrains have n^2 + 1 points, and also make sure that the point to query from your simplex function with is calculated in world space.
If you can't figure it out, post your code and I'll take a look.
Also, your terrain might look better if you used octaved (a.k.a factal) noise on your Simplex noise function, depending on what you're looking for.
Cheers!
I have the layout of a website in CorelDraw X4 and I need to move it to Fireworks CS5 (for many reasons). The thing is that, apparently, the only method I was able to find on the Internet doesn't work very well. What I do is to export the file from Draw to AI (Adobe Illustrator) format. Then I import the file in fireworks, but there, strange things happen. The first thing is that borders are thicker after this process (1 to 4) but the real problem comes with some objects thar are converted to bitmaps (or so I think). When I delete all the bitmaps, only a few objects remain and that's obviously undesired. In my original file I use transparencies and gradients applied to many different objects.
Do you know why this happens and/or a possible solution? Thanks!
Edit: I think I'm getting closer! Apparently AI format doesn't support transparencies, so... I get all trasparencies out before exporting (not very nice, but what can I do, right?) or I ungroup all objects once imported into Fireworks and then carefully delete the bitmaps (which seem to be the approximation of transparencies for AI). All this is just about testing, if someone knows what happens or of another solutions, please, thow light. Thanks...
Ok, as nobody else answered my question I suppose I can consider myself capable to provide more information than anybody else, ha!
I've been studing the case and reached to a semi-solution. Apparently, AI is the only format supporting vectors that can be exported and imported by both editors. The problem with this is that AI doesn't support transparencies nor shadows. So... If you really want to do this, be prepared to work a bit.
What I did was to copy all the shapes without effects using this export/import method (surprisingly, line thickness was preserved correctly this time), then I examined shape by shape in Corel and applied the same (or its best aproximation) effects in Fireworks. This wasn't easy because the way both programs apply shadows and transparencies is a bit different. Yeah, it's not easy, but it's all we got...
Little tip: In my case I had some shapes with transparencies AND shadows. In Corel these shadows where strong as if the object was solid (not transparent). In fireworks, the shadow disappears with the object when the transparency is applied (as logically expected). What I did to solve this was to copy the object and apply a Gaussian blur to the object in the back, acting as a full shadow even when the object in the front was fading to transparent.