help with creating a Textures.xpr
#1
whats everybody using to create the textures.xpr i have tried XBMCTEX which works but doubles the size of my textures am i missing something shouldnt it if anything be a bit smaller than all the media files?
Reply
#2
pretty sure xbmctex pads out the files with blank so they are to a power of 2 and converts the format which makes them compatible with graphics cards and quicker to load

So if you have a 1920x1080 image its actually storing it as 2048x2048 because thats the next power of 2 without

Thats why skins like jx720 are only 5mb because the textures are the correct dimensions of 2 4 8 16 32 64 128 256 512 1024 2048 and so on (plus clever coding on my part)
Reply
#3
What happens with Texture Packer then because I've found the opposite results?

PNG image 1920x1080 (1.82MB) > XBT = 275KB

Resized PNG to 1024x1024 (885KB) > XBT = 1.20MB
Reply
#4
Is there somebody who understands this, wants to share it with others a has 3 minutes of spare time? If so please write some guidelines and best practices regarding this... Some kind soul could put it on wiki then for future generations sake.
My skins:

Amber
Quartz

Reply
#5
That would be nice. The whole xbt, texture sizes etc is confusing Wink
PointOfView Nvidia ION Atom 330 - TRANSCEND 2GB DDR2 DIMM 800MHz - G.SKILL 64GB SSD 2.5
Open Elec Beta4 1.95.4
XBMC Online Manual - HOW-TO post about a problem in a useful manner - Create/View Bug Report
Setup/Fix correct resolution on XBMC/Ubuntu - Usefull linux terminal commands
Reply
#6
From my own experiences working with XBT and XBR's in the past is as follows:

When you have an image thats 1000x570 for example the XBMCTEX will make that image 1024 x 1024 by stretching the image.

I've found images that are just over the power of 2 (1,2,4,8,16,32,64,128,256,512,1024,2048,etc) will be upsized to fit dimensions of the power of two. So that example image is stretching the width only by 24 pixels but the height is stretching 570 pixels of image across 1024 in the XBT texture.

This may not be whats happening. But i've noticed that not only is there artifacting and pixellated edges with textures that are even set to power of 2 size anyway when using an XBT, but the colour quality and gradients are effected. I personally choose not to use XBTs as I have a really fast machine anyway. Because a XBT build of my dark skin Ellipsis for instance looks terrible compared to the unpacked version.
Team Blackbolt - Digital Design
Twitter.com/TeamBlackbolt | TeamBlackbolt.co.uk
Reply
#7
Blackbolt Wrote:From my own experiences working with XBT and XBR's in the past is as follows:

When you have an image thats 1000x570 for example the XBMCTEX will make that image 1024 x 1024 by stretching the image.

I've found images that are just over the power of 2 (1,2,4,8,16,32,64,128,256,512,1024,2048,etc) will be upsized to fit dimensions of the power of two. So that example image is stretching the width only by 24 pixels but the height is stretching 570 pixels of image across 1024 in the XBT texture.

This may not be whats happening. But i've noticed that not only is there artifacting and pixellated edges with textures that are even set to power of 2 size anyway when using an XBT, but the colour quality and gradients are effected. I personally choose not to use XBTs as I have a really fast machine anyway. Because a XBT build of my dark skin Ellipsis for instance looks terrible compared to the unpacked version.

Hm, that's what's happening with XPR's here... if I have an 1920x1080 image, it's 2048x2048 in the XPR but remains 1920x1080 in the XBT file (at least if the console outputs are correct). And I've not seen any egde/color/gradient issue with XPR or XBT.... this was the case some time ago with XBT but it's not the case here anymore. But the real plus of using compressed textures is the loading speed, it's all so much faster even on fast machines, animations are smoother if they are more complex etc.
Image
Reply
#8
1. Don't use XPRs. They're completely unsupported, and the code will be yanked come Eden.

2. XBT's are created using TexturePacker. All textures are stored in the sizes of the original texture (modulo small changes such as alignment to multiple of 4 for DXT images and the like). We do a texture compression check to see whether they can be stored as DXT1,3 or 5. Most textures fail this check so are stored as A8R8G8B8 - TexturePacker tells you think. There's no power of two'ing going on at all in .xbt's.

3. In addition to deciding which texture format to use, the texture data is then compressed using lzo, a fast compression/decompression library. This is purely to reduce disk space.

During load into XBMC, we do the following:

1. Load the texture as-is into memory (i.e. de-lzo the file).
2. Check the hardware config to see whether the hardware supports the texture as it is.
3. Modify the texture to suit. This may involve decompressing DXT1/3/5 images, or padding the textures out to power of 2, or both.

To summarize: The power of 2 stuff really only affects how things end up in memory - if you can use a power of 2 then great. If you can't, don't worry about it too much. Using smaller textures in general is the best way to limit the amount of space your skin takes up on disk and in memory.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#9
I am not a skin developer, but I have recently started doing a bit of xbmc development involving directx in xbmc4xbox. I'm not an expert, but I thought I would share a bit of basic knowledge I have acquired.

