pyffi
pyffi copied to clipboard
Export Embedded Texture fails : save_as_dds : NiPixelData
Embedded textures are stored in the pixeldata
attribute of the abstract type ATextureRenderData
. There are two concrete implementations NiPersistentSrcTextureRendererData
. and NiPixelData
The ATextureRenderData
attribute pixelformat
determines the type of .dds.
For NifFormat.PixelFormat.PX_FMT_DXT5_ALT
, the code only supports the subclass - NiPersistentSrcTextureRendererData
.
Fiesta online stores the texture data as an NiPixelData
for PX_FMT_DXT5_ALT
type. The code fails when it attempts to call an NiPersistentSrcTextureRendererData
specific attribute pixel_data_matrix
Pyffi is generally unable to write NiPixelData to the .dds Data container. It uses the pyffi.object.model.UndecodedData
which is an stored in a pyffi.object.model.Array
which is not streamable, throwning an exception.
I'm still leaning my way around the pyffi structure and haven't quite gotten up the nerve to start touching the code.
One thing I've started doing with a few of my tools is convert pyffi arrays to lists of tuples when I need to export them to a text file, pickle dictionary (seam mender stored seam templates as, essentially, stripped down pickled nifs), etc.
Would a similar approach potentially work here?
I suppose we should check to see the steamable implementations for other model types and go from there.
It would be great to have support for more than just DDS. KTX(ETC1/ETC2) for example is a khronos open container format for loading textures directly into the GPU. ETC1 and ETC2 are non-patent encumbered compression techniques for textures. You can use ETC1 and ETC2 in the DDS container as well or S3TC in KTX container.
In general, we shouldn't care what is stored in NiPixelData so long as we (consumer/game engine/whatever) can determine what it is, either by file extension or some other flag.
Indeed we can expand the pyffi to have general transformation functionality, but the bug is specifically that executing save_as_dds fails. The blender plugin relies on this to extract embedded dds files. Would have to check that if the embed side of things also work too