6 ms·

Based on the comments so far, I think I'm in the minority who think this would be a good feature for the web. This proposal might not be perfect, but I think th

Based on the comments so far, I think I'm in the minority who think this would be a good feature for the web. This proposal might not be perfect, but I think the idea is great. There's lots of good reasons to semantically want to embed a 3d model in a page, like any other type of media. Say you're writing a course explaining how differential gears work - a 3d model of that could be really handy to look at to learn. A shoe company wanting to have a model of their sneakers in their shop. Sure we've got canvas, and WebGL, and WebGPU, and libraries like three.js, which work. But wow you gotta get a lot of JS slapped together to just get something rendering. E.g. I wonder how long transit spent getting a truck rendering on this page. https://panic.com/transmit/ https://panic.com/transmit/ The other challenge of doing everything yourself is that code is stuck in time. It's going to get very minimal benefits from browsers and devices getting better over time, it won't get native UI changes - in 5 years it'll look very dated, if it's still accessible. A model element makes a lot of sense to me.

dsign 5y ago
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.
- albrewer 5y ago
  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. [0]https://docs.microsoft.com/en-us/dotnet/api/system.windows.media.media3d.geometry3d?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.windows.m...
- mikepurvis 5y ago
  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.
  - truted2 5y ago
    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.
  - brundolf 5y ago
    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
- mistersquid 5y ago
  > 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. [0] https://github.com/WebKit/explainers/tree/main/model#considered-alternatives https://github.com/WebKit/explainers/tree/main/model#conside...
  - DaiPlusPlus 5y ago
    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.
stefan_ 5y ago
It seems history teaches us the exact opposite. Nobody uses the native input elements because they can't be sufficiently styled and customized but simultaneously have significant behavior differences between browsers. They also of course languished for the longest time, at points looking out of place with the browser chrome itself.
- jeroenhd 5y ago
  As a user, I curse every time a website decides that my theme is incompatible with my computer's theme and that my scroll bar should in fact be bright red and 1 pixel wide just like on the designer's Macbook, and that buttons should look exactly like tabs, links, checkboxes and radio boxes because that's what the brand designer wanted. Native component's can't be styled because of very good reasons and unless you're developing a game they probably shouldn't be. HN uses purely native components and it's one of the best websites I regularly visit. Fast, responsive, works on every device. I can't help but feel like web developers recreating native components are doing so out of incompetence or complete disregard of usability.
  - TimTheTinker 5y ago
    What you're describing is a failure of particular designers and developers to build an acceptable user experience. But that doesn't mean that good front-end designers and developers don't exist, or that good UI/UX doesn't exist outside of native browser controls. I'm a front-end developer, and I currently work with one of the best UI designers in the industry (she's really, incredibly good). We consistently get very positive feedback on our work - currently rebuilding the front-end UI for a unicorn SaaS startup. Good UI controls take a lot of work on small details even beyond the design mocks - event handling, styling, keyboard navigability, layout behavior, configurable options... but when it all comes together it feels great to use.
  - 8note 5y ago
    What's the tag for the native button that shows the up votes and downvotes on HN? Is it like <up-button/> or something?
- 5y ago
Joeri 5y ago
Couldn’t you host a model custom element implementation on a cdn and get almost all those same benefits? I would rather see a turn to custom elements over extending the browser’s native set of tags further.
- gfxgirl 5y ago
  yes and an example already exists here https://modelviewer.dev/ https://modelviewer.dev/
- kevingadd 5y ago
  FYI, browsers have been separating out the cache for each website for a long time, so you will have to re-download that implementation from the CDN for each website that uses it.
  - still_grokking 5y ago
    There's a medicine against the CDN craze. https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/ https://addons.mozilla.org/en-US/firefox/addon/decentraleyes...
baybal2 5y ago
You can already embed VRML
- CrazyPyroLinux 5y ago
  I was just coming here to say this, but as a joke. :)
Jasper_ 5y ago
Years of trying to treat models like images shows us it's a poor idea. Maybe now with Disney/Epic PBR being the standard material model it's closer but, that Panic truck? Good luck defining the exact lighting for that so it renders correctly and consistently. The spec text even says that the lighting environment will come at a later date. So, no, you don't seemingly have any control over one of the most important parts that makes the visuals of your scene. Even VRML could do that. Also seemingly no word on the camera position, or FOV, or anything else. So it doesn't seem feasible to get even remotely matching renders, at which point, why bother?
- ruined 5y ago
  >This proposal does not aim to define a mechanism that allows the creation of a 3D scene within a browser using declarative primitives or a programmatic API. the goal isn't to fully render scenes, it's simply to gain the ability to include a 3d resource in the page semantically. heavier solutions to render scenes already exist.
  - bhhaskin 5y ago
    Seems already possible using a custom web component.
    - oneplane 5y ago
      You can also just render a complete OS in a canvas using wasm. Heck, why use the browser at all, just let them download a custom binary... You see where this is going right?
      - silon42 5y ago
        Mistake was made when adding Javascript.
        southerntofu 5y ago
        So true. I'd be curious about developing modern web standards without JavaScript. I'm aware of gopher/gemini but somehow i like the semantic aspects of the web.
