You can
already find this elsewhere on the internet but this post just means there’ll
be one more source that might help someone find the info. (Plus it’s a note to
self.)
So. I wanted two things to get done in notepad ++:
Modify an
existing colour theme.
Set the
default language to C++ for certain files types.
Modify an
existing colour theme.
Go to the
Settings menu > Style Configurator.
In the
upper part of the window, choose a selected theme.
Good for
you if you find one that suits you entirely. I generally like the one named
‘Choco’ but I don’t like the selected text colour which I find not visible
enough.
To personalize a theme, go find
your themes folder within your Notepad++ files. (Mine is
C:\Program Files (x86)\Notepad++\themes).
Copy your favourite
theme and rename it. Now you’d think that you could edit your newly created
theme from the Style Configurator and go Global Styles > Selected text
colour and change the background colour. So did I.
Yeah, but
for some reason this is only going to last for your current session and next
time you restart, your changes will be lost. You need to edit your theme’s text
file directly. Open it, search for ‘Selected text colour’ and change the
background colour to your desired value.
Set the
default language to C++ for certain files types.
Go to the
Settings menu > Style Configurator.
Choose the
language you want to add extensions to from the left hand side list then add
the extensions in the ‘User ext’ box:
I said that ‘At the bottom, remapping with a linear texture is almost accurate. It's not exactly, but it's a matter of texture compression.’
I WAS WRONG. Systematically blaming texture compression is too easy.A flow in my photoshop knowledge was to be blamed, and I found out about that thanks to Simon Trümpler in this post. (We will be getting back to this post some time soon).
When you create a gradient in photoshop, there's a property called smoothness that you need to set to 0 if you want the interpolation between your gradient stops to be linear. This is what was truely messing up my gradient.
An easy way to double check that this is correct in photoshop is to create a 256 texture and compare the mouse pointer position with the brightness value.
At 48 in position, the 0% smoothness gradient = 48
while the 100% smoothness gradient = 36
At 173 in position, the 0% smoothness gradient = 174
while the 100% smoothness gradient = 184
At 255 in position, the 0% smoothness gradient = 255
while the 100% smoothness gradient = 255
At 100 % smoothness, the values get accurate in certain positions (near the stops and midpoints) but they shift in between.
The 0 % smoothness ramp is not fully accurate, you might be a pixel off sometimes but overall it's pretty good.
And this how it verifies in the udk:
(don't forget that the srgb option needs to be false in your gradients textures)
Today we'll look at a very simple way to generate a ‘random’ value. Of course it's not truely random, but it does the job for an artist sake.
What will happen if you plug a constant as your texture coordinates?
Every single pixel of your constant has the same value so they're all going to go pick the same pixel. That means that you'll get a constant value as an output as well.
If you're after a flicker, simply add a panner in the middle. You'll move the texture around so the value of the pixel in the centre will be different over time, and you get a fluctuating value. You wanna pan in both U and V to avoid repetitive patterns.
The rhythm of a malfunctioning neon light could be something like this:
(The texture is simply the inverted cell pattern effect from the after effects with some levels to darken it. )
If you want some mad flicker, use a very contrasted texture and pan it faster.
If you want some very soft variations, use some very soft gradients that you'll pan slowly.
Unfortunately, I haven't been able to record any of this because the framerate issues make it useless.
It can look a bit dry at first sight but don't let it put you off. It's very clear, thorough and well described with examples.
The tip I found today works for the blur and the healing patch tool (perhaps more tools have that option).
If you tick the Sample All Layers option, you can paint your blur or healing on an empty layer which will act as an adjustment layer. The layers underneath will appear blur but will remain unaffected.
How
unpleasant is it when the camera moves through a nice foggy sprite and this
lovely illusion of atmospherics suddenly pops out right in your face? Rather unpleasant
in my opinion, it just shouts ‘gamy’.
What you
wanna do is simply fade the material as it approaches the camera. I’m sure
there are more than one approach to it, but here’s the one I like to use.
I use
the PixelDepth (distance of the pixel being draw from the camera), pick a range
and remap it from 0 to 1 so it will gradually fade from white to black at your
chosen distance. I love
this little setup which allows me to pick a range and normalize it, I’ve used it
all over the place in the past. Credit for it goes to to Gavin Costello, currently lead programmer at Ninja Theory and all times graphics programming genius :)
How does it work? If the value is greater than the maximum, the result of (Value - Min) / (Max - Min) is greater than 1 and will always return 1 since we clamp it.
If the value is lesser than the minimum, the result of (Value - Min) / (Max - Min) is negative and will always return 0 since we clamp it.
If the value is somewhere between the min and the max the result of (Value - Min) / (Max - Min) gives you a ratio. Say that Value - Min = 1.5 and Max - Min = 2. 1.5/2 = 0.75, which is roughly what's on the sketch below.
The
distance is up to you but I’d advice not to set the min at 0 because it still
pops a little. I’ve personally set it to 10 in the following example so the material is
properly faded before the camera actually reaches the sprite.
That was meant to be a quick one, fun and visual, but I realized I'll need to explain a few things before I get to the fun part.
I want to get there: sort of a bendy animated warp.
But first we will talk about :
importing gradient textures
remapping a texture using another texture
linear textures
texture compression
trigonometry
and we'll get there eventually.
Importing gradient textures.
The texture we are going to remap is a horizontal ramp, so let's talk quickly about creating the right texture to import.
When you're using a vertical or horizontal ramp, do not import a square texture, that's pointless! Make a thin strip of it, which will be stretched in the material.
Let's take our horizontal ramp. You're not loosing definition by stretching the texture vertically since the value is the same on every pixel aligned vertically. Just make a texture 2 pixel high, or maybe 4 if you're a bit short-sighted.
This is what the texture looks like in generic browser:
This is what it looks like in the material:
Remapping a texture using another texture.
This is super common for people used to work with materials but not everybody is so I'll explain it briefly.
If you plug a black and white map (let's call it texture B) straight into the UV coordinates of another texture (let's call it texture A), it will remap A according to the information on texture B.
A white pixel on texture B will go pick the colour of texture A at 1,1.
A mid grey pixel on texture B will go pick the colour of texture A at 0.5,0.5.
A black pixel on texture B will go pick the colour of texture A at 0,0.
Here's an example using our gradient:
The top stroke is white so it goes and pick some yellow, the bottom stroke is a 128 grey so it goes and pick some red and the black background picks some blue.
Exact same thing with a more complex texture this time:
Now, you
might think there’s a catch. The gradient is horizontal but we're picking the
colour in a diagonal. Sure but look, the values are still accurate.
Obviously, since a texture's got 2 directions, U and V, you can map each direction independently but it's more simply explained with 1 single channel.
In fact it can give you a bit of a headache trying to paint a map purposely. (This is experience talking.) Still, here's an example of the two channels remapped non-uniformly.
You don't really want to paint this by hand (Well maybe you do but I certainly don't), but this is really cool for automated systems.
Say in a skin shader for instance where, say the U is going to be your SSS gradient > getting red where the light goes through the skin (in texture B you'll have the SSS map in the R channel) while in the V you'll store a lighting gradient > the colour of skin in the shadow and in the light (here you'll feed in the lighting info from your level.)
Clamping your texture.
Now one
crucial thing to remember is to clamp your texture A (so it doesn’t wrap around
the material which is the default behaviour).
This is how messed up it looks
when texture A is wrapped:
While a clamped texture A looks like this:
However if the texture B you plug in does wrap, it's all good and you'll get no artifacts. No need to clamp it.
While we're here, quick digression. Do you know you can batch edit textures? (Well, not only textures but this what we're dealing with right now.) You could clamp a few textures all at once for instance.
Select a few, right clic and choose ‘properties’.
Linear textures.
We’ll also
have to talk about linear vs Srgb real quick. You can read loads about it, I’ll
only sum it up.
By default
your textures are interpreted as Srgb, they get a 2.2 power applied to them so they
look ok on our monitors (that’s because of the way monitors are built).
That's this tickbox here:
A texture that goes into the emissive or diffuse will need to be Srgb. (the ones you actually see)
Textures used for UV distortion, timings etc. should not be Srgb.
In theory at least.
That's if you need a precise result; for some noise distortions it might not matter so much to be fair. You might not need to duplicate all your textures to have one linear and one Srgb version.
If you do some kind of maths with it though, it's almost compulsory otherwise your results won't be accurate.
Here's a little demonstration.
The top texture is the original. By remapping it with a horizontal gradient we should just get the exact same result.
You can see how messed up the colour gradient gets when it's remapped with an srgb texture.
At the bottom, remapping with a linear texture is almost accurate. It's not exactly, but it's a matter of texture compression.
Texture compression.
The texture compression can become very visible in certain cases. You can have a read at this article to find out more about DXT compression.
DXT1 clearly shows compression artifacts:
Grayscale is going to look much better but will be loads more expensive in memory.
Now, if you need a really clean
result your best option is to use maths. Do you remember the Pythagorean
theorem ? That’s what we need.
It says that the square of the hypotenuse (the side opposite the right angle) is equal to the sum of the squares of the two other sides.
a² + b² = c²
a and b are basically our pixel coordinates.
The length of the hypotenuse is going to give us the colour value of our pixel.
The closer it is to the centre, the shorter the length of the hypotenuse, and the darker the colour. As you move away from the centre you move from black to white, and tada, you get a radial gradient.
We subtract 0.5 to the texture
coordinates node to bring the gradient to the centre. (You can enter
other values, that’ll shift the centre.)
We extract the U and V
coordinated (a and b in the theorem) using a component mask, square
them, and add them together (You could use the exponent node but I used a
multiply in that case so the material looks less cluttered. It
just looks more simple visually.)
That’s a² + b² done.
You than square root it and
you’ve got the value of c, the hypotenuse. Now you still need to divide
the result by 0.5 to bring it back to the range of our texture
coordinates.
When you divide by 0.5, 1 is on the sides of the material.
When you divide by 0.7071 (the cosine of 45), 1 is in the corners of the material.
That was the slightly longer version to show where that comes from, but you can replace the whole a² + b² section by a dotproduct.
The fun part.
(at last.)
The idea is
to create a sort of an animated warp. We start with a texture with multiple
gradients. Since we’ll animated it and make it warp around, this one shouldn’t
be clamped.
The setting
is the same as just before, but this time we’ll add a panner to make the
texture move outwards.
It looks
too clean though. This setup is bound to make perfect circles since the pixel
sampled is exactly the same all around. However, we can still add some noise to
it.
So. All
that radial gradient coordinates business is somehow just like a texture
coordinate node: it tells you what your coordinates are. And same as simple
texture coordinates you can add some offset to it, so that’s what is happening
there. Simply panning a texture, multiplying it by a small value to reduce its
influence and adding to the radial coordinates.
It doesn’t
look that convincing just like this but you could make the gradients less
contrasted, use this as a mask, even add the whole thing to another texture UV
coordinates for that matter.
I used that
base to create the warpy glow around the masks pickup in Enslaved.
Quick recap:
Import your gradients as thin rectangles.
Clamp them when you want to remap them with a texture that doesn't wrap.
Use linear textures to remap (for accurate results).
Using the BLEND_Masked Blend Mode is very good to make a texture disappear the way liquids do. Sort of retracting as a blob rather than smoothly fading.
The success of it relies on the information from your texture and on the threshold the Opacity Mask Clip Value applies to it.
[quick disclaimer: the
framerate of the videos is a bit jaggy. Gotta use your powerful
imagination to see them smooth.]
But what if you want that material to be translucent yet you still want that sort of mask? I’m going to show you a simple little set up that recreates this behaviour. To get there, there will be a few things to cover beforehands.
To start with, I’ll show you a way to test material animation within the editor.
Then we’ll look at creating an appropriate mask.
Finally we’ll get to the threshold part.
Testing material animation within the editor.
This is a setup I like to use to preview the way my particles will look like once they’re animated in cascade. (so as to avoid back and forth from one editor to the other.)
The sine here is set to 3. Quite slow so I have the time to see what’s going on. The output of a sine curve varies from -1 to 1. With the constant bias scale at its default values (bias = 1, scale = 0.5), we move that range to the range we’d use for an opacity : 0 to 1.
I like to visualize this sort of thing by scribbling lines on paper. It clarifies things whenever I’m confused with what’s happening to my values.
Anyway. Your test multiplier oscillates regularly between 0 and 1 in the material editor.
You can see I've plugged the output into a lerp between green and red. That's my general rule when I debug an issue: strip it bare to the minimum and
make it dead obvious.
Creating the mask texture.
Pick your favourite splatter from cgtexture.
In photoshop, invert it then turn it white using the channel mixer, which gives you more controls over the levels of you greys than a simple desaturate. Make sure you retain some details.
If your texture is detailed enough, you might get away with a simple gaussian blur.
If it’s not or if you want to extract certain areas of your texture, duplicate it, apply some harsh levels to isolate a certain range, add a gaussian blur, make the layer additive and balance its opacity.
The important thing is to avoid areas of one pure value and therefore to keep your gradients as smooth as possible. Otherwise whole zones will pop out as they fade.
I have only tested this texture creation process quickly. I might go back to it in details to try and find the perfect balance and hopefully some way to automate it.
Threshold
Let's think quickly about what's happening to your gradient in the masked mode. No more shades of grey, everything becomes either black or white. The Opacity Mask Clip Value defines which values is considered as black or white. Again, when I tried to solve this out, I had to go through a paper scribbling phase.
Say I want my white to be set at the actual 0.8 grey of my texture. Any value below 0.8 is black.
How would 0.8 become 1? By adding 0.2.
How would 0.4 become 1? By adding 0.6. How would 0.15 become 1? By adding 0.85.
Therefore, you need to add the difference between where you want the white to be set and 1.
The only thing left is to plug a floor node at the end of the chain.
And voilà!
Now you just want to plug the vertex colour alpha instead of your looping test value and animate your particle’s alpha from cascade.
Remember that the threshold is a clamping value. If you set it to 0.2, and input value of 0.1999 (and so on) is your new 0. (That’s using a constant. Multiplying by a texture will affect the result some more. )
Therefore, you don’t want to animate your alpha from 0 to 1. I mean it, don’t. Adjust your values to your threshold. Not only would you be drawing a transparent sprite for no reason (that’s pure evil), your animated alpha curve would also be biased and you wouldn’t be able to adjust the speed curves the exact way you’d want to. (the alpha would get to a value too quickly and then remain there doing nothing and twiddling its thumbs.)
Test the balance between your threshold and the multiplier you use either in the material editor or cascade. In the following case we’re using a threshold of 0.2.
I’ll use 0.32 as my min and 1.9 as my max. (You can go beyond 1, as long as your result doesn’t exceed 2 otherwise you’d floor the value to several integers. If you really wanted to, you could also clamp the output of your floor to 1 so you can safely multiply by any value later in cascade.)
Quick recap.
A few things are going to affect the amount of details and the speed of your opacity fade curve:
The details in your texture (are the lighter and darker shades spread evenly?)
