How does geometric element positioning work? #8610
-
|
I thought I knew this, but I'm seeing something really weird on one model in my iTwin.js viewer. I have two elements, They have no part instances, this is inline element geometry.
According to placement3d the geometry should be relative to the placement. So why are the two elements visibly next to each other in the viewer? Is there more to that calculation than I am aware of? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 14 replies
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
ok so I checked and neither of those elements are listed in the schedule script. What else could be affecting the position? Am I misunderstanding something? |
Beta Was this translation helpful? Give feedback.
-
Are they supposed to look next to each other? What do the coordinates in their respective geometry streams look like? Do you observe this only with exportGraphics, or do the tiles produced by the iModel backend exhibit the same behavior? |
Beta Was this translation helpful? Give feedback.
-
|
That all sounds normal and fine then. The geometry is indeed relative to the placement. When you build a geometry stream you have options for specifying the geometry in local or world coordinates. Did you create these elements? Did you use world for one element and local for the other? |
Beta Was this translation helpful? Give feedback.
-
|
I did not create them. I would have to check that connector data. I agree that looks correct in iTwin. I was confused about the exportGraphics output. Perhaps I have just encountered data that didn't have a placement origin of 0,0,0 for the first time (surprising to me), and didn't know until now that exportGraphics assumes everything is placed at 0,0,0. I swear I've processed geometry with non-zero origins... I'll need to check old data. I've been exporting the placement origin manually with the exported graphics data. Perhaps that only worked because I've only seen placements of 0,0,0? |
Beta Was this translation helpful? Give feedback.
-
|
Well if you're confirming that Maybe I've only seen non-zero origins in part geometry since I handle those differently |
Beta Was this translation helpful? Give feedback.
-
I hope that isn't the case as it's recommend that geometry be stored relative to 0, 0, 0 and unrotated and positioned in the world using the placement transform. The placement represents the local to world transform that is applied to the geometry read out of the geometry steam. Mesh A stored vertices that are not near zero and a placement that doesn't apply a translation (Not recommended).
It applies the placement transform to the mesh output to return it in world coordinates. If you aren't returning part instances + transforms it also applies the full part instance to world transform. |
Beta Was this translation helpful? Give feedback.
-
|
@MichaelBelousov look at the placements for the two elements. One is probably an identity transform, the other should have a big translation in it. |
Beta Was this translation helpful? Give feedback.
-
|
Yes |
Beta Was this translation helpful? Give feedback.
-
I know this is from what I derived the "placement origin" data in the initial post. |
Beta Was this translation helpful? Give feedback.
-
|
So we're good or do questions remain? |
Beta Was this translation helpful? Give feedback.
I hope that isn't the case as it's recommend that geometry be stored relative to 0, 0, 0 and unrotated and positioned in the world using the placement transform.
The placement represents the local to world transform that is applied to the geometry read out of the geometry steam.
Mesh A stored vertices that are not near zero and a placement that doesn't apply a translation (Not recommended).
Mesh B stored vertices near zero and has a placement that applies a translation (Recommend).
It applies the placement transform to the mesh outpu…