Wavefront Objects are made up of 2 Files
The Object (*.obj) and Material (*.mtl)
Now depending on the Exporter., somewhat depends on what information is being stored in each of these Files... that is to say that certain elements, can be in either.
UV Texture Coordinates for example are ALWAYS in the Object File... BUT the Layout and Packing can be stored in the Material File.
While all Material Information (i.e. Lighting Type, Associated Images, etc.) this is all stored in the Material File.
A major oversight (imo) with AppGameKit is that it doesn't handle ANY Material Generation., meaning you ALWAYS have to manually load Images and Assign them... but worse is because of this it basically doesn't have an MTL (Material) Loader for Wavefront Objects; which can lead to your said situation where it's NOT loading the UV Maps properly.
And what makes this worse is that Kenny Models are NOTORIOUS for Terrible UV Mapping., as they essentially use Default Automatic Projection; which is good for a "Starting" Point not for Final Mapping.
The Vehicle you've posed for example., really needs A LOT of TLC sewing UV Shell seams and generally creating more singular shells over half a dozen that in some cases are individuals faces rather than shells.
Now as a side note., most of the Kenny Packages also come with .FBX and an older version that is compatible with AppGameKit (which again why the FBX Importer for AppGameKit hasn't been updated to support up to the most current 2020 Release; instead of still being 2012 remains baffling to me., as it should more-or-less be a case of simply updating the SDK used) ... but you do have to keep in mind that each individual Sub-Mesh is going to need it's own Texture for some Models; and there is no way to specifically define that on-load.
•
Personally I'd recommend using Blender to "Fix" Issues you're having... it's a pain to learn, but it's AS fully featured as more Professional Solutions while being Free; and is in Active Development.
Beyond this., I think the community NEEDS to be more vocal to TheGameCreators about more fundamental features for AppGameKit that have been sorely needed for many years.
Proper Support for .FBX and added support for .glTF
These are the two most common 3D Formats presently used and widely supported.
Second would be to add Automatic Generation and Loading of Materials / Textures... with new Functions to "GetTextureFromObject" (for example) that will return the Generated ID of the Loaded Texture., I'd also suggest the return of the Checklist Feature from DBP.
It was an excellent versatile function that allowed the output of multiple data points (such-as a list of Textures / Animations) that were stored in files.
And that would be another automated feature of 3D Formats I'd HEAVILY recommend that are needed... Animation.
As it stands adding 3D Animation to AppGameKit is... well it's jumping through A LOT of hoops.
Needing to use DAE for example (which has been deprecated for almost 20 years now)., when File Formats like .FBX and .glTF or even .X have this built-in to the formats.
For some reason when it comes to 3D in AGK., it's almost as if TGC have made it needlessly complicated and long-winded as if to put people off bothering using said feature... and the reliance of Archaic Formats that were Legacy when DBP first hit the market a Generation Ago; is strange to say the least.