gfxgirl 5y ago
The problem is no feature set will meet even 5% of the needs of most devs. Maybe you'd like to display a "model" of a city. Oh, too big, needs to be streamed, LODed, etc. Maybe you'd like to display a "model" of a forest. Oh, well, you need a terrain renderer that dynamically generates geometry from height data plus you need a specialized renderer to render the grass and bushes else the frame rate will be 1fps. You'd like to display a "model" of Waikiki Beach at sunset and you'd like to use a water shader with a sunset and reflections. You'd like to display a "model" of the Los Angeles mountains as viewed from downtown Los Angeles, complete with atmospheric ray scattering to convey the air quality. You'd like to render a fur covered animal and render fur, not just a texture. You'd like to render a "model" of a person with realistic hair. You'd like to render a "model" of wax candle with subsurface scattering so it actually looks like a candle. You'd like to render a "model" of camera lenses to explain refraction so you'd actually like them to refract. Engines like Unreal and Unity let you change the way they render because every situation requires different solutions. No generic "render a model" covers rendering all models. An API like WebGPU/WebGL lets devs add what they need. Oh, you say, we'll just add features to cover those use cases. Now Chrome will have features A,B,C, Firefox, A,B,D, Safari B,E. That will be hell for devs. An API lets people write libraries with features they need that work in all browsers. They don't have to wait for the magic day N years from now that all browsers finally add the feature they want. Further, people will keep requesting non-3D features "I want to have an <input type="text"> in my scene". "I want to have a <canvas> in my scene" that I can draw on in realtime. "I want to have a model that displays a <canvas> in my model so people can draw logos on their avatar's t-shirts". I want to play sounds in 3D from specific points in my model, etc. until this "model tag" has all of HTML and all of JavaScript inside Again, this is all better solved with APIs instead of trying to cram more and more and more features into a single tag. > The other challenge of doing everything yourself is that code is stuck in time. It's going to get very minimal benefits from browsers and devices getting better over time, it won't get native UI changes - in 5 years it'll look very dated, if it's still accessible. And neither will a model tag. In fact it will be worse. First off, when I put a model on my page, I want it to look they way I or my artist created it. I don't want it to change over time based on someone else's idea of how it should look.
- dmitriid 5y ago
sam0x17 5y ago
Yeah I actually agree -- this is very in line with the semantic web and is in many ways is a much more elegant proposal than Canvas (though I love canvas). This will make it much easier for devs to embed a 3D model in a page without sideloading all of three.js or similar monstrosities. It will also enable 3D model search engines to more easily find models on the web because of the semantic <model> tag.
brundolf 5y ago
My first thought was "this probably wouldn't work for games, and other uses of embedded 3D content are pretty niche" But then I thought, maybe they're niche because something like this doesn't already exist
- pphysch 5y ago
  3D is a poor choice for many visualizations because when it is rendered in 2D, information is hidden behind the model being transformed over time (either manually by the user or via automatic rotation, etc). IMO it should only be considered if there are challenges with flattening the data in question. For example, if the data represents an actual scanned 3D object. On the other hand, rendering arbitrary data as "3D" models is usually a cute waste of time. There are much more effective ways to explore and analyze it.
phkahler 5y ago
>> But wow you gotta get a lot of JS slapped together to just get something rendering. Or you can just model your item in solvespace (or link an STL file) and export it as HTML. Done. https://solvespace.com/index.pl https://solvespace.com/index.pl Examples: http://m-labs.hk/software/solvespace/ http://m-labs.hk/software/solvespace/
- leppr 5y ago
  > WebGL export using Three.js, which is how the interactive models on this page work
  - phkahler 5y ago
    Yes, it does the slapping together for you.
fluxem 5y ago
Instead of spending time on the new vague proposal, maybe Apple should spend time supporting existing web standards like WebGL 2.0 by default (instead of hidden flags).
- likeclockwork 5y ago
  Agreed. This proposal makes the Safari sandbagging even more apparent.
- alanwreath 5y ago
  This ^^ I’d be surprised if Apple has any new learning to offer or if they have surveyed the landscape and decided this is the way to go.
- galad87 5y ago
  WebGL 2 will be enabled by default in Safari 15.
