Inconsistent behavior of Origin

[arnfaldur]

When I run my program, svg origins work as expected. When I run it again, it seems like all the origins default to top left, making the svgs shifted to the right and down. Further reruns of the program have the same issue.

Sometimes the issue is fixed but it only lasts for one run and then on subsequent runs the issue returns.

I've tried all origins and the issue is the same on them all. I took a quick look at the rendering code but it's a bit too cryptic for a quick peek.

Do you have any ideas about what could be the issue? What information can I provide to help?

[arnfaldur]

I've looked a bit further into this and the system behaves more erratically than I described. the issue occurs pretty randomly. I managed to fix the issue for now by just using the TopLeft offset and then putting the graphic in a child entity that has an offset to compensate.

[Weasy666]

I noticed that to...and took a short look. I wasn't able to find where this happens. The origin gets correctly applied in prepare_svg_2d. There is maybe some other function which overrides the changes in some cases.

[hmeine]

I noticed the same. Could it be a timing issue, possibly related to how fast the asset server loads the asset? This hunch is based on my observation (in line with the original issue description above) that often, the first run works better than subsequent runs. Without looking at the code (or being a bevy expert), that could mean that with hot caches, the asset is loaded before the entity / transform is set up, and maybe some piece of code handling AssetEvents or so is not triggered correctly anymore?

[hmeine]

I looked at the code, but could not find anything that would confirm my theory. The offset is computed (twice) in each and every tick, and the size, translation, and transform are identical between runs that look ok or not.

If I am not overlooking anything, there are only two possible remaining explanations for that:

1. The mesh2d differs (but why should it?!), or
2. the camera setup differs?

[Weasy666]

I have (hopefully 🤞) fixed that problem. At least on my machine, i am now getting a consistent behavior. If you are still interested and willing to verify it, then you can use #21 and give it a try. 🙂

[nametable]

I do not experience randomness with current main or your #21 branch, however I do experience very odd behavior with both, where the svg is placed according to what seems to be a larger scaled version of the displayed svg.

To try to explain this, I'm saying that if I choose an origin of Origin::BottomRight, the rendered svg is displayed far up and left of where it should be, as if the width/height used in the origin calculation is larger than the rendered size.

Another odd behavior which is different between main and #21 , is that hovering over the mesh with bevy_mod_picking works properly in #21, but in main the hover events happen when the cursor is over a position that is not where the mesh is rendered.

Very odd behavior. I can try to create a simple reproduction of what I'm seeing if needed. Maybe I will get a chance to look through bevy_svg and see if I can also try to understand what is going on...

[Weasy666]

one of the boxes has Origin::TopLeft and the other Origin::BottomRight, that looks correct to me, because the viewbox of the boxes is 10 pixels bigger than the box itself.

If you have a screenshot, that would help me in understanding the problem 🙂

I think, the odd behavior of bevy_mod_picking on main comes from the hack i used to apply the origin. That hack applies the origin to the mesh transform in the render world, so the transform of the app world and render world are not the same and if bevy_mod_picking does work with the render transform, then the odd behavior is kinda expected. 😅 But if it works in #21, then that is great!

[nametable]

In the screenshot below, I have placed an svg 5 times (with each Origin and a translation of 0.0, 0.0, 0.0). The 0, 0 point is between the two grey gates. The only one which displays correctly is the one with Origin::TopLeft. The placement of everything makes sense if you think of an invisible scaled box which is the same shape as the pink svgs, being used for origin placement. My camera being used is a 3d orthographic camera scaled by 20x (.05), but if that was the problem, I would expect the placement to be much worse. The svg being used has its canvas/viewbox cut to the minimal size. Produced it with Inkscape:

Another interesting note: when I first ran the program, all svgs were placed in the same exact location, which was in the position expected for using Origin::TopLeft, after stopping and running again, I got the result in the screenshot. Although this is on the main branch. When I test with 11_fix_incosistent_origin, the first run gave the same result in the screenshot, so there is definitely improvement I think in 11_fix_incosistent_origin.

[Weasy666]

Ok i have taken a look and you are right that there is a problem with that file. The problematic part, that bevy_svg doesn't seem to like, seems to be the height and width

<svg
   width="13.126302mm"
   height="6.5801611mm"
   ...

if you, as a workaround, change them to

<svg
   width="100%"
   height="100%"
   ...

or remove them, then it seems to work.

It is a different bug, that is probably part of #18 and not of the inconsistent origin. To me, it looks like the origin problem is fixed in 11_fix_incosistent_origin, so i am going to merge it.