Image type
-
Oh, really? Huh, I always thought that, for normal geometry, it was always relative to the 'container' it's in. Of course that may depend on the commands you use. There may be some commands that return 'world frame' coordinates and some that return 'local frame' coordinates. Unfortunately, for images the commands are sparse.
But it doesn't look like the image.origin and image.normal methods are returning world frame coordinates or local frame. I'll check again and pay closer attention, but they seem to be relative to some "original configuration" of the image (which of course isn't available).
@ thomthom: I've noticed this exact same thing. I've never looked at it for faces, but images have the exact same behavior. Faces have the 'mesh' command which seems to produce the correct coordinates, normals, etc. But images don't have that.
-
Not sure if it helps, but you can get the face and edge entities of an Image by getting to it's definition. The definition allow you access to the
.entitiescollection.
However, it won't give you per instance data.I was actually looking into, earlier this summer, on trying to extend the Image class to have a
transformationmethod - but didn't manage to create the correct transformation. -
Images have definitions?!
That actually may help a lot... I'll have to take a look. Is this an unpublished method to retrieve it, or just one I've overlooked? -
They are part of the
model.definitionscollection.Like with groups, images are also stored there. To detect them, a definition has the
.group?and.image?method. -
Hmm... that's promising. Maybe there's a more reliable way coming in from that direction...
-
@avariant said:
Images have definitions?!
That actually may help a lot... I'll have to take a look. Is this an unpublished method to retrieve it, or just one I've overlooked? -
Hi Alex, thanks for the link. Looking at your code, you are doing just about the exact same thing I'm doing except your scaling by width/pixelwidth, height/pixelheight. I'm not doing that, I'm just using width and height. I'll definitely try it out!
-
Hm... it looks like using your code didn't solve my problem. Are you familiar with the trees from tomsdesk? The leaves are images, contained in a component, and that component is set to face-me. The issue is not so much getting the correct transform for an image, but getting a correct transform when the image is contained in a component.
-
@avariant said:
Hm... it looks like using your code didn't solve my problem. Are you familiar with the trees from tomsdesk? The leaves are images, contained in a component, and that component is set to face-me. The issue is not so much getting the correct transform for an image, but getting a correct transform when the image is contained in a component.
It doesn't work when the image inside a component?
-
That seems to be the issue. Like what I said in my first post, for some reason the point returned from the 'origin' method isn't consistent when it's inside a component, nor is the 'normal' method. Since those two, at least, are necessary to create the transform matrix of the image relative to it's container, in this case the component, then I can never get a correct transformation.
And it doesn't always happen. With some components, it works just fine, other times not.
-
@avariant said:
... With some components, it works just fine, other times not.
You should take into account transformation of component!
-
Oh, I am, most definitely.
The issue is that the transformation created for the Image is inconsistent. If I have 10 instances of the same component with the same image in it, each one might give me a different result when asked for it's origin. But it shouldn't right? Because it's inside the parent component, and because I'll be multiplying in the parent components transform, the image should have the same origin, normal, and zrotation for all the instances. But sometimes it doesn't. (And I can't figure out the difference from the times it does work and the times it doesn't)And maybe related to that, as posted above, when you actually have a component open, the results are different than when you don't. I suppose there's no magic bullet until I can figure out what's different for the images that don't work...
-
@avariant said:
And maybe related to that, as posted above, when you actually have a component open, the results are different than when you don't. I suppose there's no magic bullet until I can figure out what's different for the images that don't work...
The "magic bullet" (or as close as it currently gets) is to query the Sketchup.active_model.active_path which will return an array or nil. If it's not nil, then you're in a g/c and you'll see an array listing the hierarchy of objects and you can check all the transformations as needed.
-
model.edit_transform
returns the transformation of the current edit session - so use that in combination with the instances' transformations to adjust to suit...
http://code.google.com/apis/sketchup/docs/ourdoc/model.html#edit_transform -
@avariant said:
And maybe related to that, as posted above, when you actually have a component open, the results are different than when you don't. I suppose there's no magic bullet until I can figure out what's different for the images that don't work...
This is apparently designed behaviour. When a group/component is open the co-ordinates are normalised to global co-ordinates.
-
That's definitely good info, especially the model.edit_transform command, and helps explain the weird behavior when a component is open, but that's not really the issue.
Assuming no components are open or selected or anything, given the above configuration of multiple instances of a component with an image in it, the image commands (origin, normal) return different information for each instance, but only with certain models. (This is using a ruby script to gather up all the image info, not done manually) I'm accumulating the transforms down through the hierarchy just fine. If the image was a face instead, it works without problem, so it's not the model hierarchy transforms. It's the last bit, the image.
I guess it's kind of silly to look for an answer without really understanding what all the influencing factors are. At least now I know that SU modifies the transformation when a component is open; I didn't know that before, so thanks for that!
Maybe if I can consistently create the circumstances, I'll post a scene and a ruby script to demonstrate what I'm getting at. Thanks! -
The behaviour with open components apparently pre-dates the SU ruby API. Tyler provided that bit of info.
Advertisement