Trouble with .position_material method

fizgig

So I mapped a picture onto a face that is a simple rectangle (four vertices). I stretched and pulled it to fit the texture to the face perfectly.

I then used the UVhelper plugin to get the four points of uv coordinates.

I then make my own pts matrix with that data and try to reapply the texture using this script:

pts=[
							[479.0, 0.0, 95.5],
							[10.916205, 18.852445, 0.992521],
							[0.0, 0.0, 95.5],
							[9.823678, 18.653161, 0.981672],
							[0.0, 0.0, 0.0],
							[9.872379, 17.819573, 0.986582],
							[479.0, 0.0, 0.0],
							[10.964905, 18.018858, 0.997432]
							]
						
Sketchup.active_model.selection[0].position_material "In_Theatre_Side", pts, true

I've attached the model with the texture applied correctly. I've also attached pictures of before (manually moved texture) and after (texture applied via ruby).

Anyone know what's going on?

Texture placed manually...

UV Helper tells me what's up...

My Ruby script results...

wall.skp

fizgig

Can anyone confirm if this is a bug? I'll file it but I'm not sure if it is. I might be doing it wrong.

thomthom

Might be something with other parts of the code that applies the mapping. Got a code example? Not just the array?

fizgig

The code was in the first post at the top. I've attached it as a file this time.

code.rb

thomthom

hm... there is something weird with the UV co-ords the UVhelper returns. That textures is mapped to be stretched almost one time across the face - the UVs to stretch a map across a face once is should not exceed 1.0

I'm not sure what's going on.

thomthom

Just noticed something...

Error 404 (Not Found)!!1

(code.google.com)

@unknownuser said:

a Point3d containing the UV coordinates where the X value is the U value, the Y value is the V value and the Z value is a Q value (which is not used).

It claims that the Q value is not used. But that does not seem to be the case from the values we get from the UVhelper.

fizgig

@thomthom said:

hm... there is something weird with the UV co-ords the UVhelper returns. That textures is mapped to be stretched almost one time across the face - the UVs to stretch a map across a face once is should not exceed 1.0

I'm not sure what's going on.

Yeah, if I understood what the units of the u/v coordinates were, I'd be able to troubleshoot this more.

thomthom

If you have a texture tiled once across a face you'd have a set of UV co-ords like this:

0.0,0.0
1.0,0.0
1.0,1.0
0.0,1.0

You then match these pairs with 3D points the four corners on the face.

If you want to tile the texture two times across:

0.0,0.0
0.5,0.0
0.5,0.5
0.0,0.5

Does that make sense?
With the given set of XYZ 3D points - the UV values define how many times the texture is tiled between the XYZ points. 1.0 = 100% - 0.0 = 0%

thomthom

@thomthom said:

0.0,0.0
0.5,0.0
0.5,0.5
0.0,0.5

sorry - I might not be correct here...

thomthom

Yea - I was wrong. If you want to tile a texture twice it should be 2.0.
0.5 will tile the texture only half.

thomthom

I'm really puzzled by the values returned by the UVHelper.

It does seem that the UVHelper uses the Q value when the texture is skewed.

However - it returns some strange numbers - even for textures stretched once across a face. You'd think it's be returning 0.0 or 1.0 values for each corner vertex - but it doesn't. I can't make sense of the numbers.

Btw: I made a small tool to quickly investigate the UVQ values: http://forums.sketchucation.com/viewtopic.php?f=180&t=21472&p=183291#p180592

fizgig

Using your comment - that the UV coordinates are normalized to a max of 1 (for no tiling),
I changed the pts matrix to the following:

pts=[
                     [479.0, 0.0, 95.5],
                     [1.0, 1.0, 1.0],
                     [0.0, 0.0, 95.5],
                     [0.0, 1.0, 1.0],
                     [0.0, 0.0, 0.0],
                     [0.0, 0.0, 1.0],
                     [479.0, 0.0, 0.0],
                     [1.0, 0.0, 1.0]
                     ]

It is almost perfect. The picture isn't stretched to fit perfectly like it's shown in my first post. That does seem to beg the question as to why any UV coordinate would have a value over 1.0 if it isn't tiled. Wish I could tweak the picture positioning a bit and save it.

thomthom

I'm curious to how that texture in your sample model was textured. The UVQ values returned gives Q values that are not 1.0. If I remove the material and apply it again - stretching to fit - I get a new set of UVQ values - this time their Q values are 1.0.

fizgig

Not sure what you're getting at. My q values are very close to 1.0 as it is. I think they're ignored anyhow.

I think the way the texture mapping works is you specify up to 4 vertex pairs where each pair has a vertex in the model and a vertex on the texture. If you give 4 pairs, it will stretch, rotate, shear and tweak the texture until all pairs line up. You don't need q-values on the texture to accomplish that, just u,v values.

fizgig

Sure wish I could figure this out. Anyone have any ideas why I'm experiencing the problem with this texture and face?

thomthom

I mentioned this to the Google dev team. I asked what the Q value did - as the manual claims it's unused.

@unknownuser said:

Hi Thomas,

I looked at the code, and the Q value (or Z attribute of the Point3D returned) is explicitly set to a value of 1.0 in the Point3d object returned. However, the method also does the transform to get the UV values, (which is stored in a 3x3 matrix) on the return Point3d after it initializes Q/Z to 1.0. So for transform matrices such as skew, which operate on the Z coordinate, you will end up getting a value that does not equal 1.0 (this probably also explains why UVHelper returns Point3d objects in stead of a simple UV array, so that the matrix math lines up -- still doesn’t excuse it though ). So while the value may not always be 1.0, it is not getting the value from any internal representation of the model.

Matt

sahi


pts=[[479.0, 0.0, 95.5],[0,0,0]]
material.texture.size = [height, length]
face.position_material material, pts, true

fizgig

Appreciate the posts everyone. Not sure if I have a solution though. I'm trying to understand why the UVhelper script is giving me point data that doesn't work when I use it. Thanks for any insight you can provide.

fizgig

@sahi: I think you're on to something there with the texture.size method. I notice that the texture doesn't have the right height and width. In fact, I never really noticed those parameters before, I just left them at whatever they were and then stretched the texture out with the pins.

Since the texture has a width of about 2.5' and the wall itself is 40' long, the texture has to be stretched to 16x it's width in order to fit. That would explain some of those large values in the UVhelper script.

Unfortunately, I have to put this down for awhile but I'll report back later what else I figure out.

thomthom

hm...

The material size should only be relevant if thereæs no UV mapping. It specifies the default size of the texture. When you map 3D model points to 2D UV points it shouldn't matter.