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 ?
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.
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 :
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 ?
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.
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.
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 …
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
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.
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?
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.
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.