[Code] Real UV from UVHelper data

[thomthom]

Here's a snippet that will give you the UV values from the Point3D object that the UVHelper returns.

Code: Select all

def flattenUVQ(uvq)
  uvq.x = uvq.x / uvq.z
  uvq.y = uvq.y / uvq.z
  uvq.z = 1.0
  return uvq
end


More details can be found in this thread: viewtopic.php?f=180&t=21700&start=30#p191715

The manual's description of the UVHelper and it's return data has been confusing and not accurate. It also appears that there's a SU bug related to this.

Hopefully this will be of assistance to people trying to work with UV data in SU.

[Whaat]

So...can this code be used to get the proper UV data from distorted and skewed textures? If so, than I am greatly in your debt!

[thomthom]

I believe so... I was having problems with my UV mirror plugin where I could not properly transfer distorted textures from one side to another. Scaled and skewed worked fine, as the Q value then returns 1.0 from the UVHelper - but distorted textures returned values with a Q value other than 1.0 - and that didn't play well when passing back to .position_material.

This is what jeff99 said about this trials:

I also think the q values is unused. The matrix is to transform from a 3D (xyz) point in model space, to a 2D (uv) point in image space. They just put the data in a Point3d because they didn’t have a Point 2D. If they are using homogeneous coordinates, the q value you are seeing may be the "H" value, and they should have divided the u and v values by H. (Do a Google search on homogeneous coordinates).

I do however think that the U and V values are wrong. In our GeoSketch application we map areal images to faces. We calculate the UV coordinates in our code, and use position_material to map them to the face. The textures map to the faces correctly, and we see properly textured faces in the SketchUp model.

After building the model, we have a tool to export to OpenFlight. We tried using the UVHelper to get the UV coordinates back, but when we applied them in OpenFlight, the textures didn’t map properly. Bummer.

We then started storing our calculated UV coordinates as attributes on the face (the ones we used with position_material). Then we wrote these UV values to OpenFlight, and they worked perfectly.

H value? hm... this is new to me.

I had another look at the values returned. Comparing the regular texture with the non-regular it seems that the UV values are multiplied by the Q value. Could it be that they multiplied instead of divided?

If it is an H value, then I should be able to use that to restore the regular UV values?

That would be very interesting. Let me know what you find.

It would actually mean that they didn’t divide or multiply. For homogeneous transformations you are *always* supposed to divide by H. However, for some transformations, H comes out to be 1.0, so dividing doesn’t change the values.

Your observation may mean that they didn’t divide by H. But we don’t even know for certain that they are using homogeneous coordinates. We need more information.

Well Tom, I just changed my code on our theory that they did a homogeneous transformation, and the q value is actually the H value that they should have divided by. When I divided the u and v by q, and wrote those new values out, the textures mapped correctly. Your observation that the q value was not 1.0 for skewed projections was key. When H is 1.0, you get away with not doing the division.

Thanks Tom, your diligence on this matter paid off. We can now compensate for it in our code. We just need to get Google to promise to tell us if they ever choose to fix this, and do the division by H.

Let us know how your results are Dale.