Notes (Artists)

From PixelLight Wiki

Jump to: navigation, search
Other languages
 • Русский • Deutsch • Français • Español • Italiano • 日本語 • Polski • Česky • Nederlands • 中文

Contents

Notes

Before we start working with PixelLight, here some general notes and tips.


Logs

Logs are your friend!

If the 'application/viewer' you are using is writing a log do have a look at it for application relevant information like performance/compatibility warnings or even errors. The PixelLight sample scene viewer for instance is using the PixelLight standard log pllog.log which is in the same directory as the application itself. There you will for instance find warnings if textures are not totally 'ok' which for example makes the loading times longer as necessary!

A texture performance warning may look like this:

  • [Warning]: Texture size 768x768 isn't correct! (maximum: 2048x2048)

PixelLight informs you with this warning that the texture was scaled during loading so the GPU can handle it. This will make for example the loading times longer! Another more problematic warning may be:

  • [Warning]: Lowest mipmap is 4x4, but should be 1x1! As result, the texture is propably NOT rendered correctly!

PixelLight informs you that the lowest given texture mipmap is not 1x1 - this may cause problems on certan renderer API's/GPU's. In short, try to fix all warnings and errors PixelLight writes into the log for best performance and compatibility.


Case sensitive

PixelLight is unlike Windows (but like for instance Linux) case sensitive. This means that if you use inside a material for instance 'MyTexture.BmP', PixelLight will tell you that 'BmP' is no supported image format even if it support's 'bmp' images. In this case you have to name your texture 'MyTexture.bmp'.

Another situation is for example that 'MYTexture.bmp' is used within the material, but the texture file itself is named 'MyTexture.bmp'. This 'may' (we give no guarantee) work without problems on a Windows system, but will fail on for instance Linux because the OS is in general case sensitive.

In reverse, if you develop in general on a plattform that is case sensitive, it's NOT recommanted to for instance name texture A 'MyTexture.bmp', and texture B 'MYTexture.bmp', this may work on that OS, but will not work under Windows because there, the names are the same for the OS.

To keep your project cross plattform compatible, it's REALLY extreme important that you take care of spelling! And we recomment to keep this into account from the very beginning of your project, else you may end up in an ugly chaos if the project is ported to another plattform and additional work must be spend to fix this. (time is money...)


Names in general

In general, use 'responsible' and 'readable' names for textures, objects and so on! Even better, try to define name conventions for your project so no one has to ask for the usage or type of for instance a texture.

You will not make your life and that of your colleagues happier when using for instance names like 'THeWTexA1-b copie 1.BmP' or 'This Is aN reaLly Ugly and long Name_Of My OWNTEXTURE b3 no ONE canread orreMember copy 26_copy 2_copy 36.tGa' or 'A1.bmp'.

Try to use directories to make categories of texture types like 'Brick/Dirty_DiffuseMap.tga', 'Brick/Dirty_NormalMap.tga' and so on. Also, it's not recommended you use whitespaces. ('Brick/Dirty Test.tga')

Do also try to keep names as short as possible - but still 'readable'. It's recommended to NEVER use names like orig_orig_orig_orig_orig_orig_orig_orig_orig_orig_orig_orig_orig_orig_orig_orig_orig_orig_orig_orig_SimianArchGlass #948_169 for for example material names. (yeah, we already had such names due automatic tools/scripts within graphics programs!) One reason is, that they are not handy when speaking about names within the team - but more important to note is, that there are for instance name length limitiations when for example burning data directly onto a CD. (we already had such nasty troubles with names like above!)

PixelLight itself has no internal string length limitations although concreate implementations like for instance OS backends may have some that we can't change! So, keep the read in mind when choosing names to avoid frustrating extra work later!


Textures

