Get Texture u,v coordinates fails if 1) back material 2) previous SU version


I’m porting a working Sketchup importer from previous API with COM to SU new C API
It seems I can’t get uv for back material when skp file comes from a SU 7.0 version
u,v seems to be always (0,0) (1, 0) (1, 1) (0, 1).
u,v coord are ok for front material

I was not sure to have a good SUUVHelper, so I’ve tried
SUFaceGetUVHelper(face, false, true, texture_writer_, &uv_helper);
then SUFaceGetUVHelper(face, true , true, texture_writer_, &uv_helper);
It has no impact.

With the original file,If I reset the texture in SU 2015 than stretch it and rotate it and finally save it with 2015, I got a correct import with new C-API sdk.

How can I check if this is my fault or not ?

hole origin.skp (36.6 KB)


hmm… do you have a sample snippet that is complete for us to us compile and run in the debugger?


Thanks for your proposal,

The code I have is too complex but I’ve a simple idea:

I could output skp with skp2xml SDK sample and check uv from the xml output.
What’s the fastest way to make the skp2xml output an xml file because I know nothing about SU plugin yet ?
Compile + set SU path in VS 2013 Debug target and launch VS Debugger ?



I haven’t actually looked at that example myself, I’d need to look it up. I don’t recall if that was a console app that just spits out an XML file or if it’s an Exporter interface example.


skp2xml is a dll plugin project. I’ve added a console App to VisualStudio solution to make a call to exporter so now I got an xml and …seems that skp2xml ouput uv correctly.

I’m diving in the sample.
I’ll let you know

Thanks for your answer


I’ve dived deeply in my original problem :

I think I’ve two problems with textures especially when applied on back face :
(u,v) and texture file output

In my skp I don’t think there is a texture on layer

// 1°) u,v coordinates
// uv output joined xml output are from skp2xml.sln sample
// texture_writer_ filling
// by changing uv will be correct :
size_t texture_count = texture_helper.LoadAllTextures(model_, texture_writer_, true /textures_from_layers/)

// uv will be incorrect = default ones (0,0) (1,0) (0,1) (1,1)
size_t texture_count = texture_helper.LoadAllTextures(model_, texture_writer_, false/textures_from_layers/);

// 2°) texture file output
C-API textures output is odne by = **SUTextureWriterWriteAllTextures:
// texture output names seems incorrect blpierreVerteWith0.png" (original name) become “blpierreVerteWith01.png”.
// Another thing :
// "blpierreVerteWith01.png"is not same as original, output file is morelike the result of texture streched on Sketchup ?
if (texture_count > 0) {
SU_CALL(SUTextureWriterWriteAllTextures(texture_writer_, texture_directory_.c_str()));

In zip file: (42.0 KB)
// original skp file
// uv output in xml coming from skp2xml.sln
// original and C-API textures output
// console app added to original skp2xml to call dll code (Visual Studio 2013 can’t generate compatible plugin)


two samples with back/front material inversion and face reversal but a lot of differences when using xml exporter

  • texture file output

  • (u,v)

    CXmlExporter::WriteTextureFiles() {…
    // this line
    SUTextureWriterWriteAllTextures(texture_writer_, texture_directory.c_str()));
    CXmlExporter::WriteFace(SUFaceRef face) {

    // this line
    vertex_info.back_texture_coord_ = CPoint3d(uvq.u, uvq.v, 0);

front and back 2015.skp (18.6 KB) back and front 2015.skp (18.3 KB)


The texture writer is not well documented. It has some unexpected behaviour.
SketchUp use UVQ values - while many other applications or file formats expects only UV. To address that the TextureWriter generates new textures and new UV data for faces with non-affine texture mapping. That’s why you see new image files that doesn’t match the original and new UV data.

If you want to preserve the original texture when do not use the TextureWriter - instead use the UVHelper without a texturewriter. Note that you will be getting UVQ data - if you need to translate that into UV divide the U and V valuwas with Q. And then export the images directly from SUTextureRef.

We need to improve our docs and make some new examples for this.

(Btw, when posting code, can you wrap code block as Preformatted Text please? )


Sorry for the bad formatting of my pseudo-code.
You saved me with your reply. It work like a charm :

void CXmlExporter::WriteTextureFile(SUMaterialRef material) {
	if (options_.export_materials()) {
	SUMaterialType type;
	SU_CALL(SUMaterialGetType(material, &type));
	if ((type == SUMaterialType_Textured) ||
		(type == SUMaterialType_ColorizedTexture)) {
		SUTextureRef texture = SU_INVALID;
		if (SUMaterialGetTexture(material, &texture) == SU_ERROR_NONE) {
			// Texture path
			CSUString texture_path;
			SU_CALL(SUTextureGetFileName(texture, texture_path));

			std::string texture_file_name = StringHelper::GetFileName(texture_path.utf8());
			std::string output_texture_file_path = texture_directory_ + texture_file_name;
			SUTextureWriteToFile(texture, output_texture_file_path.c_str());