WIP WIP - [Windows] [Take over] Kodi - Updated Texture Tool (.xbt)
#1
Image

After trying to have the Kodi team and myself reach out to SUUP and no response, I discussed taking over the DEV after my own use cases needed more feedback of what was actually going on while the tool ran and solve the output of 0KB file result issue. I spent some time developing and updating the existing tool and it is nearly ready. The main feature that is NOT ready is the ability for it to update. The mechanism is still in place, the notification still shows, but there is nothing to call home to. I will at some point get that working but for now, let's just see if the update passes the muster before I spend time in an area that may or may not require my time. I am still knee deep in Madnox skinning, so this was a diversion, but I think it improves the overall user experience and will be interested in your thoughts and feedback.

I would personally like to thank SUUP directly if this is seen. Thanks for a good tool and providing me a starting point. Feel free to reach out to me if warranted.

Now, for the gotcha. I can't state this more emphatically, this version of it is NOT a virus, of any kind, in any way, the source is clearly available for you to dissect, review, piss on, whatever. I know exactly what that sounds like when you read it or hear it from someone on the internet, all the red flags go up. What has happened here even has my head shaking.... and the cliff notes are basically this: The program used to DEV this is called AutoIt, totally free to use, download or you can edit with Notepad if you really want to. The entire thing is basically a GUI script converted for ease of use. You are probably saying, ok then, what's the deal. Well my understanding is that the signatures that the program uses have been flagged by multiple AV companies even if the script is not maliciously written. It had me questioning it at the beginning what was going on, turns out, AutoIt is a nice fast why to deliver hacks, keygens, worms, Trojans and anything else that you can think of, so now, it is flagged like crazy. You can send your file to the AVs to whitelist it, but what a PITA is to do and it takes time.

Why not just rewrite it in VB, or C++, because it is a PITA and there is no direct converter (if there is, show me!) and I have multiple other things going on. It seems the x32 gets hit harder than x64, but they are both built as the same time, I assume the dependencies are what cause it to fail AV scanning one over the other.

I even did a test where I built, literally, as single line of code in the default project creator, added a call to the library, compiled that, and submitted it to VirusTotal and it was flagged as malicious. literally, 1 line of code that basically does nothing but import a keyboard.dll..... high malicious score.... so you can thank the script kiddies for that.

If you've made it this far, you can see the initial development starting here (Video in a post & also shown below):

https://forum.kodi.tv/showthread.php?tid...pid3188440

The source, x32, x64 are all on GitHub, they will not be part of my skin repo and act as a separate tool. If more comes of it, I will consider getting the updater going as I will be maintaining this for quite a while as I use it in my skin dev.

If there are any questions, issues, comments, all will be handle HERE, not on GitHub, I want all info centralized in one location and it makes the most sense to do it here.

Hopefully you find the update worthy and of use. If it ultimately meets the Kodi's team requirements, maybe they can/will link it in the WIKI page which still points to v2.9.2.


Verbiage hybrid copy from SUUP's original tool thread (with updated links):
 
The tool is based on tiben20's command line extractor and Texturepacker, that only support cli.
 
For more information check the Kodi Wiki Article here!
 
It's actually pretty simple to use it:

How to decompile:

1. Select Source File.
2. Select Destination Directory/Folder
3. Press Start
4. Wait until done.

How to compile:

1. Select source
2. Select Destination
3. Press Start
4. Wait until done.
 
Image



Example Usage (Video):
http://www.kittmaster.com/imagedump/kodi...iTool.html
Kodi: Nexus v20.5 | Skin: Madnox.redux : Current Version: 20.00.11 | Forum | Madnox.redux v3 Repo
Mr. V's Original Source
Reply
#2
Reserved #1

