Asset Creation Guidelines

---

Purpose

This document was originally intended for use both internally at RenderHeads, and to be shared as a PDF with partners who may be supplying assets for a project. These guidelines were generally for use in Unity applications and typically for museum installations, however many of these concepts are broadly applicable.

Asset Tracking Spreadsheet

It is advisable to set up an asset sheet early in the project so that meaning conventions can be established, and the required assets for the project can be checked against the scope.

• This sheet should be constantly updated and be the primary source of information for the devs in terms of exactly which assets are available for implementation.
• Update the sheet with all of the relevant information, including status, size and file names that match the exports.
• File name should be related to the asset description and relate to the exported file name, not the working PSD/AI file.
• There is a template in the RenderHeads template library in Google Sheets for creating a new asset list. This can be customised as required to suit each project.

Naming Conventions

Naming conventions need to be standardised. There should not be a mix of dashes, underscores, spaces and parentheses. Underscores generally offer greater readability in a list. Instead of:

• Main-UI_Back_Bttn (Disabled).png

rather keep everything neat by standardising to:

• MainUI_BackBtn_Disabled.png.

The key thing with naming conventions is consistency. USe a format that makes sense for what you are making, as well as for your team size. You might need to add further divisions such as department names or approval status depending on your particular pipeline.

UI Assets

Assets naming conventions can be structured in many different ways. A good approach is to apply groupings by screen, function and state. When viewed as a list, these assets will naturally appear next to each other, making it easier to find them all, and to assess what might be missing.

• [Screen]_[Function]_[State].[ext]
• [Screen]_[Function]_[Description].[ext]

Examples following this pattern would include:

• MainUI_BackBtn_Inactive.png
• MainUI_BackBtn_PressedNormal.png
• MainUI_BackBtn_Disabled.png
• Options_MuteBtn_Inactive.png
• Options_MuteBtn_PressedNormal.png
• Options_MuteBtn_Disabled.png
• Options_BG_Gradient.png
• UserInfo_BG_Grass.png

3D Assets

For 3D assets, the grouping can be more functional, for example:

• [Level]_[Room]_[Item[Detail]].[ext]
• [Level]_[Utility]_[Item[Detail]].[ext]

Examples following this pattern would include:

• L1_Kitchen_CupboardsTop_01.fbx
• L1_Kitchen_CupboardsBottom_01.fbx
• L1_Kitchen_Table_01.fbx
• L1_Kitchen_Chair_01.fbx
• L1_Kitchen_ChairBroken_01.fbx
• L1_Dining_Table_01.fbx
• L1_Dining_Chair_01.fbx
• L1_Dining_Server_01.fbx
• L1_Dining_PlaceSetting_01.fbx
• L1_Dining_PlaceSetting_02.fbx
• L1_Utensil_Fork_01.fbx
• L1_Utensil_Knife_01.fbx

Individually interactable items will most likely need to be provided separately (eg knife and fork above) but the rest of the full place settings could be combined into one. L1_Dining_PlaceSetting_01 could contain all cutlery, crockery and glasses, while L1_Dining_PlaceSetting_02 could contain only crockery and glasses, as the utensils will be separately supplied.

How these categories are broken down depends on the particular use case and overall scope. If there are no levels or rooms, then change those categories for something more appropriate. The key thing is always the consistency and the grouping.

Images

Image File Formats

• All images must be RGB and at 72dpi.
• Any image file requiring transparency should be saved as a 24-bit PNG with transparency.
• Content images and full-screen backgrounds that do not need transparency can be saved as a 24-bit PNG with no transparency. PNG is preferable as it does not create artefacts on compressed images the way the JPG format does.
• Outline Design and Detail design docs need to be supplied as PDFs, not as InDesign files.
• Layered files should be supplied as Photoshop .PSD or Illustrator .AI files
• Please ensure all files have an extension, eg .psd or .png and that is the correct extension for that file type.

Asset Sizes and Crops