Impossible 5y ago
It makes a lot of sense to me as well having seen code for model viewers using WebGL. Before gltf, (relatively) standardized PBR materials, etc. it kind of made sense to just give people WebGL and tell them to figure it out. Also WebGL clearly was designed for browser games and game engine ports where it makes sense. As 3D models become more common, having robust fast implementations, standard controls, etc makes sense. As long as WebGL/WebGPU interop is good so it's possible to customize materials or still use model loading (if you want) but do your own draw calls I think it's fine
deleted 5y ago
[deleted]

dsign 5y ago

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.

albrewer 5y ago
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. [0]https://docs.microsoft.com/en-us/dotnet/api/system.windows.media.media3d.geometry3d?view=net-5.0 https://docs.microsoft.com/en-us/dotnet/api/system.windows.m...
mikepurvis 5y ago
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.
- truted2 5y ago
  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.
- brundolf 5y ago
  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
mistersquid 5y ago
> 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. [0] https://github.com/WebKit/explainers/tree/main/model#considered-alternatives https://github.com/WebKit/explainers/tree/main/model#conside...
- DaiPlusPlus 5y ago
  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.

stefan_ 5y ago

It seems history teaches us the exact opposite. Nobody uses the native input elements because they can't be sufficiently styled and customized but simultaneously have significant behavior differences between browsers. They also of course languished for the longest time, at points looking out of place with the browser chrome itself.

jeroenhd 5y ago
As a user, I curse every time a website decides that my theme is incompatible with my computer's theme and that my scroll bar should in fact be bright red and 1 pixel wide just like on the designer's Macbook, and that buttons should look exactly like tabs, links, checkboxes and radio boxes because that's what the brand designer wanted. Native component's can't be styled because of very good reasons and unless you're developing a game they probably shouldn't be. HN uses purely native components and it's one of the best websites I regularly visit. Fast, responsive, works on every device. I can't help but feel like web developers recreating native components are doing so out of incompetence or complete disregard of usability.
- TimTheTinker 5y ago
  What you're describing is a failure of particular designers and developers to build an acceptable user experience. But that doesn't mean that good front-end designers and developers don't exist, or that good UI/UX doesn't exist outside of native browser controls. I'm a front-end developer, and I currently work with one of the best UI designers in the industry (she's really, incredibly good). We consistently get very positive feedback on our work - currently rebuilding the front-end UI for a unicorn SaaS startup. Good UI controls take a lot of work on small details even beyond the design mocks - event handling, styling, keyboard navigability, layout behavior, configurable options... but when it all comes together it feels great to use.
- 8note 5y ago
  What's the tag for the native button that shows the up votes and downvotes on HN? Is it like <up-button/> or something?
5y ago

Joeri 5y ago

Couldn’t you host a model custom element implementation on a cdn and get almost all those same benefits? I would rather see a turn to custom elements over extending the browser’s native set of tags further.

gfxgirl 5y ago
yes and an example already exists here https://modelviewer.dev/ https://modelviewer.dev/
kevingadd 5y ago
FYI, browsers have been separating out the cache for each website for a long time, so you will have to re-download that implementation from the CDN for each website that uses it.
- still_grokking 5y ago
  There's a medicine against the CDN craze. https://addons.mozilla.org/en-US/firefox/addon/decentraleyes/ https://addons.mozilla.org/en-US/firefox/addon/decentraleyes...

baybal2 5y ago

You can already embed VRML

CrazyPyroLinux 5y ago
I was just coming here to say this, but as a joke. :)

Jasper_ 5y ago

Years of trying to treat models like images shows us it's a poor idea. Maybe now with Disney/Epic PBR being the standard material model it's closer but, that Panic truck? Good luck defining the exact lighting for that so it renders correctly and consistently. The spec text even says that the lighting environment will come at a later date. So, no, you don't seemingly have any control over one of the most important parts that makes the visuals of your scene. Even VRML could do that. Also seemingly no word on the camera position, or FOV, or anything else. So it doesn't seem feasible to get even remotely matching renders, at which point, why bother?

ruined 5y ago
>This proposal does not aim to define a mechanism that allows the creation of a 3D scene within a browser using declarative primitives or a programmatic API. the goal isn't to fully render scenes, it's simply to gain the ability to include a 3d resource in the page semantically. heavier solutions to render scenes already exist.
- bhhaskin 5y ago
  Seems already possible using a custom web component.
  - oneplane 5y ago
    You can also just render a complete OS in a canvas using wasm. Heck, why use the browser at all, just let them download a custom binary... You see where this is going right?
    - silon42 5y ago
      Mistake was made when adding Javascript.
      - southerntofu 5y ago
        So true. I'd be curious about developing modern web standards without JavaScript. I'm aware of gopher/gemini but somehow i like the semantic aspects of the web.