LINKS ARE BROKEN, FIXING LICENSING and other suggestions to implement.
Kodi: Nexus v20.5 | Skin: Madnox.redux : Current Version: 20.00.11 | Forum | Madnox.redux v3 Repo
Mr. V's Original Source
Reply
#3
Reserved #2
Kodi: Nexus v20.5 | Skin: Madnox.redux : Current Version: 20.00.11 | Forum | Madnox.redux v3 Repo
Mr. V's Original Source
Reply
#4
Reserved #3
Kodi: Nexus v20.5 | Skin: Madnox.redux : Current Version: 20.00.11 | Forum | Madnox.redux v3 Repo
Mr. V's Original Source
Reply
#5
Reserved #4
Kodi: Nexus v20.5 | Skin: Madnox.redux : Current Version: 20.00.11 | Forum | Madnox.redux v3 Repo
Mr. V's Original Source
Reply
#6
FYI, Kodi "P" will feature a lot more texture formats and properties (see https://github.com/xbmc/xbmc/blob/master...eFormats.h). While the XBT format won't be able to contain every texture format (as some will be internal only), there will be a lot of new ones.

Texture formats
There is support for cheaper texture formats, like single/dual channel textures, or RGB565. Compressed textures are also supported. The usage of HDR texture formats is prepared, but not really usable for now (until we implement a HDR UI).

Alpha
This doesn't change for now. While there is an option for premultiplied alpha, it is not used at the moment.

Colour space
There are no changes here either. We still expect the sRGB/REC709 colour space for all textures, but HDR (REC2020) is prepared.

Transfer function
In the current state, only textures with a sRGB transfer function are expected, as the current rendering pipeline is not sRGB aware. With a sRGB aware rendering pipeline, XBTs can also contain linear encoded textures.

Swizzling
This property governs how the texture channels should apply to the rendering pipeline. For example, a R8 texture might be applied as a luminance (RRR1), alpha (111R) or SDF texture.

Overall, you might find unpacking difficult, as some formats don't map 1:1 to common image formats (like PNG). For compressed formats, you also need to support DDS, PKM and ASTC. Swizzling might be impossible to express in such formats.

From a first glance, it seems that you added a GPLv3 licence. I don't see any licence in the repo your project is based on, are you sure that this is okay? Also, there are a lot of binaries. I somewhat doubt that the D3DX9_43.dll is GPLv3.
Reply
#7
Looking at the source dev, there is no license listed, I'll follow the same unless there is a suggestion to select. I thought I had seen that on one version of their repo. It is prob not ok, so I'll fix it. Any suggestions as to what it "should" be if at all?

I looked at the .h file, my question really becomes, while improvement is always the goal to go forward, why are you making it so hard to compress and decompress a single file to get images in and out the format? Tools like this would totally unnecessary if Kodi would provide a way to get the images in and out of the texture format.

I am unware of what all the core ins and outs of base.exe and texturepackager.exe are doing, just that we are passing arguments to either create an .xbt file or decompress it for the source images... However Kodi chooses to manipulate the images and transform them for better effects while .xbt format or whatever else is needed, shouldn't their be a section to just be able to do something stupid like "save as" from the admin panel or decompress all into usable format of .png.??  

Is that asking for the moon since we are just trying to create a great user experience with items that are not being custom created and available to the public?

Building these widgets isn't exactly trivial, but not rocket science either, I'm just curious as to why things need this much legwork to do very basic tasking to fill the blanks as needed.

Just my humble opinion.
Kodi: Nexus v20.5 | Skin: Madnox.redux : Current Version: 20.00.11 | Forum | Madnox.redux v3 Repo
Mr. V's Original Source
Reply
#8
(2024-05-22, 19:04)kittmaster Wrote: Is that asking for the moon since we are just trying to create a great user experience with items that are not being custom created and available to the public?
All .xbt files come from a source where you can download the textures uncompressed.
Reply
#9
(2024-05-22, 19:04)kittmaster Wrote: Looking at the source dev, there is no license listed, I'll follow the same unless there is a suggestion to select. I thought I had seen that on one version of their repo. It is prob not ok, so I'll fix it. Any suggestions as to what it "should" be if at all?

If the author didn't choose a GPLv3 compatible license, you can't license it under those terms. Even so, he retains full copyright, which you would infringe. How this is enforced is a different matter, but I would strongly advice against relicensing it. Personally, I wouldn't want to distribute questionable binaries.

(2024-05-22, 19:04)kittmaster Wrote: I looked at the .h file, my question really becomes, while improvement is always the goal to go forward, why are you making it so hard to compress and decompress a single file to get images in and out the format?

I did not introduce the new formats in order to make reading/writing to XBT files harder, if that's your question. If limited to a single file format for interoperability, you could choose KTX2 (with the optional swizzle in the metadata).

Also, images are often different to textures. In general, both terms can't be used interchangeably. Among other differences, images are not constraint to limitations of the rendering pipeline (colour space, transfer function, ...). Textures on the other hand can be used in more elaborate ways to generate an output image (for example signed distance fields).

(2024-05-22, 19:04)kittmaster Wrote: Tools like this would totally unnecessary if Kodi would provide a way to get the images in and out of the texture format.

Tools like this would be totally unnecessary if every skin would have its files on a public platform (like GitHub/Gitlab).

You are free to implement an XBT en-/decoder, even if it just supports a subset of the texture formats. I personally won't invest time into writing a decoder, as I see no need for it.

In the end, this was just a heads up that the XBT format is subject to change.
Reply
#10
Hi Chris...

Sorry for the delay with the feedback on the new Texture Tool 3.0.1
Everything is working as expected... Thanks for the improvement with "remembering the path".

Keep up the good work!

Sincerely,
Reply
#11
Good to know, I have to redo the Github and put the files back up, been a mess lately between the file scan issue with Omega and getting back into the swing. But at least you have a working copy.

Any bugs or issues so far with it?
Kodi: Nexus v20.5 | Skin: Madnox.redux : Current Version: 20.00.11 | Forum | Madnox.redux v3 Repo
Mr. V's Original Source
Reply
#12
No, all working grea.
Thx!
Reply

Logout Mark Read Team Forum Stats Members Help
WIP - [Windows] [Take over] Kodi - Updated Texture Tool (.xbt)0