• When elements in the design continue off-screen, please export the full image area to ensure we can move/rotate/scale the item without having a hard cut-off. This is especially important for shadow layers that are close to the edge of the screen.
• There should ideally be a one pixel gap between the edge of the artwork and the edge of the image.
• For UI assets on mobile apps, all UI assets need to have both dimensions as multiples of four. E.g. a button that is 323x199 will be incorrect, and should rather be 324x200. This is to aid the compression inside Unity to reduce the chance of compression artefacts and improve the overall compression percentage.
• When designing in a vector-based application like Illustrator, ensure that the pixel grid is enabled. Resource linked at the end of this doc.
• Items that are part of the same 'collection' should be the same size. E.g. button states should all be the same size, even if large portions of some of them are transparent. This allows us to use a single position for all states and not have to create arbitrary offsets.
• When creating sprite sheets in Unity, assets need to have a resolution of POT (power of two, eg 128, 256, 512, 1024 etc) and it needs to be square, eg 1024x1024. This is to aid in Unity’s compression on mobile platforms.
• Raster assets should always be designed at the correct target resolution and not scaled on output. If the resultant image will be displayed at 640x320, it should be designed and exported at that exact size.
• Assets should never be scaled in Unity to get them to the intended display size.

Asset Memory Usage

Image assets use up memory (RAM) differently to how they use up disk space. A PNG with RGBA and a resolution of 1024 x 1024 can take up about 120kb of disk space. In memory it takes up a lot more, to work this out we need to count all the pixels.

1024 * 1024 = 1048576 Bytes (about 1 MB)Then we have to multiply this by each of the channels, red, green, blue, alpha.

1MB * 4 = 4 MB

This is important to consider with older phones with limited memory. The iPhone 6 can handle about 480mb worth of loaded textures, which means we can only have 120 of these 1024 x 1024 PNG’s or 7 4k sprite sheets (67 MB each).

Drop Shadows

• Should a drop shadow need to be multiplied onto the layer below, it should be exported as its own layer. If it is baked into the asset casting the shadow, we will not be able to make it multiply.

Tintable Sprites

Assets that are flat coloured that need to be tinted, can be tinted inside our software development package.

• The restart button icon should be exported as white with a transparent background. In the case of the red button, which is completely square, we do not need to be export it at all, as we can create a red square in our system easily and tint it darker when the user presses the button

• For sake of consistency, in the example above, the “quit” icon should also be exported as a white X on a transparent background. This will give us the most flexibility, and keep things consistent. If you decide that you wanted to do some sort of colour tint on transition on this asset as supplied, it would be far more difficult.

• In the case of theme UI elements which are a single colour - export them all as white with transparent background. This gives us several benefits:

  • Should the theme colour change at all during client review, we can just tweak a setting in our app and update all the colours, without having to replace any assets
  • When playing interaction animation (like flash to white), we can then easily tint the sprite white. We can’t tint the ones supplied as specific colours to white.
  • In the case of the diamond on the left, and the triangle on the right we only need 1x asset for all different colour themes

9-Slicing

9-slicing allows us to scale up an image while maintaining the border resolution. This allows us to make pop ups that we can dynamically scale. When an image can be reasonably reused in such a case it should be set up accordingly

• This is how an asset would traditionally be supplied:

• The asset above as originally supplied, should rather be supplied as below:

• This way we can make the asset any size we like in our system. Minor tweaks like these mean it takes a little longer to export, and set up on your side, but ultimately will save us a lot of time should minor sizing tweaks be required. If all pop-ups have the same border, this system will save you time having to export various sizes. Take care to leave a small gap between each element.

Text with Complex Effects

Text represents a unique challenge, if you want the text to have complex effects (like multiply, lighting, etc) these elements will need to be exported for us as images in both English and Arabic. It will be very tricky to attempt to match the effect exactly in our application.

Videos

Frame Rates

Videos should either be encoded at 30 or 60 fps. In the case of animations with little movement, 30 FPS should be fine. For finely detailed animations, with pans and large movements, 60 FPS will provide a far smoother result. Please note MP4’s encoded at 60fps add quite a bit of CPU overhead.

Video Codecs

There are potential formats we can use for video export, HAP, HAP Alpha, and MP4. In most cases it will be MP4 and HAP Alpha - there are a few basic rules we can follow to determine which is the most suitable codec for our video.

Does the video have transparency?

• If it does not, then does it have many arbitrary loop points? If it does, then use HAP, if it doesn’t (like an attractor video) then use an MP4. This is because we can loop HAP videos and jump to alternate points out of sequence far easier than MP4.

If the video has transparency, is it primarily a flat colour?

• If it is, export as HAP Alpha.
• If it has a lot of colour / texture detail, then ask yourself how many videos will be playing at the same time. If multiple videos will be playing at the same time, then we need to export as HAP or HAP Alpha, to reduce CPU overhead, otherwise export as MP4.

