Spaces:
Runtime error
Thank you, but please finalize the improvment of the export :)
Not sure I understood you correctly about the camera distance. You mean, the gradio mesh viewer should be using such a camera distance so that object's scales are equal for the input image and the visualised mesh?
Thank you for the glb export!
Sorry I didn't see your reply
@dmitriitochilkin
.
Currently, building a mesh based on an image implies a camera distance, 3 angles of a virtual camera (azimuth, elevation and dutch, let's forget about the last one for now) and a focal length (more or less perspective).
For example, the iso house image is a 2.5D iso image, 45° azimuthal and 45° elevation with a infinite focal length (orthogonal camera, no perspective), but real life shots have more tricky angles and a defined focal length, like the burger, roughly 0°/15° 35mm from a 50cm distance.
The 3D viewer "sees" the mesh using this virtual camera information, examples:
Like the image, the iso-house in the viewer is seen from 45°/45°.
In the burger image, TripoSR gets the plane of the table and the plate, because the mesh is clearly aligned with it (the burger isolines are parallel to the plate), and we see the resulting mesh in the viewer with a default "camera" (view) that matches the picture (angles, distance and perspective). So the camera information exists somewhere.
The glb should export this "default" camera used for reconstruction and the viewer, to be able to open the mesh and match with the image again, this way you can really compare the 3D textured object with the 2D image you used.
Hope it makes more sense :)