How should i use s and t scale factor from SUTexture?

Developers
1

Hi everybody,

I’m currently developing a sketchup importer for my c++/openGL 3D viewer.
Everything look good except for some textures which seem to be twisted along the X axis.

After reading from the SUTextureGetDimension function documentation (here : viewtopic.php?f=180&t=58269&p=531281&hilit=distortion#p531281) i spotted the s_scale and T_scale factor existence but i don’t known how to use them.

All i know for now about the twisted texture is :
s_scale = 0,035 and t_scale = 0,064.

Should I pass them to openGL or should I do some extra computation ?
Could anyone help me ?

2

The scale factors maps the pixel size to model size (this would be inches as that is the underlying unit in SketchUp regardless of the model’s unit settings.)

So if you have an image 500x300 you’d get the model size by:

width = 500 * s_scale
height = 300 * t_scale

This refer to the Width and Height properties that the user can set for materials in the Material Browser.

3

Thanks for the answer Thomas.

That’s how the model is rendered (both software) :

model unit is centimeter and material box in sketchup said :

texture name : untitled.bmp
size : 70,8cm x 39,5 cm
so i does mean a 2,47cm x 2,52cm almost a square according your informations.

I checked the data sent to my app by sketchup sdk throught SUMeshHelperGetNumTriangles. What i got is :
2 triangles with the following texture coordinates :

(0, 1)            (1,1)
+ --------------- +
|              /  |
|            /    |
|          /      |
|        /        |
|      /          |
|    /            |
|  /              |
+ --------------- +
(0,0)            (1,0)

So I don’t understand why my texture is twisted …

4

I dumped the texture on disk throught severals sdk methods :

SUTextureWriteToFile
SUTextureWriterWriteTexture with arg reduce_size set to true
SUTextureWriterWriteTexture with arg reduce_size set to false
SUTextureWriterWriteAllTextures

all dumped textures are squared and free from artifacts.
Then i tried another approach : i dumped to file the memory data returned by SUTextureGetImageData and load it on http://rawpixels.net/

Guess what i’ve got ?

So that’s not an issue which relies on my code or OpenGL. So why Sketchup give me that twisted texture ?

5

Hm… You list the image dimension in cms. What are the pixel units?

Are you applying the UV points in the correct order?
After setting the UV data in your app - have you checked that actual UV data applied? That it matches?
From the UV data you describe there - and the screenshot from SU it looks like you are getting the correct data. So it looks to be that the texture skewing appear when you apply that data in your app.

6

That’s a dump of the frame buffer?
I’m not sure what all this is - but from your previous post, the actual UV data you got looked correct for a texture applied to a face as shown in your screenshot.

7

Hi Thomas,

Texture’s dimensions are 419x234 pixels.
I’m applying the UV mapping according counterclockwise order (openGL default) which is also the winding use by sketchup’s SUMeshHelpers SUMeshHelperGetVertices classes method.

If i replace the problematic texture in sketchup for a bigger png in sketchup everything looks good.

Yes the raw data used within the raw pixels.net website are a dump from the frame buffer’s data sent by sketchup to my app (using SUTextureGetImageData method).

Sketchup is sending me a twisted texture and i don’t understand why …

8

The actual texture image? Because the UV data looks correct. (0,0 - 1,0 - 1,1 - 0,1)

9

Can you post sample model?
Also, is the texture applied to the front or back of the face?

10

Texture’s size is ok, UV map coordinates too.
Just the texture’s data (pixels) who are shifted to the right (as on the rawpixels.net screenshot).

Texture is applied on front face. I attach the model to this answer.0981 1 barrière chantier avec panneau.skp (656.5 KB)

11

I tried that model and exported the texture using the Ruby API:

tw = Sketchup.create_texture_writer
#<Sketchup::TextureWriter:0x99ffb28>

tw.load Sketchup.active_model.selection[0], true
1

tw.write_all(ENV["HOME"] + "/Desktop/", true)
true

And that resulted in a correct image.

Do you have a sample of the code using the C API that produce incorrect texture? From what I gather you use SUTextureWriterWriteAllTextures?

12

If i use SUTextureWriterWriteAllTextures the texture will be ok but my model loading time will increase cause i will dump the texture on disk before reloading them instead of loading them directly from memory.

Is there an equivalent in ruby api for :

  • SUTextureGetDimensions
  • SUTextureGetImageDataSize
  • SUTextureGetImageData

? because i’m using theses methods, not SUTextureWriterWriteAllTextures

13

Can you provide a minimum sample code snippet that reproduce this?

(whoops, replied from my private account. I’m the same person as tt_su)

14

Ok Thomas i will prepare a C++ sample who reproduce the issue.
thanks for your time and help

1 Like
15

Ok Thomas

here you will find a visual studio 2010 solution ready to compile which reproduce the bug.

Note : I’m using the windows sketchup sdk on a x86 plate form (downloaded from skechup official website on 22 october 2014).
before lauching this project for testing (debug mode only) be sure to update the path to SDK headers and libs and copy slapi.dll (x86 version) into the debug directory.

the project include the skp model and will produce a file named" dump.raw" which is the data buffer returned by SUTextureGetImageData dumped into a file.

thanks

sample : skpTexturesDump.zip (601.1 KB)

1 Like
16

Hmm…
I tried that rawpixels.net tool and found the same as you. Though if I entered 420 as width it all looked fine. (I noticed it was an even 45 degree skew.)

Also, the width and height is reported as 419x234 at 24bpp (3Bpp) - which should make for 419x234x3 bytes (294138). But the size of the returned data is 294840 - which matches 420x234x3.

Extracting the image from the SKP file I verify it’s 419x234.

I’m not sure where these extra bytes are coming from. Alignment bytes?

@bugra or @Paul - any idea what this might be? Have we received any other reports on SUTextureGetImageData?

17

Raster formats generally make the stride at least a multiple of 4. So here the stride would be 1260

18

Yea, that’s what I observed as well. Multiple of 4. This might be a regression however - as we changed the image handling lib for SU2014 and that added row padding. The one before that was not using padding. Though I’ve not seen if 4 is safe to rely on. Need to look further.

19

Great, It starts to make sense now.

20

If you need to find an immediate workaround this apply some defensive logic around it. Compute the expected data size based on the width, height and bpp vs the actual returned data size. Account for padding if the numbers doesn’t match.

We either need to expose the padding property or simply remove the padding before returning. I personally lean to the latter. Though I cannot say when we’d have a fix for this right now.