Additional constraints and considerations:

• HAP video resolutions must be multiples of 4 for each dimension.
• When exporting video with Alpha, ensure it is set to Straight - not to Premultiplied.
• MP4 videos must be rendered using the H.264 encoder.
• HAP videos use MOV container files.

HAP Video Size Calculator

HAP files are large. You can use this tool to get an idea of how large a HAP file will be at a particular frame size, frame rate and duration: http://www.dvsgroup.com/tools/HAPGuesstimator.php

Encoding MP4 Videos for Transparency

MP4 does not support transparency by default, so we need to encoded it in a side by side format. When doing this we need to watch out for fringing effects.

In the case of the example below, the colour channel at the top has a full dilated colour channel, even in the transparent areas - this will ensure that our colour blending will be correct when we apply the transparency in our software.

The bottom of the video is the transparency (Alpha channel). Note in this case the original video size was 1920x1080, this means our final render size here is 1920x2160 (2x1080).

Sound and Audio

Audio File Formats

For desktop applications, audio files should be supplied as follows:

• .WAV file
• 48kHz or 44.1kHz - as long as all supplied audio is the same.
• 16-bit
• Stereo

For mobile applications, audio files should be supplied as follows:

• .MP3 file
• 22.050kHz or 44.1kHz
• 8-bit or 16-bit
• Mono or Stereo

The choice between these settings is a trade off between sound quality and file size. Mobile devices are not able to provide the same fidelity as desktop speakers, therefore reducing the quality to reduce the file size often results in no audible difference to the user.

Simple sounds, such as navigation clicks/feedback can be supplied as mono instead of stereo.

Choosing Separate or Embedded Audio

Embedded audio must be encoded into the relevant video file using the same specifications outlined above. Both the HAP and MP4 video formats support audio.

• If a sound needs to be played on its own, it must be supplied as a stand alone audio file.
• If a sound needs to be precisely synced with an event in a video, it must be embedded into the video file.
• If a video contains a talking head where lip sync is important, audio must be embedded in the video file.
• If a video file requires sound that is the same duration as the video, embed the audio in the video file.
• If an ambient sound needs to play which is on a longer or shorter loop than the video it accompanies and sync is not important, this can be a separate audio file.

Asset Checking Checklist

When checking assets before handing over to dev, run through this checklist to ensure there is compliance.

• File name
  • Consistency - does the file name follow the same pattern as the other related assets?
• Spelling
  • Do the file names match the asset list name?
  • No special characters, only alphanumeric and underscores ( a to z, 0 to 9 and _ )
• File format
  • Is the image format correct for its purpose? I.e. PNG for flat art, JPG for photo, etc
  • Video frame rates should all be the same for any given app, ideally 30fps - not 29.97.
• File size
  • Does it seem larger than it should be? Sometimes a PSD is saved with a PNG extension, so it might be 20MB instead of 200KB.
• File dimensions
  • All UI assets for mobile need to have both dimensions as multiples of four. E.g. a button that is 323x199 will be incorrect, and must rather be 324x200. This is to aid the compression inside Unity to reduce the chance of compression artefacts.
  • Are related items that are part of the same 'collection' the same size? E.g. button states should all be the same size, even if large portions of some of them are transparent. This allows us to use a single position for all states and not have to create arbitrary offsets.
  • Where assets have multiple states, the dimensions of the various state files must be identical.
  • HAP videos must have the dimensions as multiples of 4 in both directions.
• Visual checks
  • Are the transparent areas showing correctly without any stray pixels in the Alpha channel?
  • Do button states have their common design elements in the same place when switching between them, or are they slightly offset with no design intent? For example, if there is an icon on a button, does its position change with each state by design or by accident?
  • Look out for extra rows or columns of pixels when cropping assets, especially when saving as PNG-24 as this will create a black row or column as there is no Alpha. As a PNGA, there would be a transparent strip, but would also mean the file dimensions are incorrect.

---

Resources

Aligning items to a pixel grid in Illustrator

https://helpx.adobe.com/africa/illustrator/using/pixel-perfect.html

Crunch compression of ETC textures

https://blogs.unity3d.com/2017/12/15/crunch-compression-of-etc-textures/

HAP Video Codec

Install the Hap QuickTime Codec version 12 from this location:

https://github.com/Vidvox/hap-qt-codec/releases/tag/version-12

---