Auto Framing problem misalignment with poster image?

[lordcraymen]

I have created a script that lets me save screenshots and camera target / orbit / fov values of a model in a database. I use the first screenshot as the poster for initial loading.

I noticed that if i leave the camera at the default values, the poster and model (both my model-viewer and poster images are always exactly square) match exactly, but the more I rotate the camera or move the camera target, the initial model view and poster are misaligned. I set the exact camera-orbit ,camera-target and fov ( I guess it is "deg" as getFieldOfView returns a value without unit? ) for the initial view that were used.

what could be the reason? is this a bug, or am I doing something wrong? Thanks for your support!

[diegoteran]

Hi @lordcraymen, I think I can help with this.
Can you provide a link to a demo with model-viewer and the image (maybe made in Glitch?), and a link to the script used?

[lordcraymen]

@diegoteran thanks for your support. I created a fiddle

https://jsfiddle.net/lordcraymen/k6o3jv8a/42/

You can see that for "normal" camera positions the poster matches the model position perfectly. But if you zoom in quite a bit (and for me showing details of a model initially is a use case) the model is always slightly zoomed out a bit, and the viewpoint seems also to be a little bit higher than the one captured from the original camera. I suspect some auto framing behaviour that I don't understand.

[lordcraymen]

@diegoteran After further investigation and experimenting with setting/reading the values and logging them to the console, I've made some observations:

https://jsfiddle.net/lordcraymen/k6o3jv8a/53/

The getFieldOfView.toString() method behaves inconsistently compared to other cameraProperty.toString() methods. It returns a float value without a unit, whereas in reality, it represents degrees ("deg"). To ensure consistency, I found that adding "deg" before applying the value gives a more accurate representation. However, there seems to be an issue with this approach.

I discovered that it's possible to zoom out beyond the bounds of the max field of view. I experienced this behavior on a MacBook with a Magic Mouse. When I zoomed in quite close (around 12 degrees) and then zoomed out rapidly, I could reach above 30.00 degrees. In such cases, the value returned by getFieldOfView incorrectly shows 30.00 degrees. This issue seems to occur sporadically after loading, especially when the initial field of view is not the default (12.00 degrees).

Considering these observations, it appears that there might be a bug affecting the behavior of getFieldOfView. It's possible that others have encountered similar issues. If anyone can confirm or provide more information about this behavior, it would be greatly appreciated. Thank you for your assistance and support.

[elalish]

If you've found a bug, can you please list out specific repro steps with a simple fiddle so we can reproduce?

[lordcraymen]

Thanks for your reply @elalish

I don’t know how to make a „simple“ fiddle to simulate the behavior I’m experiencing.

the fiddle https://jsfiddle.net/lordcraymen/k6o3jv8a/53/

shows the behavior.

If you click on the button, a screenshot with toDataUrl method is taken and applied as the poster. I set the cameraOrbit, Target and FOV to the values the API gives me at the moment the screenshot is taken. A script resets the src of the viewer to simulate the model loading and showing the poster in the mean time.

Expected behavior: The Poster lines up perfectly with the camera that was initialized with the values recorded at the time the poster was generated.

Steps to reproduce:

1. Klick the button -> poster lines up
2. Zoom in and klick button -> poster lines up
3. Zoom all the way out and klick button -> poster DOES NOT line up

My expected behavior is initializing the viewer with Orbit,Target and FOV at the time when the Poster was generated, the camera of the model always lines up with the poster.

Thanks for your support!

[elalish]

Thanks, I believe our auto-framing is messing you up. Changing the FoV changes how we auto-frame (you'll get a different radius). Since you set the cameraOrbit in JS before the model loaded, I believe it's overwritten by the auto-frame. If you set it in a "load" event callback, I think it may work as you expect. I also think if you set the camera-orbit as as HTML attribute instead of through JS that the auto-framing won't overwrite you.