Effect optimization

[NickelSlick]

I have gotten to the point where I need to start paying attention performance.
I am looking for any documentation that describes optimization processes for anything that has anything to do with visual effects. Also, if anyone has any good tips, that would be awesome too.

thanks!

[darthviper107]

What exactly are you talking about optimizing?

[NickelSlick]

It looks like the two major performance hits with effects is the material instructions and the overdraw. So anything with that (material optimization is probably a little too complex for general tips). Are there any tricks (checkboxes, etc) that would reduce the calculation on like, a steam effect? Especially if that steam effect has the potential to cover the entire screen with sprites?

[Hegen]

If you want to know all about UDK optimization i need to write a book here, but i dont do that. The best and easiest idea is to optimization lighting system

[Hourences]

Make sure it LODS.

Make sure occlusion is turned on for particles, it is not by default. Turning this on won't help you if it is a small level and a large particle, obviously.

Make sure the smoke you got uses the fewest numbers of particles possible. If you can get a similar looking effect with just 10 sprites, do that. You may even get away using a few mesh planes with cool smoke materials rather than trying to do everything with particles.

The more space the particles cover on the screen the worse. Make sure dense particles are small unless there is absolutely no way to avoid it.

Set all dense particles to World Detail High.

Physics and lighting on particles will obviously make it way heavier for your hardware.

Mesh particles are way heavier than sprites, even if they are very low poly.

[Wyldhunt]

The primary material optimization that you can do is by instancing and re-using as much as possible. I don't know what your game looks like, but most of the time people can get away with using the same, or very slightly altered, material several times if it's instanced with a few strategic scalars and 'IF' statements.
It's the first instance of each material and or texture that uses up your PC's juice. If you have a material once, you may as well have 5 of them. You'll barely notice a difference. If you can take your brick texture and overlay your grass normals and tint it green to make mossy walls in an outdoor level that already uses grass and bricks, you've just saved yourself a lot.

If you haven't used any material instances, I'd research them and see if you can find any use for them.

[NickelSlick]

Awesome. Thanks for all the replies!

[polerin]

Wyld: So instanced Materials are much cheaper, even if they have a large branch of unused instructions? I wasn't sure how the shader compilation optimizes that kind of thing. Say I have a fresnel branch, what's the best way to make sure none of those instructions are executed with an if?

[3dimentia]

Material instances are cheaper, because they are sharing the base material, which means that there is less ram being used among other things....

[Wyldhunt]

Wyld: So instanced Materials are much cheaper, even if they have a large branch of unused instructions? I wasn't sure how the shader compilation optimizes that kind of thing. Say I have a fresnel branch, what's the best way to make sure none of those instructions are executed with an if?

Here's how Instanced Materials work:

Lets say that you make a material that has several hundred instructions in it. It's a pretty complicated material. It has scalars that can control the tint of the material, the scale of the normals, invert the normals, adjust the specularity and opacity, etc...

You make an instance of it and place it on your brick wall.

You then make a child instance of that one and tint it with some extra red, and make the normals more choppy so that it looks more like clay bricks.

Here is how it is handled:
The first time the material is loaded, the full (Several hundreds) instruction material is stored and loaded.
When the child instance is loaded, it only references the existing material (Already loaded) and performs only those instructions that you changed. In this case, tinting and multiplying your rg channels of your Normal. Only a very few instructions. All of the unchanged instructions (Such as your fresnel) are refrenced and not re-loaded. So they take up 0 extra space in memory.

So, what I've done is created a 'Master' material that is probably way too complicated for most people to want to use for every little thing. Then make child instances along certain branches. I have one for foliage that has certain preset options for spec and such that is common among most of my foliage. The first time a foliage mesh is loaded, it makes that change. Every other foliage mesh does not need to re-do that math because they are all child instances of my foliage instance.

Actually computing what effect something like a fresnel would have on several different shaped meshes would still require some juice, but only a fraction of the amount needed to load in all of the process of how to fresnel and following the full material and loading it all into memory(RAM or GPU).

I use a several hundred instruction count material for nearly everything in my mod and I've never found any FPS loss. Because the instruction count is way less than the piles of materials would have if the PC had to load each one of them individually. The total draw is much less as long as you use enough instances to make it worth it.

Something simpler, such as making a basic material that can be tinted and instanced would only be a few instructions to begin with, and the instances would be nearly free after that. You could make an autumn shaded forest of reds and yellows and greens and browns and only need a single material.

EDIT:
So, something like an IF to control a fresnel would always only take up the initial space in memory no matter how many times you used it or turned it on or off. Each instance that changed the output of the IF statement from what its parent instance used would re-compute that leg of instructions (And not the unused leg), but would not need to re-load it into memory. Thus making it much faster and more efficient.