Good point. Trouble is I often have the face within a group within a group within a group... I suppose I could write a function to keep going backward if worse comes to worse. Just wondering if there's a better way.

I know I can use the face.material.name to find the name of the material currently assigned to that face but what if there is no material assigned to it and the material of the group is currently being applied in its place? Can I somehow detect that instead?

@thomthom said:

You sure you have to exit the current context, can't you take the model.edit_transform into account when doing your operations?
http://code.google.com/apis/sketchup/docs/ourdoc/model.html#edit_transform

That was super helpful. I used that transformation matrix to adjust my data and it worked perfectly. Much obliged!

In order to accomplish what I need, I use the info given above to get out of the context of the group back into the overall context:

while !Sketchup.active_model.active_path.nil?	
	Sketchup.active_model.close_active
end

It would be nice if I could save the position somehow, go to the global context as shown in the code but then go back to the context when I'm done. That way the user doesn't have to re-double-click back to where they were.

I'm not seeing anything in the model class that would appear to do that. Anyone have any ideas?

Thank you both very much. I believe that's exactly what I need.

When the user hasn't double-clicked on a group or component, the active context is the whole model (and the active coordinate system is the global coordinate system)

If the user does double-click into a group, the active context is that group and the local coordinate system associated with that group.

I'm trying to figure out how to tell where the user is when they start my script. I need to know if they aren't drilled down into a group or sub-group of a group or if they're all the way out.

Does anyone know how to do this?

Thanks for carrying this on ThomThom. I think you're on to something here and I'm experimenting further.

One of the complicating factors for me is that the face I want to apply texture to is often in a group which is in turn in a group (the wall file I posted earlier was a simplified version of what I'm doing).

I notice that when I run the UVhelper script modified per your homogenous tip earlier, I get better UV values. I also notice that the real-world vertex positions are in global coordinates (returned from the face.outer_loop.vertices.each method). Conversely, when applying a texture, you need to use coordinates that are based on the local coordinate system that the face belongs to.

I'm going to play around further. I've attached my modified uvhelper script. If what I said above is confirmed about local and global coordinates then I'll modify the uvhelper script further to report in local coordinates.

uvhelper.rb

Woops, just found this in the API docs regarding the group.make_unique method:

@unknownuser said:

The make_unique method is a deprecated method used to force a group to have a unique definition.

Copying a group using the copy tool in SketchUp will create copies of the group that share a common definition until an instance is edited manually or this method is used. If multiple copies are made, all copies share a definition until all copies are edited manually, or all copies have this method used on them. This method ensures that the group uses a unique definition entry in the drawing database.

What worries me is that this is deprecated. I need this method to always be around for my program to work.

Here's what I don't understand...

1. Draw a rectangle and push it to make a cube. Make the cube a group.
2. Select one of the faces in the group and, in the ruby window, type "yo = Sketchup.active_model.selection[0]"
3. Now, copy the cube group so you now have two cubes as two different groups.
4. In the ruby window, type "yo.hidden = true"

BOTH FACES DISAPPEAR! Both cubes are affected!

I would have thought only the first face should disappear if they are both groups. They both should disappear if they are two instances of the same component definition. Me very confused!

Thanks! Works pretty well. Leaves a "1" in the corner but I can live with that. Appreciate it.

Anyone know how to clear the text? I just hit enter a bunch of times but then those enters are put into my typing history that I have to skip over to get back to previous things I typed. Just want CLS or something like that.

Understood. Thanks for the tip.

I'm not sure, knowing that, why the uv values changed when I changed the size and fit of the texture and repositioned it so it had the same look.

Also thinking out loud again. Even though the UVhelper script returns uv values as whatever unit the model is in (in my case, inches), it really is a unit-less value.

Say the value is 0.5....

I wonder if that refers to have the size of the picture dimension or half the size of the geometry that's being applied to.

Well, I changed the scale of the texture to be a width of 40' and a height of 8.5'

I then remapped the texture by hand using the pins. When I then looked at the UV values, I got the same geometry positions but the uv coordinates had changed to unit values:

[479", 0", 95.5"],
[1",1",1"],
[0", 0", 95.5"],
[0",1",1"],
[0",0",0"],
[-0", -0", 1"],
[479", 0", 0"],
[1", -0", 1"]

I made a script that uses these values and the script does work. Not sure why as I tend to think you're right: the UV coordinate mappings should overide size and width - otherwise, why have more than one pair of coordinates?

Me still confused.

@thomthom:

Interesting point. That makes sense. Sahi's method still has some application here as he just specifies one point in the real world and one in the texture. That allows the width and height parameters of the texture to take control.

I imagine if you gave it more point pairs, the width and height parameters would not apply anymore.

Guess I'm still stuck.

Do you think this is a bug? Should I file it?

@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.

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.

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

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.

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.