3D models are very variable: some are defined with just triangles, some include quads, some are NURBS or subdivision surfaces. Sometimes two sides per polygon are considered, sometimes just one.
Ways of navigating a 3D model also vary wildly. Sometimes you just want to pivot/rotate them around a little, but sometimes "walking" inside them makes more sense.
Then there are materials and lights, and here people go wild with ideas.
In our "current world", if you want a 3D viewer, you use WebGL and Javascript, and voila, what you get is what you see in all browsers that support WebGL.
> But wow you gotta get a lot of JS slapped together to just get something rendering
Indeed. But there are some quite nice 3D model viewers out there ready to roll, easy to embed, and full of features.
Seems like there's a reasonable parallel here with video content. Before native video, video was always in a flash player, and that was good enough for a lot of people— it was proprietary of course, and it it required a plugin. But it worked.
Now with native video, there are still precious few instances where it's just the browser's native video widget. In basically all serious commercial scenarios, there's at least custom player chrome, navigation buttons, overlays, JavaScript to pause the video and play an unskippable interstitial, etc etc.
I would argue that the current state of affairs for 3D viewers is closer to the current state of affairs for video than it is to the Flash player story of 15 years ago. No, there is no explicit "model viewer" widget, but you could just as easily argue that WebGL canvas is to 3D content what <video> is to h264 and webm content.
My understanding is that a lot of the "custom" players out there today are lightly-skinned <video> tags. Custom controls are a very small part of what it means to make a video player
As long as they still use a <video> tag does the chrome or JS implementation matter? The tag captures the semantics that Google can now use to show the video in their search results! etc. Using custom plugins like Flash made this much harder.
> In our "current world", if you want a 3D viewer, you use WebGL and Javascript, and voila, what you get is what you see in all browsers that support WebGL.
Under "Considered Alternatives" [0]
> 4. Do not add a new element. Pass enough data to WebGL to render accurately
> As noted above, this would require any site that wants to use an AR experience to request and have the user trust that site enough to allow them access to the camera stream as well as other information. A new element allows this use case without requiring the user to make that decision.
I’m not convinced a script-less element protects privacy: recall that subtle differences in how different machines (running the same browser) render certain <canvas> operations, it’s a given that the same underlying hardware differences will lead to subtle 3D model rendering differences (e.g. subpixel antialiasing, measuring shader render time, etc) and thus add another way for unscrupulous websites to fingerprint users.
Another issue is that it’s inevitable that support for fragment and vertex shaders will be added, which is another huge issue (MS put-off supporting WebGL for years out of plausibly legitimate concerns about possible vulnerabilities in WebGL shaders).
…of course that’s all fine on Apple’s uniform hardware: fingerprinting MacBook users with their identical GPUs will be harder compared to PC users with their huge matrix of possible GPU chipsets, GPU drivers, and GPU performance/quality settings - which all affect how simple 3D models are rendered.
I always though the way Windows' Geometry3D[0] element worked was really nice. You define a list of points in a particular order. Whether a face is on the "inside" or "outside" depends on the direction you "wind" a metaphorical string around those points. After defining some primitives you can start to compose them into a single model.
Ways of navigating a 3D model also vary wildly. Sometimes you just want to pivot/rotate them around a little, but sometimes "walking" inside them makes more sense.
Then there are materials and lights, and here people go wild with ideas.
In our "current world", if you want a 3D viewer, you use WebGL and Javascript, and voila, what you get is what you see in all browsers that support WebGL.
> But wow you gotta get a lot of JS slapped together to just get something rendering
Indeed. But there are some quite nice 3D model viewers out there ready to roll, easy to embed, and full of features.