Image type
-
Sorry if this has been discussed before. "Image" is a hard string to search the forum for...
Regarding the Image class:
I created an image, rotated around the x, then the z, then offset it. Then I made it into a component by adding a line, making the component, then deleting the line.Image.origin (before making into component) {-62.8, 24.9, 25.6}
Image.origin (after making into component) {79.4, 0, 25.6}
ComponentInstance.transformation * Image.origin {-62.8, 24.9, 25.6}exactly what you'd expect. The component transform matrix provides the extra scaling, position, etc. and the origin of the image is relative to containing component.
But when I copy that component into multiple instances, the Image.origin of every single copy is different! Even though the image is supposed to be an instance and therefore identical to all the others. And if I rotate the instance, the normal is different!It appears to me that the origin / normal of all the instance copies are the difference from the position of the original image when it was turned into a component. Everything inside a container (group / component) is supposed to unaffected by the operations that occur outside the container. But images seem not to obey that rule when in components (groups work fine, but in groups each Image is a distinct entity).
So, does anyone know what the rules are for Images in components? Is there anyway at all to use them with consistency?!
Thanks!
-
I think that finding origins, and vertex positions inside a component, still return their real world values, not their local internal values. So the image returning its origin seems normal? Though I've recently been rather confused by this.
Chris
-
@chris fullmer said:
I think that finding origins, and vertex positions inside a component, still return their real world values, not their local internal values. So the image returning its origin seems normal? Though I've recently been rather confused by this.
Chris
I found something odd today. I was investigating a face's normal. When I queried
face.normalwhile inside the component it belonged to it gave me one value. When I queriedface.normalwhen I had no groups/components open I got another.
It appears that face.normal returns a normal relative to the parent component when no groups/components are open. But when you open that group/component which contains the face it return a normal relative to the global axis (or grandparent?)
In any case - very odd, sounds like a bug. Could lead to unpredictable results when running scripts - results would depend on whether the user has a group/component open. -
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