XPR and XBT are both formats for storing "packed" textures, i.e. more or less a texture atlas (http://en.wikipedia.org/wiki/Texture_atlas). They are, however, implemented differently.

XPR does not do texture compression - it is just a packed format. The individual textures are stretched to POT and arranged into an atlas so to speak - but they stored as ARGB bitmaps for the most part. This format is for xbmc4xbox only now - don't use it for xbmc mainline skins.

XBT is similar but additionally uses DXT1/3/5 compression where it makes sense.

There is more to it than that, but I don't want to speak too much towards the details. It is, however, important to keep in mind that the size of your images on disk prior to packing is largely irrelevant in either format. By that I mean that the purpose of texture packing is not to reduce the byte size of the textures - it is to make them more efficient to load them.

In many cases (most even) the resulting XPR or XBT will be much bigger compared to the byte size of the original images. It could even be double or triple the size. That really doesn't matter at all, what matters is that xbmc can load the majority of the images used in your skin into a single texture object, and manage it memory-wise as a single object. This saves loads of memory that would be wasted due to POT padding, removes a whole bunch of redundant I/O, and allows aggressive caching of the skin resources to keep everything snappy for the user.

Unpacked skin resources put alot more strain on rendering and on top of that end up wasting alot of memory - primarily because they are usually compressed using .png or .jpg format. The video card cannot use images in either of those formats directly, they have to be decoded to a bitmap prior to loading by the video card. Point being is that the advantages of png and jpeg, namely reduced byte size, are actually disadvantages when it comes to xbmc - it has to waste time decoding them, and in the end those carefully optimized jpeg and pngs that graphics people obsess over end up as ARGB bitmaps anyway.

In the case of XBT, on top of packing the textures they are compressed into a format that the video card can load directly that uses 1/4 - 1/6 as much video memory. The format used is DXT1/3/5 (depending on whether or not there is alpha transparency and other factors). While this format is much more efficient memory wise, it is much larger as far as byte size goes compared to .png and .jpg. There is also some lose of color fidelity, as another poster has mentioned - but that is the cost of this type of compression. It generally doesn't hurt quality much though, and the savings in memory are substantial. Subtle gradients are what generally suffer the most.

As far as best practices, I'll let someone with more skinning knowledge than me answer that.
Reply
#10
Thanks for your post, but it should be noted that there are several factual errors in that post.

1. XBMC does NOT make an atlas. Each texture is kept separate.
2. XBMCTEX does pack to DXT1/3/5 - perhaps it is disabled in the source you have.
3. DXT1 is 1/8th the memory, DXT3/5 is 1/4 the memory. This is assuming that POT padding is not required (on some ATI GPUs it is).
4. DXTn generally doesn't necessarily give you a loss of color fidelity. Rather, it typically results in blocking artifacts as it's a 4x4 blocking algorithm. Some images are particularly bad though, in particular it doesn't do well on images that are predominantly greys, as you typically get green or red-shift which is very noticeable (particularly when the shift isn't uniform across a gradient). DXT1 is particularly good for photo images (i.e. backdrops) which is why we use it for fanart with the <useddsimage> option. Note that typically skin backdrops won't compress that way in XBT as the quality standard we use is too high so that TexturePacker chooses to leave it uncompressed.

Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#11
I have been using an old build bat I modified when first fooling with the Empty skin put up by wir3d How do i modify it to output XBT

PHP Code:
@echo off
ECHO ------------------------------
echo 
Creating Limbus Build Folder
rmdir BUILD 
//Q
md BUILD

ECHO ------------------------------
ECHO 
Creating XPR Files...
CALL XBMCTex -input media\ -output textures.xpr -quality max -noprotect

ECHO ------------------------------
ECHO 
Copying XPR Files...
xcopy "*.xpr" "BUILD\skin.limbus\media\" /Q /I /Y

ECHO ------------------------------
ECHO Cleaning Up...
del "
*.xpr"

ECHO ------------------------------
ECHO Building Skin Directory...
xcopy "
720p" "BUILD\skin.limbus\720p" /E /Q /I /Y
xcopy "
colors" "BUILD\skin.limbus\colors" /E /Q /I /Y
xcopy "
fonts" "BUILD\skin.limbus\fonts" /E /Q /I /Y
xcopy "
sounds" "BUILD\skin.limbus\sounds" /E /Q /I /Y
xcopy "
language" "BUILD\skin.limbus\language" /E /Q /I /Y
xcopy "
backgrounds" "BUILD\skin.limbus\backgrounds" /E /Q /I /Y
xcopy "
moviegenres" "BUILD\skin.limbus\moviegenres" /E /Q /I /Y
xcopy "
musicgenres" "BUILD\skin.limbus\musicgenres" /E /Q /I /Y 
xcopy "
studios" "BUILD\skin.limbus\studios" /E /Q /I /Y  
xcopy "
Countries" "BUILD\skin.limbus\Countries" /E /Q /I /Y 
xcopy "
playlists" "BUILD\skin.limbus\playlists" /E /Q /I /Y 
xcopy "
f" "BUILD\skin.limbus\f" /E /Q /I /Y 
xcopy "
*.xml" "BUILD\skin.limbus\" /Q /I /Y
xcopy "
*.png" "BUILD\skin.limbus\" /Q /I /Y
xcopy "
*.jpg" "BUILD\skin.limbus\" /Q /I /Y

