Unity texture summary, unity texture

Unity texture summary, unity texture

Reprinted please indicate the source

We know that the performance of mobile games is inseparable from Art. Abuse of art resources often leads to a large amount of art rework. Therefore, it is very important to develop reasonable art specifications based on game needs. This article aims to solve two problems. First, what kind of specifications are there for art plotting? Second, how to deal with the image unity is the best.

Because our project is a 2D project and rarely involves 3D models, our art resources here refer to 2D Texture.

In particular, Here we only study the situation where texture type is sprite. In this scenario, only the sprite render is the component of the object, which also overwrites the gui.

 

First, we will introduce the simple meaning of each sprite parameter.

Sprite Mode: single independent image multiple associated images, which can be cut by editor

Packing tag: The same tag can be packaged in sprite packer. pro only

Pixelstounit: Number of sprite pixels in a unit. The larger the number, the finer the number. The default value is 100.

Rotate: center point, especially when designing to rotate

Mipmaps: Multiple textures, with a memory of 1/3 more. For more information about 3D, see

Fitermode: Fill mode when stretched

Maxsize: Image Size

Format: texture Format

 

For more information, see http://docs.unity3d.com/Manual/class-TextureImporter.html

 

Texture-related aspects: memory size, installation package size, and drawcall. Of course, there are also cpu, gpu processing speed, and read speed. We will not discuss them here. We will focus on the above three points.

 

First, we will discuss the memory and installation package:

 

The size displayed by the inspector, that is, the size of the READ memory. As we know, unity can read multiple image formats, which are internally processed into its own special format and stored as assetbundle during packaging. Therefore, the size of the memory depends on the texture parameter, but it has nothing to do with the format of the image. The size of the source image is also related to the size of the source image. (In fact, it depends on the source image size and texture parameters ). We can simply think that the installation package is large if the memory usage is too high.

First, let's take a look at the situation where the psd image is directly placed in unity. (Maxsize = 1024 format = truecolor)

Let's take a look at the impact of maxsize and format on memory and installation packages.

The 1024*1024 resolution in the above two tables uses the same image. We can see that compression (POT and square) on IOS greatly optimizes the memory and package size, and the format and maxsize also have an impact.

 

Aside from the lab pictures, different processing effects on the source image (more than 1024*1024) for our games (a large number of transparent images with a wide range of colors) are different:

1. Adjust maxsize to 512. Slightly distorted and acceptable.

2 format is changed from RGBA32 to RGBA16. Completely distorted and unacceptable.

3 IOS compression is PVRTC4bit. The distortion is very small and acceptable.

4 Android compression: RGBA16. Completely distorted and unacceptable.

 

Let's look at a new table. The same picture shows that art works at different resolutions during plotting.

The image memory of 1024*1024 ranges from 4 MB to 0.5 Mb, and the installation package is reduced by 4 times. The advantage is too obvious. Unfortunately, it only supports IOS, but not android.

 

Let's discuss drawcall again.

Texture merging is the first thing that comes to mind for textures. For spritepacker, the "For optimal performance" in the official document mainly has two aspects: the impact on empty space and drawcall. So the discussion of drawcall becomes a discussion of spritepacker.

For more information, see http://docs.unity3d.com/manual/spritepacker.html.

 

Sprite render different textures of the same material will still produce multiple drawcalls, and the combination of textures will reduce drawcall. In fact, in our games, the number of pictures in the camera range is always limited, and the number of drawcalls is very low. So our focus is not here, but the influence of spritepacker on space.

If we package a full graph of a large graph in a scenario, the memory of the gallery will be loaded no matter what graph is used when the scenario is loaded. If we only use a small graph, then the appearance of the gallery is no different from the cool-killing, this is why NGUI does not do this job when there is no UGUI in the past.

However, our scenarios are basically background images, so they are not suitable for packaging into the gallery, while small "part images" can be packed, and redundant loading can save I/O, such a plan should be reasonable.

There is still a problem with spritepacker. The Pack gallery is placed in the library cache, and the library is added to the ignore of SVN. According to the official statement, if the cache does not have an atlas, it will pack again. But we know that we can customize the pack. Isn't the pack method changed stored in a setting file? Ignore is still removed from the library file. I was thinking about the problem above:

If the image given by the art is multiple RGBA32 images of NPOT, It is packaged into a 1024*1024 graph. The customized spritepacker is selected to set the entries of the gallery. settings. format = TextureFormat. PVRTC_RGBA4 does it mean that I have merged these 10 images into an gallery in the RGBA32 format and then compressed the gallery PVRTC? If so, can we further optimize it? However, the expressive power of a thumbnail is so microscopic and slightly distorted. On the other hand, the degree of optimization is not that great. Let's take it into consideration when the project is processed later.

 

To sum up the above solutions for our project:

Art plotting: Height/width 256 can be drawn as any piece, because many of them are similar to the UI.

Unity processing: Select RGBA32 for spritepacker and determine whether it can be compressed to PVRTC for further consideration.

Art plot: Height/width 256 + image, made into POT Image

Unity processing: The maxsize of 2048/1024 is set to 1024/512 (acceptable distortion) and PVRTC compression.

 

The above focuses on IOS. If Android is used, leave two ideas first. First, "the mainstream Android models currently support ETC1 compression. However, ETC1 only supports image compression through non-Alpha channels. Therefore, the Alpha channel diagram is usually separated. When the image is drawn to the GPU memory, the value is obtained from the Alpha channel, and the image without the Alpha channel can be compressed using ETC1 ." The second point is still processed from maxsize. The above discussions and conclusions are for our own projects. Different projects should have different concerns. For more information about specific parameters, see documents and experience. I hope the article will help students who need it, and I hope to correct the mistakes.