openmw.org

i said to remove the '.zip'. extension, not extract them.
A limitation of forum post attachments.

Oh, sorry. I must have skimmed that part.

blender output is piped to console, so run it from cli to get a clean stack trace.

Ok, will do on the trace. Was able to export the house you posted after removing the texture. Is that what I should have done, remove it? How does importing and exporting of textures work with the Blender .nif plugins?

Thanks!

Not sure yet, haven't gotten that far yet.

I usually create/export the NIF then use nifskope to have the vert(s) point to textures, at least that is how I did it for 2.49b.

I don't think OpenMW supports textures embedded in NIF (yet?).

psi29a wrote:I usually create/export the NIF then use nifskope to have the vert(s) point to textures, at least that is how I did it for 2.49b.

Works for me.

psi29a wrote:I don't think OpenMW supports textures embedded in NIF (yet?).

Some of the vanilla nifs like in_c_door_wood_square.nif uses Tx_common_door.tga (and several others) in NiSourceTexture. I just assumed that texture was embedded, being I couldn't find the tga anywhere.

I extracted all the data from the bsa files. Maybe I'm looking in the wrong place.

I could be wrong, but I remember reading something along that line somewhere. Maybe someone can verify this? Scrawl? Zini?

https://bugs.openmw.org/issues/2295

nipixeldata is supported. if the method is same as in 2.49 it's set inside blender baking the uv textures with absolute filepath.

Looking at some other vanilla models in nifskope, It appears that all the texture file extensions in those .nif files were .tga. Can I assume the game engine falls back or simply loads up a .dds whenever it encounters the .tga extension?

I can't really answer that, I don't know. Thanks sjek for the link, so there is a way to get texture data into a nif. I would rather just link (path name) to a texture external of a nif since it would be easier to test and adjust.