copy *.txt "
BUILD\skin.limbus\"

ECHO ------------------------------
ECHO Removing SVN directories from build
FOR /R BUILD %%d IN (.SVN) DO @RD /S /Q "
%%d" 2>NUL

echo Build Complete - Scroll Up to check for errors.
echo Final build is located in the BUILD directory
echo skin.limbus folder in the build dir is ready
pause 

I have tried simply replacing the xpr with xbt results in an empty package
Reply
#12
This is what I use -

Code:
@echo off
ECHO ------------------------------
echo Creating Alaska Revisited Build Folder
rmdir BUILD /S /Q
md BUILD

ECHO ------------------------------
ECHO Creating XBT Files...
CALL media\TexturePacker.bat

ECHO ------------------------------
ECHO Copying XBT Files...
xcopy "media\*.xbt" "BUILD\skin.alaska.revisited\media\" /Q /I /Y

ECHO ------------------------------
ECHO Cleaning Up...
del "media\textures.xbt"

ECHO ------------------------------
ECHO Building Skin Directory...
xcopy "720p" "BUILD\skin.alaska.revisited\720p" /E /Q /I /Y
xcopy "colors" "BUILD\skin.alaska.revisited\colors" /E /Q /I /Y
xcopy "fonts" "BUILD\skin.alaska.revisited\fonts" /E /Q /I /Y
xcopy "sounds" "BUILD\skin.alaska.revisited\sounds" /E /Q /I /Y
xcopy "language" "BUILD\skin.alaska.revisited\language" /E /Q /I /Y
xcopy "extras" "BUILD\skin.alaska.revisited\extras" /E /Q /I /Y
xcopy "*.xml" "BUILD\skin.alaska.revisited\" /Q /I /Y

copy *changelog.txt "BUILD"
copy *fanart.jpg "BUILD\skin.alaska.revisited\"
copy *icon.png "BUILD\skin.alaska.revisited\"
copy *License.txt "BUILD\skin.alaska.revisited\"
copy *changelog.txt "BUILD\skin.alaska.revisited\"

ECHO ------------------------------
ECHO Removing SVN directories from build
FOR /R BUILD %%d IN (SVN) DO @RD /S /Q "%%d" 2>NUL

echo Build Complete - Scroll Up to check for errors.
echo Final build is located in the BUILD directory
pause

And then you need all the Texture Packer files in your media folder and a TexturePacker.bat -

Code:
@echo off

START /B /WAIT media/TexturePacker -dupecheck -input media\ -output media\Textures.xbt
Reply
#13
thanks Hitcher
Reply
#14
jmarshall Wrote:Thanks for your post, but it should be noted that there are several factual errors in that post.

1. XBMC does NOT make an atlas. Each texture is kept separate.
2. XBMCTEX does pack to DXT1/3/5 - perhaps it is disabled in the source you have.
3. DXT1 is 1/8th the memory, DXT3/5 is 1/4 the memory. This is assuming that POT padding is not required (on some ATI GPUs it is).
4. DXTn generally doesn't necessarily give you a loss of color fidelity. Rather, it typically results in blocking artifacts as it's a 4x4 blocking algorithm. Some images are particularly bad though, in particular it doesn't do well on images that are predominantly greys, as you typically get green or red-shift which is very noticeable (particularly when the shift isn't uniform across a gradient). DXT1 is particularly good for photo images (i.e. backdrops) which is why we use it for fanart with the <useddsimage> option. Note that typically skin backdrops won't compress that way in XBT as the quality standard we use is too high so that TexturePacker chooses to leave it uncompressed.

Cheers,
Jonathan

Thanks. I knew that texturePacker did not create an atlas, but I always assumed that xbmcTex did. I never looked at the source closely enough to figure out exactly what it was doing, but you right of course. Like I said, just starting to learn this stuff... Smile

And yes, in my source for xbmcTex there is no reference to DXT at all - it looks like it only generate ARGB and P8 textures for gifs. Its very old though, comes from the xbmc4xbox tree.

The 1/6th is when compared to 24-bit RGB with no alpha, but since XBMC uses 32-bit ARGB your right - it is 1/8th.
Reply

Logout Mark Read Team Forum Stats Members Help
help with creating a Textures.xpr0