General

  • Do not use too many different (big) textures - try to reuse existing ones whenever possible. Do also try to avoid 'unused' parts within textures. (in short don't wast any resources or you will miss them later!) Although modern graphics cards have more and more memory on board, there's always a limitation and if you step over it you will notice a heavy performance hit, besides longer loading times.
  • Do not use too many small textures for a mesh. Try to pack multiple small textures into one larger one (keyword: "Texture Atlas") and you will normally notice a performance improvement.
  • We strongly recommend to use only the dds file format for textures. (more details are within the sub-section 'File format')
  • The Compressonator (http://developer.amd.com/gpu/compressonator/Pages/default.aspx) from ATI can be quite useful when working with dds (this tool for instance also allows to define the lowest used mipmap!) Unfortunately this tools writes 'dds' in upper-case, while PixelLight is using lower-case and is case-sensitive. So, when using batch-conversion, one have to use for instance a 'file rename' tool (like http://www.vlsoftware.net/renamus/) to make the filename-extension to lower case. (you can also use a Hex-Editor to make this within this tool to lowercase - but that's a bit tricky for none programmers :)

Dimension

Note, that in general textures MUST be a power of two. (2^n -> 0, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192... 65536... ) For instance 128x64 (<width>x<height>) is ok, while 124x64 is NOT. During loading the texture, PixelLight takes care of that for you and scales it automatically so the GPU can handle it... and a warning is written into the log because the result may not be the desired one and the scaling may slow down the loading time. As result, take care of texture dimension!

Beside that restriction, there's another one: The maximum possible dimension. While outdated GPUs (like my Radion 9600 Mobile) can only handle textures with a maximum dimension of 2048x2048 or less, more recent GPUs can handle 4096x4096 or even more. PixelLight will automatically scale down your texture if the dimension is to high for the used GPU. In general, do NOT make your textures larger than really required!

Color bit depth

If you don't need an alpha channel within your texture, do NOT save textures in general with 32 bit because 8 bits are unused... an unnecessary wast of resources! Use 24 bit when possible! You may ask yourself "8 bits? THAT'S NOTHING so I don't care." But keep in mind "8 bit * witdh * height". Example: 1024*1024*32 = 4096 KB for a texture of a 1024x1024 dimension with 32 bit. Same texture with 24 bit: 1024*1024*24 = 3072 KB + the GPU can handle RGB textures with a more efficient compression technique (RGB -> DXT1 = 1:8 compression, RGBA -> DXT5 = 1:4 compression) even more decreasing the memory needed for the texture on the GPU!

As result in the example above, your 32 bit texture will need about 1030 KB compressed on the GPU, while your 24 bit texture only needs about 515 KB - I think that's a minor difference! :)

File format

For best loading times and flexibility we strongly you to use only the dds-format for textures. This way you have also control over the mipmaps of each texture and they must not be created on runtime. Further this formats supports compression techniques the GPU 'understands' so the compressed data can directly uploaded to the GPU without the need of compression during runtime.

During loading, textures are 'just images' for PixelLight. This means that all known 'image formats' within PixelLight can also be used to load in textures.

Note that it's recommended to define all mipmap levels down to 1x1, otherwise the renderer API (like OpenGL/DirectX) may have some problems.

Compression

  • We strongly recommend to take texture compression into account to speed up the texture loading, increase the performance when using the textures and to be able to put as many textures into the memory as possible.
  • When using image file formats like 'tga', PixelLight does NOT use texture compression for this texture by default. (you have to force it using a 'plt'-file) This may be good during development so that there's no quality loss, but it's not recommended to use uncompressed textures for the release version.
  • Do NOT use 'standard compression' techniques for normal maps because they encode vector data and not 'real' colors. If you irgnore this, your resulting normal maps will look blocky and ugly. PixelLight offers 'xGxR swizzled DXT5' for compressed normal maps, have a look at 'Normal map' for more information.

PixelLight supports the following compression techniques:

  • DXT1: Known as BC1 in DirectX 10, RGB compression: 8:1 (opaque/1-bit alpha)
  • DXT3: Known as BC2 in DirectX 10, RGBA compression: 4:1 (explicit alpha)
  • DXT5: Known as BC3 in DirectX 10, RGBA compression: 4:1 (interpolated alpha)
  • LATC1: 1 component texture compression (also known as 3DC+/ATI1N, known as BC4 in DirectX 10, 8 bytes per block)
  • LATC2: 2 component texture compression (luminance & alpha compression 4:1 -> normal map compression, also known as 3DC/ATI2N, known as BC5 in DirectX 10, 16 bytes per block)

All this compression techniques come with a loss of quality. Keep an original uncompressed version and do NOT save, load, edit and save again because when this is done multiple times, ugly artefacts will appear.


Materials

  • Use 'two sided' materials only when really required, they need special processing during runtime
  • When using normal mapping, don't forget that the mesh using the material must provide proper tangent and binormal vector data or the lighting may look odd


"Z-fighting"/"Z-buffer tearing"

Do keep "Z-fighting"/"Z-buffer tearing" (ugly visible graphics bugs because limited depth buffer precision) to a minimum, use responsible manual near and far clipping planes for your cameras. For spot lights, use a good 'near attenuation end' value.

Another known 'trick' to reduce z-fighting is to 'shift' polygons covering other ones a little bit.

Gigantic polygons covering the hole world may cause z-fighting. If you notice such problems, it's recommended to subdivide the polyon into smaller ones.


Meshes

To get your meshes 'into the engine' you have multiple options:

  • The PixelLight 3ds Max scene exporter is the most comfortable way to go, especially for hole scenes
  • The PixelLight SDK comes with a lot of mesh loaders for multiple formats to load in directly the data
  • If there's no PixelLight mesh loader for the file format you are using, try to use a mesh converter to get the mesh into a supported format... or ask someone to write you a PixelLight mesh loader for the format *g*

Here's a short list of some mesh converter we tried:

... 'at least one' of this tools will do the job...

Retrieved from "http://developer.pixellight.org/wiki/index.php/Notes_(Artists)"
Personal tools