gfxgirl 5y ago

The problem is no feature set will meet even 5% of the needs of most devs. Maybe you'd like to display a "model" of a city. Oh, too big, needs to be streamed, LODed, etc. Maybe you'd like to display a "model" of a forest. Oh, well, you need a terrain renderer that dynamically generates geometry from height data plus you need a specialized renderer to render the grass and bushes else the frame rate will be 1fps. You'd like to display a "model" of Waikiki Beach at sunset and you'd like to use a water shader with a sunset and reflections. You'd like to display a "model" of the Los Angeles mountains as viewed from downtown Los Angeles, complete with atmospheric ray scattering to convey the air quality. You'd like to render a fur covered animal and render fur, not just a texture. You'd like to render a "model" of a person with realistic hair. You'd like to render a "model" of wax candle with subsurface scattering so it actually looks like a candle. You'd like to render a "model" of camera lenses to explain refraction so you'd actually like them to refract. Engines like Unreal and Unity let you change the way they render because every situation requires different solutions. No generic "render a model" covers rendering all models. An API like WebGPU/WebGL lets devs add what they need. Oh, you say, we'll just add features to cover those use cases. Now Chrome will have features A,B,C, Firefox, A,B,D, Safari B,E. That will be hell for devs. An API lets people write libraries with features they need that work in all browsers. They don't have to wait for the magic day N years from now that all browsers finally add the feature they want. Further, people will keep requesting non-3D features "I want to have an <input type="text"> in my scene". "I want to have a <canvas> in my scene" that I can draw on in realtime. "I want to have a model that displays a <canvas> in my model so people can draw logos on their avatar's t-shirts". I want to play sounds in 3D from specific points in my model, etc. until this "model tag" has all of HTML and all of JavaScript inside Again, this is all better solved with APIs instead of trying to cram more and more and more features into a single tag. > The other challenge of doing everything yourself is that code is stuck in time. It's going to get very minimal benefits from browsers and devices getting better over time, it won't get native UI changes - in 5 years it'll look very dated, if it's still accessible. And neither will a model tag. In fact it will be worse. First off, when I put a model on my page, I want it to look they way I or my artist created it. I don't want it to change over time based on someone else's idea of how it should look.

dmitriid 5y ago

sam0x17 5y ago

Yeah I actually agree -- this is very in line with the semantic web and is in many ways is a much more elegant proposal than Canvas (though I love canvas). This will make it much easier for devs to embed a 3D model in a page without sideloading all of three.js or similar monstrosities. It will also enable 3D model search engines to more easily find models on the web because of the semantic <model> tag.

brundolf 5y ago

My first thought was "this probably wouldn't work for games, and other uses of embedded 3D content are pretty niche" But then I thought, maybe they're niche because something like this doesn't already exist

pphysch 5y ago
3D is a poor choice for many visualizations because when it is rendered in 2D, information is hidden behind the model being transformed over time (either manually by the user or via automatic rotation, etc). IMO it should only be considered if there are challenges with flattening the data in question. For example, if the data represents an actual scanned 3D object. On the other hand, rendering arbitrary data as "3D" models is usually a cute waste of time. There are much more effective ways to explore and analyze it.

phkahler 5y ago

>> But wow you gotta get a lot of JS slapped together to just get something rendering. Or you can just model your item in solvespace (or link an STL file) and export it as HTML. Done. https://solvespace.com/index.pl https://solvespace.com/index.pl Examples: http://m-labs.hk/software/solvespace/ http://m-labs.hk/software/solvespace/

leppr 5y ago
> WebGL export using Three.js, which is how the interactive models on this page work
- phkahler 5y ago
  Yes, it does the slapping together for you.

fluxem 5y ago

Instead of spending time on the new vague proposal, maybe Apple should spend time supporting existing web standards like WebGL 2.0 by default (instead of hidden flags).

likeclockwork 5y ago
Agreed. This proposal makes the Safari sandbagging even more apparent.
alanwreath 5y ago
This ^^ I’d be surprised if Apple has any new learning to offer or if they have surveyed the landscape and decided this is the way to go.
galad87 5y ago
WebGL 2 will be enabled by default in Safari 15.

Impossible 5y ago

It makes a lot of sense to me as well having seen code for model viewers using WebGL. Before gltf, (relatively) standardized PBR materials, etc. it kind of made sense to just give people WebGL and tell them to figure it out. Also WebGL clearly was designed for browser games and game engine ports where it makes sense. As 3D models become more common, having robust fast implementations, standard controls, etc makes sense. As long as WebGL/WebGPU interop is good so it's possible to customize materials or still use model loading (if you want) but do your own draw calls I think it's fine

deleted 5y ago

[deleted]